Agile development is about building the best possible solution, generally considering the constraints in resources but above all, time. Who cares about getting the perfect system in production if you missed the market’s window of opportunity? Software development, project management, and user expectations are a complex triad that teams should know how to cope with.

Your software projects are running out of time, and your customers are unhappy with the quality of the delivered product so far. In most of these scenarios, Agile is the hero that comes to the rescue. You may have read or heard phrases like this in the past:

If your Software Development Lifecycle (SDLC) is based on a traditional Waterfall-iterative style, no doubt you should switch to Agile methodologies! However, if you’re already applying Agile techniques, well, you’re probably doing something wrong!

Nevertheless, things aren’t that simple. Delivering the expected/desired software product on time and with the right quality involves more than a change of methodology and process. A methodology is a tool, a framework that suits certain scenarios well. Neither traditional nor Agile approaches will help you without the expertise of those that lead the development.

If you already know about the benefits of transitioning to Agile development and you’re disappointed with the results, continue reading. One of the most common mistakes we make when implementing Agile may not be related to Agile guidelines but to the management and team expertise. We need to dig down to the roots of the project management to figure out what we can do and what we can generally expect, independent of moving to traditional or Agile SDLC.

More insights: Waterfall model: is it useful in these Agile times?

The Iron Triangle: Chasing time and quality

Project Management is the art of measuring, optimizing, and making decisions around three pillars: scope (what you need, requirements, and user expectations), costs (which generally determine your available resources), and time (how long it will take).

The reasoning behind representing these elements as the vertices (or sides) of a triangle is that the Project Manager can’t trade out any of these sides without the consequence that altering one constraint affects the other two. If you want to finish earlier, you either need to reduce the scope or increase the budget (adding more resources, when possible). Putting it simply, it’s good, cheap, or fast, pick only two.

When it comes to software development, the scope is given by the set of application features, the budget depends on computer hardware and mainly people, and the worst enemy is the deadlines (time). The value of these three aspects determines the quality of the software built, which can be measured by reliability, maintainability, correctness, and scalability, which are among the most important dimensions.

Another simple way of thinking about the relationship among these sides of the triangle is to visualize it as the following equation (called STR):

Scope = Time × Resources

The problem with this representation is that we dismiss focusing on the quality. Somehow, we have to include it in the equation as a constant value, that is, you’re committed to a given quality standard for the entire scope:

Scope = Functionality + Quality

Using the STR equation, one can plan more or less well how to build a house. It simplifies some planning and estimations for example, you may think of proportionally increasing resources in order to keep time constant. Unfortunately, most software projects don’t follow this reasoning.

Is it all about deadlines?

Nowadays, almost every industry depends on software. A successful business requires taking advantage of very short-term changes in the market; therefore, medium- to large-sized companies often forget the Iron Triangle implications, focusing mainly on what they need (scope) and when they will have it (being late with delivering a product may negatively affect the intended market and therefore adversely impact profit).

We often hear about this problem as the time-to-market measurement. Today, one of the main concerns in the industry is having the perfect product at a later time, which is worse than having a not-so-well done software BUT on time (independent of how many resources or how much budget we have).

There is so much emphasis on on-time delivery that stakeholders get fooled into thinking that software development can be carried out by ignoring the high costs it demands. Do you want to build the system faster without sacrificing any feature or quality? No problem. Give us more resources, no matter the costs.

But there is a catch. Software doesn’t obey a simple rule of three — the scope isn’t proportional to the amount of people you need. This is a well-known limitation reflected in part by the mythical man/month, and it has enormous consequences.

To add more fuel to the fire when calculating the resources needed, the industry has realized there is a bigger problem: The software built is way below expectations. In other words, for those projects where the cost was not an issue and where all resources were used, the result was a complete failure, even though it reached the market on time.

As we can see, the scope variable ended up being far more difficult to estimate.

Agile wonders

Some aspects of the software crisis that started in the 70s still remain in modern software development. Management still struggles to control the three fundamental elements of any project:

• Scope. At the end, the user experience and the added value didn’t meet expectations.
• Budget. Although investors are willing to pay as much as needed, it is not a matter of budgeting and resources but of software complexity. Things get worse when desperate managers attempt to fix the problem by adding resources to an already delayed project.
• Time. Software projects can take much more time than estimated. They have several variables that change over the course of the project that might be hard to estimate.

These problems have a common denominator: Enterprise software development is driven by high uncertainty and complexity that increase with time and the features added. It’s not possible to have an accurate estimate of any of the sides of the triangle for big systems that require several months or years to build.

In this context, Agile methodologies have established a new framework that has gained popularity and is the most common standard used in the industry.

How has Agile shed some light and hope on software project management? Basically, it tackles complexity and uncertainty before they get too big to handle The key aspects of Agile frameworks rely on shortening the development cycle and bringing the stakeholders closer together for one fundamental aspect — focusing on the Minimum Viable Product (MVP) that leads to success. Stop planning long-term, vague requirements and start building the minimum set of features that can be tested, verified, and put into production in the shortest amount of time, right now.

Last words: DELIVERING SOFTWARE ON-TIME, It’s all about quality

Agile doesn’t solve the Iron Triangle. Instead, it proposes to break your needs down into smaller chunks, building features that can be verified quickly and require much less resources.

Don’t be tricked by the wonders of Agile. Don’t think you can magically dodge some of the triangle’s sides. Agile won’t save you from making unwise choices with the right scope, resources, and time.

Don’t forget the triangle’s area represents quality. It must never be sacrificed. The complexity, along with the efforts to preserve maintainability, will grow no matter what, and it is key to have highly experienced teams manage projects properly. Remember that the fundamental aspects of the quality throughout your software development cycle is essential to success.

Comments?  Contact us for more information. We’ll quickly get back to you with the information you need.