This is the first in a series of articles I plan to write on Agile development, software development in general, and generally getting things done in the workplace. Hope you enjoy.
For decades, the waterfall project model has been the accepted way to build software in large companies. In this traditional approach, every phase of a project follows logically after the previous one, building upon the work that has gone before in a nice orderly flow. At the end of every phase, the entire extended project team gathers together to review the results of that phase, nod together in agreement that the deliverables are satisfactory, and sign off on those deliverables before moving on to the next phase. It is a calm, rational approach that appeals to project managers, CIOs, and accountants. And if everything goes as planned, it truly is the most efficient, predictable, and repeatable way to work.
Of course, if everything were that predictable, you could hire a precisely calculated number of monkeys, equip them with laptops, and develop the code base that runs the space shuttle in just under 3.26 years (I have the calculations from Wikipedia if you want to try this on your next project).
The fact is, once you leave the tidy world of 1000-line Gantt charts and look around you, reality quickly intrudes. The stakeholders refuse to sign off on the requirements until halfway through the development phase, and then only if you agree to add three more "tiny" requirements that they forgot to mention earlier. The technology that you chose to implement the core of your system doesn't do everything you expected it to do, so you have to write custom code. Your QA lead goes on maternity leave two weeks before testing is scheduled to begin. By the time you're done, your soothing waterfall has become a raging cataract of inefficiency and missed opportunities.
This realization has led even the most staid companies to consider their alternatives, the most attractive of which is Agile development.
Agile is not a single unified methodology, but rather an umbrella that covers several different approaches to software development, all guided by the principles of the Agile Manifesto, a statement of purpose that was created by some of the leading minds in software development in 2001, which says:
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
This simple statement strikes fear in the hearts of order-loving managers everywhere while simultaneously energizing their teams. What if you actually believed this? The possibilities open up:
- Developers could spend their time writing code instead of documents
- Analysts could actually talk to customers instead of guessing what they might want
- Stakeholders could actually see an application in action before code freeze (or, in some cases, launch)
- The most important features in a project could be live in production and serving the customers in half the time it would otherwise take, with additional features following at regular intervals
- The inevitable change requests and additional features could become a point of conversation instead of conflict
- Business people and technical people could work together on the same team, instead of lobbing paper grenades at each other over a wall of organizational dysfunction
No wonder the managers in those big companies are nervous. The potential competitive advantage is clear, but they have no desire and little authority to turn the world upside down in the name of better software. Software isn’t their livelihood; it’s just a tool to get the real work done. So how can they get there from here?
Fortunately for them, there is an answer: Agile for the Enterprise. The trick here is to recognize that a large financial services firm can't pretend that it's a small software startup, nor should it. The answer lies in fitting the Agile methodology to the environment, not in making the environment Agile-friendly. When you recognize an organization's constraints -- distributed teams, offshore resources, separate teams for development and maintenances, project audit requirements, etc. -- then you can craft a solution that fits within the culture, or even takes advantage of it. Rather than saying, "Build your business around our development efforts," you say, "Let's make our development efforts actually serve our business." It's still a change, and it's still scary, but it's no longer doomed to fail.
Get ready: we’re taking the plunge.
Want more information on Agile Development? Start here: http://en.wikipedia.org/wiki/Agile_development