Don't "Control" Agile Projects
Don't "Control" Agile Projects
Join the DZone community and get the full member experience.Join For Free
[Latest Guide] Ship faster because you know more, not because you are rushing. Get actionable insights from 7 million commits and 85,000+ software engineers, to increase your team's velocity. Brought to you in partnership with GitPrime.
One common complaint about agile methods is that management doesn’t have the same degree of “control” over projects. We need to stop worrying about this complaint as a vice and start thinking of it as a virtue. When we “control” agile projects we can lose a significant portion of the benefit of agile methods. The better approach for agile projects is to “guide and bound” them.
Much of the journey from traditional project management to agile project management is changing vocabulary in order to change how projects are viewed by management and others. “Control” for example, is one of those words that rarely get examined because control is good, isn’t it? We have to control projects or they get out of hand, don’t they?
However, control in the traditional sense means—conformance to plan. What plan? Why the scope, schedule, and cost plan. But what if we expect the plan to change? What if we view the plan in an agile fashion as a hypothesis about the future, one to be explored into rather than a prediction? What if we expect that resolving uncertainties will send us off in different directions? In Lean Startups, for example, we expect to make a pivot or two—pivots that may drastically alter our “plans” for product, business model, or expected customers. “Controlling” a Lean Startup project makes little sense. Conforming to our original hypothesis, based on a certain set of assumptions, puts us “in control” but with the wrong solution.
The big hurdle for many managers is realizing that projects with significant uncertainty are by nature unpredictable and they need to forget about control and try to “guide and bound” such projects. The guiding parameters help us determine that we are getting the results we want while the bounding parameters help design solutions and stay within acceptable limits. Guiding parameters are vision, value, and quality while bounding parameters are the constraints—scope, schedule, and cost. In other writings I’ve referred to these as aspects of the Agile Triangle (rather than the traditional Iron Triangle).
Is guiding and bounding harder that controlling? You bet it is. However, it’s also the only approach that makes sense when operating in uncertain and volatile situations. Product vision might be depicted using an informal Product Box technique. Value, either tangible or intangible, can be claimed as features are delivered. Quality and cycle time measures can be used. Constraints are different from estimates and they usually indicate more flexibility than estimates. Constraints, normally time or cost, are essential to the process as they bound potential solutions. When constraints are exceeded it indicates that it’s time to reevaluate our hypotheses and assumptions. All this can be much more thought provoking and difficult than controlling to fixed points, but it will increase your odds of successfully traversing the bumps of uncertainty.
Projects are different and therefore measuring the success of projects should also be different. There are projects that can be well managed using traditional control practices and another set of projects where guide and bound practices give the best results. Using the wrong approach on a project usually leads to a less than optimal solution. For example, over controlling a highly uncertain project might lead to accepting the predicted result rather than the innovative result that would have emerged from a pivot. You often get what you measure—you just have to be sure you are measuring the right thing.
Published at DZone with permission of Jim Highsmith , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.