Day One.
Just configured Hudson to build my project. It was easy. After configuring Mercurial and Maven it was nothing more than triggering the build. I found an extremely helpful tool for maven projects, it is m2eclipse. It allows you to create Maven projects within Eclipse which is nice but for me the killer feature was the pom.xml editor!

Looking up dependencies is easy! Just add a dependency and m2eclipse will provide you a search. Start typing the dependency name and it will show you the results of its search. Select what you want with correct scope and you are done.
Now, time to get back to test-drive some features to my home experiment!
I’m on my winter holiday, Yay! I was thinking that I will spend most of the free time practicing my art of coding. I am not very familiar with maven, Hudson nor Sonar so I am planning to write a piece of software using all three of them.
It may seem odd that something as essential as maven is unfamiliar to me, but looking at my career it starts to make sense. I have been building software mostly with C and Perl in a legacy environment with in-house build systems so there has been very little use for maven. For continuous integration I have used QuickBuild and only scratched the surface with Hudson.
So, it is a good time to learn those tools now that I have some free time!
It’s getting closer and I am excited. We, meaning me and my partner in crime, have prepared close to 130 slides for the 2,5 day training. That may sound like a lot comparing to the simplicity of Scrum. This is not just a Scrum training. We are presenting our way of doing things. What has worked for us during the year and a half of transformation and what has not and what are the issues we are still struggling with. We present an example how it can be done.
First we will go through the idea of Scrum presenting the manifesto and principles of Agile. Then we will continue with the artifacts and roles present in Scrum process. We will have hands-on practices which will yield working agreements, definitions of done and a rough schedule for their sprints. Product owners will learn how to do release planning with Scrum.
During the second day we will concentrate on breaking down what work Scrum actually contains, what kind of work and objectives there is. We will have sessions for grooming the backlog and planning the sprint as well as for demoing the results of a sprint and having retrospectives, inspecting the past and adapting.
The half day will then be spent on visual management which aims to satisfy the upper level managements needs for seeing progress in some reported form.
But, then I have 5 hours just for myself. I will be giving a primer in Test-Driven Development. Being a newbie myself I hope that it will work out at least on some level and that I don’t screw it up :-P But that remains to be seen.
I also hope that I am able to affect these people and leave a positive mark in their minds. Hopefully some of my enthusiasm stays behind and infects them with a yearning for improvement!
Recently in my futsal practices, my side was taking a beating. I had absolutely no clue why. On paper our team composition was better than our opponents. We had one substitute enabling us to keep up a huge tempo. There shouldn’t have been any obstacles for us, we should have won majority of the short games we played. But no. We lost a huge majority of them.
The team consisted of our regular players, we knew each other well and play football together during the summer. But still there was something wrong and we were lousy. Later that night I thought about it and I realized what went wrong. We didn’t play as a team. We didn’t have clear rules how we play. We didn’t agree the intervals for substitution. We didn’t have tactics nor strategy.
We should have decided that substitution interval is short enough to allow enough field time for all. We should have agreed how we play, in what formation and what are our key focus areas tactically.
In other words we didn’t have clear agreement on how to play together. We were missing our working agreements.
Week and a half ago I decided that it is time to do something I haven’t done before. I volunteered to organize Scandinavian Agile 2010 conference. My application was accepted so now I am part of the organizing committee. Of course the main work of organizing is outsourced so our responsibility is to innovate and decide what will be the focus and the content of the conference.
My comfort zone was expanded my multiple square miles! I am eagerly waiting what will come out of this and I hope that I can contribute something to the conference.
I faced a situation where I wanted to develop locally at home but still keep the sources available for myself on other hosts. For example, I am currently developing a TDD primer slideware and I have a simple example code base for a coding dojo that I wrote here at home. I want to be able to continue it at work too and then be able to sync it with my home laptop.
The problem is that I don’t want to run a Mercurial webserver at home (no proper hardware, just an old T42) or use any commercial service like bitbucket. I can’t run servers at work either due to firewalls and corporate policies.
But what I do have is a shell! And it does have Mercurial installed. So, off we go to setup a private code proxy that I can use as an intermediate storage for my work.
remote> ssh user@remote
remote> cd ~/my-repos/
remote> mkdir project
remote> cd project
remote> hg init
remote> exit
local> cd project
local> hg clone . ssh://user@remote/my-repos/project
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 6 changesets with 29 changes to 13 files
Just remember that clone assumes path relative to users home directory (that’s why there was so short path on the command).
After the first clone I have to manually run
on the remote to make it aware of the changes. Now I just edited the projects hgrc file on the remote to contain
[hooks]
changegroup = hg update
Now it updates itself when ever I push stuff into it again. That’s it, now I can easily setup and share with myself any repositories that contain source code I want access anywhere.
Just ordered three new books to be put to my ever growing reading backlog (ie. a pile of books beside my bed)
I just joined the Agile Skills Project which aims to create a baseline
of the skills an Agile developer needs to have, including a shared vocabulary and understanding of fundamental practices.
I encourage you all the at least skim the contents of the project since in order to succeed with Agile you need to have a certain set of skills. I sincerely hope that this project succeeds and is able to clarify what kind of skills people should focus on when they aim to implement Agile methods. Practising Agile requires effort and skills in order to make it.
There has been even some pondering over an “Certified Scrum Developer” certificate that would actually guarantee some level of quality. See these interesting posts from Ron Jeffries and Uncle Bob:
Developer Quality! … and Certification?
Developer Certification WTF?
We work in an infinitely complex telco and service provider environments where it is extremely hard to keep up with the change. Our customers are driven by their user base which is as unpredictable as possible while the technological surroundings keep changing.
Thus they want their time-to-market to be extremely small. Despite the fact that we have solutions that are very flexible we sometimes struggle while trying to contain the changes. Year and a half a go we introduced Scrum in our R&D. Transformation is still ongoing but we have reaped some benefits of it. Primarily we have managed to reduce a lot of waste, gained clearer prioritization and started to build continuoud integration systems.
We have delivery departments that deliver the required customizations on top of our platforms. They face ambigious, and sometimes even non-existent requirements from the customer and try to cope with them. There is a constant flow of changes coming from the customers as they elaboreate their own business models. Until recently everything has happened under waterfall processes, not least because of the strict contracts based on phases of the delivery.
As part of the Scrum transformation the deliveries have started to use Scrum in the delivery projects. The project teams are constantly fighting in a cross-draught of different projects. The teams may abruptly be changed taking away all that was built so far breaking every single aspect of team building, one of the cornerstones of Scrum.
After following the deliveries for a while I have come to a conclusion that their environment is too chaotic for Scrum. If they can’t even keep a team intact over one delivery it is useless. But there exists another process model in the world of Agile that fits this situation perfectly and that is Kanban.
Removing the unnecessary sprint plannings from their environment and concentrating solely on a continous flow of feature and change request deliveries they could achieve much more leaner projects. Prioritize tasks everyday, place strict limits on the amount of tasks that can be under implementation at the same time. In other words control the chaos by limiting the work in progress.
Let’s say you have a team that is full of capable individuals who have started to bond. They are eager, wise and good workers. They have clear goal, clear stories to implement, well-formed backlog and proper tools. Is there something that can prevent them to succeed, to become a hyper-productive team? Unfortunately yes and a very common structural impediment.
Lack of autonomy. Without the power to influence their surroundings, tools, ways of working and so on, you are bound to end up with a mediocre team. Mediocrity, the enemy of good.
Enable your team by giving them the autonomy they need!
If you are in a managing position your sole duty is to enable your team. Draw the borders and let your team go. They are the best persons to decide how to achieve the objectives you give them.