Agile is Not Scrum, Part 2

A while back I wrote a post entitled Agile is Not Scrum. Machiel Groenveld commented on that post:

There is quite a bit of frustration in this post. You say you’re not bashing Scrum, but you are bashing something, I can’t make out what exactly though.

This question has been percolating since I read it, and I think I have my answer. I get what is so frustrating to me.

The typical developer in a a small to mid-size IT department has more responsibility than simply writing code. He takes action when the network goes down. She gets called when the receptionist can’t “find her email”. This is just reality for many.

The Software Craftsmanship movement is about getting everyone, even these developers to care about quality and form. We can easily agree that it is a big win to move folks beyond drag and drop to deliberate software design.

I propose we stop dragging and dropping Scrum on these teams. Explore alternatives that may very well work better.

The Conversation

The situation is typified by a real conversation I had with a Guild 3 customer recently. It went like this:

Customer: So, my developers are telling me we gotta get some of that Scrum around here. Can you teach us that?

Me: Well, yes. I can teach you how Scrum works and how you could use it, but I don’t think that will help here.

Customer: Why not?

Me: Not to be cheeky, but this is our 3rd phone call and you’ve been late to each one. You haven’t been able to stay for the entire scheduled time in any of them, and you constantly describe your environment as “on fire”.

Scrum says that the Product Owner may not change her mind for 2 weeks or so. Even a week is possible, but you must allow the team to focus without changing your mind for some period of time.

Customer: You know me pretty well, I see (laugh). I can’t commit to a set of work for 2 weeks.

Me: I know. That’s why I don’t believe Scrum will work for you. Yes, Scrum works for those companies whose business is supported by the model, but that isn’t how you do business.

The core of Agile software development is communicating well with our customers, and delivering well-crafted software iteratively. If you buy into those ideas…

Customer: I do!

Me: Great! Then the only thing left is to find a structured way of developing software that supports your business. Trying to change your business to support a process like Scrum just doesn’t tend to work in my experience with an environment like yours.

Customer: I like that a lot. So where do we go from here?

Me: Let me tell you a bit about this Lean stuff…

The Reality

You may be tempted to be frustrated with the client here. You may want to say, “But, the way he’s doing business isn’t effective! Context switching is killing him!”

I agree.

I also recognize it is a long road from this situation to a Lean or Scrum-Driven organization. The most effective path to get there is hardly to say, “Well, the team needs you to commit to 2 weeks worth of work, so just do it.”

Even if he agrees, the more common causes of flaccid Scrum will remain:

• No identified Product Owner other than a departmental manager or lead.
• No consistently groomed and managed backlog. The team will end up having to define their own backlog.
• No respect for iteration boundary

And the last ugly truth is that I don’t know these people’s business enough to say that their constant priority shifting is wrong! It may well be perfectly appropriate to their business. I don’t know enough yet to make that recommendation, I just know that there would be a huge cultural change needed to make Scrum effective here.

An organization trying to implementing Scrum is more often than not trying to change their existing culture to fit the process, rather than the process being flexible enough to accommodate the organization.

The Advantage of Lean

In my experience, sure signs of Lean being more appropriate than Scrum include:

• The person who developed the application is responsible for keeping it running in production.
• Software developers have duties that call them into tactical fire-fighting situations like bringing up a dead network, or troubleshooting an ailing Exchange server.
• The organization does not think in terms of “Products”.

I think this describes many small to mid-size IT departments. When you are dealing with smaller teams, people tend to have responsibilities beyond just that of writing code.

This doesn’t fit well within Scrum. Although it can work, it is a constant discussion and point of tension rather than an an embraced situation. Lean allows us to embrace this reality.

The advantage of Lean is simple. Lean say’s let’s take what we are doing now, and make it better. Let’s identify what is working, and use it. Let’s find what isn’t working and change it. Let’s just embrace the reality of our organization and support the way our business needs to do business.

I don’t need a lot of $5 consultant terms like “Scrum Master” to help a team start becoming more effective almost immediately. We just look at what is happening today and how that’s going. Then we propose and execute small changes everyone can agree on.

This is often a palatable way to begin the transformation to a truly agile organization.

Conclusion

Introducing a team to Scrum when Scrum’s rules won’t be respected by the organization is a failure waiting to happen. Although a Scrum-driven organization is a beautiful and highly effective thing, it isn’t always possible due to conflicting needs and values of the organization.

Lean practices offer a viable alternative for many teams looking to adopt agile practices.