Scaling Agile initiatives is hard. Retaining the focus and effectiveness of the initial small successful projects is an elusive and often unfulfilled goal when transitioning into enterprise initiatives. This article reports what we are seeing from the field as we find ways to improve user story development, Acceptance Test Driven Development (ATDD) and Test Driven Development (TDD), release planning, iteration planning and delivery...
as Agile efforts scale.
We'll start with the a means to the end of Agile scalability, the Focus Story, and the value this practice brings to Agile growth efforts. A focus story is a simple, high level statement containing what needs doing, who is involved, and a concrete example to measure getting the job DONE. How I came to this definition will emerge as you read. This tip gives some background on what needs a Focus Story fulfills in Agile Efforts that are scaling up.
This series of four tips was germinated in my short blog post, Focus Stories – Is Your Story Big Enough for the work you are doing?, which caused a great number of irritating ideas and observations to fall into place. The next installment covers how the Focus Story serves to align multiple teams sharing a common Product Backlog by providing guidelines for common goals and objectives, a tangible statement of DONE and a timebox in which the story needs to be accomplished. The third part will discuss how the focus story aids in organizing the planning and developing of test, development, and release approaches. The final installment will tie all of these together so that a Product Owner and Stakeholder can manage change in direction in a comprehensive manner for a large effort.
Focus Story origins
The Focus Story came about while facilitating retrospectives for projects that were transitioning from small successful tactical efforts into large complex enterprise programs. As they grew in size and complexity, they lost focus and effectiveness. Out of control, these projects slowly spin into the earth! The anti-pattern that emerges is a steady increase in the frequency and the priority teams gave to certain types of retrospective comments with themes such as these:
- "No shared vision of the product;"
- "No agreed to definition of DONE;"
- "Conflicting architectural/application/ development goals and paths;"
- "Management indecision;"
- "Scope Creep;" and,
- "Loss of Agile Principles."
The attempts to address these issues by the team, Product Owners, stakeholders, and management also had patterns that repeated. Initially they agreed to resolve the concerns in those themes but after repeated lack of improvement, confusion and dismay set in and they turned to the familiar project management muscle memory and the use of conventional support to fix the Agile effort.
Problem Indicators in scaling Agile
Certain indicators are predictors of lack of focus and effectiveness. The indicators to watch for are as follows:
- Meetings get longer and more frequent with no resolution;
- Determining DONE at the task level becomes a major impediment in planning sessions;
- Pieces coming from different modules of development do not fit together; and,
- The conventional mindset you have been struggling to win over sighs and goes back to its safe place, waiting for the Agile fad to die.
The pain endured extending Agile practices into the enterprise can grow to cover both ends of your spine. It can even be the end of Agile, as you know it. Why? What makes scaling Agile so hard? At the root is the fact that the larger the effort, the harder it is to keep focus on what the value you are delivering is, communicate that value focus and retain value consistency across larger groups of people.
So let us ask a hard question. Is scaling Agile or any collaborative methodology a fool's errand? Can anyone really do big things in a collaborative model? Is this slide into entropy inevitable or is there empirical evidence to the contrary? Consider the impact of this single sentence, spoken by President John F. Kennedy on May 25, 1961:
"I believe that this nation should commit itself to achieving the goal, before this decade is out, of landing a man on the moon and returning him safely to the earth."
It seemed to me to be a perfect user story. It has a user role --"this nation" – and an action or goal "of landing a man on the moon." Also, it has a very well-defined definition of DONE: "returning him safely to the earth." However, what a story! What an epic! What a way to get a nation, and a world, to focus. However, it is not a User Story because it also contains a time box of 10 years "before this decade is out" that starts the clock ticking.
Where the definition of a Focus Story emerges
You could say this is just about all that any program needs, but it is all an Agile program needs to begin producing value, without having all the details worked out. Why? In Agile, User Stories can be reviewed quickly and efficiently to see if they meet minimum standards. Using the "man to the moon" as an example, the first thing you have to do to get a man safely back from the moon is to first get them there safely. That requires they be launched safely and are equipped to survive getting back safely. Statements like this flow because of the focus on what has to be DONE and what makes up the criteria of a successful DONE. Stories that do not provide an operable definition and criteria of DONE are put back into the backlog or returned to the requestor for more information.
In the next installment, we will discuss how the Focus Story's ability to shape User Stories aids in creating releases, backlog priorities, and in discerning the ability to ascertain a story's capability to support DONE.