“I’ll never know less about this goal than I know right now.”
This is the final sentence in my previous post in this Agile series. I feel it is the perfect segway (if not a full-blown shortcut) to answering our next question: “What is Agile?” (and what is it not). To dive further into this question, let’s go back to the most popular methodology of delivering software prior to Agile’s hostile takeover.
Waterfall Methodology (or Waterfall Model) is a very tried and true way of delivering software. For decades, it worked quite well. Teams gathered requirements, created a design, implemented their requirements/design, tested and verified their work, and then deployed to production. After releasing the product(s) they were in Maintenance Mode where they would release improvements/fixes until the software went out of date and they’d start the cycle over again. So, what changed?
Technology.
More specifically, the speed of technology’s growth.. When an industry moves slowly, you can plan slowly. “Ready. Aim. Fire.” Congrats, that you nailed the target! So what if it took you a while to aim? The important thing is you hit the target. But what happens when your target is moving so fast that by the time you fire, your target is no longer in sight? You have to switch up your order and react quickly.
Ready. Fire. Aim. …fire again.
Keep repeating until an arrow hits the target.
This is Agile, and this is why it was created. As technology needs (software, to be more specific) began to change more rapidly, Waterfall projects began failing at a higher rate. Projects that did succeed were often delivered well past any concept of a due date. This created what was referred to as “The Application Development Crisis”. The average delivery time for just one project was three years. AVERAGE. There were many projects that were much longer.
These delays were due to the large amounts of requirements and designs that would be documented in the early stages of projects and then have to be reconfigured over and over to handle changes late in the project. If lucky, this would mean schedule and budget changes. If not, it often meant failure – even years into the project! The industry needed a better way to manage these constant changes.
Jeff Sutherland, John Scumniotales, and Jeff McKenna were the pioneers to start this process (or at least the most successful ones to do so!). Following Rugby’s example of “passing the ball back and forth”, they created what they called “The SCRUM Development Process” while working at Easel Corporation in the early 90s. Their efforts later culminated with a larger group of industry leaders on a 3-day ski trip in Snowbird, Utah in 2001 where the Agile Manifesto was born. I imagine that trip to have been several potluck-style meetings where the group told their Waterfall project managers they were not allowed …unless they brought food for everyone and promised not to talk. 🙂
NOTE: Remnants of Agile can be traced back further outside of the software industry (see Toyota’s Takeuchi and Nonaka), but as a formal software development methodology, the manifesto was the beginning as an organized methodology.
If you want to read more on the detailed beginnings of Agile, a quick search will give you hours of reading. For now, I’ll move on.
Although people, such as co-founders of hip software companies, like to write countless articles about the subject, at its core, Agile is very simple. This was the purpose of the Manifesto. Communicate a set of values that frame successful software development. Then bolster those 4 values with 12 principles.
The 4 Agile values are:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
The next line of the Manifesto reads “That is, while there is value in the items on the right, we value the items on the left more.”
I’ll touch on this again in the second half of this post, but let me just say that I think this is an aspect in which many modern Agile teams have failed. Too often we put so much focus on the left that we imply (and even act as though) we do not value the items on the right.
Speaking from personal experience, focusing on the left at the expense of the items on the right is the fastest way to lose the trust of stakeholders. It’s also a great way to derail large projects. If your car has no brakes and slick bald tires, I think we’ll all agree that NO ONE is driving til the brakes are fixed, but the tires must be replaced before you drive it across the country for the family vacation. Less important does not equate to non-critical.
So, quick summary before I pause for discussion (and then we will wrap this up with Part 2 in a couple of weeks):
Agile was created to address the lack of flexibility in Waterfall project development in an increasingly fast-paced technological world. Agile shifted the focus from planning and executing end-to-end solutions towards creating working software as quickly and efficiently as possible while fully expecting the final product to be different than original requirements. And, rather than fight against this notion of change to protect the timeline and documentation, welcome the change while interacting closely with those that request it so they understand the impacts and outcomes of each decision.
I don’t care if your programming is Extreme, SCRUM or no SCRUM, Kanban or no Kanban. THIS is Agile. It’s a way of thinking, not a framework.
Sooo, this post turned into a history class. In the next one we’ll dive more into the practical application of “WHAT” Agile is. For now, I’ll pause and ask for feedback from anyone out there who was present during this shift in software development from Waterfall to Agile. Please jump over to our LinkedIn and share your insight or experience – whether it is something industry-level or just from a single team!
(Stay tuned for Part 2 where we’ll dive into the importance of VALUE in an Agile delivery model and touch on everyone’s favorite topic – timelines & estimation.)
