Agility eXPlained

To Add Speed, Add Lightness


Basics of Scrum Roles

Scrum is one of the most used Agile methodologies, and we often refer to roles in Agile when we speak of Scrum’s roles. According to Scrum, there are three primary roles: the Product Owner, the Development Team and the Scrum Master.

Product Owner

The product owner (PO) represents the voice of the customer, defining the features and scope of the product.
It is the main responsibility of the PO to ensure that the team delivers business value at the end of each iteration or sprint, and he or she does this by writing customer-centric user stories, ranking and prioritizing these stories, and adding them to the product backlog.

Development Team

The team is made up of some number of developers and other specialists who contribute to executing the work and delivering value.
You don’t want too many people on any team. According to the 2-Pizza rule, if you can’t feed your team with two large pizzas, your team is probably too big. Scrum teams are self-organized in that apart from any “management” they decide when to meet, who does what and how to implement the PO’s stories.

Scrum Master

The Scrum Master (SM) is a servant-leader responsible for removing all roadblocks that prevent the team from reaching their sprint goals.
Scrum masters are keepers of the rules of Scrum (and other Agile methods), and they enforce them in order to keep the team insulated from external interruptions and operating proper Scrum processes. The SM may facilitate team meetings such as the daily standup or the sprint retrospective. Many scrum masters encorporate coaching and mentoring in their role.


What is Agile?

The word “agile” is defined as being able to move quickly, to be nimble or light on one’s feet. Think of a gazelle speeding across the savanna or a monkey moving from tree to tree.

In the world of software development, Agile represents a group of related methodologies used to manage and create software products. These Agile methods are characterized by incrementalism and iteration; that is, they promote dividing tasks into small phases of work and rely on frequent reassessments and adaptations of plans.

Agile methods aren’t used only within the software industry. In fact, the roots of these methods are in manufacturing, specifically the just-in-time (JIT) and lean production strategies employed by auto makers in the mid-twentieth century. These methods can likewise be applied in other areas of business as well as in our personal lives.

Agile as a methodology is flexible enough that we can mix-and-match these related variants as needed, using only what is appropriate on a given project. We’re not tied to a rigid prescription of how to do things, so long as the focus remains on the inspect and adapt cycle of providing incremental deliveries of business value.

The term “agile” was popularly introduced in this context with the drafting of the Agile Manifesto in 2001 as a response to the traditional method of creating software projects. The waterfall model (as it’s known) operates sequentially, moving completely through each phase of software development (eg. requirements > architecture design > writing code > testing & validation > deployment) before cascading down to the next activity. While it looks good in theory and is essential for some types of projects (eg. stable, highly-regulated), waterfall isn’t as effective in the faster world of software creation.

By being sequential and slow to change, waterfall introduces wasted time (waiting) and significant risk of missed requirements (and other surprises). For example, the diagram below shows that the risk (red line) shoots upward significantly as the waterfall project nears completion. Meanwhile, risk is kept low throughout the Agile project.

waterfall brings risk


Low risk is accomplished in Agile projects by reducing batch sizes (incrementalism) and testing earlier & often (iteration), as demonstrated in the following illustration.

effects of batch size


We can see that the older methods of software project management are predictive (in that the try to predict future needs from the outset), while Agile methods are adaptive (able to react and adapt to change). In Agile, requirements are written just-in-time and the architecture emerges as the project matures. The benefits to Agile include:

  • reduced time to market
  • increased quality
  • reduced waste
  • better predictability
  • better team morale

In other posts we examine some of the several variants of Agile, including: Scrum, Extreme Programming (XP), Feature-driven Development (FDD) and others. We’ll also look at the Scaled Agile Framework (SAFe), an attempt to introduce Agile to the large enterprise.


The Agile Manifesto

In mid February 2001, at the Snowbird ski resort in the mountains of Utah, 17 people met to solve a problem. What came out was the Agile Manifesto, a short but powerful statement of beliefs for how software could be better developed.

Manifestos are simply declarations of beliefs or opinions. Anyone could write a personal manifesto to declare what is most important to them. Organizations may have manifestos to communicate their vision. The Agile Manifesto was written by an informal alliance of representatives from Extreme Programming (XP), SCRUM, DSDM, Adaptive Software Development (ASD), Pragmatic Programming, as well as others sympathetic to the need for an alternative to the “heavy”, documentation-driven software development processes that was pervasive.

Manifestos need not be long – the Agile Manifesto contains only 68 words – but the message must use strong, affirmative language. Below is the complete text from the Agile Manifesto:

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

Kent Beck James Grenning Robert C. Martin
Mike Beedle Jim Highsmith Steve Mellor
Arie van Bennekum Andrew Hunt Ken Schwaber
Alistair Cockburn Ron Jeffries Jeff Sutherland
Ward Cunningham Jon Kern Dave Thomas
Martin Fowler Brian Marick

© 2001, the above authors. This declaration may be freely copied in any form, but only in its entirety through this notice.

While this manifesto clearly and completely declares the four key values of Agile, the authors also communicated the twelve principles upon which these values are based.

The Agile Manifesto is a public statement professing their beliefs and intentions.  Although it was originally drafted by only 17 men, it’s been signed by over 15 thousand people as of this writing.  You can become a signatory as well. I signed in April 2011.


Simplify, then add Lightness

Colin Chapman, the influential automotive designer and founder of Lotus Cars, had an obsession the lightweight. “Simplify, then add lightness,” was his philosophy, making clear the vision of his company and its cars.

The Agile Manifesto, published on February 2001, was the result of 17 software developers discussing lightweight development methods. The idea was to introduce iterative and incremental development to the masses, freeing them from the tyranny of bloated project plans with long, drawn out schedules.  Adaptive planning and rapid, flexible responses to change were preferred to the weight of traditional development methods.

Over the years, the evolution of this simple idea had indeed brought lightness. By “subtracting weight” the Agile enterprise enjoys a favorable speed advantage over its counterparts.