The agile revolution

- Being a traditional waterfall project manager made it really unlikely that your project would be successfully completed, let alone according to the plan you laid out at the beginning. It was more like being a weatherman doing a forecast for a specific day next year. Except for random luck, you'd be wrong. Waterfall, as a methodology, is not inherently a bad thing. In some cases it makes good sense, like in building construction, where a predefined set of steps, when executed in order, will result in a building. You can absolutely plan and schedule that whole project upfront. It happens every time a home or an office building is built. The problem comes when applying the technique to highly empirical work like software development. Empirical work is more like a science experiment. You try something, check out the results, and if it didn't work, you try something else. You certainly can't do that when building a house, but with software or some other products, you do it every day. That's the crux of why waterfall didn't work well for software development. You literally cannot upfront plan the process of discovery. The frustration of highly-skilled software developers working on waterfall projects was the tipping point that led to the Agile revolution. Tired of having a failure rate equivalent to a weatherman, these individuals decided they had to come up with a better option. The result is known as the Agile Manifesto. Grounding themselves in the mindset of lean manufacturing, where you do just enough just in time to meet the goal, they started figuring out how that applies to software development. The result is the Agile Manifesto and its underlying principles. Take a look at the Agile Manifesto. You can check it out at this online address. As if these words weren't revolutionary enough, this group of innovators supported this manifesto with 12 key principles. This manifesto and the principles became the foundation for a new set of project management and software development methodologies. There are a couple of overriding themes that make Agile different. One of the key changes is that we're asking our business partners to work with us throughout the whole project, not just show up at the beginning to describe what they want, then show up at the end and tell us how we missed the mark. We need direct, ongoing interaction to deliver what they really need. Another key is that we no longer want to measure success using milestones and project phases. We want working software to tell everyone how we're doing, and we want to hear feedback the whole time. Perhaps the most revolutionary change is to allow teams to self-organize. They'll do a much better job doing the design and tests from the ground level than any upfront plan could do. Upfront planning is theoretical. Evolving design is both practical and tactical. It'll get you to your goals faster, with higher quality. Between the manifesto and its principles, this group of developers was done being the high-tech software versions of the weatherman. They were ready to succeed. There is a better way to do software development, and it's Agile.