There are two main misconceptions that lead to the failure of agile software development projects.
First, stakeholders conceive of the project as a monolith—one big thing that has a fixed set of features and a fixed price tag. And, second, stakeholders often only participate in the project at the beginning and the end.
The way this plays out is that every company executive has that number in their head. That ideal number, or sweet spot, where the budget isn’t inflated and the project fulfills its original scope. The problem is that the original scope is based on upfront planning, so putting too much stock in it runs counter to agile principles.
So what does treating an application under development as an evolving set of features look like? And how does this affect the way you manage the budget?
Too many stakeholders for development projects think of the application as a singular and static tool. Instead, they should think of the application under development as a set of features, one that needs to be arranged into a hierarchy of value—and then rearranged over and over again throughout the project as both developers and stakeholders acquire greater insight through hands-on engagement.
This a fundamental shift in how you conceive of the entire scope of a project. For example, if an executive wants “X” number of features related to their product, and those features exceed the budget they’ve allocated (mainly based on the work needed to complete these features), the project will suffer, either financially, or in scope.
The solution? Instead of giving an agency a wish list of features that are static and unmoving, executives need to establish which features offer the most value to the organization, and be willing to let go of the less valuable features. This allows both the teams working on development and the end user to recognize the value and execute on a product according to priority. Determining actual value in every project detail becomes a deciding factor in choosing what to develop next.
To make a simple metaphor, sometimes an unplanned night out with your significant other might be more valuable than grabbing beers after golf league. Depending on the situation, you may choose the golf league. Other times, you’ll decide that a quiet night with a spouse is warranted. An effective life balance allows us to make sure we have an execution system that is flexible enough to account for deviations – and project planning should be just as fluid.
Often, a product owner or stakeholder participates actively only at the beginning and end of the project. This is the second factor to failure. Their absence makes reassessments and rearrangements of the value hierarchy impossible, because it’s these very business stakeholders who possess the greatest insight into the business value of each feature.
Prioritization of features based on business value, followed by assessment and reprioritization of those features, is the foundation of the agile mindset. And it can’t be accomplished by the dev team alone; it requires close, ongoing collaboration between people on the technical side and people on the business side to succeed.
Executives should collaborate with the project and the team on a regular basis. We aren’t going to be very effective if we set the budget at the beginning of the month and review the performance at the end of the month. Introducing weekly reviews of the performance of the budget allows us to ensure that we are executing according to plan. Any deviations to the plan can be identified quickly, and assuming you don’t have easy access to an additional income source, you can begin deallocating money from those items at the bottom of the priority list to account for the plan deviation.
In short, establish a hierarchy of value and review often. The you can re-evaluate budget. Lather, rinse, repeat.
The streamlined process described above is exactly how we execute projects here at Aptera. Here are three steps we take in every project to ensure we’re offering the greatest value in the shortest amount of time:
Step One: We begin our process by defining a backlog of features that describe the project initiative; we called these “expenses” or “features”– they are the things the client most wants and needs. We then begin to prioritize the features based on the value they deliver to the organization. This all occurs before the project has even begun; basically, we are building a solid project plan.
Step Two: The project is executed in short timespans to account for inevitable change. There is going to be learning that occurs as the initiative moves forward. Priorities are going to change, new ideas are going to be presented, some features are going to be more complicated than expected, and some features less. As a team, we (together with the client) must ensure that we execute within a system that is flexible to account for these deviations. Performing regular reviews of the performance of the project initiative is fundamental to its success.
Step Three: The sprint review should focus on understanding how past performance will impact future work. To call back our metaphor from earlier, do we need to skip beers after golf league because date night with your significant other was more expensive than anticipated? Or change date night to cooking at home and enjoying a movie? Too often, project planning assumes that change cannot, or will not, occur. Anticipating change and embracing it creates a balance, and ultimately produces better results.
The final step for the organization stakeholders is to allocate the money available to spend on the project initiative to the items feature list and re-evaluate scope, product features, and budget.
There are some glaring differences between this agile model and the traditional waterfall approach. Company financial executives are upfront planners. They want to see estimates. They want to see projections. And they want to compare actuals to those projections at the end of the engagement. We understand that the agile mindset can put some executives at great unease. “Why wouldn’t you be able to tell me how much work you’ll have done halfway through the project?” This leads many to say, “Sure, agile sounds great in theory, but how do you sell that to a CFO?” In the second part of this series, we’ll address the discrepancies between an agile mindset and the financial branches of an institution, and how to establish trust, estimate velocity, and put that CFO at ease.
Stay tuned for parts two and three.