Picture this: Fixed Agile

By Eelco Rustenburg and Maarten Winkels
Picture this: You enter a room and seated at a conference table you find two grumpy looking men, arms crossed, that tell you: “We want fixed price, fixed date, fixed functionality!” Now imagine you are the manager of a Software Development Company championing Agile, what would you do? It is easy to spot the conflict: Agile dictates to embrace change and to do away with stringent planning. How could you approach this difference? It takes a special person to fit a square peg in a round hole.

Starting point
Before telling them they are completely nuts to request the impossible, you decide to take a closer look at their request and to ask why they think it is feasible and even desired to approach it this way. They tell you that it is a fairly small project, maybe two months, and that they have done similar projects before, so they know what they’re dealing with. They want “this much” in “this time” for “this price”. They want to feel confident that all development risks are covered and they don’t mind to pay a little extra for that.

You try to clarify their situation and show them how you would be able to help them and before you know it, you’re sketching a simple picture on the white board. “This is what you are looking at,” you tell them. “The horizontal axis is time, the vertical axis is functionality. You know what you want to achieve and when you want it done.” You draw the triangular shape and explain them about velocity. “With your knowledge of the problem domain and my technical know-how, we can empower a team of our people to achieve just that.” But this is not enough. You want to convince them of the advantages of an Agile approach.
Iterations

“We like to develop software in an iterative and evolutionary way,” you start to explain. “We will show you working software at the end of every iteration and this will enable you to steer at intermediate points in time.” You divide the timeline in four equal parts and start to draw an arrow that points up slightly from the optimal velocity path. “You see,” you continue, “if for some reason our team does not perform as well as projected, the functionality remaining to be delivered will be more than planned at the end of an iteration. At such a point we can help you to achieve the deadline for the project, for example by dropping some of our quality standards or cutting down on the complexity of some of the requirements.” From the endpoint of the last arrow, you draw an arrow dropping down to the deadline point. “By doing so, we make sure that at the project deadline you will have working software, even if it is not completely up to our quality standards or doesn’t contain all the ‘Should-Have’ functionality.” You extend the first arrow to reach the timeline. “After the deadline, our team can continue to work on the open issues, to complete the project and reach the required quality. As per our fixed-price-contract, you will of course be entitled to a penalty for late delivery.”
Prioritized Backlog
One of the men on the other side of the table starts to warm up to your ideas. His experience with Fixed Price projects is that after the initial phase, he can no longer influence what is happening in the project and progress reports from development are minimal. With the model you present, he’ll have insight into what is happening at every point in time and he can do his own projections.
“So what do we need to provide your team to accomplish all this?” he asks. “Well, of course you need to tell us what you want,” you begin, “but what we actually need is a prioritized backlog.” You explain that to be able to plan the development the required functionality needs to be split up in ‘bite sized, SMART chunks’. These UserStories are the vessel of communication between the client and the developer. Each UserStory should convey a part of the required functionality and it should be self contained, so the client and the developer can agree on when it is finished. To attain this, it should be Specific, Measurable, Achievable, Relevant and Time-bound.
“After we have agreed on the initial list,” you continue, “you need to order them most important first. For each Iteration or Sprint, our team will take the topmost stories of the list and commit to finishing them within the sprint. They will estimate for each story how much time it will take to complete it. These stories are then fixed in the sprint backlog. After each Iteration, the team will show you what has been accomplished and you get to look at the rest of the product backlog.”
Request For Change
The other guy is still not convinced. He’s been a project manager for all his life and has seen many new project management approaches come and go. “So, how do you handle change?” his question is, “We already know that some of the requirements of our customers will change during the project.”

You refrain from telling them that this statement summarizes the whole demise of the Fixed-Price approach in favor of the Agile approach and come back to the picture you were drawing. “All changes can be added to the product backlog during development. You can decide what the relative priority is with respect to other backlog items. With each new sprint new items are transferred from the product backlog to the new sprint backlog. With this in mind, changes are just normal requirements that have not been implemented yet.”
Below the horizontal you draw a rectangular region, starting from the origin and with one edge following the line of perfect velocity. “The amount of work that is added during the project, can be tracked in the model like this,” you explain. “Adding work will not slow down the team, so the velocity will remain the same, but it will influence the total time required to finish the project. This can be tracked by adding the requested changes to the negative axis of the required functionality,”
Conclusion
“So all we need to do is to provide a prioritized list of all required functionality and track the progress by attending the demonstrations at the end of each sprint?” the first guy summarizes your explanation. You tell him that you provide multi-day trainings, that aim to explain just that and that he’s probably the first to grasp these essentials in such a short time span. Satisfied that you have both learned and achieved something today, you leave the meeting,
On the way back, you realize that Agile is in essence a very natural paradigm and that explaining its core principles to any streetwise person should not take more than two pictures and a handful of words.