Agile is here to stay. Everybody wants to be Agile including businesses that depend on the contractual development of software (also called as outsourcing). The style of development for contractual development and agile teams are a lot different. Imagine a golfer with a handicap below five, aspiring to play golf in the style of Samba soccer. Simply put, being Agile and also bidding for a fixed price project, just don’t gel.
OK, let’s first understand what Agile and Fixed bid projects are.
This article is published from the DNC Magazine for Developers and Architects. Download this magazine from here [Zip PDF] or Subscribe to this magazine for FREE and download all previous and current editions
The Agile team takes things as it is thrown at them. They don’t plan on how to develop a software until they develop it. This scenario is like crossing a bridge only when you reach it. You don’t plan how you will cross the bridge until you get to the bridge. Many environmental conditions, constraints, and decisions can change before you reach the bridge. It may happen that by the time you get to the bridge, you may decide not to cross it at all and then all the planning that you did on how to cross the bridge, might just go waste. While being Agile, you should only plan and focus on immediate actions required and not on something you may need to do in distant future. This methodology has lots of advantages while developing software. It avoids wastage due to avoiding a lot of actions which are not required, in a way that improves the efficiency of development. It enables the stakeholders to monitor and guide the development efforts for the requirements, which are needed by the business.
We develop software for improving some business practices, so whatever helps business practices, should be taken up for development. It usually happens that needs of businesses change, and that too rapidly. That’s because it’s business; not a process to get some permission or certificate from the government which is unlikely to change for years. Supporting the changed needs of business in software is Agile development. And that leads to the success of business. So, being agile is synonymous with being successful. But that also means that whatever the team develops, is not fixed, until the team develops it. Last minute changes are accepted and encouraged so that team develops whatever is needed by the business.
Fixed price projects
Now let us look at the other angle, that of the fixed-bid projects. In the last 20 years, software development outsourcing has become another way to succeed in your business. It gives you the possibility to get a software developed by some team at a different location in the world, wherever it is profitable to do so. In the beginning, only low-end work like development and testing were outsourced. That did mean that the control was entirely in the hands of the customer. They managed the entire process of development. The team that was developing or testing did not mind this arrangement as they were getting paid. In other words, Macro-Management for doing whatever was told by the controller. If something went wrong and had to be backtracked and created in a different way, good, that meant more hours of work, more money. It meant rework and time-consuming fixes. The more the merrier.
But then two things happened over the years. First, the teams that were only coding, now aspired also to manage the process of development. Second, the customers became wiser. Customers now wanted that if it is something that needs to be reworked or fixed, they did not want to carry the whole burden of it. They wanted to share that with the development team. So now the pattern of outsourcing changed to ‘fixed bid’. In a fixed bid project, the customer floats a requirement as a sort of an auction and teams bid for those requirements to be developed into software. One obvious thing about this is that a team cannot arrive at their bid if the requirements are not entirely known. If they do bid for developing a software for which the requirements either are not fully known or are changing from time to time, then the bid will also keep on changing in line with those changes in requirements, and will not be fixed bid.
Categorically speaking, do customers know the exact requirements of the software they want and do those requirements remain unchanged until the software is completed and accepted? I have come across many projects and product development where the customer had only a high-level idea of what they require from the software. Those requirements do change over time when customer and users get deeper insights into the way that the software is going to work, and that happens only after that software is created up to a particular stage. If the customer knew about the requirements in detail before the software development began, then that project need not be Agile. But knowing full detailed requirements before the development starts, is a myth.
Agile and Fixed Price Juxtaposition
Being agile and bidding for a fixed bid project are two ideas that are in juxtaposition to each other.
Figure1: Agile and Fixed Bid Juxtaposition
Agile needs us to welcome changes, whereas fixed bid cannot accept changes in requirements. What are the chances that the team going for fixed bid project can also remain an agile team? Very slim. But then as an Agile coach, I do want the benefits of being Agile be available to companies working on fixed bid projects.
Let me recommend a few things that came to my mind and which I tried out in some organizations.
It is in the interest of the customer to accept the fact that requirements are not frozen up front, but are kept in a fluid state until they reach a deeper level of understanding of these demands. In this way, the correct and exact requirements will be met and not the ones that are partially understood. Fluid requirements also mean elastic time and money. Let us have a look at the tradeoff triangle. To adjust to elasticity in requirements, the schedule and cost also need to be flexible. This tradeoff is tough to accept for a customer.
Figure 2: Tradeoff Triangle
Usually, customers who give out contracts to create software with full outsourcing, have a fixed mindset. Customers assume they know what they want and do not want to accept changes in requirements because it affects their budgets. At times, they even have a distrust about the third party that is taking the contract of outsourcing. It is essential to change that mindset in the interest of both the involved parties, but this article is not about how to do that.
For this article, I assume that the customer has made up that mindset, and it is almost impossible for us to change that. The real tricky issue is; how do we address such a situation now if we want to remain agile?
Being Agile in Fixed Bid Projects - How it works
At the beginning of the project, the feature level expectations of the customer are stated by them. The development team should apply a top-down approach where they know the top level requirements and make assumptions about details of requirements once they come lower down the level. The development team makes a high-level effort estimate and offers a monetary bid for developing that software. What we understand here is that the team makes a bid with the knowledge of requirements that are known at that time, and we also expect that those requirements may change a little over time, without any significant changes. With these requirements and budgets, a framework is created for the estimation of the number of team members and schedule of completion. Once this framework is in place, now we should think of periodic delivery. We can decide the periodicity of delivery over the possible implementation of a block of features. Let us call it by the commonly known term of ‘Release.’
When we start development for such a project, we make certain assumptions about the time required for creating that software and depending upon that, the money to be spent on it. We need to work within those parameters and still should have some amount of flexibility to remain Agile. We need to synthesize the waterfall model of development with iterative development model. Waterfall model is natural and conducive for fixed bid project. Iterative development is instinctive for Agile teams. We want the benefits of both, for our process.
As a part of such a synthesized process, my first suggestion is to identify the Macro-Management tasks clearly, as against the Micro-Management tasks. What I mean by Macro-Management is that a part of the product creation is devoted to non-development tasks like getting feedback about the released part of the software, refining next set of requirements, updating design documents and setting budgets with approvals for next release. For Macro-Management tasks, we can adapt a long cycle release process that has many steps in it.
Micro-Management tasks to be executed by the team of developers every day include requirement tracking, efforts management, code management, build management and deployment management, etc. This part of the release iteration should be further divided in smaller iterations and should be executed by the Agile team. My observation is that the release cycle made up of 3-4 development iteration, works well.
In the early part of the release cycle, macro management is the primary goal. Macro management activities ensure that we remain in the budgeted time and costs. Those are the activities that put the focus on long-term goals, achievable and ensures that we do not go beyond the bid that we have made. Once the activities related to macro management are over, only then the iterative development process starts.
Figure 3: Synthesized model of long release cycles consisting of shorter development iterations
In this model, we are not expecting that feature level demands of the customer are going to change much. That is why we can schedule and implement them in a particular release. A number of such releases with time and cost for them, as well as feature level scope is decided up front. At the same time, it also provides flexibility to manage development process for requirements that are part of the feature and address the feedback given by the stakeholders, as is done by Agile teams. This adjustment of detailed level scope gives strength to the Agile teams.
Let us understand the macro-management tasks first and then the micro-management tasks.
1. Requirement analysis and release scope freezing: This is the beginning of the release cycle. The development team and stakeholders define the requirements in as much details as possible. The scope of the release is limited to features that will be implemented. The team should not look at the time to implement those features at this moment, since the release cycle can be of variable length. Factors other than time like the dependencies, risks, etc. should be considered.
2. High-level design creation: The design team creates or changes the high-level design diagrams. Usually, it is done at the module level to ensure that communication between components is well defined and is not conflicting.
3. Plan and schedule the development activities: A gross level of the estimate is created to complete the development for release. A plan of implementation is carved out with the number of development iterations. These iterations are scheduled.
4. Development: This is an iterative activity where each iteration of development completes the part of the release scope. We will discuss the specific actions under this task in the micro-management section.
5. Stabilization: During this period, the testing team tests the completed part of the software. It extends the testing that is done by the development team, so that System Integration testing, Performance testing, etc. are carried out. It may also include User Acceptance Testing. During this part of the release cycle, some of the members of the team start working on the first activities of the next release, so that rest of the team can start with second part of the next version as soon as they complete the stabilization task.
These micro-management tasks truly define the way an Agile team works.
1. Identify requirements that are to be taken up in an iteration: This is also called as Sprint Planning in SCRUM. Depending upon the capacity of the team and the known estimate of efforts for each requirement, the requirements that can be completed in the iteration are identified. Other criteria for selection of requirements can be dependency relationships, risk analysis, value to efforts ration, etc.
2. Work breakdown: Each requirement is broken down into tasks that are needed to implement that requirement. Ideally, these tasks should be small enough to be completed in 8 hours. Each of them can be assigned to a different person if necessary.
3. Development: Coding, Unit Testing, Manual Testing, etc.
4. Staging: Deploy the created parts of the software on testing or staging server from where they can be executed and demonstrated to stakeholders.
5. Feedback: Seek and accept the feedback from stakeholders so that any corrections and changes can be incorporated.
Handle Budget Overruns
By taking a top-down approach and implementing planned multiple releases of software, we are reducing the chances of the project going above the budgeted limits. But in spite of this, we should also address the important aspect of what happens if we cannot complete the development in the budgeted cost and are likely to exceed the bid amount. Off course, we do not have the freedom to adjust features, requirements and schedule to suit the monetary constraints.
Let us understand why cost and time overruns would happen in spite of top-down iterative approach that we have taken. Scope creep is the foremost reason for this budget overshoot. Since the budget is fixed, we should take care of the following points right from the beginning of the project to avoid such overruns:
1. Convince the customer that implementation of all necessary parts of the software is much more important than strict adherence to the bid amount. Some flexibility should be built into the contract.
2. Prioritize the requirements in such a way that only the lowest priority requirements remain when the budget overshoot happens. You can stop further development keeping the customer informed about remaining low priority requirements.
3. Focus and freeze the releases in advance so that budget overshoot does not happen.
4. Ensure that there is no scope creep at the level of features.
5. Ensure that number of actual releases do not exceed the planned number of releases.
6. Keep the customer informed about the scope creep if it happens and then negotiate for adjustment in scope to ensure that number of releases do not exceed the planned releases.
It is not natural for a team doing contractual fixed bid development to become agile. If such a team desires to become agile, it will have to synthesize the waterfall model of development with an iterative process. In this article, we have discussed an option for meeting these two ends. Long cycle planned releases with short iterations of development is the suggested option. By planning the releases, we are ensuring the adherence to budgeted time and cost which are in line with the bid but at the same time, we are giving the liberty of iteration planning and requirement level implementation freedom to the development team for ensuring agility.