Agile project team values and their embodiment in actual practice are highly subject to personal interpretation on the parts of practitioners, and thus necessarily suffer criticism for its wide-ranging variety of acceptable variations, all claiming to be agile. So a significant percentage of projects that claim to be agile, yet not adopting all of the Agile Manifesto values have at least themselves to blame when they do not produce the results promised and hoped for.
Those projects aside, even considering the projects that are faithfully adopting all of the agile values (early and continuous delivery, welcome change, deliver frequently, daily multi-stakeholder collaboration, support and trust motivated teams, face to face conversation, working software, sustainable development, technical excellence, simplicity, self-organizing teams, and continuous improvement) still often meet with less than ideal results. It’s useful (and necessary) to ask “Why?”
Agile (and Scrum in particular) rely heavily on direct interaction between the business users and the developers. In most projects, it is not possible to get direct interaction between the user communities and the developers, due to a variety of factors.
It is often necessary for someone (typically designated “Product Management” in the old dictionary, but “product owner” in the new) to step into the team interactions, to represent the “customer”.
Done well, this of course has many advantageous benefits.
- Customers aren’t bothered to spend large amounts of time with product development teams
- The PM / PO can distill the multiple wants and desires of a large user community and arrive at the crystallization that is the core of what the community appears to be asking for, but in different ways and words
It is also quite possible to perform this role poorly. In such circumstances, we often see these questions asked:
- “What is the customer really doing with this feature?”
- “How often is this done?”
- “Is this more important, or is that?”
- “Is there a way to cut back a little on this fancy feature, so that at least the user / customer is happy, without taking another 2 months of development time?”
- “My design had to change this way; what customers are affected?”
- “How much business is the company going to get with this feature?” and of course the related “If I do it this way, how much more (or less) business will the company see?”
- “Where is the customer when they are doing this?”
These questions reveal a lack of certain customer understanding among the development team. It is not sufficient that one member of the team understand these points (usually the PM or PO); it is often not possible to predict when such information can be useful and critical in tradeoff analysis decisions, many made daily by each product development team member.
Therein lies the key omission of Scrum (and most other agile methods): The backlog of user stories are taken as a starting point. They are not examined for their “quality”, “completeness”, “cluefulness”, budget impact, etc. The user stories are assumed “good”, and used as an “input” to the Scrum process.
[These thoughts are work-in-progress towards a white paper Jeff McKenna and I are collaborating to produce. More tomorrow – Sam]
Sam Hahn
