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.
6 thoughts on “Which is more important: clear requirements at the start or good collaboration?”
James, I agree with what you said, which is essentially an 80-20 approach. Get scope and requirements 80% clear/correct by following the right disciplines. The last 20% can take 80% of the time if you rely on formal process/disciplines, so I would tend to rely on people and collaboration in the team in order for it to happen more quickly. -Stephanie Owen (Strategy2Life)
Hey Strategy2life – yep I think when PMs get more experienced they start getting better at risk management and effective feature development through getting the most out of the crew rather than having to rely on a methodology.
I guess the real challenge is knowing when the 80% planning is done and how to get the team to collaborate. I guess that is why a good, experienced project manager can get so much done in a project and why projects are often so hard. I have often said I only hire lucky project managers from now on
I don’t think there is an excuse not to have good upfront planning, and continued good planning throughout the endeavor.
Hoping that one can “fix it in the mix” or “wing it” down the road is just asking for trouble.
The golf equivalent of that would be aiming more or less towards the green and hoping that you can play it from wherever it lands and succeed….
Most golfers know this is a disastrous strategy — one has to know the course, know where the hazards are, know which side to hit it on, etc.
That’s called playing the course. The alternative is to wing it and let the course play the golfer. Most golf course designers inflict severe pain on golfers who do it that.way….
So I’m gratified that ,more emphasis is being put on upfront planning, gathering requirements, mocks, all that….things that the agile industry has tried to paint as unnecessary. for too long
Thanks Post-agilist. I love the name, I bet it helps generate some passionate conversations with agilistas.
I agree we should alsways have good planning and that some (many I admit) agile project teams decided to go faster by dropping the planning and the understanding of what was needed (ie requirements). This has been a great source of revenue for me in rescuing doomed projects in the past 🙂
I may have a slightly different view on what good planning is though. If you want to win at golf you should definitely see the course before hand, learn the curves and traps and run through your game. Similarly in a complex technical project the more analysis you do, the sooner you finish (the the quicker you jump to coding a solution, the later you finish).
But in many projects I have been in, I have found that we are playing on a golf course that nobody has played on before. You can practice on what you expect the course to be like and you can plan your game (project) in great detail but in fact you cannot really know what will happen without experimentation. In this case I would factor in more iterative approaches with experiments, deferred commitments and deliberate attempts to learn and adapt as the project progresses, rather than detailed planning and then tight execution against the original plan. This is still good planning but it means that you have to replace detailed planning and prediction with disciplined experimentation and adaptation. Simply executing against what you thought should happen leads to very efficient failure
Well, of course, the golf metaphor only goes so far, but, what I’m saying is, and I agree with you that on unknowns you can’t nail the requirements down as much ahead of time however:
1) Agilistas use that as an excuse to never plan; many projects are more known than known yet many Agile teams go on about their business as if that is not the case
2) Even in the case of unknown, ultimately, it becomes known, and needs to be nailed down, whether it’s sooner or later
3) When playing on an unfamiliar course, it still makes sense to play to your (teams) strengths and hedge against their weaknesses — not assume that the course is a plateau that doesn’t require thought
Maybe the name bothers Agilistas; that wasn’t really the intent. The intent was to rename my nickname by function (Postagilist) versus just a vanilla name that noone has heard of.
Also, it somewhat stops some of the knee jerk “you just don’t get it” type bible thumping that Scrum Masters especially often throw at me; with this nickname they know I’m beyond it and don’t want to hear the bible quoted at me so it saves some keystrokes for everyone 🙂
I can’t really argue with those points. I also sometimes refer to Phillipe Krutchen as “post agile” because he keeps asking people questions like “What about your architecture – are you planning what to do with that?” and “What are you hoping to achieve … what will happen when you achieve that?”. They are not at all anti-agile but they do make people uncomfortable.