Agile transitions is when a company makes the full transition to to a flexible, responsive approach based on agile principles.
Because Agile projects are less predictable than traditional Waterfall projects, the transition to Agile practices can be difficult for some executives, especially those who are accustomed to detailed reporting and tight controls.
Agile projects include a degree of uncertainty; there are no detailed project plans or lists that specify what will be created, when it will be available, and how much it will cost to produce. As a result, executives who have spent their careers in a traditional project environment may struggle to adapt their management style to this less-documented approach.
To help these senior managers better understand Agile practices and deal with the organizational transformation, be prepared to answer the following questions:
How do I create a budget for an Agile project?
For some projects, budgeting is easy; the budget is predefined and the release will include as many features as can be created within the budgeted total amount. The product released typically will satisfy many (if not all) of the most important customer requirements, because each Agile iteration is designed to include as many of the highest priority items from the product backlog as possible.
For those Agile projects that release products only after a certain number of features have been completed, budgeting can be problematic. Management may be reluctant to commit resources to projects that, by their very nature, are open-ended—the requirements are incompletely defined and the release date is unknown. To overcome this reluctance, it may be helpful to have the team develop a high-level view of the project first to set the project boundaries. You can then suggest that senior management use these boundaries to decide how to fund the project. This will still allow the team room to adapt its work to best achieve the project’s objectives, but will assure management that the project will not exceed the preset boundaries.
As an alternative, you can suggest to management that they set up initial funding for the project, then review project progress after a certain number of iterations to decide if funding should be continued. In this way, management can terminate funding for any projects that are not meeting expectations at any point and free up funding for projects that better meet the organization’s objectives.
How do I track the budget for an Agile project?
It is actually easier to track budgets in Agile projects than in traditional Waterfall projects. Daily updates to the burndown chart (or burn-up chart) show how many tasks are completed each day; by tracking how much of the budget was expended to complete each task, management can compile an accurate picture (rather than an estimate) of the value that was produced for the costs incurred. (This can also help determine how much it will cost to complete each story point, which can then be used to forecast expenditures for future stories and iterations.)
How do I create a schedule for an Agile project?
Some projects set a release date and then work to satisfy as many requirements as possible within the allotted time (similarly to using a predefined budget as a constraint, as described previously).
However, if the schedule is not set as a constraint, senior management should decide whether it will use cost or scope as the boundary for the project, then have the team schedule a preliminary planning meeting to discuss how many iterations they believe it will take to create the product. Although this discussion will result in only a rough estimate, the estimate can be refined as the project continues.
Alternately, because the Agile cycle produces potentially shippable products at the end of each iteration, management can decide when the product will have enough minimally marketable features to be of value to the customer. They can use this point as the low end of a range, and set the date when all of the features will be completed as the range’s high end. The range can then be refined and updated as the project progresses.
How do I track the schedule for an Agile project?
Much like tracking budgets in Agile projects, tracking Agile schedules can also be easier than tracking Waterfall project schedules. Iteration reviews, team velocity, burn charts, and timeboxes make it easier to track real progress against the remaining schedule and to forecast future results.
How do I provide adequate rewards and compensation for performance?
Because Agile practices stress teamwork and collaboration, it may be very difficult for senior executives to adequately measure individual performance and provide appropriate compensation. Even with significant input from the Agile project managers and product owners who work with the team every day, developing an appropriate reward and promotion system can be difficult. Individual rewards recognize team members who demonstrate exceptional skills and achieve outstanding results but may cause competition among the team. That can inhibit teamwork and the sharing of information. Team-based rewards foster a “team-first” attitude, but may hamper growth and learning if teams resist adding new teammates who they feel will slow their progress.
One approach is to develop Agile compensation and promotion systems that reward both team and individual accomplishments. Management could, for example, provide compensation to the team, then let the team decide how it will divide the reward among its members. However, for this to be successful there must be complete trust among team members that the distribution is fair for all involved.
For Agile organizations to be successful, senior executives must adapt their management style to align with the work of its Agile teams. For many managers, this transformation can prove difficult. They have to leave old management ideas behind and adapt to new methods and practices. Those that are able to adapt create options and opportunities for organizational success.
Mini case: Senior Management and Agile Transitions
When the phone on Darius Glover’s desk rang, he scanned the digital readout to see who was calling. It was Noah Davis, a senior executive and one of Glover’s superiors at CHX Systems, a consumer electronics company based in Richmond, Virginia.
Davis got straight to the point. “I’m a little concerned about the AudioSixteen project. Can you meet me in the cafeteria in about five minutes for a cup of coffee so we can talk through some issues? Thanks.”
Glover agreed to meet with Davis, hung up the phone, and headed for the cafeteria. He wondered what Davis was concerned about and whether it involved the new approach Glover was taking with the AudioSixteen project. CHX had run several successful Agile pilot programs, and had recently instituted a company-wide Agile rollout. Glover had been a product owner for a few of the pilots, so he and his team had been assigned to guide the AudioSixteen sound card project to completion.
Unfortunately, Davis had been traveling on business when the AudioSixteen team was doing its initial planning, and while Glover had briefed him on progress, Davis had struggled with the idea of brief iterations for the project.
Glover and Davis filled their coffee cups and sat down at a table near the door.
“Thanks for meeting with me,” Davis said. “I’ll get right to the point. The AudioSixteen project is only two weeks into a six-week schedule, but you’ve already used up more than half of the project budget. When the project was planned, the financing department set a firm budget cap. We can’t shift any additional funds to the project.”
He paused before continuing. “I know our pilot programs were successful, but it looks like you’ve spent a lot of money and probably still have a lot to do before you complete the project. Can you tell me how you will meet the project requirements and still keep it within the approved budget? I’m very concerned that the AudioSixteen project has gone off the tracks.”
Answer the question in the textbox, then click Submit to compare your answer to an answer written by an experienced project manager.
How can Glover reassure Davis that the project will meet expectations?
Because a budget was set for the AudioSixteen project, it acts as a constraint that the project team would have considered in their planning meetings. The team has already completed several successful pilot projects so they should have a good idea of their velocity and how much money they’ve spent to complete story points; they would have used that information in their iteration planning meetings to determine how many features they could complete within the budgetary constraint. And because the iteration planning meetings are designed to schedule the most important requirements for project inclusion first, the product should already include a significant number of high priority items that will satisfy customer requirements.
Glover could use the team’s burndown chart and other story boards to assure Davis that the project is progressing as expected. He could also invite Davis to the iteration review meetings and let the team demonstrate the iteration results directly.
Davis is assuming that there are still a significant number of tasks to complete (which may be true) but those remaining tasks should be of lower priority. If the project spending does approach the preset budget limit before all of the iterations are complete, management can close the project and still release a product that will satisfy a majority of customer needs.