Some people in the Lean-Agile community think of me as an outspoken critic of Scrum.  That has never been my intention. My intention has always been to help people do software development effectively. I am not against Scrum, I am for something - effective software development at the entire organizational level. Since its inception, Net Objectives' vision has been effective software development without suffering.   Sometimes, however, when you are for some things, you have to speak up against other things - especially if  the two are opposed to each other.  I am not speaking against Scrum per se, I am speaking against claims made about Scrum that are hurting people.

Let me explain. I have worked with dozens of companies transitioning to Lean-Agile methods.  I have watched other Net Objectives consultants work with many dozen more. Except for the simple cases of where only one or two teams were involved, these companies needed to know a lot more than merely Scrum. They needed to know:

1. About flow and how delays and too much work in process (WIP) adversely affects it
2. That most errors arise from the system they work in, so better systems will achieve better results
3. About using value streams to assist in figuring out problem
4. That one must evaluate the effectiveness of any local work by looking at its affect to the entire value stream
5. That there is little value in making a team agile if it does not help the business become more agile
6. That the problems teams have are often caused by issues having little to do with the team
7. That management is very important in anything but a team only agile transition
8. How to align disparate members of the organization that are currently working to optimize their own responsibilities

My issue is not with Scrum. Rather, it is the belief that starting with Scrum is always an effective approach or that all teams can benefit from Scrum. Scrum was originally proposed as a team process that began after a project started. It's sometimes hard to tell what it is nowadays, but I'll use this as a definition since this is what is taught in the Scrum Alliance's CSM classes. In our experience at Net Objectives, most of the issues facing software developers in large organizations are outside of their control and require stronger methods than timeboxed iterations.

Unfortunately, the industry has almost defaulted to beginning an Agile transition by sending people to a CSM class and starting a Scrum pilot project. Ken Schwaber has acknowledged that "75% of those organizations using Scrum will not succeeed in getting the benefits that they hope for from it." The question is why? Is it because people are doing Scrum improperly or is it because Scrum doesn't provide the insights needed to fix the impediments stopping its effectiveness.

Many Scrum consultants would say that the power of Scrum is in being a lightweight framework within which the team figures out how to solve its problems. It is a correction to overly burdensome processes of the past. But is this the right focus? It depends. If the team has been set up to solve a particular problem and it is free to do its work and is not affected by outside impediments, then I would agree that they could get away with little more than their wits and commitment. (I believe they would still do better with some Lean-Agile thinking). However, if that is not their situation - and most teams have to work with other teams, or are impeded by other parts of the organization, or do not have clear priorities - then I would say that such a parochial view is dangerous. It leaves people un-prepared for their work. 

This is why I am so vocal: To alert people that there is a lot available beyond Scrum and that knowing these things will increase their chance for success. There is plenty of useful knowledge that others have learned and we should be using it!

To help people understand the importance of these concepts, I will be writing a series of blogs dealing with these specific issues. These blogs will be:

• The importance of creating proper systems / environments for people to work in (covers point 2 above)
• The importance of flow, delays an WIP limits (covers point 1 above)
• Value stream mapping and optimizing the whole (covers points 3, 4 and 5 above)
• Management's role in a Lean-Agile transition (covers point 7 above)
• Why you must see where you are in order to know how to start your Lean-Agile transition (covers point 6 above)
• A summation of the above to take as an approach to align an organization (covers point 8 above)

Our vision - "effective software development without suffering" - has two important parts. The first is that one must have the right attitude. In other words,suffering is often caused when one feels they are a martyr or victim in their work or life. A better attitude can make a big difference.  However, often having the appropriate tools can make one's life easier. In other words, while being enlightened may help you deal with the pain, dealing with the problem also helps eliminate the pain.  You need both: A combination of effective people skills along with an extensive knowledge of what helps you get your job done.

But please don't take offense. It doesn't matter what either side is saying; what matters is what the community is doing.

This series of blogs is for those who are trying to help their organization be more effective. I want you to know that there are effective methods that can help transform your organization. While we don't want overly burdensome processes, throwing out what works is throwing away the baby with the bathwater. Let's use what works! We don't have to figure everything out on our own.

Alan Shalloway
CEO, Net Objectives
Co-author of Lean-Agile Software Development: Achieving Enterprise Agility

Technorati Tags: Lean-Agile Scrum

tag with del.icio.us