oon after I joined a startup online service company I realized that for the first time in my career there was no project manager keeping track of the team's progress and helping clear obstacles. The absence was noticeable in the disorganized manner work was delegated, tracked, and planned. I had just come from a dot-com that was trying out Scrum and I had become an enthusiastic believer in the efficacy of the process. So, I set about figuring out how to sell Scrum to my IT department and business management.
In this article I'll attempt to use my experience to help you advocate for implementing Scrum at your workplace. I'll help you predict and avoid the obvious pitfalls and help you prepare for the questions that are sure to arise from your colleagues and managers. This article presumes that you are familiar with basic Scrum and agile terminology. Some exposure to the concepts of Lean development is helpful but not essential. This article won't detail what Scrum is or how it works but you can find pointers to excellent books and online information in the resources section at the end of the article or read our short, practical guide to Scrum.
Scrum Process ControlKnow What You're Selling!
Scrum is a project management methodology, not a development methodology and is based upon empirical process control theory. Scrum's roots can be found in the Lean Manufacturing concepts that were most successfully advanced and implemented by Toyota over the last few decades. These ideas were ported to software development by Jeff Sutherland about 13 years ago. Jeff Sutherland and Ken Schwaber formalized and commercialized the process known as Scrum. You can find pointers to their work in the resources section at the end of this article.
A simplified definition of empirical process control is that processes are monitored and controlled with awareness of what is really being produced and a willingness to make changes based upon these observations. Manufacturing, in contrast to software development, usually has a well defined and fixed set of inputs; this makes it easy to implement rigid schedules. Due to the more predictable nature of manufacturing processes a prescriptive control methodology is appropriate. However, when a prescriptive control process is applied to an inherently volatile undertaking such as software development, both management and development personnel suffer the consequences.
The "Lean ideal" is to approach the building of anything in such a way that continuous process improvement efforts are considered an essential part of what is being built. Self-managing and self-organizing teams are empowered to make choices to improve the product and make their work more productive and enjoyable. I hope to delve into the evolution of Scrum from Lean concepts in a future article but if you're in a hurry Mary and Tom Poppendieck's book "Implementing Lean Software Development: From Concept to Cash" is a great resource.
The book outlines key Lean concepts that improve software quality. Many development managers and IT professionals (not to mention business people) still conceive of software development to be like manufacturing. Therefore, understanding Scrum's roots in Lean manufacturing can help you make the case for Scrum by discussing how these progressive ideas map appropriately to software creation. These ideas aren't of the 'flip a switch and you're done' variety but rather concepts or themes that guide the way processes flow in your organization. In her paper, "Principles of Lean Thinking," Mary Poppendieck succinctly lists these basic principles as follows:
The Basic Principles of Lean Development
- Add Nothing But Value (Eliminate Waste)
- Center On The People Who Add Value
- Flow Value From Demand (Delay Commitment)
- Optimize Across Organizations
These basic, underlying principles are then applied to translate Lean manufacturing concerns into the software development concerns listed below.
The Seven Wastes of Software Development
- Overproduction = Extra Features
- Inventory = Requirements
- Extra Processing Steps = Extra Steps
- Motion = Finding Information
- Defects = Defects Not Caught by Tests
- Waiting = Waiting, Including Customers
- Transportation = Handoffs
Check out the resources section of this article for more information about how to translate these golden rules into development best practices. For now, I'll turn my attention back to making the case for Scrum.