So far, we’ve discussed learning and value as benefits of agile. Now we turn to a more human side: satisfied stakeholders. Agile methods provide multiple roads to satisfaction for customers, users, business people, bureaucrats (okay, maybe not _all_ bureaucrats), team members, managers, shareholders, and interested passer-by. There are three primary mechanisms by which this occurs: engagement, trust-building and feedback-control. [UPDATED: added link to explanation of Commitment Velocity]
There are so many different stakeholders for any given project or work effort, it is impossible to make generalizations that apply to them all. This is one reason why methods such as Scrum do not define any roles for the stakeholders. Nevertheless, as a concept, stakeholders are important people to consider when thinking about an agile approach to working. How is this method going to improve the satisfaction of our stakeholders?
Some stakeholders are satisfied simply to be involved, to know what’s going on, to be part of something that is progressing. They have no need for specific results or specific contributions. Rather, these stakeholders might be looking to learn, trying to increase their influence, or simply curious about the work being done.
Agile methods provide improved engagement for these stakeholders using two simple mechanisms: visibility and frequency of delivery. Visibility comes in that anyone is welcome to come to the demos, to walk through the team room, to examine the burndown charts or task boards, or simply to ask questions of the team members. Frequency of delivery through short iterations gives a stakeholder the opportunity to see progress (or change) on a regular basis. This visible change satisfies engagement simply because of the potential it represents: hope for the future, opportunity to influence.
Another set of stakeholders are more concerned about results. And not just any results, but reliable, predictable results. Results that you can depend upon. Agile methods are ideally suited to help these stakeholders. The visibility, capacity measurement and commitment aspects of agile methods all help these stakeholders come to understand, rely-upon and ultimately trust the work of the team and the organization.
Here there is a substantial pitfall. There are a few agile practices that _must_ be put in place and followed rigorously in order to develop this trust. First, the team must keep a consistent time box for both duration and effort of work. Every iteration or Sprint must be the same amount of work time. Secondly, the team must use estimation and tracking of tasks that is compatible with “commitment velocity“. Thirdly, the team must use iterations short enough that these stakeholders don’t get frustrated waiting for the commitment velocity to stabilize. Fourth, the team must get it’s work up to a level of quality where defects are rare rather than expected. Finally, the team must be protected from interruptions. Don’t forget: two hours can waste two weeks!
All this is not easy, and doesn’t happen quickly. Trust is a deep and important quality for both people and organizations so it is worth the investment.
Then there are the contributors. The people who, for various reasons, some legitimate, need to make their mark on the work. This group should include the team members themselves! These stakeholders are interested in providing input into the process, seeing the results of that input, and then being able to have another chance based on those results. Business people want to see the results of their work in the marketplace and use those results to get better. Users of software, consumers of media want to have a say in what the next version looks like. This is the level of active engagement.
Agile methods provide opportunities for active engagement, for feedback and control, through the backlog or queue of work, through the demos, through participation in the team’s discussion about the work, and through the visibility of seeing their contributions take effect in “real time”.
Now control is obtained through the specific rules of engagement in one’s particular agile method. In Scrum, this is through the role of the Product Owner and the Product Backlog, the daily Scrum, etc. Each agile method has a defined set of practices and guidelines about how ideas, suggestions and criticisms are handled. Fortunately, those mechanisms are oriented around visibility, adaptability and speed so that frustrating delays in seeing results are rare.
In some methods, team members are ignored or downplayed as stakeholders. In many agile methods, the importance of the team’s well-being is given high priority. Agile methods reduce micro-management, reduce command-and-control management, reduce shoddy workmanship. Agile methods increase the need for creativity and problem-solving, the level of responsibility, support an honest working environment, increase the chances of delivering something that will actually be useful (and used), increase the challenge without causing “death marches”. All that said, agile methods are not for everyone!
Agile Benefits: Rapid Learning
Agile Benefits: Early Return on Investment
Agile Benefits: Satisfied Stakeholders
Agile Benefits: Increased Control
Agile Benefits: Responsiveness to Change
Agile Benefits: Summary Article