Tuesday, 10 July 2012

Tomorrow's Retrospective Experiment

I stumbled over a videoblog on YouTube over the weekend, Improve your Team Agility in 10 minutes. The main idea on how to improve agility is...(drum roll)... have a retrospective.

One idea that the presenter suggests is this: print out the agile manifesto and the principles of the manifesto. During your retrospective,  talk through them, then give each member of the team 2 red dots and 2 green dots. Get the team to swarm the printout of the principles, adding a green dot for what the team does well and a red for what the team needs to improve. Then analyse the results and see if there are any ideas for improvement.

Some rules that I'll be using are:

  • We need to read and think about the principles before the retrospective;
  • The green and red dots are to represent what the team does well/badly, not any individual within the team *;
  • We should at least try to explain why we chose to dot a particular principle;
  • The dotting is done en masse, so nobody is influenced by previous dots;
  • We don't have to use all 4 dots.

* I tweeted about this experiment today, and it sounded like it was to root out an individual in the team who wasn't agile enough and do away with him/her, like Piggy in Lord of the Flies. The point of the experiment is to improve the team by making the team realise what it needs to do better, not by culling its weakest member!

Monday, 2 July 2012

Yes to Keystoning, No to Branching

The Agile Environment

I have worked in my current job for nearly a year now. The R & D team's approach to development is as agile as possible; limiting work in progress, close collaboration between developers and testers, pair programming (or at least, peer code reviews), TDD, small checkins, continuous integration, collective code ownership, releasing to production quickly and often, reducing the feedback loop, scrumban, continuous process improvement.


The release schedule of our main product is every fortnight; peripheral packages are released the week when our main product isn't being shipped. This means that sometimes our product ships with part-completed (but NEVER untested) features in it. These part-complete features are generally invisible to the user by their nature, sometimes a new database table, sometimes a new repository. These changes are designed to be used by the customer only when the keystone is deployed. As the name suggests, this is the final piece of the feature that allows it to be made visible and used by the customer. It's usually the UI component, but could also be code that's enabled via a config switch.

No Branch, No Merge

In the year I've been at the company, I can count on one hand the number of times we've branched the source code. Each time we have, it was to apply a hot patch to a release. We don't branch the code for concurrent feature development; everyone checks their code in to main / trunk. One reason for this is to avoid the all-too-common 'merge hell', trying to keep each branch up to date with the others' changes. If the code is branched and e.g. a 6 week feature is produced, there could well be thousands of code changes to merge, per branch, with the very real possibility of hundreds of merge conflicts. I have been responsible for merging releases of source code into a main branch, and it is not easy and it's certainly not pleasant. But most of all, it's not necessary.