This document discusses best practices for adopting agile methodologies in fixed-bid projects. It identifies key challenges such as lack of mutual trust between customers and vendors and lack of customer involvement. It recommends holding a pre-game workshop to establish product vision, estimate scope and timeline, and agree on ways of working. It also recommends collaborative change management where customers can change low priority stories without cost. These practices help deliver projects on time and within budget while allowing flexibility that agile requires.

1. `
- Best Practices
- on
- Agile Adoption in Fixed Bid Projects

2. Gopinath Ramachandran, PMP, CSM
Senior Engineering Project Manager,
Abstract:
In current business context, most of the product companies want to adopt Agile as it is viewed as “silver
bullet” for getting better visibility and at the same time, fixed bid contract is negotiated for better control
over cost. In fixed bid model, scope, cost and time are fixed where as agile works on time-boxed and
flexible scope approach as per dynamic business needs.
Adopting Agile in Fixed bid model poses various challenges as traditional fixed bid approach contradicts
with some of agile principles. Agile manifesto [1] emphasis on “Customer collaboration over contract
negotiation” and advocates on collaborative relationship between vendors and customers to promote
sharing of risk with flexible options for accommodating changes. In contrast Fixed bid contracts contains a
contractual fixed statement of work, where customer may face inflexibility to change the scope even for
small changes and also vendor has to deliver the agreed scope in spite of unforeseen risks during project
execution. This inflexibility impacts the agile principle [2] for “embracing changes” even at later phase of
development and in turn impacts the customer collaboration. In product development, “upfront product
design” is seen as best approach in fixed bid where as various agile methodologies promote “evolutionary
design”.
This paper will discuss on the key challenges in adopting Agile in fixed bid model and explores the best
practices like “Pre-Game Workshop” and ”Collaborative Change Management” that can work well in a
fixed-bid model while following as many Agility principles as possible to meet the customer expectations.

3. Keywords: Agile, Scrum, Fixed Price, Fixed Scope
1. INTRODUCTION
It is becoming an industry trend that Fortune 500 customers are started requesting for agile
methodologies, due to its benefits like better time to market and transparency, for co-creating their
product in Fixed Price (FP) business model..
Agile adoption is more than a process implementation, which defines better “Way of Working” for
Software development. This requires complete mindset changes for all the stake holders involved in the
Agile Software development. Agile advocates on “embracing changes” even at later phase of product
development and focus on delivering values at each and every sprint. Agile needs a dedicated customer
involvement in prioritizing the requirements (user stories) and sharing the unforeseen risks, along with the
vendor during development. This requires very good trust and collaboration between customer and
vendor for adopting agile in product development.
In traditional Fixed bid model, the scope is clearly defined and cost of development is agreed
contractually between customer and vendor. Mitigation of any foreseen risks raise during project
execution is responsibility of vendors and they need to budget risk mitigation cost in their fixed bid
contract. There will be strict change control mechanism even for small changes, which may strain
customer-vendor relationships during project execution.
Agile by its nature, works well with Time & Material (T&M) business model and adopting Agile in Fixed bid
business model may poses few challenges as fixed bid approach contradicts with some of the agile
principles. Vendors are puzzled with the fact how to estimate and plan for agile methodologies while
executing software development in fixed price model. The following sections will discuss the key
challenges and highlight some of best practices based on our experience in successfully executing fixed
bid agile projects last couple of years.
2. KEY CHALLENGES
Mutual Trust

4. As Alistair [4] says,
“Software development is a cooperative game.”
Agile advocates “Self Organizing” Cross functional team, which has shared vision, common focus, mutual
trust and respect, working in collaborative manner for quick decision making and managing rapidly
changing priorities.
“Collaboration is expected not only within the development team but also across organizational
boundaries, with expert users and project sponsors.”
Agile works well if there is a good trust relationship exists between customers and vendors. This trust
relationship leads better collaboration and transparency in communication while discussing the
challenges, resolving the issues and mitigating the risks.
We faced the challenge initially while adopting Agile in Fixed bid model with new customer engagements,
where mutual trust needs to be build between vendor and customer.
Agile Process Maturity
Due to the increasing popularity of agile, customers are eager to adopt agile methods in distributed
software development to reap its benefits like time to market and flexibility to adapt the changes without
giving much attention on their maturity of agile ecosystems.
Customer has pushed the user stories/requirements in each sprint more than team capacity/team velocity
without mutual consensus, which leads unrealistic commitments and surprises during demo. This
resulted in following agile-but (no team empowerment) and impacted the team morale.
Customer Involvement
Agile methodologies [2] are intensely customer driven, which is both a characteristic and a risk factor.
That is, no customer involvement, no Agile approach. High Customer Involvement is critical success
factor for Agile Project success.

5. In Fixed bid Project, vendor needs to complete ownership and customer involvement was comparatively
less, which poses major challenges. The “Product Owner” [3] in Scrum is to define and prioritize business
requirements, review the implementation and provide feedback for the continuous improvement on
product and processes.
We experienced the lack of Involvement of Product Owner resulted in delayed responses/decisions and
incorrect feedback, which has impact on the team velocity.
Change Management
In Fixed bid project, the scope of work is well defined and mutually agreed between vendor and customer.
Any change in the agreed scope needs to follow strict change management process.
Key wrong assumptions in fixing the scope [8] are:
The more detail we include in the scope definition up front, the better we understand each other
Well-defined scope will prevent changes
A fixed scope is needed to better estimate price and time
During project execution, we realized, key interface requirements are missed out in original scope and
customer has raised the change request for the missed requirements. Customer morale was low due to
negotiation on change Requests (cost aspects), which is reflected during demo.
3. BEST PRACTICES
The section details the Best Practices for adopting Agile Methodologies in Fixed bid Project, which is
based on our experience in successfully executing Fixed Bid Agile Projects.
PRE-GAME WORKSHOP

6. Agile Software development project can be viewed as three staged process:
.
Pre-Game (product visioning, estimation, release planning, overall timelines and
effort, contract etc.),
Game (scrum development iterations) and
Post-Game (any additional testing, documentation, audit, last minute clean-up
before product release and formal closure).
We proposed separate contract for Pre-Game phase and contract for rest of the phase was
planned at the end of Pre-Game Phase.

7. Pre-Game stage consists of three broad activities, Product Visioning, Release Planning and Way
of Working. The duration required to accomplish these activities is generally less than or equal
to 4 weeks so it should be treated just like any other single sprint (label it as sprint # 0).
1. Product Visioning
Product Owner (Customer) uses product vision/Requirement workshop as well as all the
relevant information (direct inputs from end customer, protocols, guidelines, benchmarks,
statutory/regulatory requirements (specially from security perspective), inputs from other
stakeholders etc.) to create a prioritized list of user stories called Product Backlog.
The user stories in the Product Backlog are prioritized into 3 categories- “must implement”,
“would like to implement” and “corner of hope”. First category (70% of the scope), which
covers basic and mandatory product features and second category (30% of the scope), which
covers optional features. Third category (out of scope), shall be considered if any of the
requirements dropped from first category and second category.
Product vision includes base architecture and design, which will evolve during game phase
and shall guide all the technical decisions (that will have impact on performance, scalability,
reliability, testability and maintainability) hence it should be reviewed with all the
stakeholders, even though the final say is of the Product Owner.
This Requirement workshop has helped us to have common agreement on scope of work,
which covered in the form of product backlog, to understand the customer priorities and to
have common consensus on base architecture and development approach.
2. Release Planning
Team had done Story Point Estimation for user stories in Product Backlog using “Pokering
Game“along with Technical persons from Customer. Project manager in agreement with the
team has used the velocity to estimate gross total time required to complete the release.

8. Depending upon the release date and the time (final gross effort that includes relevant
buffers) required to finish the release backlog, project manager defines a team size,
composition and sprint duration (how many developer, how many testers, who should be
Scrum Master, one Scrum Team or multiple teams etc.).
For the new engagements, where relevant velocity figures are not, team is asked to
breakdown 4-5 odd stories into tasks, sub-tasks and then estimate the hours required to do
these tasks, sub-tasks. Project manager thus has both story-points corresponding to these 4-
5 stories (from planning poker based relative sizing) and effort in person hours. These two
values (story points and effort) can be used to calculate velocity. This is a virtual velocity and
effort planning can initially be based on it; but project manager must re-visit release planning
after 3 sprints are completed and replace this velocity with actual one.
The combined Release Planning with customer has increased trust and confidence of
customer on us. We had mutual consensus on release dates and risks associated with the
deliveries. Definition of Done is reviewed and approved by the Product Owner during the
Pre-Game Workshop.
3. Way of Working
Agile is more than a process and it is better “Way of Working” to create the best software. During
Pre-Game phase, we had set right expectation to customer on required customer involvement
during various Scrum ceremonies like Sprint Planning and Sprint Review/Demo. Project manager
along with customer sets-up work environment (including communication tools, hardware &
software resources to enable informative workspace and promote collaboration) for Scrum
team.
This mutually agreed “Way of Working” promotes collaborative work environment, effective
communication and high level of customer involvement. The customer collaborates with

9. development team in defining/prioritizing the user stories and in providing feedback on the team
deliveries.
“Team needs to analyze their Way of Working in Sprint Retrospective for Continuous
Improvement and Customer needs to be open for team’s suggestion on further improvements”
Cross Cultural workshops are conducted during Pre-Game Phase to create the awareness on the
societal/organizational values of other teams from different geographic. This cultural awareness
has helped in increasing the trust and mutual relationship between team and customer.
We have referred the following “Ranges and Changes” [7] contract model, which is provided good
insight.
“A two-part contract consisting of a discovery phase designed to provide customers with
ballpark cost and date ranges for a preliminary set of features which can then be used to
determine if it makes sense to proceed with a delivery phase using a Money for
Nothing/Change for Free contract”.
Collaborative Change Management
In Fixed Bid Project, customer needs to go through strict change control even for small
changes and also they are not allowed to de-scope the requirements, which are agreed before
start of the project. But as per Agile, changes needs to be accommodated even at the later phase
of development and it focus on values delivered in term of deployable features to customer.
It will be challenging to embrace changes as suggested by Agile in traditional Fixed Bid
business model. We had followed collaborative change management, which is “WIN –WIN” for us
as well as customer.
Prioritized Product Backlog consists of 3 categories of user stories:

10. First category (“must implement” 70% of the scope), which covers basic and mandatory
product features and second category (“would like to implement” 30% of the scope), which
covers optional features. Third category (“corner of hope”) shall be considered if any of the
requirements dropped from first category and second category.
Change Request can be as Follows:
Addition of new (“corner of hope” or completely new) user stories to product backlog
Deletion of any user stories( whose development not started) from product backlog
Modifying any user stories in the product backlog
Customer has flexibility to add or modify user stories and can de-scope any other low priority user
stories of equivalent story points without paying any additional cost.
Only if they add user stories, which exceed the total story points for the project, customer needs to
pay differential cost.
We have referred the following “Change For Free” [7] contract model, which is provided helped us to
formulate “Collaborative Change Management”.
“Per Scrum rules, the customer Product Owner is responsible for re-prioritizing their Product
Backlog of features according to business value at the end of each iteration. Changes in the
backlog's priority are free provided that the total contract work is not changed. New features may
also be added for free during Sprint Planning or Sprint Review in exchange for an equal sum of
low-priority features”
4. RESULTS
All the best practices, discussed in section 3.0 have helped in achieving the following results in Fixed
bid Agile Project:
On Time Delivery with Excellent Quality

11. Complex Telecom Application delivered for GA (General Availability) on-time with very
few minor issues (<5) defects found during Customer Acceptance Testing
No Cost Overrun
Project completed within the budgeted cost
Higher Customer Satisfaction
The Customer Satisfaction score for this project is rated “Highly Satisfied”. Customer has
appreciated Team for “Openness” “Transparency” and “Flexibility”
5. CONCLUSION
Fixed bid contracts are part of the culture of software in many companies and we can not simply avoid
them. But we have to find ways to make Agile to work well in this fixed bid business model.
The key take-away from this paper is innovative Agile Fixed bid contract - “Ranges and Changes” and
collaborative Change Management – “Changes For Free”.

12. 6. REFERENCES
[1] Manifesto for Agile Software Development, http://agilemanifesto.org/, 2001
[2] Twelve Principles of Agile Software, http://www.agilealliance.org/the-alliance/the-agile-
manifesto/the-twelve-principles-of-agile-software/
[3] Ken Schwaber, Agile Project Management, 2004, Microsoft Press
[4] Alistair Cockburn, Jim Highsmith, Agile Software Development: The Cooperative Game, 2008,
PEARSON Education
[5] The Scrum Framework in 30 Seconds, http://www.scrumalliance.org/learn_about_scrum
[6] Jeff Sutherland, Change For Free
, https://sites.google.com/a/scrumplop.org/published-patterns/value-stream-pattern-language/product-
backlog/change-for-free
[7] Three Contract Models for Scrum Projects,
http://www.derailleurconsulting.com/blog/three-contract-models-for-scrum-projects
[8] Marcin Niebudek, Agile Team Meets a Fixed Price Contract, http://www.infoq.com/articles/agile-
team-fixed-price-contract
Author’s biography
Gopinath Ramachandran, PMP, CSM certified, currently holds the position of senior
engineering project manager at Aricent, where he focuses on Telecom VAS solutions in the
Product Engineering Services group at Aricent. Gopinath has over 14 years of industry
experience in managing and developing software for communications and network
applications, including IN, SS7, VoIP, and SDP. He holds a bachelor’s in electronics and
communication engineering from Madras University, India, and a Master of Business
Administration (Marketing/Systems) from Alagappa Institute of Management, India.