Category: Agile Concepts

Five Things You Must Understand about Agile Team Velocity

Agile team velocity is an often misunderstood concept that is prone to misapplication. This article sets the record straight.

Agile software development is the way we build software now. The general consensus on management of software development projects is that predictive planning approaches (e.g., Waterfall) are ill suited for the job. However, almost two decades after the release of the Agile Manifesto and the rise of Scrum as the most popular Agile framework, team velocity is still a point of confusion.

Some organizations are under the mistaken idea that they can “buy” Agile-Scrum software development services à la carte based on team velocities. Under this contracting model, service vendors offer prepackaged teams rated at some velocity. Based on that velocity, the organization could then pay for a certain amount of that team’s time to complete predefined tasks. This arrangement treats Scrum teams as plug-and-play units of development capability. This mentality is evidence of a fundamental misunderstanding of Agile and Scrum, of what teams require to be effective, and of the concept of team velocity itself.

What is Team Velocity?

The concept of team velocity is not officially part of the Scrum framework. It is a best practice for estimating Development Team throughput. More specifically, it is the rate at which the Development Team, in collaboration with the other members of the Scrum Team (i.e., the Product Owner and ScrumMaster), delivers discrete items of functionality that are finished, tested, and accepted during an iteration/Sprint. The Scrum Team documents requirements for those items as User Stories and tracks and orders User Stories in the Product Backlog.

Rather than simply counting the number of completed stories at the end of a Sprint, the Scrum Team determines its velocity by adding together story points from every story completed during the Sprint. Story points form the basis for determining team velocity. Calculating team velocity allows Development Teams to estimate the amount of capability (value) they can deliver at a sustainable pace during a Sprint.

Σ Story Points of Completed User Stories During a Sprint = Velocity

It is important to view team velocity results as data points along a trend, rather than as definitive stand-alone measures.  In other words, to understand how much value a Development Team is capable of delivering, we need to look at velocity results from the previous two or three Sprints to get a sense of whether the latest result is part of a trend or an anomaly.  Such anomalies often indicate issues requiring attention.

Like the concept of team velocity, story points are not part of the Scrum framework. The Development Team assigns story points to Product Backlog items (i.e., Epics and User Stories). Story points are heuristically-determined, numerical proxies representing the combination of perceived or estimated:

  • User Story complexity, risk, and uncertainty
  • Level of effort required to complete the User Story

This combination is often referred to as the “bigness” or “size” of a User Story. The Development Team estimates User Story points by “sizing” User Stories relative to each other. More complex User Stories typically require more time and effort to complete, thus earning more story points than less complex stories.

Story point estimation is not restricted to specific timeframes or meetings. It is part of a continual refinement of Product Backlog items by the Scrum Team that includes:

  • Adding, updating, or deleting items
  • Decomposing items into smaller items
  • Adding details and estimating story points
  • Ordering/prioritizing items

Five Key Team Velocity Concepts:

1.  Only the Development Team estimates story points with input from the Product Owner and other relevant stakeholders. They are not determined by a chief engineer or some other senior authority as an estimation exercise prior to the establishment of Development Teams and the appointment of Product Owners.

2.  Team velocity is specific to the team.  Velocity cannot be used as a point of comparison between teams.  Team X is not necessarily faster or able to attain a higher throughput than Team Y because they earned a higher number of story points during a Sprint.  The story points upon which team velocity is based are specific to the relative sizing performed by the team on their particular backlog of User Stories.

3.  A team’s velocity is the end result of many factors, including:
  • Individual team member productivity across the team
  • Team cohesion, collaboration, and effectiveness
  • Team skill set and experience mix
  • Level of programmatic support (i.e., the factors that fall under the purview of program management)
  • Empowerment and level of engagement of Product Owners
  • The team’s familiarity with the business domain, technology mix, and enterprise architecture
  • The amount of automation leveraged in building, testing, and deploying code

Thus, the makeup of the Scrum Teams and the environment or ecosystem within which they operate determine velocity.  Team velocity is ultimately a proxy for the overall health of the software development program and organization.  When team velocity stagnates or drops, the search for potential causes must be systemic as opposed to a hunt for individual culpability.

4.  It is normal for team velocity to fluctuate.  What should concern us are large fluctuations or downward trends in velocity.  Changes in personnel, technology, organizational structure, etc. will affect development teams in different ways and to varying degrees.

5. Improving team velocity is not the goal!  Improving team capabilities, practices, tools, and program support improves team velocity.  Focusing on improving velocity results in attempts to game the system rather than systemic improvement.

Conclusion

Scrum Development Teams are composed of people. People are not machines calibrated to deliver a predetermined rate of output. Teams need time and stability to gel into highly effective teams. Helicoptering Scrum Teams, even experienced ones, in and out of tasks significantly degrades velocity except perhaps for the most mundane and menial tasks (In which case, why employ Agile/Scrum at all?). Decades of reducing people to resources allocated across Gantt charts has led many to also think of Scrum Teams as abstract productivity units. Scrum requires much more of us.



Article Review: The New New Product Development Game

A look back at a 1986 Harvard Business Review article provides insight into the roots of Agile and its application.

No, there isn’t a typo in the title. 🙂  The title of this blog entry was taken (borrowed?) from a very interesting article published in the Harvard Business Review from January 1986.  Scaled Agile Inc. (the developers of SAFe) references it to make a number of points concerning how to best structure Agile teams.  In particular, Scaled Agile Inc. references the article’s assertion that:

  1.   The “relay race” approach to product development [i.e., Waterfall] conflicts with the need for speed and flexibility.
  2.   That a holistic or “rugby” approach [a la Agile] where, “a team tries to go the distance as a unit, passing the ball back and forth” better serves highly competitive environments.

The things that strike me about this article are:

  1.   It was published in January 1986.  A good 15 years before the Agile Manifesto was published.
  2.   All of the examples are product development efforts outside the software development realm:  Xerox copiers, HP printers, Honda cars, Canon cameras.
  3.   The fact that they likened the process to Rugby (a foreshadowing of Agile-Scrum).
  4.   The focus on self-organizing teams – A major item in the list of Principles of the Agile Manifesto:  “The best architectures, requirements, and designs
    emerge from self-organizing teams.”
  5.   Encouragement of contributor autonomy – A major component of the SAFe principle of unlocking the “intrinsic motivation of knowledge workers.”
  6.   Fostering of “Self-transcendence” – Similar to the concept of Ba: an old Lean term brought to new relevance in Agile-Scrum and SAFe circles.
  7.   Emphasis on “Cross-fertilization,” known in Agile as “Cross Functional Teams.”
  8.   The article’s concept of “Overlapping development phases” roughly translates into the Agile idea that SDLC phases (planning, analysis, design, implementation, and maintenance) should not be separate phases at all but should, instead, be performed concurrently within a specified time-box (iteration/sprint), on a small scope of work, with overall system scope accruing incrementally and iteratively.
  9.   The recognition that for all of this to work, we need management to change away from linear and static product development thinking.
  10.   The recognition that, “A different kind of learning is needed.”  By this they mean engineers need to have both deep skills and broad understanding to be effective in cross-functional teams that execute in less structured environments:  “T-shaped skills.”

I recommend organizational leaders and managers read the article to gain perspective on the thinking that led to Agile, so they may better understand how to adopt it within their respective organizations.  Engineers of all disciplines and current Agilists will also benefit from a better understanding of how real cross-functional, self-organized teams are formed and behave.



Down with the Agilistas!

Are you an “Agilist” or an “Agilista”?

I consider myself an Agilist. I have been working within the Agile software development realm in different capacities/roles since 2008 and I whole-hardheartedly believe in the potential of Agile and Lean to dramatically improve, not just software/systems development, but also organizations that sponsor IT capabilities development. I believe that the success and ongoing effectiveness of any Agile implementation depends on closely hewing to the Agile Manifesto and the 12 Principles of Agile Software.

Now that I have firmly declared my commitment to Agile principles, I differentiate myself from those whom I refer to as “Agilistas.” In my definition of the term, an Agilista is someone who takes a binary, black or white view of what is and is not “Agile.” Believing that deviations from Agile practices they have learned and practiced cannot be Agile, some Agilistas stifle change and innovation in the Agile domain.

Others are strict literalists who treat published Agile best practices as instruction manuals that must be followed, to the letter, in every situation, regardless of the realities/constraints imposed on/by projects and organizations. They wish to ignore or change factors external to software/system development concerns to fit their “pure” Agile implementation.

Still others confuse attempts to enforce engineering discipline and address complexity in large-scale software/system development efforts with establishing burdensome and unnecessary processes and documentation (i.e., bureaucracy).

Many Agilistas decry “Agile frameworks” and “Agile transformations,” feeling that methodologies that go beyond the established canon of team-level Agile practices and techniques are inherently anti-Agile. In their minds, “proper” application of the canon, in the “proper” spirit, with coordination across teams via Scrum-of-Scrums (in the case of Agile-Scrum) is all that is required and desirable.

Too often, this desire to keep Agile simple and pure leads to exhortations that others “think” and “be” more Agile, without proposing how to do that in the face of technical, programmatic, compliance, and fiscal realities that constrain and shape all non-trivial system development efforts.

I am sympathetic to the frustration that leads to this brand of reactionary thinking. For a couple of decades, Agilists have had to witness and, sometimes, take part in failed Agile implementations misinformed by Waterfall software/system development prejudices and undermined by an unwillingness on the part of organizational leadership and stakeholders to embrace what I call Agile Zen:

The primary role of management is to empower those who actually deliver value to the customer and to create work environments and customer relationships within which these “value providers” are able to succeed and flourish.

No amount of Agile process mechanics, training, management tools, DevOps tooling, etc. will bring the benefits of Agile to organizations that ignore this maxim. Unfortunately, often it is not just ignored; it is outright rejected by leadership incapable of shifting towards a “servant leadership” orientation. Adoption of an Agile software/system development approach within an enterprise requires alignment between the work performed by Agile software teams and the program and portfolio level organizations that form and sustain them. In other words, Agile development becomes a forcing function for change throughout the enterprise.

This is why I am excited about SAFe. It is a framework for scaling Agile practices to the scale of hundreds of teams while adhering to Agile principles, enforcing engineering rigor through systems thinking, and ensuring long-term continuous improvement and ROI through the application of Lean principles. It includes and fosters approaches to Agile program management and governance based on Agile principles and addresses real-life enterprise/organizational concerns without sacrificing those principles. The future of Agile is in Agile scaling. I hope the Agilistas will embrace it.