My customer wants a roadmap with dates

Another question from Oredev, one comes up a lot:

Q: What do I do when a customer wants to see a roadmap showing features with dates?

Selling features by the pound

First note, even getting into this position in the first place suggests problems. You are selling features rather than solving customer problems. While many software companies have found this a profitable line of business it is self-limiting and reduces long term ability to create value and generate revenue.

Working like this is akin to a vegetable shop selling potatoes. Customers come in with money and leave with potatoes. Every-time a customer walks in you need to have potatoes in stock. What happens is someone else offers potatoes for less? Or customers want rice?

Contrast this with the subscription model of meals companies like Hello Fresh. These companies don’t just sell potatoes, they solve a problem: how do I feed my family?

When you are selling features by the pound you are at the low end of the market. You have to keep selling features which means your product is destined to end up feature rich and unusable. You are always playing catch up with where the customer wants to be.

When you sell solutions you get ahead of your customers and show them how they can be better. Instead of selling them a hypothetical future sell them the quality product you have now.

This is also better for the engineering team. Sales are based on never ending feature requests everyone is on a treadmill.

So: stop selling features, sell solutions. To do this understand your customers, understand their problems, aim to sell solutions and get ahead of customers. Become their trusted partner with fees to match.

Let the customer drive

Back to today: you are probably following some form of backlog driven development (BLDD). So let us accept your organization could be better. What do you do in the meantime?

I would turn the question around. First ask the customers what they want to see, then ask them when they would like to have these things. Make this prioritisation conversation, A or B first? I might extend that conversation to value (“What benefit will this feature bring you? How much money will this save?”). Right after the prioritisation conversation or I might postpone value till later and I might use value poker to get handle on value.

Next I want to know their dates. Laugh when they say “Yesterday.” If need be explain you don’t have a time machine but recover and get them serious. If they keep insisting yesterday, now, tomorrow start slicing the work down. “We can’t give everything but maybe we can give you something small.”

More on, do you need this in the next 3 months? the next 6? next year? More specifically, what is the time-value profile? when is a feature worth the most money? and when does it become worthless?

Notice, I don’t want to suggest anything at this stage, I want to hear what they want.

Neither do I want to talk about dates based on effort estimates. The only thing that is certain about estimates is that they are wrong. Remember there is always more than one way to solve a problem. You now have their perfect roadmap.

Back at the office I would talk to engineering about what might be possible in the time frame the customer is asking for. See, I’m prepared to change the solution to meet the time scales.

Lean roadmap

All the time this is a “what if exercise.” There are only thing you can say for certain: what you are working on now and what you think you will work on next.

Some people call this a Lean Roadmap. This has 3 parts: what we are doing now, what we plan to do next and everything else.

Now if you have just one customer you can iterate on this process and effectively co-create a “what if” plan with the customer. But I still wouldn’t want to go further than now, next and everything else.

In contrast, if you have multiple customers you can still iterate but at some point you have to accept that you are going to upset them. The question is: how long do you wait before you break the bad news?

Now, you might be thinking “This is unrealistic, my management won’t buy this so I have no chance with my customers.”

In this answer I am being brutally honest: no schedule based on effort estimate dates will work – read Dear Customer. Putting out such a “roadmap” only delays reality and means people will be unhappy when dates are missed so let’s find a better way.

The Lean Roadmap (now, next, everything else) is one option.

What we really want are rich conversations with ourselves and our customers. From those conversations we can build understanding. We can say things like “In Q3 we plan to build a solution to the mobility problem.” You might even stand a chance of delivering such a plan. What you cannot say with any confidence is “In Q3 we plan to build epics 1234, 1249 and 2734.”

Creating those rich conversation means enriching the communication between engineering and customers, reducing intervening proxies (BA, Product Manager, Sales) and focusing on solutions and the benefits.

If that still sounds impossible then by all means list your features, write some random dates against them – don’t waste your time on pretending you can estimate unless you have the statistics to prove it. Hand that to your sales people, make sure you are paid regularly and accept you are working in a feature factory.

Subscribe to hear more from Allan Kelly and download Continuous Digital for free

5 options for when the boss changes the target before you reach the last one

Another question which came up at Oredev recently:

Q: What do you do when leaders change direction before you have finished your last goal?

I’m sure many readers will recognise this problem, and let’s face it: it can be depressing, you’ve not finished and suddenly you are heading off in another direction. When it happens repeatedly it is especially depressing.

Unfortunately, the term “Agile” implies that one can change direction and change regularly. So maybe this is something we just have to accept? – although depressing, is it really a problem?

Don’t forget: Writing OKRs mini-workshop masterclass, online December 12, 2022 – limited number of early bird tickets still available

– use discount code BlogReader to save another 20%.

Before we try and fix this problem lets acknowledged that it might not be a problem. Chris Matts used to tell a story of a company which when it landed a big enough sale simply threw away what it was working on, rolled back to the last stable release and immediately started working on the new thing. They had rationally calculated that when a sale was big enough it was worth more than the partially done work. (If I recall correctly, they made releases regularly so they would only be throwing away two weeks work at most.)

So, your first option, solution #1, is to optimise your work and deliveries to support rapid changes in direction. One could even argue this was “true agile”.

But, for many teams repeated changes of direction are a problem. They are a problem because the team aren’t able to move forward at all let alone reach a destination. Work which is partially done is either abandoned (and lost) or left unfinished. Unfinished work may increase costs because it gets in the way. We might tell ourselves we will come back and finish it once the panic is over but, as I discuss in always time for tea, that never happens.

So that is the real problem: changing direction is not itself the problem, rather the problem is that nothing is finished. When teams complete and deliver work at the end of every sprint, then as long as direction changes only occur in the planning meeting then there is no problem.

The same applies to more regular changes if the team can finish their work. So, if at the end of every day the team complete some work and deliver it then, if the next morning things change they still loose nothing. True, it might still be depressing that things change so often but it wouldn’t represent a loss.

Thus, solution #2 to this problem: make your pieces of work small and self contained to minimise the loss and increase your ability to roll with changes.

One cause of this problem can be the Product Owner is not doing their job properly. The PO should be peeking into the future and understanding what is round the corner. Sometimes they don’t do that because they lack the skills, other times because they lack the time to do it, but mostly they don’t do it because they lack the authority. They don’t get to visit customers or people in the organization usurp their authority.

So, solution #3 is to fix the Product Owner: make sure they have the authority, skills and time to do their job.

Solution #4 is to go to source: the people causing the changes and work with them.

When I’ve seen this before one of the driving forces was that the people asking for the change of direction didn’t feel the team would be able to complete one piece or work in a timely fashion and advance to the next. Nor did they appreciate the loss that that caused the team when they repeatedly change direction.

Now, if you apply solution #2 and work with lots of small then you can build trust by delivering early and often, that will give you more credibility when asking the direction changers to slow down. But that is unlikely to cure the problem entirely.

Therefore it is important to help those causing the changing direction to understand the consequences of changing: and the fact that constantly changing direction might be the cause of the problem they are trying to solve themselves. To this you need to create a feedback loop so people can see the consequences of their decisions.

One team I worked with would write down the request on a card and take the card and person making the request to the kanban board which showed their work for this sprint. They would ask “Where do you want this work?” The person asking for the change would be asked to decide which work was to be derailed or reprioritised. When this was simply a matter of positioning an index card on the board this was easy to see, the physical act made this really impactful.

Another client redesigned their burn-down charts so the powers-that-be could see that every time they changed direction they increased work and lost what had already been done.

Longer term, there is a question of strategy and sticking to that strategy. Constantly changing direction is itself a valid strategy. It is only a problem when complete responsiveness is not the strategy and when the team are not prepared for it, i.e. when change goes against the strategy.

Having a strategy (which isn’t complete responsiveness) allows one to judge each change request against that strategy. If the change request is coherent with the strategy then doing it makes sense. If not then there is a discussion to be had and there is probably a good case for rejecting the change.

This is not to rule out strategy changes, companies should pivot and change strategy sometimes. However, if one is constantly pivoting and abandoning strategies then it is a sign something is wrong. Strategy, by its very nature, should have some longevity.

Unfortunately, companies often lack strategy either completely or fail to communicate what the strategy is. One Town Hall does not mean everyone knows and follows the strategy. Strategy is embedded in every decision and action of the company leaders.

So, solution #5: fix the strategy.

When ever option you choose Objective Driven Agile can help.

Q: When you have a 12 month deadline?

One of the points I made in “Its always time for tea” was why it makes sense to leave things late – until the last responsible moment. I also pointed out there research shows that when you have more time work expands. But, while humans are very good at working to deadlines we are atrocious at estimating time. Later I argued for thinking small – Kelly’s (second) Law of Projects: “Inside every large project is a small project struggling to get out.”

So, it was perhaps unsurprising when someone came to me later and asked:

Q: “What do you do when you have a far out deadline but one you must meet? e.g. you need to change vehicle software to stay compliant when the law changes in 12 months.”

It would seem that waiting until a month before the deadline to do the work is not the most responsible thing to do. But starting now would risk the work expanding in size.

I see several options for this.

First: just try and do the work. I’m assuming this is non-trivial so allow yourself, or your team, a few weeks to try and do the work. This is what we used to call a “spike”, the idea is not to do the work but to learn what you need to do to learn to do the work.

At the end of the time period you can throw anyway your work but you will have learned a lot. You should have an idea of the order of magnitude of the work: month or weeks, a small team (say 4) or many teams.

Having done that, even if you fall back on classic project management to design and plan the work but having done the spike you would be working with superior knowledge.

While you could set yourself an early deadline and try and do the work immediately there is a danger that, knowing it was safe to be late, the team would let the work expand. So, while this approach might not be the most cost-effective it would probably deliver on schedule.

If, from the spike, you are confident the work could be completed in a few weeks you might decide to delay starting on the work. After all, the payback for this work is a year away so work on something which has more immediate value.

One of the problems any early start approach will face is knowing when to stop. It is quite possible that the team will complete the original work but knowing there is time (and funding) to do more they do more. One way to combat this would be to specify the tests right at the start.

Specify the tests and conduct them before you do any more work. See how close you are, and, when you are doing the work execute those tests regularly. When you pass the tests you know you are done.

Having these tests should help you be ruthless with the work the team is going. The problem with many big projects is they accumulate tangental “nice to have” work. Having tests should allow you to sideline any work which is not going to support passing the tests.

Now, it is possible that your spike leads you to believe that getting the work done is a challenge, you might not make it.

One option here is to use this information to ask for more people and other resources in the hope that a bigger team will get the work done faster. Yes, I know that goes against my original advice, and I know that Brook’s Law and pregnancies suggests it won’t help but put it down as an option.

Now we are into spending big money more options open up.

Do the best you can but in parallel launch a lobbying campaign to change the rules or have them delayed. This might sound repulsive, and it is not an engineering solution, but actually big companies do far more often than most people realise.

Another option is set based engineering as practices by Toyota. Form up two teams, give say 90% of the budget to one and 10% to the other. While the big team takes the rational approach the other team work on a lightweight solution. If the 10% team succeed you are on safe ground and potentially save money by cancelling the other work.

Finally, I’m speaking from an abstract perspective. I expect a company which faces this sort of situation has probably done so before, more than once. So in addition to doing a spike and writing some tests I’d want to look at past performance. That might offer some more options or tell you what not to do.

Online Writing OKRs mini-workshop masterclass, December 12, 2022 – limited very early bird tickets available until 28 November – discount code BlogReader to save another 20%.

Writing OKRs – a mini-workshop masterclass

Next month – in just over 3 weeks in fact – I’m running a mini-workshop Masterclass (2 hours) on Writing OKRs. Specifically on making key results measurable and quantifiable. Yes I know targets can mislead, that might be something we will talk about. Its timed for 2pm which should be good for Europe and the East Coast. Sorry far east, Australasia and West Coast.

Tickets are available now but are limited so if you want to don’t delay, book now. Plus, for the next week cheap very early bird are available, and if you use the code “Blog20” you can get an extra 20% off.

I hope to see you there

Its always time for tea (Oredev keynote)

Always time for tea

Last week I delivered the opening keynote at Oredev in Sweden: It’s always time for tea – lessons for Alice the software developer. I also picked up a whole bunch of questions – about agile, OKRs and tea – which I intend to answer here in the coming weeks.

This was a unique presentation, a challenge to put together but still a lot of fun to create and deliver. You see, the conference had an Alice in Wonderland theme so the challenge was to deliver an Alice themed keynote. Having read Alice twice in the last few years I knew immediately where to start: the Mad Hatter’s Tea Party.

The lessons I drew from Alice form a mini-manifesto which nicely describes much of my own philosophy when it comes to managing digital work.

Deadlines over estimates

‘Yes, that’s it,’ said the Hatter with a sigh: ‘it’s always tea-time, and we’ve no time to wash the things between whiles.’

Which nicely describes the life of technology creators. I argue that “it is always time for tea” is actually the natural state of things. When it is not “time for tea” we lack motivation; humans are bad at estimating time but good at working to deadlines. (See my old Notes on Estimation and More Notes on Estimation.)

Therefore we should organise our work processes around deadlines not estimates and structure our work in the expectation that we will not get time to make things good later.

Purpose over plans

“It doesn’t matter which way you go,” the Cheshire Cat tells Alice, “‘you’re sure to [get somewhere] … if you only walk long enough.”

In Through the Looking Glass the Mock Turtle concurs: “‘no wise fish would go anywhere without a porpoise. … , if a fish came to ME, and told me he was going a journey, I should say ‘With what porpoise?'”

Similarly, plans are not benign, plans have a dark side, they can be demotivating, demoralising, controlling and mislead us. Planning is essential but plans are downright dangerous.

We often overlook purpose, mission and outcomes in favour of following the plan and just “doing the backlog”. Yet out backlogs have become bottomless pits and burn-down charts are often burn-up charts.

At some level we are too busy doing stuff and earning money to think about the bigger questions but there is evidence that companies which focus on purpose and regard profits as a side-effect do better, and not just in the long-run.

Small over big

Everyone knows about Alice growing bigger, and smaller. Which echo’s “Kelly’s law of projects: “Inside every large project is a small project struggling to get out.”

The idea of doing small things comes up again and again: minimally viable products, prototypes, proof of concepts and so on. But we too often think big and fall for the old economies of scale myth.

Simplicity over complexity

With big comes complexity, which Alice discovers when the King invokes rule number 42:


Again and again we find complexity hides simple truths, we need to constantly work for simplicity.

Along the way I talk a bit about the nature of agile methods and explain that while SAFe may be agile it will never be lightweight.

I think it will be a while, if ever, before this presentation gets repeated but hopefully a video recording will be out before long. In the meantime you can get the slides.

After my presentations at Oredev, and over coffees, I picked up a few questions which I thought I’d answer in the next few blog posts. I hope you find this useful, and as ever, please leave a comment or get in touch to talk about these ideas more.

Nuke your backlog – the podcast & a webinar

In case you missed it, Tom Cagley has released the “SPaMCast” podcast we recorded a couple of weeks ago: Nuke your backlog!

Since recording that I saw Rob England describe similar thinking as “declaring backlog bankruptcy”. Certainly bankruptcy is a more business friendly than “nuke”. And in the weeks since I releases “Honey, I Shrink the backlog” I’ve had several people tell me about their experiences ditching their backlogs.

So, while the disposing of the backlog may be a somewhat radical idea it is not completely new.

If you like the podcast you might want to join a webinar with Adrian Reed next month where we will be discussing the problem with backlogs: Moving Away from Backlog Driven Development: A New Chapter in Agility? – free, registration required.

Objective Driven Agile, BLDD & Reactive styles of development

Looking across the state of teams today I can clearly see three different styles of agile: Backlog Driven Development, Reactive and Objective Driven Agile. All have their place, all have their uses but the first two of these are a dead end. I’ve been speaking about the third, which I’m calling Objective Driven Agile, for years but in the last few months, since writing Succeeding with OKRs in Agile and speaking to many people about how OKRs and agile fit together, it has become clear to me that ODA allow us the industry, and teams, to address a number of problems that have arisen with agile in recent years.

1) Backlog Driven Development – BLDD. Teams are typically working in a Scrum fashion with a backlog and short sprints. Such teams are sometimes called “feature factories” because they are aiming to “do the backlog” – and the backlog is inevitably a lis of features.

While the Scrum these teams practice is a lot more agile than what came before they haven’t really moved very far from the big requirements documents of old. Backlogs are frequently bottomless pits, the team can never reach done. The loss of change review board might well be making things worse because Product Owners often lack the authority to say “No” or remove items from the backlog.

Still, not only are these teams agile but in many places this is success. The team are churning out stories, customers can see progress and are persuaded to part with cash. If the backlog can be tamed they might even declare done one day. But then, if the team is being operated by a consultancy or other outsourcer for a client the last thing they want to happen is for work to be done.

2) Reactive. Reactive teams gravitate towards Kanban but some are compelled to work in a Scrum fashion which doesn’t match their real work. Such teams may see backlogs are an anathema because they do “what is needed, right here, right now.” Team members here will say “true agility is listening to what customers want and getting it done as quickly as possible.” And in a way they are right.

Again, these teams are a success story, particularly if they are supporting a live system, running DevOps or if customers previously had to wait months for results.

The problem here is that these teams don’t have much capacity for doing the backlog or anything else and yet they are frequently still expect to “do the backlog”. If such a team have been tasked with immediate customer support then that isn’t a problem but frequently these teams face competing demands.

3) Objective Driven Agile, ODA: this is the approach I’m focused on at the moment. With Objective Driven Agile teams have a mission and a higher purpose, something more than “do the backlog” or “keep the system working.” Such teams might be considered “Empowered” and might practice “Dual track agile.” The key thing is, they are not beholden to a prepared list of things to do. The team are responsible for deciding what customers need, what will add value and what will meet team and organisational objectives, and then, delivering that thing.

These teams have “Product Owners” who are more than mere Backlog Administrators – I’ve started calling them “Product Specialists.” These people are tasked with understanding what will add value for customers, users and other stakeholders. Importantly they have the power to decide what gets done and to say “No”. With that power comes responsibility: responsibility to the team, to stakeholders and to other leaders in the organization. That means Product Specialists can explain – in a business case or in a star-chamber – how work on the product adds benefit and how the desired outcome – the objective – is moves things forward.

All three of these styles have their advantages and disadvantages but the real problems occur when the styles are not clearly stated.

Consider the team trying to deliver the backlog BLDD style but who have to “keep the lights on” and support a live system. It is mathematically impossible to make accurate forecasts about delivery when events can derail you. It is also nye on impossible to deny customer requests when they are waiving a large sum of money or escalating their ask through your organization. But again, this can blow up any plan or roadmap.

Nor is is possible to pursue objectives when teams are committed to supporting live or delivering a backlog. At best the objectives duplicate the role of the backlog and at worst increase work-in-progress and add stress to individuals on the team.

So my advice: decide which type of team you are and focus.

In the last few months I’ve been speaking a lot both about objectives and “just in time backlogs”. I’m fired up and want to pursue this idea, if you are interested please let me know and I’ll write more.

Subscribe to hear more from Allan Kelly and download Continuous Digital for free

User Stories by Example back online

Better user stories

My popular User Stories by Example online courses have been absent for a couple of months while I moved platform. I’m pleased to say these are back online on a new platform. The code Blog2022 will give you a 25% discount on the courses.

Also included here is a package deal of the e-book and audio book of Little Book of Requirements and User Stories both of which are DRM free.

Objective Driven Agile – 7 step lightweight method

Lets get back to lightweight methods, let me propose a 7 step process with the working name Objective Driven Agile – although I also want to call it Really Simple Agile or maybe Xanpan 2022 – and I’d rather forget the A-word altogether and get back to lightweight.

1) Start where you are, with the people on the team, with the code you have, with any existing documents, there is no pre-work, you start here with what you have. Any pre-work you think you should do, any blocks or impediments you are facing, any reason not to start now becomes a work item to be done.

2) Default to a 3 month “super-cycle” and 2 week iteration cycle (OK, we’ll call them sprints), you may change this later but put the dates in your calendar now and set them to reoccur.

3) Set a maximum of 4 objective(s) for this period.

I will assume you are using OKRs for this and limit them to a maximum of 4 key results for each objective. Key results are not small pieces of objective but bounding criteria which describe the objective, acceptance criteria.

If you team must “keep the lights on”, operate as a DevOps team, support a live system or other “business as usual” then this is objective zero and must be acknowledged as work to be done.

Objectives are outcomes, they make the world a better place. Objectives should support business purpose and strategy. The team should be able to explain how the objectives meet these criteria, better still it should be obvious.

One of the objectives should be nominated by the team themselves with the aim of making future work better, easier and more productive even if the outside world can’t see a difference.

4) Run sprints (iterations) inside your super-cycle: the first sprint starts as soon as the objectives are confirmed.

If any preparation work (e.g. interviewing customers) is needed this is part of the work to do. In the sprint planning meeting review your objectives, then decide which will be the focus of the sprint and ask “What do we need to do to advance our mission?” and write stories for this work.

For each story ask: “can this be completed within one week?” If it cannot then find a way to rewrite it as several stories each of which can be completed within one week.

When you have written the stories ask: “is this enough work for the sprint?” If the team thing they have capacity to do more work, or might do all of this work, then write some more stories – about the same objective or another. If the team feel this is too much work for this sprint prioritise the work then hold some back for the next sprint.

5) During the sprint aim to release each story as it is done, continuous delivery style. Review progress against OKRs regularly (but not every day). If the team can’t do release individual stories at the start then it is something to work towards, something for that team nominated objective.

Work items which arise under OKR #0 should be recorded as “yellow stories”, the team may refuse such work but once accepted it has priority over all other objectives unless otherwise decided.

6) At the end of the sprint release any finished work, demo to stakeholders, review, retrospect and replan. Count the stories – including yellow work – completed each sprint and maintain a graph during the super-cycle. The graph should show planned and yellow work.

7) At the end of the super cycle close out the sprint, review progress against OKRs, hold a retrospective for the whole period. Destroy any stories which still remain undone.

Return to step 3.

Two assumptions: you are setting objectives using OKRs, you are running Scrum like sprints. Both assumptions can be relaxed (i.e. you don’t need to use OKRs and could run Kanban style) but I would need more space to explain how that might work and I’ve deliberately kept this short.

I expect regular readers won’t be surprised by this, my recent work has been going in this direction – I’ve already explained the logic in here in Honey, I Shrunk the Backlog, Backlogs, #NoBacklog(s) and comfort blankets and last year’s Xanpan 2021 (Xanpan 2021 slides or Xanpan 2021 on YouTube).

Let me know if you would like me to expand on these ideas.

Subscribe to updates from Allan and download Continuous Digital for free

Lessons from Alice – free & online

In November I’m delivering the keynote at Oredev in Malmo: “Its always time for tea” – the conference has an Alice in Wonderland theme.

Before then, I’m doing a practice run at Agile Bath and Bristol entitled “Lessons from Alice” on 11 October. This is online so if you can’t make it to Malmo you can get to see an early version – and if you are going to Malmo you can get a sneak preview.

As the name(s) suggest I’m aiming to draw lessons for technologist from Alice – after all, I was told long ago that Alice is Wonderland is packed with mathematical observations.

Its free so sign-up now.

Verified by MonsterInsights