Comments, Code and Qt. Some words about the wonderful world of software engineering


Non-sterile Agile: Distributed teams

I call this post non-sterile agile because I feel that once agile principles are let loose into the corporate world agile development changes its nature and face. In this (and hopefully upcoming posts) I will try to go through some of the ideas and experiences I have about agile development in the corporate world. Agile development embraces communication over written documents. This we learn already from the agile manifest. Good communication is best achieved by talking to each other. Then you can really describe the problem. You can ask direct questions or even draw something on a whiteboard to make things really clear. If all relevant people sit next to each other working on the same project, there is no need for design documents, architecture descriptions, UML diagrams and such when you can go and ask the person next to your seat if something is unclear. Likewise you wouldn't not need send emails and wait for replies which will only hold you back while you wait for the answer. Sprint planning meetings and retrospectives are the corner stones of a successful Scrum project. All people sit together for a day and talk together what was done and how to go forward. The customer is there who has a crystal clear plan on what to do next. The team can do ad-hoc backlog grooming by splitting too big items into smaller items that they can commit to. And so on. Agile development and Scrum project management especially are in my opinion the best software engineering practices we currently have. Don't get me wrong about that. But when Scrum hits the corporate world, some things are different which makes Scrum harder to make it work. These aspects require extra planning and organization from the ScrumMaster and also the customer. Take distributed teams in this case. In the real world, outside the beautiful gardens of the academic theoretical world of having all the good cases in your hands, you might not have all the developers in one room. This can be achieved in small scale, but how about larger IT projects. Or should we go as far as say that agile development only works in small (prototype?) projects? No, I would not go that far. In bigger projects you will have people sitting in different locations working on the same code.  In really big projects probably even on different time zones. In this case "going and ask the fellow next to my desk" scenario seems pretty far away. Even the simplest, but the most important, practice of Scrum is not self-evident anymore. How to gather all the members of the team for the daily standup meeting? Modern technology offers us many solutions for this; Skype, IRC, Jabber, Tandberg video conf, web cam and so on... But is the daily stand up meeting really the same? It can very easily become a situation where the team feels that they only report to the ScrumMaster because they have to. The team doesn't feel the real importance of this meeting anymore since it doesn't feel intimate and being one group driving towards the same goal. How to make daily scrum meetings feel like important sync meetings, for people to understand where the team is and where is it going in the sprint? This is in my opinion a very important question that impedes the team most when we talk about distributed scrum teams. It is so critical for the team to get into the performing mode and only then the team can hyperform. And this is in the end what Scrum is all about - the team to get into a mode where it feels unstoppable and take responsibility on its own to make software perfect and achieve the goals. I would go as far as claim that distributed Scrum teams can never hyperform due to communication overhead and lack of tight team spirit. The things get even worse when we think of how to do sprint planning meetings for a distributed team. Use the same communication methods as for daily scrum is the obvious answer. But the whole point of the scrum planning meeting is to be able to discuss efficiently and be able to get a crystal clear picture what needs to be done. In this case it is very important for the customer to have that crystal clear target (s)he can communicate to the team. This puts a lot of pressure on the customer to success in communicating the goal. If this is not achieved, the whole sprint can be a disaster before it even starts. Hence - even more risks on a distributed scrum team. Scrum is of course no silver bullet for software engineering. But I think it is the best we have. It will only make the evident problems even more evident but it will not solve them. In a distributed team the communication is always an issue. It's just even more important to have the goals clear (pressure on the customer, but also ScrumMaster to create good backlog items) and ensure the team knows its direction and no impediments occur and if they do, they are resolved (pressure on the ScrumMaster). Having good daily communication channels are so important for the daily working. For this I recommend IRC because it can be left on the background, you can create channels for group chat or have one-to-one discussions. Whenever the team cannot sit next to each other in the same room, you are sacrificing some parts of Scrum. Sometimes you don't have a choice, but just be aware that Scrum might not be as rosy as it sounds in some presentations in this scenario. Or at least you have to work somewhat harder to make it work and ensure you only have the best persons in the team. I currently work as the ScrumMaster for a development team for the third year while working as a software engineer in the team as well. I am a Scrum Alliance certified ScrumMaster. I have also done product owner duties and worked on backlog planning. I wrote my Master's Thesis on agile process assessment (link to Master's thesis here).

Technorati Tags: , , , ,

  • Good article! All this sounds very familiar:)