What Lifecycle or Agile Approach Fits Your Context? Part 5, Origins of Agile Approaches

The original signatories of the Manifesto for Agile Software Development wanted to solve these specific problems: How can we:

• Bring more adaptability to software development?
• Stop “plan the work and work the plan” thinking?
• Release something of value earlier?

Especially since teams now had these levers, from the iterative and incremental approaches:

• Prototype something for fast feedback.
• Release something and obtain feedback.
• Build and maintain a clean code base to enable fast releases.
• Work on only the most valuable work and projects.

Not all teams knew about those levers. I wasn't there, but maybe that's why the Snowbird group created the Manifesto.

The Context for the Manifesto

Before the Manifesto, we had plenty of books and articles that discussed more lightweight approaches. For example (books have affiliate Amazon links):

• Takeuchi and Nonaka published The New New Product Development Game in HBR in 1986.
• Gerald M. Weinberg in his series of Quality Software Management books discussed “steering” as a way to guide projects to success, in 1992.
• Christopher Meyer published Fast Cycle Time: How to Align Purpose, Strategy, and Structure for Speed in 1993.
• Steve McConnell published Rapid Development, which discussed incremental approaches and small chunks of work, in 1996.
• James P. Womack and Daniel T. Jones published Lean Thinking in 1996.
•  Don Reinertsen published Managing the Design Factory in 1997.
• Preston Smith and Don Reinertsen published Developing Products in Half the Time: New Rules, New Tools in 1998.
• Jim Highsmith published Adaptive Software Development in 1999..
• Kent Beck et al published Extreme Programming Explained: Embrace Change in 2000.
• Andy Hunt and Dave Thomas published The Pragmatic Programmer: From Journeyman to Master in 2000.

That's 14 years of people writing books about lighter-weight, more adaptable approaches. That's just books. That doesn't count the articles or how people practiced more lightweight methods. (I hadn't yet written any books in the 90s. I only wrote articles.)

If you read these books, you could understand project-based agility.

However, many people wanted “the recipe” for agility. And, they wanted to be recognized for their agile accomplishments. That set the scene for the Scrum certifications in about 2002.

Certifications Changed How We Think of Agile Approaches

If you claim to practice Scrum and you have not yet read the Scrum Guide, please take some time and read it.

From about 2003-2009, Scrum worked for many of my clients. Those clients had the characteristics in common:

• The team only worked on one product at a time. They might have to do support in addition to development, but only for one product.
• The team had all the people it needed as full-time people—a real cross-functional team.
• The team could make all its own decisions for its product.

As a result, these teams delivered working product every 2-4 weeks.

Then, Scrum “stopped working.” Why?

• The team wasn't a full team. People over here, people over there, often separated by too many timezones.
• The team was supposed to work on several products in one iteration.
• The team didn't get finish anything. (They often worked across the architecture, not through it. (See An Attempt at Pictures for Implement by Feature vs. Architecture for my earliest picture.)
• The product owner wasn't available.
• … and many more.

People used the Scrum words without realizing they were treating an agile approach as if it was a cargo cult. I wrote about Agility in Name Only.

If you don't understand the principles behind agility, you might think Scrum is the only agile approach. Nope.

Two Primary Approaches to Team Agility

We have two primary agile approaches: timeboxes or flow.

Both approaches:

• Limit the WIP (Work in Progress).
• Require a cross-functional team to complete work.
• Request feedback from the customer, the business, and anyone else the team needs feedback from.
• Assume the team can work “forever” at a sustainable pace.
• Expect working product on a regular cadence.
• Inspect and adapt/reflect and refine on a regular cadence.

So many people believe “agile” == Scrum. However, Scrum is just one of several timeboxed-based agile approaches:

• Scrum
• DSDM
• Crystal
• Feature-Driven development

Timebox approaches tend to ask a team to “commit” to some set of work for a given time duration. That timebox helps the team limit the scope and limit the team's WIP. That's why you can't add or change things once the timebox starts. You violate the WIP limits.

Flow-based approaches ask a team to pull work as needed. Instead of a team limiting its work for a timebox, flow asks a team to map how the value flows through the team. Then, with WIP limits on each column, the team pulls work.

For many of my clients, iteration-based approaches mean the team pushes work into a timebox. Flow-based approaches mean the team pulls work, starting from the column closest to done.

See Board Tyranny in Iterations and Flow for more information and images.

“Done” Makes Agility Possible

Notice that when I discussed the iterative lifecycles, we still had just one release, at the end of the project.

Until we finished work and released increments of value more often, as in the Incremental lifecycles, we couldn't use short feedback loops. Those short feedback loops allow us to use double-loop learning.

What do we need to achieve those feedback loops?

We need to get to “done.” Done for every single story. No “final integration” or “final test” or final anything. The team can release each story as its own release. That's what done means.

(To read more about these ideas, please read Create Your Successful Agile Project.)

This idea of “done” requires technical excellence in the form of completed technical work:

• Automated unit, functional, system tests
• Any other tests your product needs
• Some way to review the code and tests

You can do this with tests after you code. Or, you can use any of the test-first ideas: BDD, TDD, ATDD.

You can review code and tests after you write them. Or, you can pair or mob.

If you can't achieve “done” on every story, never mind at some interim date, you don't have an agile culture.  You might be using staged-delivery or design-to-schedule. Better than you were, but not an agile approach.

(What if you're prototyping to understand a problem? You decide what done means for your prototype. If you're supposed to release it, you make the prototype releasable. If you're not supposed to release it, I hope you throw it away. See Consider Product Options with Minimum Outcomes for a more thorough discussion of the various minimums and what they might mean for you and your context.)

Does your culture support a team achieving “done,” on a regular basis? That one piece often demands people change what they do, all over the organization. That's why I say agile approaches change the culture—in the team and in the organization.

Agile Approaches Change the Culture

How do you get to “done” on every small thing? The team:

• Works in flow efficiency.
• Has the ability and responsibility to release when they are ready. They don't need to ask for permission or wait for a centralized group to release their work.

Which means we often bump up against what the company rewards.

What does your company reward? Collaborative or individual work? Decentralized (team-based) or centralized responsibility where all work funnels through a team external to the team who creates the outcome.

When companies focus on individual rewards or centralized work, you can't sustain an agile approach.

Does your company discourage certain people from discussing certain ideas? For example, does your team have to live with an architecture from someone outside the team? Or, from just one person on the team? Who gets to put work on your backlog? Do you have a say in what work goes on your backlog and when?

How do people treat each other? Can people offer each other reinforcing and change-focused feedback? Or, does the manager offer all the feedback?

These three ideas comprise a company's culture:

• What people can discuss.
• How people treat each other.
• What the organization rewards.

That's why an agile approach is a cultural change. It's also a different way of thinking about projects and work. However, the cultural changes dwarf the project changes. In Part 4, you saw that there are plenty of ways to use iterative and incremental approaches that aren't agile approaches.

You don't have to use a named agile approach. Instead, you can develop and use your own agile approach. I'll address that in Part 6.

This series:

• What Lifecycle or Agile Approach Fits Your Context? Part 1, Serial Lifecycles
• What Lifecycle or Agile Approach Fits Your Context? Part 2, Iterative Lifecycles
• What Lifecycle or Agile Approach Fits Your Context? Part 3, Incremental Lifecycles
• What Lifecycle or Agile Approach Fits Your Context? Part 4, Iterative and Incremental but Not Agile Lifecycles
• What Lifecycle or Agile Approach Fits Your Context? Part 5, Origins of Agile Approaches
• What Lifecycle or Agile Approach Fits Your Context? Part 6, Create Your Agile Approach
• What Lifecycle or Agile Approach Fits Your Context? Part 7, Lifecycle Summary