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):

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:

5 Replies to “What Lifecycle or Agile Approach Fits Your Context? Part 5, Origins of Agile Approaches”

  1. My first exposure to agility was Beck’s book, which I only skimmed. It seemed crazy to me. Frankly, I thought it put too much control in the developers’ hands, and I feared they’d run amok with it.

    After reading Weinberg I started to come around.

    As a leader of engineers I’ve had to counteract that tendency a few times. So my fear wasn’t unfounded. But for the most part, once you have gotten your teams at least mostly aligned with business goals, iterating on small changesets works well. I deliberately didn’t use the word “agile” there because it hasn’t always been agile. But it has always worked for the context I was in.

    1. When I first read Beck’s book back in 1999, I really wasn’t sure about On-Site Customer. At the time, I had very little IT experience, where the customer is down the hall. Then, I thought about several projects and programs where I felt as if I was always knocking on Marketing’s door. I had no trouble with continuous integration and rolling wave planning (what he called The Planning Game). I was a little worried about refactoring—how could we avoid redesign or re-architecture? I loved a lot of that book, including the “simplest” ideas.

      I suspect I had two advantages over you. My early bosses expected me to work with a (small) project team and to deliver something fairly often. That delivery was for their eyes, so they knew we weren’t running open-loop. We took that independence seriously and figured out ways to collaborate and find our way through problems. The Weinberg books helped me refine that kind of management.

      Doing what fits for your context is much better than trying to “be” something that doesn’t fit. Hmm. I should write that down in more places 🙂

  2. A good list of the early work! Another often overlooked early proponent of agile-like approaches – Tom Gilb and Evolutionary Delivery. I was using this approach a couple of years before Kent Beck wrote his first XP book.

    Interestingly, there’s some evidence that NASA used incremental and/or iterative approaches as early as the mid-60s. Industry interest in those dropped sharply when the U.S. DoD started requiring waterfall. References at the bottom of this report: https://kiberle.com/wp-content/uploads/2016/01/2005-Evolution-of-Software-Lifecycles.pdf

    1. Thanks, and thank you so much for your pointer to those sources. I had forgotten about Evolutionary Delivery. I think that’s because I never used it. (Your picture looks a lot like mine in Manage It and in What Lifecycle. Great minds, Kathy!)

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.