I have been more successful with Agile processes than any alternative I have tried in my 40 years of programming. My early work predates even phased processes like waterfall. Roy Singham, our founder, often teases me by claiming I invented waterfall. Not true; however, I was one of the programmers IBM experimented on with waterfall in the early 70's. I even did a stint in an IBM programming practices group. So when I say have been more successful with Agile, I have tried quite a few other ways.
I have found that there are three critical enablers for successful Agile projects:
- Writing code in a style that let's me change it easily
- Using a compatible management practice (not Gantt charts)
- Throwing heaps of processing power at it
Writing Code That Can Change
I have previously discussed this in The Secret Assumption of Agile. If you can ignore future requirements while working on the requirement for today, you gain enormous productivity. But you can only ignore the future if your code can tolerate the constant changes demanded by that ignorance of the future.
The premise of Agile is that you absorb requirements as they come in, and you accommodate the change the new requirements demand. Does that mean the code you write today may get thrown away? Possibly. Perhaps, even likely. I estimate that for every 100 lines of code I write, I probably wrote and discarded 200 other lines of code. Wouldn't it be faster if I wrote it right the first time? Sure, but not if I have to think about it. What if in order to get it right, I would have to think about it (design, model, review) for the time it would take me to write it 10 times in Agile? That was my experience in waterfall. We often measured how much of the development dollar was actually spent coding (versus reviewing, being in meeting, creating designs, etc.). The answer was ten cents (10%). If I invented the best programming IDE in the world and could instantly write code in it, I would only save 10% of the programmer cost in a waterfall process. So don't spend too much time worrying about how much code I threw away. Rather, measure how quickly the development was done.
For me to spend most of my time coding, I need to code in a style that will not slow me down when I make changes in the future.
Agile-Compatible Management Process
The second critical enabler for Agile is to realize that common project management techniques are not compatible to Agile. These management practices assume that
Software is like building a bridge.
In other words, it is a step-wise process requiring that each step be completed before moving to the next (or almost completed). Hence I need complete requirements before architecting; complete architecture and design before starting construction; and construction must be done in a precise order (physics requires that the pillars be laid and cured before building a road bed on top of them).
But this doesn't sound like Agile. We are overlapping the phases almost completely. And software is not bound to the physics of civil engineering. It is called soft- for a reason.
Rather, Agile is much more like a production process. Indeed with Agile, I think
Software is liking making cars.
What is the best process for making cars? The Toyota Manufacturing Process, renamed Just-in-Time (JIT) when moving outside Toyota, and subsequently renamed Lean when moving outside of manufacturing.
Look for many more posts on the use of a Lean management process for managing Agile.
For now, consider the use of a Lean management process a critical enable for Agile success.
Agile thrives on processing power. I like using the term horsepower. It directly effects the productivity. Consider the typical use of processing power in Agile:
- Using OO languages with interpreters and virtual machines
- Running complete suite of unit tests before checking in
- Use of powerful refactoring IDEs
- Continuous builds being run with suites of tests
- Key code metrics being collected constantly (test coverage, duplicate code checking, etc.)
In an Agile project, you wouldn't choose to not do any of these things. ("Let's use Notepad. It is runs faster than eclipse." "We could use C instead of Java. Java runs too slow on my machine.") When some aspect of the development process is taking too long, the first choice should be to throw more horsepower at it. It is much cheaper than people's time.
Agile in the 70's?
If Agile is so much better, why did we adopt waterfall processes in the 70's? Why didn't Agile emerge earlier? Perhaps we were stupid. I would rather think that we didn't have the enablers:
- We didn't have the languages (Java, C#, Ruby) and techniques (OO, rules engines) to write code that could be changed. Our paradigms were actually the opposite: Design your data structures, and the code writes itself.
- JIT (Lean) hadn't made it out of the automotive manufacturing sector.
- We didn't have the horsepower. I have more memory in my watch than I had in my first computer. And don't think of comparing an entry iPod to the first PC.
So basically, we couldn't do Agile in the 70's. But we can now!
Is your organization still stuck in the 70's?