We have a few projects on the go around the country at the moment. In most cases I get an opportunity to view their burn-down charts on a daily basis and its interesting to understand the reasons why a project might appear to flat line in terms of progress. Of course an automated burn-down chart is just the beginning of a conversation to help understand the actual progress on a project.
There are really two or three common reasons why a development project appears to slow down:
- Architectural challenges forcing some re-work.
- Someone forgetting to actually update work items which then impacts the reports.
- External impediments that the team needs to deal with.
It is the job of the Scrum Master to recognise the cause of team impediments and work with various stakeholders (including the team itself) to resolve them. The first two reasons are usually easily overcome. Architectural re-work is a natural consequence of evolutionary design, you just need to make sure that you aren’t gonna need it (the YAGNI rule).
The second option is really about team education. In fact I find it harder to explain to experienced agile/Scrum team members why it is a good idea to keep the electronic representation of their records up to date. It ultimately comes down to extending the reach of your information radiator. Walls are great, but for very real commercial viability reasons you need to be able to see this information remotely.
The third reason is the hardest to deal with. External impediments on a project often fall out of the realm of direct influence of a Scrum Master, and sometimes even the product owner. When initiating any project, regardless of whether you are practising agile or not, you want to make sure your external dependencies are falling into place ahead of your development effort. Otherwise you can find yourself in the situation where you are all stocked up in terms of team members, but can’t supply enough work for them to complete because of the blockers.
In a world were we treat people as “resources” it is very easy to think that you can just turn off the tap, but that has a real impact on vendors, and if you are using contractors, their income. If you do find your burn-down flat lining here are some of the things that you can do:
- Reprioritise work so that the external dependencies are no longer blocking.
- Assist the external dependencies in delivering if possible for the “common good”.
- Get a commitment for when the external dependencies will be unblocked and then perhaps try and get a smaller project completed with the same team.
- Suspend development (but this should be the last option).
Good application architecture can really help avoid blocking on external dependencies. You can mock out your external dependencies and simulate them for as long as necessary. The trap here is that you do need good examples of what those external dependencies will be returning to you if they are some kind of API.
Just some random thoughts about the impediment blues.