Integrate the Agile and Lean Principles

Think about what the agile and lean principles together buy you. These principles say to use a collaborative cross-functional team structure so that the entire team works on features. The principles emphasize seeing the work as it proceeds to get feedback on the work and the process. The principles caution you to not start more than the team can complete in a short period of time. And you deliver working product often and as fast as possible to see progress, increase customer collaboration, and receive feedback.

How can you think about the agile and lean principles for your project? How can you build respect for the people and continuous improvement into how your cross-functional, collaborative team can deliver small chunks of value often? That way, your team can not only deliver often, but also receive feedback often.

Consider How an Agile Approach Might Work for You

I often hear people describe their projects as being “agile/Scrum.” Let me clarify: “agile” is an umbrella term that encompasses many agile approaches, one of which is Scrum. Some of those approaches are defined in the following table.

There are more agile approaches, but these are well-known approaches for teams.

Scrum is one project-management framework that helps a team adopt agile techniques.^[6] Many teams start with Scrum because it is the most famous approach to agile. Scrum works for collocated teams who work on one project at a time, and where the team has all the cross-functional skills and capabilities it requires. And Scrum creates the need for cultural change. However, I have found teams that meet the following criteria are not good candidates for Scrum:

• Your team works on more than one project at a time. Or the team needs to provide significant interrupt-driven support or maintenance.

• Your team is distributed across more than four time zones.

• Your team is not cross-functional. That is, you have a team of developers trying to collaborate with a team of testers, often across time zones. Or you have a work group instead of a team.

• Your team does not have the skills or capabilities it needs. You have a scarcity of some necessary role, such as UX or DBA.

• Your “team” does not need collaboration. All the work is independent, not interdependent.

In these cases, I do not recommend Scrum as your agile approach. (Can you make Scrum work? Of course. It’s more difficult than an agile approach has to be, but you can try.) I recommend you integrate flow into your agile design. You might also use iterations for a cadence of planning and delivery.

As described in ​Iteration- and Flow-Based Agile​, iteration-based agile uses timeboxes to manage the scope of work the team will complete. Scrum is similar, and also offers specific roles, such as the Scrum master and product owner. In addition, Scrum incorporates several events, including these:

• The daily standup

• The preiteration planning meeting (which Scrum calls the Sprint Planning meeting)

• The backlog-refinement meeting before the next iteration

• The demonstration to show and explain what the team completed in the last iteration (In Scrum, this is the sprint review and includes the team’s assessment of whether it achieved the sprint goal.)

• The retrospective at the end of the iteration

You might decide these events are for you. However, you don’t need to use Scrum to use an agile approach—even an iteration-based approach—that works for you. You might find that given your context, choosing an alternative or designing your agile approach works better.

I have seen people and teams use the agile and lean principles to progressively move to agile approaches as it fits for them. I recommend you do, too. The more your team is resilient and adaptive, the easier it is to create a great project that delivers a successful product.

You do not need to name your agile approach. I recommend you design an agile approach that incorporates the values and principles of agile and lean, rather than try to stick to a framework, regardless of its fame.

Keep Your Iteration Duration Short

If you decide to use iterations or cadence for planning, improvement, or retrospectives, how long should an iteration be? Iterations and cadences are about feedback. How much time would you want to elapse before you could know if everything the team did was wrong?

Pick an iteration length that would make it okay if you had to throw everything away. If you plan on a cadence, make sure that cadence is short enough that you’re not replanning too late to accommodate change.

Maybe you’ve considered the ideas presented in the Potential for Release Frequency graphic​here​, and you know your customers can’t take product releases more often than once every six months. Should you wait to release once every six months?

I don’t recommend that. In fact, regardless of when your customers can take releases or how much external releases cost, I recommend you release internally at least once every two weeks—ten business days.

Many teams decide that one or two weeks is the right iteration duration. That’s five or ten workdays. Some teams choose three or four weeks, fifteen or twenty workdays.

Joe asks:

Why Count the Business Days in an Iteration?

You’ve noticed I count five days in a week, not seven. That’s because we work for five days out of seven. (I’m not counting people who work four 10-hour days. You folks can do your own arithmetic.)

If you count all the days, including the weekends, people are likely to work all the days. That’s a problem. It’s impossible for people to work all seven days in a week for any duration of time. It’s possible for people to race to a deadline for maybe a couple of weeks. It’s not possible to sustain that pace.

Count the days in the week you work. It doesn’t matter if you work Sunday–Thursday or Monday–Friday or some other option. Count just those five days.

In my experience, it’s easy for a duration of more than 10 days to lead to the ​Trap: You Have Iterations of Waterfalls​. Be careful of iterations more than 10 business days long.

If you decide to use iterations, select an iteration duration you can standardize on. That will allow you to gather data and become more predictable for your planning.

If you are using flow, consider a cadence for retrospectives and improvement activities. I assume if you use flow, you will release internally every time you complete a feature.

To start the iteration, you have a short planning meeting, where you either have enough user stories for a ranked backlog, or you develop them. The team agrees it can complete them in this iteration. At the end of the iteration, you meet with the product owner (responsible person) and conduct a demo, showing your completed features. The team conducts a retrospective so the team can inspect and adapt its process. Either at the demo or at the retrospective, the team and the product owner can agree to inspect and adapt the backlog for the future.

Loop until you meet the release criteria for the project. Note that since the product is releasable, you can release at any time.

Create Your Agile Mindset

A mindset is the values, beliefs, and principles you hold that guide your actions in a situation. (See Gil Broza’s Agile Mind-Set [Bro16] for more information.)

An agile mindset means you value the collaboration and feedback in an agile team. You believe that small steps and frequent checking of progress will help. You believe that people collaborating can deliver a terrific product. You use the agile and lean principles of collaboration, delivery, and transparency to guide your work.

I had a challenge when I first used agile approaches for my work. I had perfection rules—I had to have the work perfect before I allowed anyone to see it.

That doesn’t work. Instead, I needed to create the mindset that I could build something, release it to someone else to gain feedback, and then use that learning from the feedback to decide what to do next, as illustrated in the figure.

I have found that using Carol Dweck’s growth mindset ideas, as described in Mindset: The New Psychology of Success [Dwe07] and outlined in the table, helps people see that exploration and learning are critical ideas for agile success.

Agile builds in adaptation to your projects and daily work. You can make this adaptation work if you adopt the growth mindset. When you work as a team, adopting the growth mindset and the agile and lean principles, values, and beliefs, you often discover you can experiment and learn from your experiments.

The agile mindset is one that says, “What small experiment can I learn from and make progress based on the outcome?”

Avoid Frameworks Until You Understand Your Context

You might be wondering, “Why can’t I just use a framework?” If you can find a nonprescriptive framework that fits your team, go right ahead. Many of the current frameworks might work for your team. In my consulting, I have found that many frameworks are too prescriptive and do not create the agile mindset for a team. And management thinks the framework is all the team needs.

Instead of “installing” a framework, look at your team and see what your team needs to use an agile mindset and create its agile culture.