Gopinath ramachandran


Published on

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

Gopinath ramachandran

  1. 1. ` - Best Practices - on - Agile Adoption in Fixed Bid Projects
  2. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 12. 6. REFERENCES [1] Manifesto for Agile Software Development,, 2001 [2] Twelve Principles of Agile Software, 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, [6] Jeff Sutherland, Change For Free , backlog/change-for-free [7] Three Contract Models for Scrum Projects, [8] Marcin Niebudek, Agile Team Meets a Fixed Price Contract, 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.