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:
However, more often than not, teams are in a situation where:
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:
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:
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:
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