Making Agile More Agile

by Techtonic
blog hero image

Agile development has quickly become the de facto standard for managing software development projects, and for good reason. Agile allows businesses to leverage the inherent flexibility of software development to move quickly building new projects, adding features, and responding to market demand. At Techtonic, we use many development models (including Agile) with clients, tweaking them along the way via retrospectives and feedback to deliver the finest possible product. To assure all customers receive the maximum value for each project, we deploy a process called Managed Agile. 

What is Managed Agile?

We built Managed Agile after examining the debriefs and feedback from dozens of other projects. Following the review of this information (particularly what has been requested most often by clients), we created a series of recommendations to further manage costs but still maintain agility on projects. Simply put, Managed Agile is built from Agile and uses Agile, but focuses on more precise cost management to help remove obstacles to project success.   

How does Managed Agile work? Read on – you’ve come to the right place.  

Start with a Baseline

First, a baseline understanding of the project size is needed. In some cases this is easy. A client may have a relatively detailed idea of what they want, or you can easily get there by asking the right questions and making educated assumptions.  

When you have a good idea of the project scope, the first step is documenting what you know and the assumptions made. Then provide this information (along with an estimate and timeline) to the prospective client. This is the baseline – this estimate will likely change but at least the client has something in writing and you have a basis from which to manage costs.

If the idea is not very detailed (or includes substantial R&D), there are two options available to help move forward:

Then – Discovery – This can be one or more sprints, depending on what needs to be worked out. If you are doing R&D or building a proof of concept app, this usually will involve a small team for several sprints. Discovery itself can build into the project, or you may need to stop and decide how to move forward once discovery is done.

Estimating with Many Unknowns – This is risky, but with strongly documented assumptions and clearly worded time/cost ranges, you can at least have some protection and buy some protection while ferreting out the unknowns. 

Beware of situations where the business stakeholder demands a “very firm” estimate but won’t provide the details necessary to manage to your number.  

Establish a Flexible Spending Account

To truly make Agile agile, the team needs the ability to keep their momentum by making small to medium decisions without stopping everything to ask (for example) for $200 to tweak some completed code. If every change is a temporary red light, then sprint planning is either a waste of time or requires negotiation. This drag on the team will cost someone money. With a fixed bid, time and material changes will typically cost someone money (usually the dev team or vendor). We will provide more details on billing and pricing in Part Two.

Think about a flex spending account from an insurer’s perspective – allowing the client (you and me) to buy inexpensive but medically appropriate products and services without submitting mountains of paperwork saves everyone time and money. In software development, it does the same thing. By setting aside a percentage of the total budget (generally 10% to 20%) to cover small tweaks, the team is empowered to keep the project moving forward. In our experience, we have set aside as little as 10% (which usually had to be replenished) to as much as (a client requested) 40%. The amount is important, but the idea behind it (to maintain project momentum) is of equal or greater importance.  

An important note –  this is not change control. Flex spending is what is required to make Agile agile. Also, transparency is needed – everything should be shared with the client/business and they should be aware of how much is spent, how much is left, and how it is being used. Careful record keeping is essential to use flex spending. This does add some additional cost, but the benefits are well worth the added expense.  

Change Control – The Basics

In any project, larger changes should be managed in the more traditional project management fashion. These will require a new estimate and review to be submitted for approval (or rejection).  

To avoid cannibalizing the existing sprint ceremonies, plan for one or two additional meetings per week to discuss these items (we use one internal and one external meeting). Some, more standard projects might need only one meeting per week, but in our experience, this would be the exception. As long as the leadership meets to discuss these items (and records the time and topics), new estimates should be easy to create since this would be the responsibility of the leadership team anyway.

Change Control – The Advanced

Change control is no fun, but it will always pop up at some point in a project (whether Agile or not). Clients change their minds, features get added, things turn out to be stickier than originally anticipated – you know how it goes.

With Agile, we actively encourage change because it is likely to achieve the best outcome for the client. Flex spending will handle some of the surprises, but not all. Here are a few tips on change control:

The Importance of Emergence – Every project has emergent requirements – these can’t be foreseen until you’re in the middle of a project. Use this language early so clients/stakeholders buy into the concept early. Even the most expert teams will encounter emergent requirements as they get deeper into a project.

Dev Team Wishes are not Free – Even team member-nominated solutions have a cost. This flows from point one, but it bears repeating. You have to own this and say, “We didn’t think of this before, so there will be some impact to the project.” It could be uncomfortable, but it is your job to own it.

Users Always Want New Features – Here’s a news flash, right? In theory, new user requests should be celebrated, because it means people are engaged. No amount of wireframes, prototypes, non-interactive demos, videos, pictures, words, meditation, or other deep thinking will produce a different effect. When the user touches a system they will see other pathways, opportunities, and uses for the system you created. These items go into change control or flex spending.  

Assumptions are not Predictions – Assumptions are our best guess about what will happen and what types of emergent issues may occur. They will never cover 100% of cases and will never be accurate all the time. When an assumption changes, it is documented and handled through the mechanisms already described.

Change Always Happens – If you don’t like change or you don’t see the value and excitement in emergent requirements and marketplace changes, the world of software might not be for you.

Task Complexity Can Be Tough to Predict – If all we did was build the same system over and over again, complexity would be predictable. Software development can be compared to building a house, but this is where it breaks down:  wood is wood, metal is metal, glass is glass, and dirt is dirt. Building a home always uses these materials and the processes are therefore fairly standardized. Software can be very different because: 

  • User Expectations are Constantly Increasing – This is good, but it means we need to do things differently. We can’t just build the same systems in the same way over and over again.
  • The Landscape is Constantly Changing – New tools are available and both customers and businesses need them to stay competitive.
  • Employee Retention – This isn’t strictly a client or business concern, but it is essential. Not using new tech or adopting new methods means your best people will get bored and will look elsewhere for challenges. IT turnover is already a problem – you don’t want to make it worse.

Making Agile more agile serves everyone – clients, engineers and companies. In Part Two, we will address how to manage the complexity of new tasks and added features, while effectively handling the pricing and billing. Join us next week!