Scrum or Kanban? Should we estimate using Story points? and if those estimates are clearly wrong once we start work, should we re-estimate them? Should the PO attend the retrospective? Design Sprints? Technical Product Owners and part time Scrum Masters…? the list of questions goes on and on. This is my life, fielding an endless stream of questions from well-intentioned inquisitive people looking to improve their lives and the lives of those around them.
The answer to all of these questions is the same, always the same, “It depends”. Most questions I am asked are focused on the practices that teams or individuals undertake within some framework of Agile delivery, so these are questions of process or tooling; usually HOW or WHAT questions rather than WHY questions.
Dan North neatly explained a lot of Agile execution with the neat paradigm of
Practice + Context = Behaviours
“Agile is a culture not a process” – another soundbite, this time from Jeff Patton, and the point is that what matters are those Behaviours, that Culture. The Practices, the tools and processes that we employ, are being used to try to encourage those Behaviours that we are searching for. The deep difficult WHY questions are about these Behaviours, the HOW and WHAT questions are more typically on the Practices.
How to use the practices is therefore dependent on the context in which they are being used. Context is critical, the context is also unique to your situation, and it is always changing, as a result the answer to those HOW and WHAT questions will always be different as the context is always slightly different.
One of the dimensions of explanation used with Cynefin are the concepts of Best, good emergent and novel practices. Complicated situations where context is predictable can employ Good practice, but in complex situations such as a team of people working together to build new software, then Emergent practices are favourable, which imply emergent responses to questions – that usually start…. It depends!
The downside of this is that discussions with Agile coaches can be very frustrating, those that see the role, and often by association the software delivery process, in the complicated space will find that they never get a straight answer. The coach will be seen as vague, elusive and non-committal.
Coaches have a responsibility to ensure that they are not seen in this light, to leave the situation in that state is to undermine their own capabilities because this damages trust. We should never say just “It depends”; it should always be followed up by some balanced contextual reasoning. Asking the opinion of the questioner is typically a good approach, it also puts the questioner into space of owning their own processes and practices, avoids the coach unwittingly doing the thinking for the team which leaves them open to adsorbing accountability and slowly disempowering the team.
Most coaches will agree with the sentiment in this article, as to whether it is useful to you, well that depends…