I have been struggling with how to improve our development team output lately.
We have managed to get 20% to 40% faster with better quality over the last couple of quarters so I am pretty happy with that. We have flip-flopper (er experimented) with better requirements and modeling before a sprint or lighter up-front requirements with more time for collaboration and “OODA Cycles” within a sprint.
I asked the team what which we should do more of next, now that we have experience with different approaches that work for us.
This is what one of our scrum masters came back with:
Can I pick a 3rd choice, clarity in scope (which ties to requirements) before the start of the sprint.
It would be best if we would be able to understand the scope, clarify what needs to be delivered, and narrow down the scope should the scope be too huge as we have a dateline to hit.
Once the scope is clear and understood by the team, requirements would the fall into place, and the team can move forward quickly. However, collaboration during the sprint is still needed because there may be things that we somehow had not foreseen, and thus this would require the team and PO to work together to resolve certain issues.
I thought about my previous projects and realised that this is actually the essence of agile for me:
- Lock down a short period of time, clarify the scope you think you can probably do in that time and then let things fall into place.
- Then realise that unexpectedly good and bad things will happen and rely on the collaboration of the team to get you the best outcome possible from there (rather than more advanced planning, more hours, better tools or other hoped for factors).
So I defer to my learned colleague on the subject of project management. I will get back to blogging on the dark arts of office politics for my next article.