What Lifecycle or Agile Approach Fits Your Context? Part 6, Create Your Agile Approach

I discussed the origins of the agile approaches in Part 5. In this post, I'll discuss how you can create an agile approach that fits your context.

Why should you create your own agile approach? Because your context is unique to you, your team, project, product, and culture. You deserve an agile approach that helps you achieve the business outcomes you need. And, with any luck, nudges the culture in a good direction for your team, project, and product.

I also discussed the two major approaches to team agility in Part 5: timeboxed and flow approaches. Before you choose which approach makes more sense for you, let's discuss why you might want an agile approach.

Why Do You Want an Agile Culture for Your Product?

Knowing your “why” helps you decide whether to start with timeboxes or flow. (You might want to read Define Your Agile Success.)

Notice I said the culture is for this particular product. And, because your customers want different things from your product over its lifetime, you might want a different agile approach for a given project.

What do your team and your product need for agility and to manage product risks? When you know, you can make educated choices.

You might want:

• Receive customer feedback (iterate over feature sets).
• Offer more features with releases (increments of value).
• Ability to cancel projects when they've done “enough.” That allows you to manage the project portfolio more easily.
• Fix the existing defects in the product (iterate over fixes).
• Prevent new defects from escaping (technical excellence in the increments).
• An empirical approach to forecasting dates and more.

What do you need? If you said “all” of this, you do need an agile culture. If you don't, you might want to read Part 5 and see how to integrate technical excellence into your project.

An agile culture will help you create transparency, collaboration, and more. Those are outcomes, not where you start.

What risks do you have for your current project? If you review the pyramid and ask the questions about your project's boundaries, you will have a pretty good idea about what your project needs.

Here are some ways to think about your agile approach:

• If you have more risks around low defects, time to release, or cost to release, consider starting with a flow-based agile approach.
• If you have more risks around getting feedback around features, consider starting with a timeboxed agile approach.

Remember, an agile approach starts with a team.

Start with the Team

Let's start with a couple of assumptions:

• You work on a product.
• You're part of a cross-functional team.

I'll discuss workgroup considerations or times when you don't work on a product below.

What's a cross-functional team? A team that—by itself—can fully deliver the items on its backlog. I am sure that team needs developers and testers. The kind of developers, testers, business analysts, etc—all that depends on your product.

What if your team can't deliver the functionality by itself right now? Start here: Change the Indispensable Employee Mindset. Make sure the expert collaborates with the team as a whole.

What if your team is a cross-functional component team? Your team can finish its work, but your team depends on other teams to release working product. Consider the experiment in From Component to Cross-Functional Teams and  Rethinking Component Teams for Flow.

What if you can't do any of that? Work in flow and measure your cycle time Don't make yourself crazy with timeboxes that don't allow you to get to done.

As I said in Part 5, getting to “done” makes all the difference between an agile culture and a not-so-agile culture.

Agile Approaches for Workgroups and Not-Product Work

What if you have a workgroup? Or, if you work on services, not products? Or, a product that's not software/hardware?

You can create an agile culture of small increments of value that you deliver every day. (I wrote about this in Create Your Successful Agile Project.)

An agile culture in any team or group means you create small increments of value and ask for feedback. Only you know when you should ask for feedback.

I recommend you start with flow in these circumstances, so you can see where the work is. And, how to get to “done” every day.

How Can Your Team Get to “Done” Every Day?

If you want an agile culture, you probably want frequent releases of value. (Refer back to your why.)

We get these frequent releases because we decide what we can release as a Minimum Outcome for now and then replan.

You can't get to “done” without technical practices. Technical excellence allows the team to release something every day, or more often. (Read Product Orientation Requires Technical Excellence and maybe that whole series.)

When I think about the technical practices that support an agile culture, I think of:

• Continuous integration.
• Automated tests at all levels.
• Ability for the team to release its own work.
• Early warning signs when things don't work.
• Collaboration within the team to support fewer items in progress. That allows the team to finish working product faster.

Where does this leave your team, if you want to create an agile culture? Consider starting with your team's flow.

Start With Flow

I said in Part 5 that I used to teach Scrum. It worked for my clients.

However, I didn't use what I taught. I used flow, with a one-week cadence of planning and retrospectives. I realized I used Personal Kanban.

Why did kanban work for me when timeboxes didn't? Especially since I timebox work all the time?

Because my clients and I have similar problems:

• Interrupting work. I receive calls and emails that interrupt me with more work.
• Too much potential work. I need to limit my WIP to focus and finish one thing at a time.
• I can't wait for the end of a longer timebox to change what I want to do. For example, if a client calls on Monday, I'm not going to wait for the next Monday to start a proposal. I want to start it that day or the next day.

I have schedule, cost, and released-defects risks. That means flow works much better for me to see my cycle time, costs, and the various risks. I can see my data with flow as I proceed.

When I want customer feedback, such as on books, I ask my reviewers to respond in several weeks (a timebox). I don't see the data as I proceed—I need to wait until the end of the timebox.

Does that mean you can't use Scrum and flow at the same time? You can, especially if you ignore story points.

I strongly recommend each team map its flow and measure its cycle time. If your team can commit to a week or two of work—and not need to change the work—then, sure, use Scrum.

If you can't commit to even one week of work, don't start with Scrum.

Create Your Agile Approach

Here's the nice thing about flow and timeboxes. You can create your own mashup of these two approaches. You don't need a certification to create and practice your agile culture.

Here's how you might start:

1. Map your current flow of work through your team. (See Create Your Successful Agile Project and From Chaos to Successful Distributed Agile Teams.) See your current reality.
2. Ask yourself these questions:
   1. Do we have too many open items? If so, add WIP limits.
   2. Do we have too many items waiting for too few people? (I see this with teams with too few testers.)  Review your queued work. You might need WIP limits. You might need to change your technical practices to help the work move through that queue.
3. Assess how often you demo releases. How can you gain more feedback, internally and externally?
4. Assess how often you do a kaizen or retrospective. How often do you create experiments in your process and for the product?

Now, you decide how to use timeboxes and WIP limits. I love one-day timeboxes for teams to use spikes. I use anywhere from 15-60 minutes for writing timeboxes.

I've been teaching about cycle time for several years. So far, every team/group that's measured their cycle time sees what they might do to decrease it.

That's how you create an agile culture. Release something that's done and learn from it. Every day or more often.

You can do that if your team works in flow efficiency. And, the team needs to break the centralization of any “shared services” mentality.

Culture Changes with an Agile Approach

(I forgot to write this before I hit publish! Sorry.)

What makes an agile approach a cultural change? I like Schein's definition of culture. My interpretation of his definition of culture:

• What we can discuss
• How we treat each other
• What we reward

Team A selects all their work together for the next month. They rank-order the work with the help of the product manager. They collaborate on the work, often swarming and mobbing. The team demos every Thursday morning to the product manager. After that demo, they sometimes change the order of the work. They do a short kaizen every Thursday, just after the demo and replanning.

I would call Team A an agile team, despite the fact they don't use a recognized agile framework. They use cycle time for estimation. Team A collaborates much more often than they work individually.

Team A can do this because they don't have individual, supposedly merit-based compensation. (See Creating Agile HR, Part 6: the Agile Compensation System for more details.) They have some individual compensation. However, the bulk of their compensation is team-based. Because they're not focused on “their” rewards, they feel free to (and do) offer each other feedback and coaching.

Team A has a person who acts as a project manager, protecting the team from interference. That project manager reports team progress to the various interested parties and answers queries on behalf of the team.

Then, there's Team B. They think they're using Scrum, but no one has read the Scrum Guide. Their Scrum Master assigns work to each individual person. They rarely collaborate as a team, because that would destroy their individual compensation plans.

They regularly talk about “technical debt.” I suggested it was unfinished work, devoid of technical excellence. The Scrum Master informed me that the dates were so important, the team needed to do the “minimum” required.

I do not consider Team B an agile team. They're using agile words. However, they work as if they're a serial-lifecycle, command-and-control team.

Words don't create an agile culture.

Create Your Unique Agile Approach

You can create your own unique agile approach. Start with the principles of:

• Short feedback loops inside the team.
• Short feedback loops with the customer, or, at minimum, a customer proxy.
• Team collaboration, flow efficiency thinking.
• Frequent reflection to use double-loop thinking about everything.
• The lean and agile principles to guide your actions.

You don't need a framework to do any sort of agile approach. You definitely don't need a framework to “scale” agile approaches. See “Scaling” Agile series.

I'll summarize everything in the final post.

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