Hi all.  I’m on “vacation” in San Diego this week.  I’m kind of splitting time between vacation, reflecting on business and writing my Lean-Agile Anti-Patterns book. Today,  I wanted to discuss the difference between what I think are normal Scrum practices and what could be called “Lean-Scrum”, or what we, at Net Objectives, call Lean-Agile. I hope to write a blog entry each day of this week, so please stay tuned.

Mike Cohn once asked – If there is such a thing as Lean-Agile, is there such a thing as Fat-Agile?  He was being sarcastic, I believe, but I actually think there is definitely such a thing as Agile or Scrum that does not sufficiently follow Lean guidance.  And, in my experience, often with ineffective results – so calling it Fat-Agile or Fat-Scrum may be appropriate, although I wouldn’t call it that.

My experience with working with dozens of teams and training thousands of people is that Scrum is relatively straightforward when the following applies:

• You have buy-in from management
• You are kicking off an isolated team
• The team being selected for the work is working primarily on just this project
• The team is organized so that all resources required (e.g., analysts, developers, testers) are on the team

However, more often than not, teams are in a situation where:

• Management is not sure about Scrum or Agile
• Your projects span more than one team and you therefore need to figure out how to get them to work together
• Teams typically are working on many projects at one time
• Analysts and/or testers belong to another organization and you can’t get everyone you need to be available when needed

As I mentioned in my blog  “Questioning Why (not if) Scrum Works”  I believe much of the success in companies adopting Scrum have had to do with teams creating themselves as workcells and working on only one project at a time.  This aligns with the Lean principles of limiting work to capacity and using pull methods.  This is a great start and does not mean to imply Scrum is not great or shouldn’t be used.  Unfortunately, people are not always aware of why they’ve had success.  This has them miss opportunities for improvement even when agile methods aren’t available as well as makes it more difficult to remove impediments when the do use agile and impediments show up (as they always do).

Let’s look at each of the above to demonstrate what I mean.

Management Is Not Sure About Scrum.

This is more typical than not.  And why should they be sure about Scrum?  They are really interested in the ability of the business to respond to change (we call this ability Enterprise Agility).  These changes come in the form of competition, environments, business opportunities and the like.  Software development teams are instruments for the business achieving its needs.  In other words, good business managers are interested in Enterprise Agility which they can achieve through Team Agility.  Unfortunately, it is not always apparent to them that agile methods will give them this.  Not if it appears to them that agility means they can’t predict what they are going to get.  This is a common result when team members talk to management about agility from the perspective of the team instead of the perspective of the organization.

Lean’s Enterprise focus can include both the business' perspective and the teams’ perspective.  It emphasizes delivering value quickly in a sustainable way.  It talks about the competitive edge of delivering fast and gives the insights on how to achieve this with high quality.  It focuses on cycle time instead of resources utilized. It gives managers on the business side of things something they can relate to and work with to improve the development side of the organization.

Your Projects Span More Than One Team.

Many agile teams attempt to solve this with Scrum of Scrums. Scrum of Scrums will work when you have an aligned organization.  But without one, how do you get one?  Scrum’s team focus won’t necessarily help. In the same way a group of individuals working independently on related topics does not make a team, teams working on the same project sharing information does not necessarily make a cohesive organization. Lean’s “optimize the whole” principle can assist in aligning the teams.  Value stream mapping can also help because it provides an overall view of how the teams can work together.  

At Net Objectives we used to do Scrum of Scrums in an attempt to coordinate and integrate teams.  We found that it works well (and we still use it) for communication - that is, it is effective for letting people know what is happening.  However, if you need to direct teams in a coordinated way where some of a team’s stories neither help them directly nor add value to their customers (i.e., when you are adding value to other teams or their customers), you need more.  We’ve come up with techniques for this based on Lean principles.  This blog is already too long to go into them here.

Teams working on many projects at a time.

This common practice has disastrous consequences for many reasons. First, efficiencies of the people involved go down dramatically due to context switching which results in thrashing.  Second, key people are stretched even further than normal – making them thrash, but also greatly increasing the wait times others have to be able work with them. Think of the number of e-mails you have outstanding to get information you need to get a sense of this.  But perhaps greatest of all, the time a project takes greatly expands because teams are applying only a small part of their resources to any one project – thereby forcing it to take longer.  This has a double whammy affect.  First, it increases the time from project initiation until value delivery.  Secondly, it causes delays from when errors are created (e.g., misunderstood requirements, code bugs) until they are detected – greatly increasing waste and thereby decreasing value delivered. Ironically, this has product managers ask for even bigger projects to take place because they know it will be a long time before they get a return.  This causes (at least) two vicious cycles.

Vicious Product Portfolio Management Cycle #1:

• Teams are working on many projects at a time
• Projects take a longer time to get completed than if teams were working on only one project
• Since learning what customers truly need often takes place at the end of the project, obtaining this knowledge is greatly delayed
• This means delivering the truly important things is delayed
• It is harder to complete projects on time
• Product managers feel even more pressure to get what they need done in their next project
• Product managers ask for even more items to be accomplished

The size of the project increases making it take even longer and therefore runs into the timeslots given to following projects

Vicious Product Portfolio Management Cycle #2:

• Teams are working on many projects at a time
• Projects take a longer time to get completed than if teams were working on only one project
• When a product enhancement is needed, product managers feel compelled to start it immediately instead of waiting until the current projects are done
• This new project slows down the other projects making them take even longer than they would have
• This makes current projects run into the timeslots reserved for following projects

Breaking these cycles requires a lot more than merely having the teams work better.  It requires effective product portfolio management.  Lean’s principles of Optimize the Whole, Deliver Fast, Defer Commitment, Create Knowledge (and others) will greatly assist here.  In particular, Lean’s mantra of delivering small, high value items quickly with high quality, will give great guidance in how to solve this problem.

What We Can Do

The bottom line is in order to fix the problem we have to work on the problem.  In many organizations, the biggest problems faced by the teams have to do with:

• The number of projects they are working on
• The size of the projects they are working on
• The structure of the teams
• The metrics of the organization

Agile methods focused on the team will have little impact here.  Talking about these challenges to executives will not be effective unless you can come from the executives' perspective.

Lean Thinking can help greatly here.   Agile thinking, when it includes Lean Guidance, can be greatly effective as well.  But if agile practitioners focus only on the team they will not be working on the true problems their team is facing.

Alan Shalloway
CEO, Net Objectives
Achieving Enterprise and Team Agility