Agile/Lean Principles Simply Will Not Scale

[From the Archive: Originally posted at Amplify.com Dec 29, 2010]

A somewhat contentious title in this clipped post (intentionally on the part of the author) but a post congruent, in general terms, with my recent “State of Agile” piece.

Amplify ’d from www.linkedin.com:

Agile and Politics Like Oil and Water

Agile/Lean principles will simply not scale. Ah good now I have your attention. The truth is that Agile development can scale in small, medium, and large companies, but they typically won’t. Now I am not saying this to upset Agile and Scrum purists. I have had the opportunity to work in small development companies (i.e. iLinc Inc.), medium size companies (i.e. Syntellect, Inc.), and larger companies (i.e. US Airways, GoDaddy.com), and I can tell you that Agile, for the most part, is not working there. It has been over 9 years since Agile was first introduced as a development methodology. Agile was developed during a ‘pow wow’ in Utah in February 2001. For more details on this please check Wikipedia (http://en.wikipedia.org/wiki/Agile_software_development) or the Agile Alliance website (http://www.agilemanifesto.org). Today there are more and more software development companies adopting Agile, Lean, and more iterative development practices and methods. The idea being that they can increase the quality (or at least not lose any) while simultaneously speeding up the “Time to Live”. This is a great thing; however here is the problem.

Now how does this relate back to Agile? Well if Agile will expose waste, and your job is pointless, then guess what? You are out of a job.
Therefore when Agile is introduced into a large company with a lot of these unnecessary positions, those people are in big trouble. Of course, if these people can get management to somehow not by into the Lean/Agile approach to doing business, then they may keep their positions.

In an attempt to shed a little light on this topic I would like to offer an approach to this issue where those who are “hiding in the details” to find a place in the new methodology.

First: Be the scrum Master. Now this topic could be its own article and I may actually write one on it one day, but lucky for you today is not the day. Just know this a Scrum Master is the person with the least amount of control or influence. A big problem is that development managers freak out and jump on this role because they think it is the one with the most control over the team. Sadly it is not. The scrum master is more like a waiter in a big restaurant. They are the servers to the team. The reason
development managers take on the role of a scrum master is because they hear that the team is “self-organized” and therefore they are no longer needed. Again this is not the case. A Scrum Master, is the process cop. The scrum master is the organizer and assistant to the team. This would be a great role for someone that can make the move to learning how Scrum or XP SDLC should be done, and not have a vested interest in the success or failure of the project.

Second: Be a SME (Subject Matter Expert). As you have been in your role for a long time you surely have picked up a few details and tribal knowledge that needs to be shared. Take that information and offer it up as part of the team. Help with the requirements gathering and defining of acceptance criteria. This will be very important as the team needs to capture this information as early as possible in the process.
Read more at www.linkedin.com

– Bob