How to Successfully Execute Fixed Price Agile Projects

Table of Contents

What is fixed price project in Agile?

Fixed price project is a quite self-explanatory term. In this model of software development, the enterprises require planning, strategizing, and inherent control over the processes that they want to execute. They want clarity on whats; whys; whens; wheres, and hows of any software development project.

A fixed price Agile project involves:

• Fixed-cost
• Fixed-time
• Fixed-scope

All these are decided at the outset of the project. Any change in any of these would invariably affect the entire project and its fixed price model. The changes in agile processes would occur inevitably as the customer needs and market expectations are always in flux.

Enterprises often prefer to choose fixed price Agile projects to protect themselves from these deviations, inherent in all agile methodologies. They often assume that fixed price model means fixed timeframe and also fixed scope of work.

However, any sensible enterprise would also always want to meet customer and market expectations. They cannot afford to sacrifice their product at the altar of their notions of fixed price agile projects.

So, is it possible then that an enterprise’s budget and time constraints can be effortlessly managed along with the inevitable deviations during the course of the agile projects? Well, the answer to this question is YES. Let us explore how.

Major challenges in the seamless execution of fixed bid Agile projects

The major challenge in successfully implementing agile projects with fixed price model lies in the perception of both agile methodologies and fixed price model of the project.

Lack of clarity on Product Backlog Items (PBIs)

The agile culture believes in no waste. Therefore, the team is trained to not to work on anything extra or more. This approach is fraught with misunderstanding.

When there is only a one-liner backlog item, “just enough, and elaborate later” mindset leads to underrating of the items. This happens because:

• Requirements set at the beginning of the fixed bid agile projects are often unclear or ambiguous one-liners.
• Teams interpret these one-liners based on their experiences or skills. Most often, these interpretations prove to be undersized.
• This underestimation then results in teams working overtime.

New changes in the middle of the project

The world of technology is constantly changing. Sudden or new changes in the middle of the software development cycle are natural and inevitable in the fixed price contracts in agile processes. When there is such a change:

• Enterprises assume that agile estimation for fixed price projects already takes into consideration such changes at no extra cost or time.
• Teams often feel constrained in the implementation of these new changes in the absence of authority or liberty to modify cost and time limits.
• There is an obvious gap between the product functionality and the market expectations and customer requirements.

Lack of accountability

Large fixed price contracts in agile often involve more than one team and third-party vendors. Very often, these teams do not share the same sense of urgency or belonging to the agile projects or agile practices. This often results in lack of accountability or ownership. And when there is even the slightest of lack of accountability or ownership in any team or part of a team, the project suffers inevitably.

Lack of enterprise engagement during the development process

Enterprises believe that the initial involvement during the agile estimation for fixed price projects is enough. It is like a toxic masculinity that believes that its job is to help only in procreation, and not in the development or nurturing of a child. A man driven by this toxic masculinity is often a proverbial absent father who does not know anything about his child’s progress or development.

Similarly, when enterprises assume that their job is restricted only to the initial talks and clarifications regarding the agile projects, communication suffers. When communication suffers, project gets delayed. The absent enterprise during the development cycle of the software, like that of an absent father during the growing up years of a child, is often disillusioned with the product as it was not the software that it ever wanted!

Ignorance regarding agile methodologies

It has been almost over two decades that the agile practices have captured the imagination of the IT industry. In spite of its long run, it is not absorbed thoroughly by the concerned stakeholders. Both the enterprises and the developers often make assumptions about its architecture that ultimately result in disasters.

When enterprises assume that fixed price contracts in agile require no more involvement than the initial requirement disclosures, it creates communication gap.

When teams are not well-versed with the agile approach, it often results in faulty products. It also creates credibility issues in the market for the concerned enterprise. And, most importantly, it results in terrible customer experience which is an absolute violation of the very first principle set forth in the Agile Manifesto: “highest priority is to satisfy the customer through early and continuous delivery of valuable software.”

Overcoming challenges in the seamless execution of fixed price agile projects

As they say, the cure for the pain is in the pain, the solution for this seeming contradiction of hybrid methodology of agile and fixed price model lies in the agile methodologies themselves. It is therefore important that all the stakeholders thoroughly understand the agile practices and the agile processes.

Let us have a look at major techniques that help the developers overcome the inherent challenges in the hybrid methodology of fixed price projects in agile.

Creating clearly defined fixed price contracts in agile

When an enterprise explores its options for software development through agile practices, it needs to be careful and clear in its expectations. While entering into fixed price agile contracts, all the stakeholders need to have clearly defined sense of time and budget.

Both the enterprises and the developers can leverage agile methodology itself while defining these. Agile methodology encourages the use of ‘timeboxes’. If the developers know the correct use of these timeboxes, half the battle is already won.

The correct understanding of timeboxes not only guarantees completion of the project on stipulated time and budget but also helps businesses define the success criteria of their projects.

This then leads us to explore another factor that significantly matters in the successful implementation of fixed price agile projects — scope.

Openness to redefine the idea of scope in fixed price agile projects

When there is total clarity on the use of timeboxes, it would be important for all the stakeholders to be flexible on the idea of scope in the agile triangle.

The Project Management Institute (PMI) in its paper: Fewell, J. (2011). Fixed price agile projects: making the impossible possible, presented at PMI® Global Congress 2011—North America, Dallas, TX, explained this quite interestingly:

“Project success is much more likely when we are authorised to modify the project scope, in order to meet our bottom-line business goals within the fixed price and fixed schedule”.

In order to get the best of both worlds that is the agility of the agile methodologies, and security of fixed price model, it is important to determine the size of the fixed price contracts in agile instead of their scope.

We already know that agile processes use story points to fix the size of the projects. Bacancy Technology has thoroughly explored the role of story points in project estimation in its earlier blog post as well.

Hence, when the developers are given that liberty to modify the size of the project as per the emerging market trends, it naturally alters the scope of the project without affecting overall budget and time frame.

For example, if a fixed price project with scrum is sized at 5,000 story points, the emerging market trends can be accommodated within this limit of 5,000 story points by replacing the present PBIs with the new PBIs of the equivalent size. This technique is often called exchange model or trade-off model in agile practices.

Exploiting MoSCoW method

Agile project cost estimation for fixed price projects can leverage famous prioritization technique called MoSCoW. The term is an acronym wherein the first letter represents each of four major categories of prioritization: M= Must have; S= Should have; C= Could have; W= Won’t have.

Usually, in this technique must have requirements do not occupy more than 60% of the project scope. Should-haves take 20% and the remaining 20% is allotted to could have that often become contingencies.

This method can help the teams tremendously in delivering the solution that has all the “must haves” and “should haves”. The must have and should have features can be clearly defined in earlier interactions or the workshops with the clients. When this is clearly defined, there are bright chances of the team coming up with a solution that not only has “must haves” and “should haves”, but also a few “could haves” too.

Successful implementation of fixed price contracts in Agile using MoSCoW technique can deliver not only the solution that exceeds the expectations of the clients, but it can also create higher customer satisfaction and market value.

Organizing workshops with the clients for clear communication

Workshops are powerful techniques to get over “just enough, and elaborate later” mindset. They can be organized at the outset of the project as well as during the development of the project periodically. They may be called initial workshops and discovery workshops, respectively.

The initial workshops or early workshops involve:

• Coming together of the teams and the client to have a closer look at the backlog items and the requirements.
• Creating a common ground where the definition of each backlog item is acceptable to all the stakeholders.
• Persuading the clients to have periodical discovery workshops that would involve deliberation of issues after the sizing of the project.

When the clarity on the PBIs is achieved through the initial workshop, the teams can go back to their development laboratories and come up with the clear size of the fixed price projects in agile.

They can communicate it with the clients before actually organizing subsequent discovery workshop that would involve enough brainstorming, discussions in case there is a discrepancy in the team’s evaluation of the project features and the client expectations.

The discovery workshops can typically include:

• Negotiations with regards to addition or removal of items based on their priorities.
• Presenting more confident agile estimation for fixed-price projects after having discussed the business problem thoroughly with the clients.
• Mutual agreement on the “Definition of DONE” for individual stories, increments, and releases.
• Selecting vendors based on requirements and corresponding skills rather than just costing.
• Creating a culture of open and honest discussions that strives for maximizing value—one of the basic principles of the Agile Manifesto.

Persuading clients to participate in these workshops requires a sales team with solid and deep knowledge about agile processes and agile methodologies. This then lays the foundation for meaningful collaboration with the clients.

Encouraging active client participation

Having defined the product backlog at the outset of fixed priced agile project is not enough. It is important for the enterprises to remain involved in the product development throughout the agile processes. This, however, requires client orientation to real agile methodologies and agile culture.

Many a times, clients have traditional waterfall background in the software development process. It means they do not consider it necessary to participate actively in subsequent developmental collaboration with the developers.

It is important that the agile teams make the clients understand the importance of active involvement in the project development. A client training at the outset of the project can be of great help in bringing about this clarity and understanding. Active client participation involves:

• Clients regularly attending sprint reviews, and providing important feedback to the teams early on in the project.
• Teams working on this feedback before the release; preventing reworks and delays.
• Making product owner own her role responsibly.
• Making clients aware of the efficiency and skills of the team so as to avoid surprises at the end of the product development.
• Making everyone on the same page at every phase of fixed price agile projects.

Team training

Team training primarily involves establishing a shared sense of urgency and accountability for the fixed price agile projects. It is very important that the team consists of members who think in agile! Team training involves:

• Making teams deliver according to the sprint plan.
• Making periodical presentations of the products as they are to the clients.
• Encouraging teams to communicate honestly and openly during the sprint reviews.

Team collaboration

It is important that all the teams involved in fixed price project in agile collaborate consistently and smoothly. Ideal team collaboration looks like:

• Clearly defined frequent milestones
• Allocation of ownership of each milestone to the concerned teams
• Identifying common patterns in the challenges during periodic sprint reviews across the teams.
• Arriving at earlier combined solutions for each challenge
• Steady collaboration with the product owner to keep her posted about risk factors and dependencies; allowing her to have an early clarity of the final product.
• Better way of reusing the code to save time and efforts in the agile processes

Conclusion