25

As someone who's worked effectively with Agile before, I am trying to convince my current employers of its benefits. However, management are insistent that we retain the ability to make upfront estimates in order to assess the business value of projects.

Most of my customers are internal, and I was recently tasked with going round teams and asking them for ideas on business processes to automate. I was then to find out how much time this was taking them, work out how much time the solution would save and estimate the total development time. That way, managers could attempt to measure how effective a solution was likely to be in terms of time saved.

However, it looks to me like there's no way to approach this requirement in an "Agile" way. Flexible requirements means that not only will estimates of time taken be wrong, so will estimates of potential time saved. I explained as much, explained why it was likely to be problematic, but was told it was non-negotiable.

The question How to sell Agile development to (waterfall) clients has some useful advice on how to "sell" Agile to external customers. I'm not trying to sell it to external clients: I'm trying to work out how I can best reconcile the demands of internal management while retaining a methodology I believe works well.

Is there any way to approach this task in a flexible manner which allows me to retain at least some Agile benefits?

Improve this question
10
  • 1
    If possible, try to decompose projects into smaller parts and see if any of them will be useful on their own, with the remaining parts building on them. The benefit to estimation accuracy from shrinking your cone of uncertainty ( whatis.techtarget.com/definition/cone-of-uncertainty ) will outweigh the cost of flexibility.
    – Ben Aaronson
    Sep 25, 2015 at 12:36
  • 1
    Are you currently able to make accurate estimates of how long development will take for a given project?
    – Daenyth
    Sep 25, 2015 at 12:57
  • 2
    @MattThrower ProTip: if management entrusts important IT functions to a single developer then they never had much faith or trust in IT to begin with. They certainly don't seem to be convinced that IT has a good ROI or else they wouldn't be so tight on the purse strings.
    – maple_shaft ♦
    Sep 25, 2015 at 13:17
  • 2
    If you can't convince management that what you're about to do will save more money than it costs to implement, why would they pay you to do it? Agile is a development methodology, not a project methodology. Your problem is to convince others that your estimates will match actuals. When you do that, they don't care what your methodology is. Every time requirements change, you must be able to say what the effect of the change is in time or effort (and hence cost), otherwise how will they know if the change is worth it or not?
    – RobG
    Sep 25, 2015 at 14:55
  • 1
    possible duplicate of How to sell Agile development to (waterfall) clients
    – gnat
    Sep 25, 2015 at 15:02

7 Answers 7

Reset to default
25

As other answers have stated, Management has every right to get a high level estimate upfront of a project. They are not unreasonable for trying to determine ROI.

One of the approaches that I like about Agile however is that the scope of a project is not fixed. It can be initially sized out at the Feature and Epic level, then business can determine ROI based on what are the most important features. Maybe the fancy UI with bells and whistles has low business value, but the workflow engine for handling claims has a high ROI.

When you lump the whole project together then it harder to meet ROI than if you focus on the critical business functionality that is desired.

Here is a way that I have done this:

Take your WBS milestones and turn each of these into a deliverable feature

This allows you to categorize your project into mini subprojects that have varying business value. Each of these should stand on their own in terms of business value.

T-Shirt Size the Effort on Features

This is a very easy way to get a rough idea about how big or involved a particular feature might be. Perhaps low value features still have a great ROI if they look like easy wins.

Break Down a Feature into Stories

Go through the exercise to find a small feature that is well understood and break it down into stories initially. Estimate these stories by points. Now you have a basis where

Small -> 40 points

This will be a basis of comparison to other features

Associate story point effort to all Features

Compare your Small Feature to other features. For example,

Medium Feature Y feels like it is twice the size and effort of Small Feature X of 40 story points.

Medium Feature Y is probably 80 story points. Continue this until you have story points estimated at a high level for all features.

Estimate your Team Velocity

Looking at your development team, try to determine how many story points could this team effectively deliver in a given sprint. If you have previous Agile projects as an example with this team that is a great place to start. If you do not have such history behind the team then go through a mock Sprint Planning with your team where you start looking at your Small feature that you have detailed out. What kinds of hourly estimates are people giving for their tasks on these stories?

Based on how much work the team thinks they can deliver in 2 weeks, use that total story point number as the average potential velocity of your team!

Find your Projected Completion Date

If your team in mock sprint planning feels comfortable delivering 25 story points in a sprint, and your total backlog looks like 300 story points for the gold Cadillac version of your project, then it looks like your team would ideally take 12 sprints or 24 weeks to complete everything.

Now it is trivial to turn cost of resources on your team into dollars per week to arrive at a cost for ROI vs. Business Value. The negotiation can continue on what the most important features are and then your project management becomes basically a Knapsack Problem.

Improve this answer
3
  • 2
    +1 for being the only person (so far) to actually answer the question.
    – RubberDuck
    Sep 25, 2015 at 13:27
  • 2
    I think this answer glosses over the fact that while management is not unreasonable for trying to determine ROI, they are being unreasonable (or at least, extremely unrealistic) if they expect such up-front estimates to be remotely accurate in practice. This answer provides a good explanation of how to forecast release dates under Agile. But I assume the OP already knows that part, and was asking more about how you can provide a guaranteed accurate estimate up front in an Agile context (or any other). The short answer is you cant; which is why people use Agile in the first place.
    – aroth
    Sep 26, 2015 at 14:01
  • @aroth Shhhh! Don't give away the secret to the Normies! In all seriousness though you are right about estimates but at the very least Agile does well in comparing relative complexity and can allow hard choices to be made with more information at hand. Software is a messy and risky business and it seems to me that nothing else seems to give a better idea about what to expect on a long term project.
    – maple_shaft ♦
    Sep 26, 2015 at 15:47
10

This is not a problem with "management". It is an absolute requirement to be able to estimate the cost and benefit of any potential project before starting. Otherwise, how would anyone know what is worth doing (or attempting)?

Then why Agile?

I would argue that to use Agile methods is not to choose uncertainty. Rather, Agile is an argument that uncertainty is inevitable, and the detailed specifications and estimates of traditional methods introduce false certainty--which can be quite costly.

Some key points in terms of time estimation:

  • Changes to requirements throughout a project are inevitable; Agile takes this into account rather than pretending there will be no change.
  • Detailed specifications often contain design flaws that are not uncovered until well into the project. This may mean bigger changes in a traditional project than an Agile one.
  • A time estimate based on "how big of a thing do I think this whole project is?" is likely to be just as accurate as adding up the estimated time for many detailed requirements.
  • The main thing that leads to good estimates is a cycle of estimating, measuring, and reviewing--which can be applied to any consistent process.
  • The "work saved" estimate is going to be driven by the primary requirements for the project rather than the details, so I doubt Agile would much harm the ability to estimate this.

Update:

Just to clarify, your response to your bosses seems to be "We can't estimate time saved or total development effort very well using Agile, because it is flexible." I think this is mistaken. I believe these estimates can be made just as well when using an Agile process, since the uncertainty is there anyway. And of course Agile allows for a more flexible and responsive process as the project unfolds.

Improve this answer
2
  • Thanks for this. I appreciate that the whole point of Agile is baking uncertainty into the process. What's worrying me is that I thought I'd helped others understand this but my latest batch of requirements strongly suggests otherwise.
    – Bob Tway
    Sep 25, 2015 at 12:57
  • @MattThrower, I have added some further thoughts to the answer, because I'm not sure it was clear what I was trying to say.
    – user82096
    Sep 25, 2015 at 14:42
8

This is certainly one of the toughest part of introducing Agile

"Management still needs time estimates"

My approach is:

  • Pad 300%. The old saying of 300% is useful when you are in a situation where being really agile at a management level isn't going to happen. This is not an "agile approach" perhaps but is a compromise for this situation. You'll be able to come in ahead a few times - but don't count on it!

  • Ask for a review based on work achieved at what would would be the 'half-way' point of the project. Project when you would be complete based on work done. Then talk to management and go over which they which to sacrifice - functionality or quality - given that time is fixed based on guesses at the start of the project.

  • Make sure you are collaborating on features done and quality with management so they actually make those decisions

  • Go with the flow for this project and allow the usual things to happen - missed deadlines, compromised quality, burned out and stressed (and possibly departed) employees that leave. When the next project of phase comes up, discuss these 'side-effects'.

  • Focus and demonstrate the advantages of a "true" agile approach. Talk about the improvement in quality. Talk about the ability to make changes late in the day right up to and past them going into production. Talked about less need for re-work. Talk about less technical debt that will eventually bring development to a crawl. Make analogies to the real world, for example, we can put off an oil change on any day, but put it off long enough and the engine suffers, performs poorly and eventually blows a rod.

  • Keep your resume and linkedIn profile up to date. If you can't get management support after making your case a few times, move on. Some organizations will not listed to your arguments so move to ones that do. Called it Darwinism employment ;)

Improve this answer
4
  • Your first bullet is know as the Scotty Principle, and it's 400% :-)
    – corsiKa
    Sep 25, 2015 at 14:48
  • While I agree to a certain extent with the 300% rule, should we have to do that forever? With a continuous cycle of estimate, measure, review, shouldn't we eventually get better?
    – user82096
    Sep 25, 2015 at 15:39
  • 2
    @dan1111 In my experience, agile or not, no it doesn't. The over-estimate isn't because you actually over-estimate the project but rather we always over-estimate how productive we are and under-estimate the challenges involved.
    – corsiKa
    Sep 25, 2015 at 16:00
  • 1
    @dan111: Once you have a reasonably consistent measured velocity, then your project estimates can be based on points/sprint. But the instinct "it'll take about an hour of actual work" will always need to be padded because as corsiKa says it takes longer than an hour to do an hour of actual work. The only thing left to decide is whether the programmer should give a "likely time elapsed" estimate instead of an "actual effort required" estimate in the first place or whether that should be left to the formal process, which will include a padding factor of 300% or whatever was measured.
    – Steve Jessop
    Sep 25, 2015 at 19:14
3

I think you are making false assumptions about Agile development. Flexibility and changing requirements are literally baked into the Agile Manifesto.

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

Flexible (read: changing) requirements are welcome in Agile. Granted if you ask most developers they will add a caveat that the change must be reasonable. Asking a team to build a 3D game then changing the requirements to be "control system for a nuclear reactor" is a bit much. But adding, removing, or modifying requirements in the scope of the project is perfectly fine.

The question is how do you cope with changing requirements? The typical answer is to use short iterations so you can make course adjustments early on before you waste too much time. It also forces the team to decompose requirements into smaller pieces so everyone can better understand them and implement them in a reasonable amount of time and effort.

Simplicity--the art of maximizing the amount of work not done--is essential.

I also like this Agile principle. It normally is taken to mean that a team should strive to deliver only those things that are necessary through ruthless efficiency. For example: if the customer thinks they need something but it seems fishy, dig around. Maybe the end users really have no use for it, so the work should not be done.

However, I think your question hit on another aspect of this principle. Software generally serves the purpose of automating a manual process. The software itself exists to maximize the amount of work not done -- by the end users.

Measuring the amount of labor that software will save the end users is definitely a worthy metric. I have measured this myself in my career. It is actually a critical component of a cost/benefit analysis: how much effort will the software project take to implement, compared to how much effort the final product will save the end users.

This is absolutely compatible with the Agile (or any other) development philosophy and your management absolutely should buy into this.

Improve this answer
3
  • 1
    I do understand this. I'm not sure everyone else in the business does.
    – Bob Tway
    Sep 25, 2015 at 12:58
  • 2
    @MattThrower: From what I understand from your question, your management is asking you to provide a cost/benefit analysis, as described in the second part of this answer. They probably need that to be able to allocate funds/people to the project in the first place.
    – Bart van Ingen Schenau
    Sep 25, 2015 at 15:46
  • @MattThrower Agile is not an argument against estimates of time. If it was then tracking metrics like Velocity would be meaningless as they would have no predictive factor on future success. What Agile gives is more insight and negotiation into what the business priorities are on a project. They still need the estimates for each milestone though to have that discussion
    – maple_shaft ♦
    Sep 25, 2015 at 16:52
2

Yeah, agility has some advantages.

  • It allows business folks to change their minds mid-flight.
  • It sort of protects the business against the engineer's perpetually bad estimates.
  • It delivers value early and often, before the final vision is achieved.
  • It spares you some of the up-front planning cost, which can often produce bad plan anyway.
  • It's super cool. Right?

But, you still need to give reasonably accurate up-front estimates.

If you don't, you're effectively asking the business to invest in your product without any evidence that your product is even worth the initial investment -- and in some cases, anything at all.

And I can hear it now.

I've heard it before. I'm pretty sure I've said it before:

Oh - But Haow!? HAOW does a mere mortal man such as myself gaze mine eyes into the destiny of such things! Things which only the gods themselves can divine and direct. Things which mortal men can only dream in deepest slumbers and forget by wake of day! Oh tyrannical managerial types, HAOW can such demands be met!?

Use your past performance as a guide and be honest.

  • Have enough of a conversation with the stakeholder and/or end-user to determine how complex the product and/or it's major components are relative to other major components you've worked on. Make an initial, relative point estimate.
  • Inflate that number by the historical amount of scope change and bug fallout you've historically seen.
  • Apply your historical velocity to the point estimate to arrive at a rough timeline. And, apply a reasonable cone of uncertainty.
  • Re-review your estimate and understanding of the project. Be confident that you would be willing to make a decision about tackling a project based on your assessment.

Finally, present your cone of uncertainty to the stakeholders, state your assumptions and concerns, and leave it at that.

As an aside, I'd also suggest coming up with an objective point-estimation heuristic to sanity-check you and/or your team's normal estimates.

You can use this estimate as an Nth vote during planning poker, or in validating your private estimate if you're going solo. For example, my team tends to estimate about 1 point per minute of loosely technical discover discussion about a story. This is especially helpful if your gut tells you a story is 5 points, but it took you a 20 minutes to understand what needs to be done -- it's usually a good indicator that there are still complexities and misunderstandings lurking around.

Improve this answer
1

I've never worked in any company that was able to have consistently good time estimates, nor have I ever worked with anyone who claims to have done so either. Searching will show you that estimation is an unsolved problem across the industry.

I'd try to get buy-in about measuring velocity based on abstract story points, and if you can't do that, I'd pad your estimates more.

Improve this answer
2
  • I have never worked for a Company that agreed to start a project without some idea of how much it would cost and how much it would earn.
    – Paul Smith
    Sep 25, 2015 at 15:13
  • 1
    I /have/ worked in companies that had very good time estimates. But they were professional services companies that repeatedly delivered comparable projects, and they invested a lot in methodologies. Outside that sector, it's rarely the case.
    – Alfred Armstrong
    Sep 25, 2015 at 15:30
1

Agile is a great solution to a whole range of problems, but despite what some evangelicals would suggest, it is not the only solution and it is not always the right solution.

Your stated case is simply not an agile problem:

I was recently tasked with going round teams and asking them for ideas on business processes to automate. I was then to find out how much time this was taking them, work out how much time the solution would save and estimate the total development time. That way, managers could attempt to measure how effective a solution was likely to be in terms of time saved.

You are tasked with determining the cost and benefit of automating some business processes, that is not an agile task subject to change, it is a specific problem with specific solution. You will produce a list with an arbitrary number of business processes and for each, there will be an estimated cost of automating, an estimated cost of not automating and an estimated benefit of automating. Management will match this against their budgets, resources, requirements and strategic goals and determine which (if any) of these processes to automate. If you are conscientious, then you will have highlighted selected tasks which have potentially lower ROI's in themselves but which will reduce the cost of other phases so improving the total ROI. You may also have identified different ways of achieving the automation including in-house and outsourced bespoke development (using agile and/or waterfall techniques), buying off the shelf solutions, using third party service providers and so on. This whole process was very fashionable in the 90's when it was known as business process re-engineering.

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.