Is Agile a Cargo Cult or a Reality for Your Team?

A cargo cult occurs when people adopt rituals expecting some good behavior to occur. They really don’t know why they are doing these rituals and don’t understand the reasons behind them, yet they keep doing the rituals expecting great results. In this article, I’ll give two contrasting examples that I’m familiar with: Project A talks the walk, Project B walks the talk.

Agile: The Talk of the Town
Everyone’s talking agile these days: refactoring, iterations, story points. Everyone’s got the lingo. Are they really doing agile to get the benefit of it? And does that matter?

Project A claims that it is working in an agile way. It has a product owner. It uses two-week iterations. It demos and conducts a retrospective at the end of the iteration. And it feels as if agile has “let them down,” a quote from several team members. Why?

Members never finish what they commit to for an iteration. The product owner is only available for the demo, not to explain a feature when anyone on the team has a question. Their retrospectives are no longer than 15 minutes–and they never have action items from the retrospective. And although they claim to be doing two-week iterations, the iterations are a development iteration followed by a testing iteration. The developers and testers rarely work together on a story. Project A has trouble releasing anything ever.

Project A uses many of the agile words. It is even attempting to use an agile approach. Project A seems to have missed what agile is.

Waterfall…and Proud of It
Project B is unabashedly proudly waterfall. That’s what team members have said: “We are waterfall and we are proud!” They deliver internally at least once a month, sometimes twice a month. They have an external release each quarter–more often if the customer wants a fix. They work on one or two features at a time. They carefully analyze the feature, design it, write the code and test it—in that order. They know about project retrospectives and conduct them whenever they release externally.

If you look at the lifecycle definitions, Project B is more like a design to schedule or staged delivery approach than pure waterfall. Whatever it does, Project B releases much more often than Project A. Project B has the benefit of fast customer feedback and happy customers, what Project A wants.

Which team seems more agile to you? Project A, where they are attempting to use some of the agile rituals and can rarely release? Or Project B, where they reject the agile rituals and deliver value often?

Some projects, such as Project A, exhibit agile cargo cult behavior.

The project team does not understand the reasons behind collaborative development, so they don’t do it. They claim to have two-week iterations, but they are actually doing four-week (or longer) iterations, because they sequence the testers after the developers.

Because they are multitasking, the team members are not managing the flow of work into the team. Neither are the managers.

They claim to be agile, but they are far from it.

Project B has rejected the rituals and the agile lingo. Members keep doing what they’ve always done: work on a feature or two at a time, as a cross-functional team. They have no product owner. They have a product manager who provides them a roadmap for the product. They decide which features to work on next.

Because Project B delivers something to the customer base at least once a month, it has built trust with its customers, product management and senior management.

Do You Know About Your Project?
When you think about going agile, do you think about the rituals or about value delivery? Many teams start with the rituals, without realizing the rituals are about delivering value to the customer.

Instead of rituals, consider how you deliver value. Here are some questions for you:

  1. How often do we deliver value to our customers?
  2. How do we take feedback from our customers and integrate that into our decision of what to do next?
  3. How often do we improve our team process?
  4. How do we limit our work in progress so we can create value as a team and deliver our work?

There are no right or wrong answers to these questions. Here are some discussion points about these questions:

1. How often do we deliver value?
Some applications cannot deliver value too often to their end customers. I have worked with several teams who developed school-based applications. Changing how teachers mark grades in the middle of a semester/grading period? Not such a great idea. And there were many other parts of the system they could change in the midst of a grading period.

When those project teams transitioned to agile, they asked themselves, “What can we deliver internally, and when? What can we deliver externally, and when?”

When they changed the question from “How often can we deliver?” to those questions, they saw many ways to deliver value without interrupting their customers.

2. How do we take customer feedback and use that feedback?
There is no right answer to this question. You might not want to take your product in the direction your customers currently desire. You might have a direction that allows them to do much more than they can imagine. However, understanding their feedback will help you. The more often you can deliver something to your customers, the more they see the product direction and how they can influence that direction.

3. How often do we improve our team process?
A team that doesn’t inspect and adapt its process is not using a key agile ingredient. Agile is all about change–not just the change that delivering value provides, but the change that you can use to see how to evolve or create a new team environment on a periodic basis.

4. How do we limit our work in progress?
One of the key ideas in agile is that the team, as a whole, works on the team’s work. That means a team limits its work in progress. The team members do not multitask on several projects. Each person doesn’t take one story: “That’s my story, I’ll do it alone.”

Instead, people work together to finish stories. People might work as a developer-tester pair, or several developers and a tester, or even swarming or mobbing over the story.

Here are just some of the benefits of working as a team on one story at a time:

  • The team members learn all about that area of the code and tests.
  • The team members can help each other so the team does not accumulate technical debt.
  • The team members help each other learn. No one is left behind in the product evolution.

Help Your Team Become More Agile
Avoid cargo cult agile. Help your team become more agile by starting with the four questions I listed above. If you focus on delivering value all the time, your team will become more agile.

Leave a Comment

Your email address will not be published.

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

%d bloggers like this: