I was fortunate enough to attend a great team-building course led by Dan Lyons, World Gold Medalist in rowing.[i] This creative and  {sidebar id=1} 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, however "DEFINE THE PERFORMANCE OBJECTIVE" speaks to Agile's ability to tie line-of-sight between daily activities and business goals. The illuminating example of leading with vision was a rowing team creating a place to put its medals for which it was training.  This ensured that the team was focused every day on what had to take place for the visibly empty trophy case to some day be filled with gold.  Having implemented Agile in both large corporations and start-ups, I've found that vision and visibility of goals are critical to ensuring that every task worked provides optimal business value.

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."[ii] 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).  Just as 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.[iii]  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. 

Reflecting again on the first Agile Principle, "...early and continuous delivery..." 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 produce the most visible (highest priority) work.  It's not unreasonable for a software engineer to 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 and illuminate 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.[iv]

Keep the Product Manager Engaged
For this article, "product manager" refers to the client who defines and assigns business value to the capabilities being developed by the Agile team.  In Scrum, this role is known as the "product owner."  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 "product backlog board" 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 overloaded queue (waste due to waiting in Lean terms), and I agree.[v]  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.

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 keep energy focused on what matters most -- rapid delivery of business value.  Table 1 below provides an executive summary of these suggestions and benefits.
 

Table 1:  Best Practice and Benefits summary

Guy Beaver is the Director of Software Engineering at Critical Point Group, and a Certified Scrum Practitioner.  Prior to joining Critical Point Group, he served as systems manager for an industry-leading mutual fund organization, where he presided over the delivery of the firm's Web applications for account opening and funds transfers. In this role, he successfully implemented Agile in a mature Six Sigma IT organization. Before that, he served as a software engineer for an application development company that was under contract to the NASA Langley Research Center. He was also a research physicist for the U.S. Naval Research Laboratory. His recent experiences include rapid delivery of enterprise web applications and leading the change to Agile in both large corporations and start-ups. He has over 23 years of software engineering and IT experience in several industries including DoD, NASA and Financial Services. He has published articles in several technical journals, and is currently writing a book on Agile leadership.

[i] see http://www.teamconceptsinc.com.

[ii] see Principles behind the Agile Manifesto, (http://www.agilemanifesto.org/principles.html)

[iii] see "Information Radiator", Alistair Cockburn, http://alistair.cockburn.us/index.php/Category:Information_radiator

[iv] see "Agile-V Scorecard", (http://www.agilejournal.com/content/view/274/)

[v] personal communications (with permission) with Mary Poppendieck, Author and Lean Software Development Expert (http://www.poppendieck.com/)

Trackback(0)

TrackBack URI for this entry

Comments (0)

Write comment

Show/hide comment form

Name

Comment

smaller | bigger

Subscribe via email (registered users only)

Write the displayed characters

Add Comment Preview