Managing budgets and cost control may not be the first thing that come to mind when you think about Agile software development, or ‘agility’ in general. It’s likely that you associate fast flying ideas and business pivots with Agile. Luckily, Agile development is built for quick shifts in fast moving worlds. However, many businesses are trying to achieve a specific deliverable within a managed (and often tight) budget. This budget can be time or cost, and sometimes. Regardless of development approach, businesses must often ask themselves (and their development partners), “what can we do with X amount of money?” or “what can we build by X date?”. They ask these questions because there is rarely an instance when software development exists in a vacuum. A balance between development and project support (marketing, business operations, hiring, etc.) needs to be reached.

So, can Agile development still work in such an environment? Yes. You just need to think about a few things that aren’t always a part of the typical Agile effort.

These fall into a few of key steps:

  • Start with a defined project estimate, approach, and scope (when you can).
  • Refer to your estimate and scope to understand when things are changing.
  • Confirm with the client when things are added, subtracted, or get more complex.

During the first step, you should estimate all the parts of the system that can be estimated.  In our experience, this is often all or most of a system. There are occasions where there are functional or technical unknowns, which can be loosely estimated. By starting with an estimate based on an approach and project scope, you set boundaries. You may need to stretch or exceed those boundaries, but at least you know where your boundaries lie.

Now that you have some boundaries, you need to keep them in mind when the vision for the application starts to expand, whether that means new animations, additional subsystems, or gamification. You can refer to your starting point and make sure that you are staying on track.

Sprint planning meetings are good times to refer to your original reference point and establish sprint boundaries. However, that is by no means the only time you should refer back to the original plan. Design discussions can happen at any moment and it is important, when inspiration strikes, to remember to refer to your original plan to see if things are changing (well, maybe after the inspiration strikes, but it is still important).

Lastly, communicating the result of all the changes that may occur on an agile project is important.  Whenever we identify that things are different it is important that the client understand the impacts and that we work together to decide how best to move forward.  By examining changes and daylighting any impacts we can make sure that a client makes informed decisions and does not inadvertently extend the timeline or increase costs without being made aware of this possible outcome.

By starting with an estimate and managing to that estimate along the way, you can ensure that the project runs smoothly, avoid surprises, and allow customers to make the right business decisions along the way.

 

jonathan_01 button_twitter button_linkedin