1

Context

Multinational enterprise organisation working with business process automation. Fairly new team and new to Agile values and iterative working. The development team are effective and receiving a workable pipeline of user stories as of this week when I took over.

Challenge

The organisation has a full portfolio of programmes and projects. A current NDA initiative has the task of halving all current projects due to a restructuring. To prevent this, each waterfall project has submitted a (likely inflated) benefits case and a Gantt chart extending out to 12 months. We have been asked to provide a strong benefits case to support our project

Problem

Our backlog only extends out, in detail, for the next 2 weeks. The previous Agile Coach considered automation to be too hard to turn into user stories so the dozen or so stories that were produced is stuff like "Finish the whole process" or "Do a code review".

Outside of that we have identified 26 epics to be delivered. Each Epic is linked back to one of 5 business areas that has dozens of potential processes we can automate. I hope that makes sense. So a business unit says "You have carte blanche" and we go in. For every process we can develop against we raise an Epic. We have 26 concrete processes so far we can develop but there are potentially hundreds.

What the Exec have asked for

  • Quickly triage every single process in every single business area and produce an Epic for each
  • Produce a benefits analysis for each Epic
  • Tell us how many Epics can be completed in the next 12 months
  • Add up the Benefits case and if it is greater than X then your project survives the cull

Empirical Data

There is a very little. The previous Agile Coach did not ask the team to record metrics and allowed all delivery artifacts to exist on post-it notes or C:drives so I don't have a data source like Jira with which to interrogate.

What Have I tried so far

  • I have asked the Exec for time to break the previous deliveries down into Epics and user stories then backtest and backestimate that to provide empirical data with which to apply to future Epics of relative/similar complexity (They said no. Current deliveries must continue)
  • I have asked for 8 weeks (4 Sprints) in which to capture delivery metrics from the team for everything they deliver from today. Some of the exec said yes, some said no and cried foul.

What I am seeking

  • Cited sources I can use to evangelize why a fully formed backlog is less valuable than delivering software and adjusting while we go (3 months backlog good...12 months bad)
  • Senior anecdotes of how individuals would/could/have handle this
  • Concrete coaching techniques I can use to demonstrate value to the NDA project-culling team

You are all my peoples - help please! Extremely demoralised Product Owner and Team looking at me...

Improve this question
4
  • To be clear - you're the single Agile Team in an entire organization that is otherwise Waterfall? Or did I misinterpret?
    – Sarov
    Jun 13, 2018 at 15:45
  • Not the single team but very close to the truth, yes. There are other small pockets of agility in different countries/locations.
    – Venture2099
    Jun 13, 2018 at 16:55
  • 1
    Could you contact those other pockets to determine how they intend to handle this, then?
    – Sarov
    Jun 13, 2018 at 17:36
  • 2
    Long-term "estimates" are always guesses, and are always wrong. Yours won't be any more wrong than anyone else's. Why not just stock the backlog with epics, do a rough "fist of five" estimate of the whole backlog, and call it good enough for the management filtering process, which will largely be a political rather than economic decision anyway?
    – Todd A. Jacobs ♦
    Jun 14, 2018 at 13:16

4 Answers 4

Reset to default
1
  • Cited sources I can use to evangelize why a fully formed backlog is less valuable than delivering software and adjusting while we go (3 months backlog good...12 months bad)

I can compare the “Fully formed backlog” to a situation that happened inside Google, have a look at the book “How Google works”. There’s a part where they are explaining how a product manager created a very specific document to describe a plan of action and how they decided to not go with it and have a “High level plan” and change it dynamically as priorities changed (can’t remember the section unfortunately and I only got the audio book so can’t search).

But references are everywhere, look at the Agile manifesto for example (Responding to change over following a plan). Agile has been used everywhere and it has proven its value.

  • Senior anecdotes of how individuals would/could/have handle this

I would go with mentioning the value of your team first, rather than the value of the project itself. A people deliver A results even with B ideas.

  • Concrete coaching techniques I can use to demonstrate value to the NDA project-culling team

My first argument is that they have tried for ages to follow the waterfall approach and apparently it hasn’t given them enough good results. My second argument is in my first point; agile works and it has been adopted because of that reason.

Improve this answer
1

This is a typical problem in many work places. A skilled agile practitioner must be able to tackle this problem from multiple angles.

My preferred approach would be:

Identify 1 or 2 high value area of the business. Identify 2 or 3 processes where value of improvement can be translated into savings/efficiency-gains (i.e. Dollar Value, money talks).

Build your case around... if our work on this couple of processes saves you so much money, you can only imagine what you could do for the business.

Good Luck, hope this helps.

Improve this answer
1

The NDA team do not need (nor want) a detailed planning of what you are going to accomplish in the next year. What they want is a forecast of how much money your team is going to make for the company.

Assuming that you use the term "epic" in a conventional way, meaning a piece of work that takes multiple sprints to complete, the 26 epics that are currently identified already give you more than a year worth of work on the backlog.

What you should do, for each epic that is currently identified, is

  • Make a forecast of the business value of the epic (how much does the revenue increase or the costs decrease)
  • Make a high-level estimate of the epic (how many sprints would it take to implement this). Do this estimation with the whole team and you could also first do it in t-shirt sizes (S, M, L, XL, etc.) and later convert those to time.

Then, in the report to the NDA team, order your epics such that you get the most value out of the year and add a small footnote that the order is not committed to and is subject to change.

Improve this answer
1

For this:

Cited sources I can use to evangelize why a fully formed backlog is less valuable than delivering software and adjusting while we go (3 months backlog good...12 months bad)

I haven't gone through any real life experiences but I can recommend the book "Escaping the Build Trap" which is precisely focused on companies stuck in trying to deliver features without realizing if these will provide any business value. Based on this I would suggest finding out which one of the 26 epics would give more visible value to your company and prioritize that.

As someone mentioned earlier use that to create buy in on your strategy of having a smaller backlog.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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