If you were to search “What is the Agile Scrum Methodology of project management?” you’d find this:
“…an alternative to traditional project management, typically used in software development. It helps teams respond to unpredictability through incremental, iterative work cadences, known as sprints. Scrum is one framework used to run a project using the Agile Methodology.”
And while that is useful information, to really understand what using Agile offers your project, you need to understand the values that guide the method– the “why Agile and not something else?” piece of the puzzle.
Value #1 - Individuals and interactions OVER processes and tools
To understand these values, let’s start with two, fictional companies. The first company, we’ll call them Client Yellow, wants to hire the second company, we’ll call them Vendor Green, to build a widget. In days past, Green would pull out a massive, detailed plan that explained every tool and technology that would be used to build the widget. This was a “one size fits all widgets” process that often would bury the reason why Client Yellow needs the widget because the focus would be only on what exactly is being built and how exactly to build it.
Value #2 – Delivering value and working software OVER comprehensive documentation
This Agile value is the backbone of the “Agile vs. a more traditional approach” argument. Looking at our two companies again, let’s imagine that Vendor Green sits down with a few executives who work at Client Yellow. These people are usually not the ones who will be involved in the actual building of the widget and might not even be using the widget after it’s built. Regardless, Vendor Green writes down everything said and decides to apply one of its ready made solutions. Vendor Green takes a lot of time to write functional specification documentation that spells out how to fix the concerns they heard from that first and, potentially, only meeting with Client Yellow. At the completion of the project, Client Yellow will often end up with a lot of documentation for a solution to a problem it turns out they didn’t really have, and a product that they now know a lot about, but never really needed.
In contrast, Agile’s iterative approach allows for task adjustments and continuous re-evaluation of “what is the most valuable work we can deliver within this smaller, manageable chunk of work?” In addition to greatly reducing the danger of getting to the end of a build and having a widget no one actually needs, you have the added bonus of showing the worth of the work done throughout the process and not just a big, “fingers crossed you got it right” reveal at the end.
Value #3 - Customer collaboration OVER contract negotiation
Communication, communication...and more communication. This does NOT mean that Client Yellow and Vendor Green should throw caution to wind and have no contract for building the widget. It does NOT even mean that Client Yellow has to have an open budget and timeline. It does mean that an environment of trust needs to be created that allows for collaboration throughout the project. It does mean there needs to be a well thought out change order process in place that both Client Yellow and Vendor Green feel good about following.And, most importantly, it does mean that both companies have a better chance at being truly satisfied at the end of the project and with their business relationship overall.
Value #4 - Responding to change OVER following a plan
The iterative approach of Agile Scrum gives both Client Yellow and Vendor Green the flexibility needed to incorporate new information as it presents itself. This is more desirable than the traditional approach that basically makes both companies stick to the original, fully laid out plan whether or not that plan still makes sense as the project progresses. A strict, set in stone plan written at the beginning of a project assumes you know everything you need to know at the beginning. This is the equivalent of asking a child what they want to be when they grow up, then forcing them to be a “Rockstar Scientist Unicorn Tamer” per their five-year- old blueprint.
Agile fixes this disconnect. The goal becomes open communication with all identified stakeholders throughout the process to deliver a “mini-widget” of sorts every few weeks. This delivery schedule is known as a “sprint” and is typically 2-4 weeks in length. These mini-widget deliveries give Client Yellow a chance to speak up in real-time if something isn’t going the way they excepted. An appropriate change can be made immediately –whether it be due to an earlier miscommunication or just a re-evaluation of what feature Client Yellow feels is most valuable. A plan is definitely still important but it is considered a living thing that might need to flex and stretch to get at the true need of the client.
In short, Agile assumes Client Yellow and Vendor Green are working toward the same goal – a great widget that solves a business need. Through trust, collaboration and flexibility, that goal can definitely be reached.
For more information on the Agile Scrum Methodology, visit https://www.scrumalliance.org.