A phrase heard often in agile development practices discussions is "let the product lead." Applied correctly, these four words powerfully focus an agile team's energy directly on work that provides the highest business value. Traditional engineering practices that focus on process often divert a technology team's energy away from quick delivery of business value, and toward design of infrastructure and architecture.
Deep focus on technology decisions breaks the line-of-sight with business goals, creates opportunities for over-engineering, and requires complex tracing activities that ultimately slow the process. By focusing on implementing working software quickly, agile methodologies provide feedback loops to constrain the end result so that no effort is wasted on unneeded features or over-engineered architectures and frameworks.
By quickly delivering working software, the agile approach makes line-of-sight with overall business goals achievable and visible. This article spotlights best practices which result in an agile team keeping its “eye on the prize” where the prize is a pleased customer, receiving high-quality capabilities delivered quickly in prioritized small increments.
I was fortunate enough to attend a great team-building course led by Dan Lyons, World Gold Medalist in rowing. [1] This creative and entertaining class used experiences from successful 8-person rowing teams to get across several key attributes of high performing teams. The class broke down eight fundamental behaviors that were common to winning teams. Not surprisingly, all eight behaviors are characteristics found in a well-formed Agile team.
Plan With Vision
The first of twelve Principles behind the Agile Manifesto states that “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” [2] While customer satisfaction is a goal of any software delivery effort, it is difficult to keep as the highest priority unless agile or lean methods are used.
Legacy engineering approaches allow for the creation of infrastructure and documentation that have little or no direct line-of-sight with the end product. In fact, the line-of-sight must be forced into existence by abstract traceability exercises, which are difficult to understand and maintain, and slow down the emergence of the final product.
Agile creates an approach that allows organizations to be driven by delivery of working software. This is by definition the highest form of business value, provided that each delivery increment is properly staged and prioritized by the customer or product manager. Creating the high level vision and keeping it visible is a trait of a well-formed Agile team. It is not uncommon for the high level vision to be referred to as the “one big thing” (OBT).
Letting the vision drive the goals discovered for each iteration is another indicator of Agile success. One good practice to encourage this behavior is to start each iteration planning session with a visioning exercise to remind the team what the planned release is about, as well as the creation of a chart to capture the goals of the current iteration. The stories that unfold to describe the work during the planned iteration should all be enablers of the iteration goals. These goals later come in handy during the iteration review (Sprint Retrospective for Scrum), where the same chart can facilitate conversation on what goals were met and why or why not.
Keep the Prize Visible
Once the release vision and iteration goals are captured, they need to become visible (see Figure 1). Justas the empty trophy case served as a constant source of inspiration for the champion rowing team, an Agile team should be constantly guided by these visible goals. An effective agile practice is to display all work underway on an information radiator. [3] This is the perfect trophy case to display the iteration and release goals, and all the identified work required to implement the current backlog of business prioritized capabilities to be delivered.
Figure 1: Example of Information Radiator keeping the Release amp; Iteration Goals visible
Reflecting again on the first Agile Principle, "early and continuous deliver" implies short iteration cycles. In fact, iterations should be constrained to be as short as feasibly possible. Ten business days is optimal, and helps emphasize (and make visible) the amount of effort required to producethe most visible (highest priority) work. It's not unreasonable for a software engineerto estimate and commit to 10 days of effort. Contrast this with having to commit to a large program with all planning attempted up front.
Keeping iterations short works because feedback, always guided by release and iteration goals, constrains the system so that it converges to the solution in the most efficient way. Shorter sprints help bring sharp focus to prioritized work underway andilluminate effort required and business value created. Both of these quantities can be measured and displayed on the Information Radiator using the so-called Burn-down and Burn-up charts which together provide real status on effort remaining and business value delivered. [4]
Keep the Product Manager Engaged
For this article, quot;product managerquot; refers to the clientwho defines and assigns business value to the capabilities being developed by the Agile team. In Scrum, thisrole is known as the quot;product owner.quot; It is critical that the product manager be engaged directly with the Agile team, and practices described in this section help fully integrate the product manager with the Agile team.
A good practice to engage the product manager is to set up a quot;product backlog boardquot; in a highly visible place near his or her office. This gives the product manager a place to post big ideas and unfold high level stories as the priority grows. Creating this board jointly with the product manager gives the Agile team a great opportunity to teach the art of writing stories. It also provides a great brainstorming area for the product manager to play what-if games by visibly sorting the stories into priority order. The product backlog board ideally becomes the source of stories for iteration planning sessions.
Mary Poppendieck cautions against the product backlog becoming an overloadedqueue (waste due to waiting in Lean terms), and I agree. [5] The purpose of the product backlog should not be to blindly pile up work to be completed in the future. It is best viewed as a visioning area where the product manager can stage prioritized work ahead of the next iteration planning meeting.A best practice is to have "epics" (big ideas that break down into several stories) guide what is placed in the backlog, and only unfold the details when needed (see Figure 2).
Allowing the product manager to re-prioritize work ahead of the next iteration gives a real sense of the change tolerance built into the Agile approach, and reinforces that Agile teams can re-align as business needs change. Contrast this approach with the notorious change control process built into legacy engineering practices to slow the amount of change to original requirements.
Figure 2a:Example of a product manager's Product Backlog Board, prioritized left-to-right. Note that detailed stories appear at the left side of the board, staged for the next planning session, but only higher level stories are at the rightside of the board. This emphasizes just-in-time unfolding of story detail.
Figure 2b: Zoom-in of Product Backlog Board, showinghow Epics (white cards) guide thestory unfolding (yellow cards).
Poppendieck also raises a valid concern that the backlog should in no way create a barrier between the product manager and the Agile team. It is critical that the product manager participates with the Agile team in validating each story that is being worked in the current iteration. One best practice to promote this is to encourage the product manager to write the stories for (and with) the team. The result is that the product manager has a vested interest in seeing the stories that she wrote “come to life.” Another benefit to this story connection is that the product manager gets a real sense of the effort required to complete each story which greatly aids the iteration planning sessions. Most importantly, seeing stories completed that were authored by the product manager builds trust, which is often lost in large waterfall projects as the clients see only progress against a plan and deliverables until the end of the project.
Summary
This article has highlighted some approaches to leveraging visibility as a means to keep an Agile team's efforts aligned with business goals. These simple but powerful practices can help keepenergy focused on what matters most -- rapid delivery of business value. Table 1 below provides an executive summary of these suggestions and benefits.
Practice | Benefits |
Begin iteration planning with a vision exercise to get consensus on release and iteration goals. | Provides principles on which all effort (and stories) should focus. Also serves to facilitate iteration review (Sprint Retrospectives). |
Plainly display release and iteration goals on an Information Radiator. | Provides a constant reminder of why the Agile team is in existence. |
Keep a product backlog board visible and accessible to product manager's office. | Provides brainstorming and staging areas for high priority work that feed the next iteration. |
Encourage the Product Manager to participate inwriting stories. | Gives product manager a vested interest in the status of the stories and encourages him to come see status and validate the end result with the Agile team. |
Keep iterations as short as possible. | Ensures that energy is sharply focused on delivering business value. Helps constrain wasteful activities (like creating unneeded features). Makes it easier to estimate and commit. |
Table 1: Best Practice and Benefits summary
[1] see http://www.teamconceptsinc.com.
[2] see Principles behind the Agile Manifesto http://www.agilemanifesto.org/principles.html
[3] see “Information Radiator” Alistair Cockburn
[4] see “The Agile-V Balanced Scorecard Metrics”
[5] personal communications (with permission) with Mary Poppendieck, Author and Lean Software Development Expert ( http://www.poppendieck.com/)
