Agile Zone is brought to you in partnership with:

Tom is a software engineer currently working at Plath GmbH in Germany in the field of radio reconnaissance. His main focus lies on Java, JEE, web clients as well as rich clients such as the RCP. He has several years of experience with software development with Java and various frameworks and likes to work in agile teams. He is a strong supporter of the agile community. Tom is a DZone MVB and is not an employee of DZone and has posted 2 posts at DZone. View Full User Profile

Applying the Agile Manifesto in Practice

  • submit to reddit

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 :-)


Published at DZone with permission of Tom Meier, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


James Sugrue replied on Fri, 2008/12/12 - 9:24am

Great post Tom. As I mentioned on your blog, I'm sure we're all getting too hung up on how to get a process working and forgetting the real principles behind the agile manifesto. If we kept referring to these principles as best practises for working, we'd have a stronger industry. But I think we're getting there!


Tom Meier replied on Fri, 2008/12/12 - 10:08am in response to: James Sugrue

Hopefully! Understanding the meaning of agile development is an important step towards improving software quality and delivering on time. I've seen processes that were labeled as agile but actually were very far from it if you compare the process against the principles of the manifesto. Cheers to anyone signing it :)


Joseph Bradington replied on Sat, 2008/12/13 - 7:33am

Do you have a customer (product owner)? Did they want to wait?

Slava Imeshev replied on Sat, 2008/12/13 - 5:48pm



Good post. I have a question - have you tried to understand in wich ways the changes to the db by other teams break your stuff? Is it possible that your part is over-coupled with the db schema? 

My solution to this problem so far has been keeping the DB schema and test data sets in a version  control system. Whoever makes changes to schema gets to run a fullclean build and tests before checking is the changes. If the changes break something (your project in this case), the owner of changes gets to fix the breakage before check in.

DBUnit is a great helper when it comes to maintaining test datasets.


 Slava Imeshev

Cacheonix - Distributed Cache for Java



Tom Meier replied on Sun, 2008/12/14 - 12:54pm


Yes we do have a customer and product owner. As long as the planned stories are done at the end of each sprint everything is fine. The thing that was causing problems here was outside our scrum team, due to the fact that the other team(s) don't use scrum or agile methodologies at all.



Our application is very strongly coupled to the underlying database, something we can't change soon. But your suggestion on using dbunit as a mechanism to automatically enforce compliance is really good and I'll discuss that with the team. Constant improvement is good :)

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.