The Benefits of the Agile Process
When the Agile Process first came onto the software development scene it created quite a stir. Before Agile, business owners and IT departments had to make decisions that would affect the entire project while still in the discovery phase, before they fully understood the problem. After starting a new development project, the team then had to wait until the very end, until launch day, to find out whether the solution met all of their needs or not. Clearly, this methodology was not only slow and clunky but also ineffective in many cases.
The Agile Process, on the other hand, boasts both flexibility and efficiency. Since the Agile Process is iterative, introducing new functionality about every two weeks, developers gain the ability to address the highest priority needs at all times. The immediate feedback inherent to the Agile Process allows the development team to test as they go, and see what’s working and what isn’t, before sinking too much time and money.
The Drawbacks of the Agile Process
All of this sounds really great—and it is. At Kopis, we use the Agile Process because we believe it produces the best results. However, there are cases where Agile can be less appealing, and even frightening, for some companies.
For example, if you are the owner of a business that sells a software product, Agile is likely your best friend. It is simple for you to set a fixed budget. Two developers per year budgeted to create your new product line, perhaps. If you are the owner or CTO of a business that provides services, or of a larger company, it suddenly becomes much more difficult to estimate both the cost and the benefits of using Agile Process. Kopis works with large companies like BMW, for instance, and it can be nearly impossible to determine whether the redundancy or the inefficiency caused by the software quality problem is costing more or less than a custom software solution. And we all know that the solution has to cost less than the problem, or what’s the point?
In the end, this is the biggest drawback of Agile Process: Businesses often need a more definite price and timeline upfront than true Agile Process is able to provide. To meet the needs of these companies, Kopis created a system that we call “Agile With Guardrails.”
What is Agile With Guardrails?
The short answer is that Agile With Guardrails is exactly what it sounds like. It’s a methodology that combines flexibility and predictability, finding the perfect balance between a fluid and a fixed workflow.
Here’s how it works:
The Requirements & Design Phase
This phase of Agile With Guardrails combines processes from both the Agile and Waterfall methodologies. We meet with you regularly to understand the problem, collaborate on possible designs and get comprehensive feedback. In addition, we prototype risky or unknown aspects of the system. The goal of this phase is to spend the least amount of time learning and validating that both Kopis and the client both understand the problem and have created enough “guardrails” for the project stay in the right lane.
The outputs of this phase are:
- A document outlining the scope of the project – not trying to dot every ‘i’ or cross every ‘t’ like the Waterfall approach
- Mockups that describe screens that are difficult to visualize or are crucial to the operation of the application
- Prototypes of risky or unknown areas of the application
- A budget
- A project plan and timeline
Development
Now we flip over more towards the Agile methodology. All of the standard Agile practices come into play here – sprints, stories, demos, feedback, and adjustments.
It’s important to understand that the Agile with Guardrails methodology is structured, but not static or rigid.
So where do the guardrails come into play? Just like in standard Agile, we use stories to describe what the users should be able to do in the system and provide an estimate to complete the tasks for that story. We believe that we can keep you within your budget if we stay within guardrails:
- Avoid approving additional stories in the backlog
- Avoid additional revisions on In Progress or Completed stories
The first guardrail is typically pretty straight forward. Adding approved stories (new scope) adds time to your project and increases the total budget of the project by the amount estimated for the newly approved story. Stories added to the backlog but not approved for development are estimated by the team, but are not included in the project budget until approved. Similarly, removing stories, if early enough, has the opposite effect on total budget.
The second guardrail has more nuance. The effort to complete the tasks for a story includes time for initial development, fixing bugs found by QA, and a few small adjustments after a demo. So, for each story we have set an allowance. Now, over the
course of the projects, stories will run slightly shorter and slightly longer than expected, but across the project we’re pretty good at getting the total budget correct. Just choosing the fixtures, paint, and any other allowance based decisions for a house, exceeding the allowances for a stories can put the total budget and timeline in jeopardy.
While Kopis will remain flexible and happy to work with you. We can still shift and pivot quickly, making whatever changes are necessary but ultimately, we set the budget and the timeline based on the guardrails.
The end result of Agile With Guardrails is the perfect marriage of flexibility and predictability. We still rely heavily on the iterative, collaborative process that is the hallmark of Agile, which leads to more interactions, more innovation, and better solutions. But we also tailor the scope of each project, setting up boundaries that work for you, in order to better serve you and make sure your development project is delivered on time and within budget.
