I have been asked several times in just the past two weeks whether I believe that you can “apply Agile” to every project. This is a very interesting question to me, since I believe that agile is a culture, and not a defined process. To me, this question is much like asking whether you can apply your religious beliefs to every situation in life. Agile is a way of approaching software development, and if you are truly “doing agile”, you will continue to use that same approach for every project – you can’t simply set aside your core beliefs regarding how quality software is developed. To say that it doesn’t apply to this product indicates that you don’t believe that you can develop this project to meet real customer needs with a high degree of quality. Why would anyone take on that project in the first place?
I was very interested to read Alistair’s explanation of applying agile practices to home building. This really shows how these concepts are truly universal, and can really be applied to many different situations.
When people ask if agile can be applied to any software project, I believe that what they are really asking is whether the specific agile implementation that they are familiar with can be strictly enforced for any project. Of course, the answer to this is “No”. As a matter of fact, I believe that ANY implementation of agile cannot be strictly enforced – defining an agile implementation (like XP or Scrum) is an oxymoron.
To truly “do agile” one needs to look at the environment, understand the people involved, know the product and its complexities, and then put in place the pieces of certain agile processes that make sense for that environment. You have then created a culture where software can be developed with minimal documentation, a test-first mentality and most likely with daily stand-ups and automated testing. You take the values from agile and create a culture of software development that results in high-quality products that meet real customer needs.
When you create this culture, you do not set it aside for some new project that may not seem to fit into an agile process. Instead, you mold your processes around the culture you have created to meet the needs of this new project. Being an agile development team means more than strictly applying an agile process – it means being agile in the very definition of that process, and molding the processes and procedures to meet the needs of the project.
It’s important to remember some history behind Agile. Most of the concepts actually come from The Toyota Production System (TPS), which Jim Womack, in the mid-80’s, called Lean and that name has stuck ever since.
Agile came about as a response to big-design-up-front approach, or waterfall. Lean approaches things via one-piece flow, as opposed to batchy manufacturing practices that the American auto manufacturers followed. An analogue to “batchy” processes in software is the extensive documentation up-front, which leads to requirements churn because things change. So, a lean approach is to apply one-piece flow, or small increments, but many iterations.
Lean is being applied everwhere — from service industries to healthcare to, of course, manufacturing.
Here’s a good introduction to Lean for Software.
Keep up the good work. Nice blog.
I agree with you that Agile is a mindset with a caveat. I’ve been a proponent of Agile processes on many projects and I’ve noticed an interesting tendency to start using “Agile” as an excuse to do things wrong. When someone just wanted to skip out on writing something down in any fashion they’d say, “Hey, we’re supposed to be Agile, right?” So I’d say that Agile is a mindset and a way to solve problems, but it is also a core set of practices that can’t be diverged from and still be Agile.
It’s interesting to think about what that core set of practices really is outside of software. I always liked Larmen’s discussion of “New Product Development” to describe the basis for Agile processes. Ken Schwaber’s description of the 3 legged stool also resonated with me, “visibility, inspection, and adaptation”. His use of the term “Empirical Process Control” also is a better label to me than “Agile”.
I think you’re right that it can be applied to many other problems. The core of Agile is just using feedback to improve your outcome in a measurable fashion, which as the other commenter pointed out comes from Japanese process engineering for the most part.
I work at Appistry where we make grid virtualization software to scale out applications in a lightweight fashion on commodity hardware. I think that we are a great platform for agile software projects because our core philosophies enable the Agile process problem solving approaches. I see ourselves as enabling agile hardware architectures.
later,
jasen