Customize Your Agile Approach: Select Your Agile Approach That Fits Your Context

I’ve heard too many people say, “Agile/Scrum,” as if Scrum was the only way to use agile approaches. Scrum is terrific and it’s not for every team. In fact, iterations might not be for your team—you might need a cadence of delivery, planning, and reflection instead of a timebox. Instead of assuming that one approach will work for you, consider how you might decide which parts of various agile approaches might work best for your product, project, and team.

This is the first in a series of articles that will help you think about how you might want to customize your agile approach for your context. This article is for you if you are wondering how to make agile approaches work for you: your work, your team, and your organization. You might be a project manager, Scrum Master, coach, or other leader who is experimenting with agile approaches. This article is about understanding the difference between iteration, flow, and cadence and when you might consider each to customize your agile approach.

You might think that agile approaches work. My experience is that many different approaches work for various teams. One of the big problems is when people assume they can take a specific framework and “just” use it, as is.

As humans, we see what other people do. We think it might fit our context. Then, when it doesn’t work, we think there’s something wrong with the entire idea.

Not so. That specific framework might not work for your team or your project. Consider Bob and Sally, who are part of two different projects with different environments.

Bob is part of a team that is collocated, works on one project at a time, and has all the skills and capabilities it needs. Bob’s team is using Scrum and it’s working for them. They are able to use the ceremonies effectively. In addition, the product owner is full-time and can work with the team as needed.

Sally, however, is on a different kind of a team. Sally is the lead developer based in Boston. She works with a tester in India and several other developers and testers across the US. Her product owner is based in California, and can only spend about an hour total every week with the team. In addition, they develop new features for one product and support four other products with ongoing maintenance.

Sally’s company wanted every team to use Scrum, but Scrum didn’t work for her team. They use flow and a cadence of planning and retrospectives to make their agile approach work for them.

Bob and Sally have different project contexts. While Bob had a great experience using Scrum as a framework, Sally’s context is different. Sally’s team uses the agile mindset, visualizes their work, and works with the product owner to rank the work as it arrives to deliver the most value as often as possible.

Think about your project. Is your team collocated? Can your team plan for a couple of weeks at a time? Do you have access to a product owner as you need that person? Does your team have all the skills it requires?  Start with your context and think about which agile approach might work for you.

Every Team is Unique

Every team is unique, so every team needs its own agile approach. Some teams can use an off-the-shelf framework, such as Scrum, XP, or the Kanban Method. However, in my experience, most teams need to customize their agile approach to their circumstances.

Here are some reasons for customizing your agile approach:

• You have a geographically distributed agile team, and it’s distributed across four time zones. Having a daily meeting or synchronized refinement, planning, and retrospectives is quite difficult for you.
• Your organization is still new to agile approaches, and you have a team of developers and a team of testers. Your UI people are part of a “shared services” team. In this case, you might use a kanban board to show the flow of work so everyone realizes where the work is and what the delays are. You can use that board and your data to bring UI people into your team.
• You work as part of a workgroup, not a team. Your work is independent, not interdependent.  Software teams have interdependent work—that is, you need developers and testers to collaborate to finish the work. Imagine a Customer Support “team.” The company calls that team a team, but they don’t have interdependent work. Each person works alone. In some situations, people might collaborate on difficult problems, but each person can deliver their finished work alone most of the time. When people are independent, they work as part of a workgroup.
• Your team needs to provide support or maintenance, and that work is a higher priority than your project work. That work interrupts your project work.
• Your team works on multiple projects at one time.

Each of these circumstances might require a cadence of planning, demos, and releases. However, your team might discover that the same cadence does not work for all three parts of what we think of as agile rituals.

What’s Your Cadence of Planning, Demos and Reflection?

The General Agile Picture is a way to think about how agile approaches work:

Figure 1: General Agile Picture, © Johanna Rothman

The Responsible Person (often called a Product Owner, PO) takes the ideas from the customer and/or the organization and creates a ranked backlog. The cross-functional team takes that ranked backlog and releases small, shippable product on a frequent and regular basis. At some point, the team demos their work and conducts a retrospective.

If you use iterations, you plan for time, because iterations are a timebox. By definition, the team finishes the work at the end of that time. The PO decides if any unfinished work moves to the next iteration or farther down the product roadmap.

If your team uses iterations as in Scrum, the iteration starts with the ranked backlog and ends with the demo and retrospective. If your team uses flow, you can demo and retrospect at any time.

To be fair, iteration-based agile approaches don’t prevent you from demoing or retrospecting at any time. Many teams wait until the end of the iteration to demo and reflect.

Some teams have found more frequent demos and reflection to help both the product and flow of work. Ben’s team demos features as soon as the team completes the feature. They can demo because the PO is available most of the time. They started the demo-as-you-go practice when they had some complex features and wanted feedback more often than only once an iteration. That practice worked so well they continued it.

Ben knows of another team in his organization that has a practice they call “constant reflection.” That team does a five-minute reflection each day after their standup to prepare for the next bit of work. They have their standup just before lunch. Since they all meet in the lunchroom for lunch, that team often refines their process or discusses it over lunch. They also perform an end-of-iteration full retrospective.

If you use flow, you plan for scope, because flow doesn’t care how much work you have—once you are done with this item, you take the next item. At some point, you do a demo and conduct a retrospective. Teams decide when demos and retrospectives make sense for them. Teams using flow don’t necessarily demo after every feature, although most of the flow-based teams I’ve met do demo after every feature. Some teams demo on a cadence.

Sally’s team demos every feature, although the way they demo is different from Ben’s. Sally emails her product owner (PO) to explain the new feature. Sally asks the PO to try the feature the next day and provide the team feedback. The PO often takes a couple of days to provide feedback.

If the PO is happy with the feature, no problem. When the PO is not excited about the feature, Sally first talks with the PO to clarify the PO’s concerns. Then, depending what the concerns are, Sally with either work with the team or ask the PO to clarify the story or further work.

Sally’s team incurs delays for their work because their PO is not available enough of the work day.

Sally’s team reflects at a cadence. They conduct an asynchronous retrospective every week. They use an asynchronous retrospective because they have so many time zones to consider. In addition, they meet in person once a quarter to reflect together. They start their in-person meetings with retrospectives.

Understand the Difference between a Timebox and a Cadence

I have found it useful to differentiate between a timebox and a cadence.

By definition, timeboxes help you draw a line to say, “Pencils down! Work is over!” A cadence says, “It’s time to do this activity again.”

Teams might have trouble finishing stories in a timebox or iteration. There can be any number of reasons for their trouble. Here are three common problems I’ve seen: the stories are too large; the people are multitasking on several stories or worse, projects; and the team is not working as a team to finish stories. If the team can’t finish because of multitasking, a cadence might make that even worse. However, visualizing their work might make a difference.

Sally’s team had trouble finishing their stories inside an iteration. Here’s what happened with them:

Sally’s team never met their commitments for an iteration. Part of the problem was that the PO changed his mind during the iteration and swapped out stories they’d discussed with stories they hadn’t discussed.

Sally decided it was time to change things. She suggested her team to limit the number of stories they would discuss in advance of starting to work on them. The team chose three stories. And, she asked the PO not to change those stories or swap them out. The PO agreed. The team agreed to work to deliver those three stories every week plus their support work. That meant the team and the PO could plan their three stories every week. That flexibility meant the PO could change or add stories once a week.

Sally’s team had a one-week cadence for planning and flowed work into the team. The team demoed every feature as they completed it. All of them were much happier.

Sally’s team uses the one-week cadence to plan and demo. They often use short timeboxes of a morning or an afternoon to spike, but they no longer use iterations because things change too fast for them.

Sally’s team has a one-week cadence for retrospectives, also. They examine how they’ve worked, manage their risks, and impediments and decide what to do next.

Decide What Fits Your Context

Can you use iterations and use the timeboxes as a way of managing the work your team can commit to? Or, do you think it might be better to have more flexibility with flow? Maybe you can use both ideas: timeboxes so you have a defined cadence and you know what you can commit to, and flow so you can see where the Work In Progress (WIP) is.

WIP is all the work the team has in progress. If you use a Scrum board, it’s the work in your “In Progress” column. See Figure 2.

Figure 2: Typical Scrum Board

If you use a Kanban board, it’s all the work between your Ready column and the Done column.

Figure 3: Possible Kanban Board © Johanna Rothman

The team using a board in Figure 3 has eight items in their Ready column. All the work between Ready and Done: Discuss Story; Develop and Unit Test; System Test is their WIP.

This particular team has a full board. The WIP limits prevent the team from taking any more work off the ready column until they have room to work on it.

The team would move from the right-most column, clearing work as a team to move their work to Done. Since the team is at its limit for System Test, anyone available to start something would assist whomever is working on the System Test items to complete them. Then, whomever is now ready could pull work from Dev-Done into System Test.

When a team uses WIP limits, the team manages its flow of work and its throughput. Some teams discover that creating different columns and WIP limits helps them realize what they could try in their agile approach.

Sally’s team changed how they worked when they moved to flow. They limited their WIP in every state—on purpose. When they used a typical Scrum board, they didn’t see how much work they had in which state. They could have created a Kanban board to use inside their iterations, but they didn’t.

Consider Your Team’s Options

Especially if the team uses a tool, the biggest decision is how to manage the flow of the work. Can a team use iterations, or should the team use flow? My guideline is this: if the team can depend on a stable set of stories with no interruptions for a week or two, use iterations. If the team needs to respond more quickly to change than a one- or two-week iteration, then use flow.

Then, ask the team to consider how often they want to demo and reflect. The team might use a cadence of planning, demos, and reflection, and use flow for their work. Or, the team might be able to use iterations and have the timebox of the iteration drive their planning, demos, and retrospectives.

I happen to use flow inside of one-week timeboxes for my work. I plan what I can accomplish in a week. I might change the order of that work and sometimes I change the work itself during the week because of interruptions or opportunities. I reflect once a week and then plan the next week, seeing what I’ve done. Because I stop at the end of the week and decide what to do about any WIP or not yet started work, I do use timeboxes.

There is No One Right Way to use agile approaches. Consider your context, your team, and your project so you can customize your agile approach for your successful project.

About the Author

Johanna Rothman, known as the “Pragmatic Manager,” provides frank advice for your tough problems. She helps leaders and teams see problems and resolve risks and manage their product development. Rothman is the author of more than ten books, including: Create Your Successful Agile Project: Collaborate, Measure, Estimate, Deliver, Agile and Lean Program Management: Scaling Collaboration Across the Organization, Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects, 2nd ed., See more of Johanna’s writing at jrothman.com.