Having recently watched the Stephen Hawking film The Theory of Everything, I consider myself a bit of a physics expert and was struck by the desire in the software delivery industry to find a magic, simple approach to building software and say, We are done. To steal from Fred Brooks, there is no silver bullet. Or, to be more precise, there is no one approach that will enable every organization to deliver on the promise of enterprise Agile. Instead, there are things that may or may not help you to deliver software faster, cheaper, and to wow your customers. At the heart of it, the things that make large scale software delivery work are VERY different from the things that make small scale software delivery work.
The Agile Manifesto provides a great set of principles for helping teams deliver great software. It came from both a focus on what works and a revolt against heavy processes like the Rational Unified Process. It concentrates on how teams need to work together to deliver software and it discards many of the practices that were being encouraged to allow large organizations to deliver software.
The four main principles are:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiations
- Responding to change over following a plan
If you read these four principles you would think that teams collaborating with the customer to deliver working software, in a situation that supports change, is the ultimate end goal of Agility. And you would be right. In situations that support this model the result is true Agile. But what happens when:
- You have a large problem that requires a large group of people to solve it
- There are lots of dependencies among those groups
- The customer cannot be easily collaborated with
- The business needs to know when things are happening in order to plan other things
- And you need to prove to other people that your software works
Now, if I were a pure Agile advocate, I would say Dont worry about that. If you document these constraints and provide the freedom for the teams to solve these problems everything will be okay. In my experience, if you do that, or help the teams build a workable environment to deliver software in-the-large, you will end up with many of the characteristics that Agility railed against. But you will also end up with a team centric approach augmented with process, tools, documentation, commitments and plans.
So, what about that grand unified theory? Is it possible to build a model that allows you to describe a software project in-the-large with limited effort and then (as if by magic) deliver on that model? Perhaps, but not yet. We are only just discovering how to better align business, technology, process, analytics, and tools to enable better software. And without process, tools, documentation, commitments and plans we will never get there! So stop kidding yourself Agility in-the-large is not the same as Agility in-the-small.