Applying the Agile Manifesto in Practice

Just today I came across a post referring to the agile manifesto. We have it framed on the wall just beside the door to our office. It usually doesn't get much attention.

We started a new sprint yesterday and a fellow team member was giving out about another (non-scrum) team regularly changing the database schema which we share. It doesn't happen often but when it happens it usually breaks our continuous integration build. My scrum team is a small sub project as part of a bigger project. We're basically developing a set of components for a specific customer. Most of the components work automatically in the background and process data relevant for the customer. In our sub project we're developing a multi tiered GUI client based on the Rich Client Platform and we're basically the only agile project in the entire project. The only interface to the other projects is a massive database.

Anyway, back to my ranting colleague. I was discussing with him and the rest of the team if it's worth putting this on the impediment list but the tenor was, 'well, uhm actually it's not that bad but in the last sprint we had this happening two times and it doesn't really fit into the agile process. If they want to change something they should tell us and we can plan it into the next sprint'.

This didn't sound very much like scrum to me. 'They' and 'us' is always an indication that something is wrong with communication. And I can't imagine the other teams being happy about waiting up to two weeks before we can integrate the system. So I remembered the good old agile manifesto and there was the solution, based on two of the four principles:

Individuals and interaction over processes and tools - talk to the guys, we're all working on the same thing. The customer doesn't care that we have multiple projects. Even though we have a agile process based on scrum, talking to the individuals is much more important than following the process by the book. It's much easier to just talk to the other folks and ask them to inform us whenever they plan to change the shared database schema so that one of us can change our persistence layer.

Responding to change over following a plan - change in the form of changing database schemes is apparently necessary in the entire project so the best thing is to 'embrace change'. Ok if it really is stopping somebody in the team from working it should be put on the impediment list and resolved soon, but this isn't really the case. It takes a minute or two to implement the changes necessary to make our software compatible to the database changes.

I thing this is a very good example where going back to the agile manifesto was a good idea. No need to discuss a lengthy process of applying database changes nor any tiring email discussions. Being agile and pragmatic works :-)

From http://coffeespawn.blogspot.com/