I want it by October

It is often the case that a client or a boss (or his boss and so on) comes to you and says “I would like have the Foo module by October”.  There is generally very little technical understanding of what Foo may be.  Often there is very little business understanding of the scope of what Foo might be as well.  So what do you say?

Step 1: We can do something

There are a myriad of options.  Yes. No. Maybe.  What is Foo? I’ll need a full spec before I can commit to anything.  I’ve said them all.  I’ve worked with them all.  None of them make anyone completely happy.  In general – if the date is in the future – I now go with “Yes, we will be able to do something, I’m just not sure yet what exactly that will be.”  So that isn’t no, but it isn’t yes either.

The problem is that no one may know what Foo is yet.  So how can you with provide an answer to this question with any amount of value?

So we’ll be agile about it – and if we prioritise well – we’ll get the right things done.  That is what our track record says and we’ll continue to do it.

Aside: What if “something” isn’t enough?

But what if there isn’t enough of a Minimal Marketable Product by the date?  Do we work harder?  Hire more people? Fire some people?  “We don’t know what will happen when you add 2 people to the team” isn’t a particularly useful answer but it is the correct one.  The business side of the equation needs to understand that as well.  Adding more people is well known not to be a short term solution – even if you can find people good enough to add.  We need to work to manage demand and optimise the flow of delivery.  Everything can’t be delivered in October – unless we only do one release a year – and then it becomes “which year?” 😉

Step 2: Define what it is

In the past I have worked starting with the one liner of “I would like Foo completed by October”.  From this often an RFC is initially written up by my PO.  I’ve worked with the PO to generate a list of stories.  Most recently those stories  arrived with no input from me.  Based on that list of stories we can now start discussing both what is missing and the realities of what it might mean.

Step 3: Size it

At a point where we believe the backlog is defined enough (which may be quite early) we then do some sizing.

I have in the past done a 4 hour estimation session – 2 to 3 minutes per story – with the whole team.  It was unpleasant for all concerned.  Since then I’ve done affinity / magic estimation and it works like a bomb.  In the most recent session I tried to compare my estimates made before the team did the sizing to that which the team came up with.  They were pretty close – and as the team progressed and resized items as they better understood them they came far closer to my  original sizing.  But I haven’t yet used my sizing for initially planning yet 😉

Step 4: Plan and forecast

So now we have a backlog and sizes have been applied by the team to the items.  This is very rough!  But it is good enough to manage within a couple of sprints – assuming that there isn’t a lot of unexpected work.

From the size we can take average, highest, lowest, last velocity achieved for the team and provide some forecasting as to how long it will take to deliver the known work.  Generally I’ve been working in 3-4 sprints worth of work and this has been relatively reliable within a sprint or so.  So you can agree on a reasonable date based on past experience of the real velocity and padding for stabilisation and backlog growth where you needed.  Everything changes, so expect a little change – but sometimes the client / boss would like you to not – in which case show the change visibly in order to show why you should have planned for it in the first place.

Step 5: Manage expectations transparently

From here on out I report on progress with complete transparency.  I report on change – up and down.  I report on actual work completed.  I report on the amount of remaining work and how that may have changed.  I work on how the last sprint has changed the average, highest, lowest and last velocity and how that influences the potential end date spectrum.  I report on this Every Single Sprint.

Practicalities: Sometimes you need a date, but try not to

My current process that I’ve been using for the last two years is possibly not very agile.  But when a date is asked for and that is what the client / boss is managing to then you sometimes need to provide one.  And then you possibly need to argue what to change in order to stop managing to the date.  I’ve (maybe) just won that argument – but we’ll need to see how that project continues.

Step 6: Replan every sprint – the numbers don’t lie

The beauty of this is that the numbers don’t lie.  It is simple as that.  We can be hopeful and optimistic and plan on the best velocity – but if we’re consistently not achieving the best velocity that will continue to self-correct every single sprint and the end date will move accordingly.  If we don’t discuss the information that is radiating out of the figures then we have our heads in the sand and we’ll fail.  Managing the expectations continuously and early will ensure more probability of success.

Step 7: Be Successful at what you know

Success is a relative term.  Managing expectations and ensuring that we’re successful with delivering what we know ensures that we’re successful.  Managing the change so that we can be as agile as the client / boss will allow us to be ensures that we’re successful.  We can’t do magic.  But we can manage the reality or what is actually happening Every Single Sprint.  And everyone can embrace change and be successful.  Or fight it – and hope to be successful despite the need for change – it is possible.

Are there other ways to plan?

Of course there are. There are vast options on the planning tree.  When it comes planning without involving the team there are many options.  At my current organisation there is a magic spread sheet that turns input into days based on numbers of developers to understand a guess at the size of the work.  The bottom line is that no matter what the original plan is on day 1, there is a good possibility that it will change at the end of the first sprint based on the feedback cycle from that sprint.  Embrace that information and deal with it rather than hide it and pretend we’ll do better next sprint.

Scrum provides an amazing opportunity it empirically measure progress and hence reset the planning at the end of each sprint.  Ignore it at the risk of failure.

But is it agile?

I’m not convinced that what I’ve done in the past has been very agile.  The PO and myself have done a lot of preparation work in order to ensure that the backlog is defined enough and able to be sized.  All the stories are small enough.  We haven’t been looking at epics.  This can take a reasonable amount of effort and be wasteful.  But it avoids including the full team until a full understanding of what is wanted is obtained.

Recently we’ve had the scenario where the RFC was understood but wasn’t “signed off” so we couldn’t start working on it – despite knowing that there were solid chunks of work that were very unlikely to changed.  That is waste and not very agile at all.  That is one of the things I’ve been frustrated about and have wanted to change.

Recently the PO has started working more closely with one or more team members to define the backlog better.  It will be interesting to see how that pans out with a more collaborative generation of the backlog.

I’ve also pushed very hard for us to be more agile about the requirements definition.  Let’s work it out as we get there – let’s rather embrace a little more ambiguity in order to avoid the in depth up front work for the PO and stop fighting the ambiguity as the RFC isn’t perfect.  However we do work in a remote scenario so this might turn out to not be such a good idea if the PO isn’t always available.

Equivalently with ambiguity comes less predictability on that Big Date that we may be managed to.  However I believe we have an agreement that the date isn’t usually an important feature so we should stop managing to that.  And get some of that continuous delivery going with more releases more often.

Aside: Are dates reasonable?

Is the original question reasonable?  Of course it is.  A CEO wants to make a deal and needs to know if something is possible.  A managing director needs to move forward with a product and needs to know if a certain client can be supported in a certain timeframe.  A managing director needs to be able to calculate the ROI for two different streams of work and hence needs to know the relative sizes of the work.  These really aren’t unreasonable business requirements.  But they all need to be weighed up and balanced to ensure that in the timeframe required we can deliver the highest priority items for the business.  That should always be driven by the business.  But the business should still ask us before committing.  And we still can’t do more work than we’re capable of.

Step 8: To close…

This is how I’ve been planning.  Continuously feeding back on the progress.  Get the client / boss to understand what that means.   And fight the fight when it comes to a head that the “date” isn’t in the planning – or hit the date because the velocity calculations make the delivery vastly more predictable than other methods so you can actually get the date right – or even deliver early.  Rather do that than deliver late.

I’ve had really great success delivering predictable releases with the above.  There is no magic.  Just a little maths, a lot of measuring and strong will power to help the client understand.  Hopefully this can help others to be more successful as well.

2 comments on “I want it by October

  1. Carlo says:

    Simon’s recent CSPO course had me in stitches. His question which prompted my hysterical laughter was: “would we still be so dysfunctional if we called estimates and padding by their real names? Namely, guesses and lies.”

    Think about the distribution of power (and risk) vs. information. The successful win-win outcome is dependent on collaboration, under well defined constraints (such as delivery dates and budgets).

    Attempts by either party to shift responsibility (or risk) are likely to inhibit the flow of information that is vital to success. This is the essence of “Customer Collaboration over Contract Negotiation”

    Lastly, from “eXtreme Programming Explained” is this wonderful idea. Your responsibility (as developer) is not to manage expectations. Your responsibility is to be open in your communication, so that the customer can take responsibility in managing their own expectations.

    • patrickvine says:

      Thanks Carlo.

      Yes – I use the terms guess and hope when I’m referring to planning all too often. Lies comes across as a little negative though. I have actually offered to lie about the planning if it would make the client feel better. I stressed it wouldn’t change anything though.

      I completely agree with the comment about responsibility. If the client were capable of assimultating the information radiated out to them effectively (which they can…) then they’d understand exactly what is happening and be able to ask probing questions. Unfortunately sometimes you need to actively spell it out to make sure the reality is understood as sometimes people like to live with their heads in the sand and pretend that because a guess was provided it is concrete. Or they could be reading it but hoping that it isn’t so.

      The more transparent the communication – I try to expose all the warts – and the more responsiblity both sides take – the less you need to managing expectations at all – as more trust and understanding is generated.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s