allan kelly

Lets talk about money: the ultimate feedback loop

Agile / / / , , ,
Pile of dollars

Money is information. I like to joke: “money is the best form of feedback.” Unlike comments in a retrospective, kudos cards, and SurveyMonkey results I can trade your information for something else and in so doing, give someone else feedback.

When someone buys your product they are saying “Your product is worth giving up …” – money in the bank, a nice meal out, a new car. You give them the product and they give you information. Money is a feedback, perhaps the ultimate feedback loop.

Within companies money also provides information. Money signals what the company values and who has power.

I worked as an agile coach with a Belgian company applying “the Spotify model” a little while ago. The leader of the tribe repeatedly told squads “you are masters of your own destiny.” He was keen, at least when speaking, on self-organisation, on squads taking control and aiming high.

One of the squads I coached decided the best way of improving performance was to improve quality: reduce bugs, reduce outages, make customers happier, improve code quality, etc. Then they asked for money for technical training and coaching. End of story.

The squad had no budget of its own. The tribe had budget but it was earmarked for something else. Asking for more budget was off the table. The squad only had power while they didn’t spend any money.

Team finances

Teams, development teams specifically, rarely get to see or talk about their own budget. In fact they rarely get to talk about money at all. It is funny, most of us live and work in capitalist in free markets societies. Success is judged by profit (or at least revenue), and the aim of the company is to make money for investors.

But day-to-day how much does anyone on your team know about the finances of your team? How much does your team cost per month?

What about your product: What does it sell for? What is the profit margin on the product? How much will that new feature you are adding earn?

While managers will often talk about cost-benefit “bang for your buck” and ask “how long will feature X take?” or “is it a quick win?” it is seldom quantified. If it is then it is probably only in days or weeks not pounds, shillings and pence.

Inside the company it is almost as if we live in a cashless communist enclave where money can’t be spoken of. People even say “Its all about money” as an insult – still they expect to be paid in money and (usually) want the company to keep doing so.

Informed authority

But what is devolved authority, self-determination, self-organization if it isn’t backed-up with the power to spend money?

How are we to make informed decisions if we don’t know how those decisions will effect cashflow? – while we might know costs how can we begin to talk about revenue without information. And how can we evaluate the impact of our decisions if we don’t see the bottom line?

I give my children a few pounds a week pocket money. They can choose to save it or spend it, I do my best to respect their choices even when I disagree. When it comes to bigger things, holidays and even clothes, Mum and Dad make the decisions.

If companies don’t open up finances to teams then they don’t trust those teams. They are placing severe limits on what the teams are allowed to self-organize. But in almost every company I’ve ever worked for, or with, development teams are treated like children and kept away form money. Even asking about money is frowned on.

Is it any wonder engineering decisions happen without reference to financial impacts? Why should we expect engineers to suddenly become aware of the cost of their decisions when actual costs are hidden? And there is no feedback loop?

Hourly efficiency

I can’t recall ever seeing a team with their own budget. Even a small budget would be an improvement (of course ultimately we want Beyond Budgeting but I’ll settle for imperfect budgets right now.)

I’ve long advocated Kazuo Inamori’s Amoeba management model. Inamori points out that in most companies teams get no feedback on their financial performance. In amoeba management, hourly efficiency reports are used to control costs and allow teams to make their own trade-offs on expenditure – not unlike beyond budgeting in fact. (In Kyocera hourly efficiency is calculated as: (revenue – (costs – wages))/hours.)

Unless teams have financial information they can’t make decisions. Back in Belgium I couldn’t quantify the cost of bugs because there was no data on salaries, contract rates, product contracts, support desk costs. I couldn’t put a value on removing bugs. But I was forced to put a cost eliminate those bugs. Consequently I couldn’t do the cost benefit equation and it was down to one man making a decision which seemed to favour some teams over others.

Talking of value without financial feedback loops is pointless.

Enjoyed this post? Subscribe for updates and download Continuous Digital for free

Lets talk about money: the ultimate feedback loop Read More »

Is all management bad? Or is it just bad management?

Agile / / / ,

There is an interesting piece in this week’s Economist about the poor quality of management in the UK, “For Britain to grow faster it needs better managers” (paywall). It suggests bad management is a large part of the productivity gap between the UK and other developed nations. Living in the UK, and having seen inside many British companies this rings true with me. I’ve long thought it was less a case of “In search of excellence” and more a case of “In search of mediocracy.”

Now that said, I don’t have an objective point of view: I’ve been involved with many “project rescues” or “turn arounds” (actually I quite enjoy them, call me!) in the UK but my clients abroad are normally more stable. I suspect this is selection bias: because I’m UK based it is easy to ask for help. Flying someone in from abroad is a barrier so only the better managed companies in Europe and the USA would do it. So while I might think UK management is bad it is entirely possible that it is bad everywhere. Indeed, I am sure there is bad management everywhere, and there is good management too; but in the UK the ratio of bad to good is higher.

The international agile movement doesn’t do much to encourage management to improve. All the anti-manager talk (“self managing teams”, “no project managers”, etc.) creates a barrier. It has long been my view that such anti-manager talk is largely a reaction to bad management and it is entirely possible that “no management” is better than “bad management.”

Simultaneously, “good management” can be value adding, people don’t push back on “good management” (even if it gets branded as bad just because it is management). Sometimes, making things better for the many means being unpopular with a few. The few will voice their complaints more loudly than the many will voice their praise, and often it is hard to attribute success to managers anyway.

What we miss

The common agile view of management as “a bad thing” misses two points:

First off: removing the managers will remove some management work but will leave a lot. Removing managers does not remove management work. The work which remains either doesn’t get done (worse still) or is spread around those who remain so everyone’s work gets disrupted. On the whole these people don’t want to be managers, so they are unhappy and don’t have management skills. They do have other skills – business analysis, Java, support desk, whatever – so now they are not using their most productive skills and are unhappy with it.

Second, and more importantly: removing managers does’t do anything to improve the skills of those who do management work. Whether this is managers in place or people who have to step up when managers are fired. In other words, all this talk of “no managers” stops us from improving management skills one way or another.

Yes, I think workers and teams should have a voice in the work they do.

Yes, I think we should make group decisions and take into account diverse opinions.

Yes, managers sometimes need to use authority but good managers spend more time nudging, enthusing, guiding, structuring. Occasional use of authority can help, over use undermines.

Yes, I think people can take more responsibility. Some of what passes for management work is admin that could be dropped, information sharing which could be automated, or managers making work for other managers.

But I happen to think good management recognises all those things and respects the expert workers.

Bad management ignores all those things and subscribes to the “Action Hero model of management”: you do this, you do that, I’ll siege the bridge, if I’m not back in 10 blow it all to kingdom come, move it!

The irony is, those who subscribe strongest to the “no management” meme will say “Let the engineers (or doctors, or designers, or whatever) run things” but when you do that you find a management style cadre arises who are experts in their own field. Being a senior engineer (or whatever profession) often means being a type of manager, they need their original skills but they also need some management skills. If they don’t learn new skills those people become bad managers.

Is all management bad? Or is it just bad management? Read More »

Why is it hard to reduce WIP?

Agile / / / 1 Comment

Turning to my second potential silver bullet: reducing WIP, work in progress. This is easy to comprehend but hard for people to action. Again optimism plays a role: because we are optimistic, and because we don’t like giving bad news people naturally tend to take on more work than they can reasonably do. Making this worse are members of the agile community who go about talking about “commitment” and “doing twice the work” which makes people feel they should be doing more.

Culture also plays a role. When people like to present a “can do” image, when hierarchy is important and when people are accustomed to doing a little of everything and saying “No, I’m fully loaded” then reducing WIP is harder.

People are reluctant to say they are “full” until they are very close, or even beyond, 100% capacity. But the problems with queuing work occur long before 100% is hit. Even leaving aside human cognitive capacity to juggle many things basic queuing theory tells us that as work increases, the variability in work (i.e. some things take 5 minutes while some take 5 hours) means delays will occur. As capacity nears 100% the system looses capacity to absorb the unexpected (someone is ill, a delivery is late, etc.) so predictability is lost and delays spiral – the “bull whip” effect.

Notice I say system: we all work within systems, not computer systems, workflow systems. One person’s heroic efforts count for little when they work in a saturated system. We end up like Boxer in George Orwell’s Animal Farm, saying “I will work harder”, we work harder, wear ourselves out and burn-out. Too often we forget the old agile principle of sustainable pace. (Watch Stockless Production to see this in action.)

Sponges destroy trust

Once it becomes clear that little is being delivered, and even less to budget and deadline, trust is loss. People are less willing to see work requests queue. They want to see action, any action.

In a rational system some work will wait until there is capacity, but when there is no trust people want to see their requests being worked on. So instead of a team working on a project for a month and then moving onto the next thing in sequence the lack of trust means everything has to happen in parallel, slowly. So, a lot of work happens at the same time, there are much higher switching costs, variability creates delays and management overheads rocket. The team becomes alike a sponge: work goes in but very little comes out.

This can all be particularly tough in start-up environments. In the beginning start-up often depend on a few founders doing ridiculous amounts of work. This culture of long hours and heroic efforts. It is thus hard for people to accept that fewer hours and lower WIP might create a better outcome.

This is particularly true when the founders are still in the start-up: inevitably they worked very hard at the start and they want to see that ethos in their employees. Their start-up survived because they chased clients and worked very very hard. Therefore the founders see hard-work and lots of WIP as the recipe for success. The last thing they want is someone saying “no, do less.”

The same ethos carries over to investors who want to see lots of action, lots of people running around being busy. And because in a start-up it is hard to know what will work it makes sense (portfolio theory) to work on lots of different things to find one that wins. Again this creates a culture of high WIP.

Aligned & misaligned feedback loops

For those seeking promotion it makes sense to be involved with lots of different work and cultivating a “can do” image. Being see as “Dr No” or shying away from work is unlikely to lead to promotion. So there are incentives to take on more work. And when such a person gets promoted than their theory of success is proven so they expect the same from others. Meanwhile, those who surreptitiously balance their work load, keep within their own capacity, beaver away and quietly delivery are less likely to be promoted.

The feedback loop promotes the wrong behaviours: each piece of work is viewed in isolation. Each one suffers its own delays and it is hard to see how one obstructs the another. The project model makes this worse because it disconnects funding (based on benefit analysis) from capability to do work.

If you are lucky you can say “Reduce WIP” and people will do it.

If you are unlucky then you need to build a feedback loop to show these problems, you need to start pushing back where you can, you need to start building trust.

See also: Two Unspeakable Silver Bullets and Why don’t people Test First?

Enjoyed this post? Subscribe for updates and download Continuous Digital for free – please share!

Why is it hard to reduce WIP? Read More »

Why don’t people Test First?

Agile / / / , / 1 Comment

In my last blog I describe two potential silver bullets: working test first and reducing work in progress. I finished by promising to discuss why they aren’t used more. This post briefly discusses why people don’t work test first, the second one, looks at why it is hard to reduce WIP, work in progress.

It is easy to understand why people don’t work test first: we (humans) are optimistic. Test first is hard and historically test comes at the end of a process. Because testing is traditionally (almost) the last thing that happens moving testing requires change which is counter intuitive and often perceived as risky. (That risk is very really for when work is sub-contracted: there is an incentive for the supplier to delay testing to make it harder for clients to change suppliers.)

The thing we call “Testing” has several parts. The first, should, involve working out what tests to do: test writing. Later those tests are executed (manually or automatically) against the candidate solution. If the candidate does not pass there is more work to do. While the test execution cannot occur until the is a thing has been created the tests themselves can be decided in advance. This is what I call test first: decide what tests you intent to perform. Thinking about the tests up front is an act of learning and informs the work of creating the solution.

Working test first requires thinking and it requires thinking about something we would rather not happen. Since we are optimistic we see this as waste, or something that should be done by people paid less than us. So it requires discipline to do it. You need to be able to project yourself into the future and ask “What will the result look like?” Thinking test first is often better done with others, e.g. pair programming or “power of three” analysis sessions, so keep each other disciplined.

While it is relatively easy to work test first when programming the skills required to write automated test first require some time to master. This skill still isn’t taught at most schools or colleges so people need to learn it later in their career. Since people are optimistic, they often lack the motivation to learn to write tests first so they never master the skills. Since they are always on the learning curve test first coding takes longer and they often give up before they master it. If they stay the course, if they master the skills then they will find that while coding may still take longer the elapsed time is less because they no longer need to fix things afterwards (“debug later”.)

(As an aside, I’ve long been of the opinion that when we get AI technology to write programs (which is now starting to happen) writing tests will become more important than code. While machines will write more code which executes and doesn’t crash there is still a need to test the code does what is wanted. If we have a good test set then machines can be left to iterate and mutate code until it passes the tests.)

Outside of code the testing skillset is less well defined and people are less accustomed to thinking about tests anyway. Consequently working test first is more difficult. Add to that the fact that there are many more parameters to consider, and people are more forgiving than machines and it become more difficult still.

So, while test first working might be a silver bullet it is not easy to adopt. But then, because it is hard to do it is also hard for your competitors to do which means test first can be the source of competitive advantage.

Next Why is it hard to reduce WIP?

Enjoyed this post? Subscribe for updates and download Continuous Digital for free

Why don’t people Test First? Read More »

Two unspeakable Silver Bullets?

Agile, OKRs / / / , ,

“There are no silver bullets” wrote the late, great, Fred Brooks. Consequently most writers and evangelists avoid claiming they have a silver bullet even when it sounds like they are claiming just that. I’ve cautioned against silver bullets several times in this blog. I often find myself telling clients “The devil is in the detail.” Meaning: there are lots of things to address and no single big fixes.

Anyone claiming to have found a silver bullet deserves to be faced by scepticism. Still…

I find myself coming back to two solutions again and again. They are the closest thing to silver bullets I know. Even if these are not silver bullets in their own right applying either makes it easier to work the detail and tackle problems.

Yet these silver bullets dare not speak their name. To do so risks endless debate and damaging your own leverage.

Keep reading for the Silver Bullets

Writing this I’m avoiding naming the potential silver bullets because I even feel many readers will stop reading the moment I name them. Please, keep reading.

Both are widely discussed by the agile cognoscenti but both are controversial. Suggesting either may lead people to think you fail to comprehend the situation or are just stupid. Thus in both cases you are likely to end up in long discussions.

Both are disliked by opposite ends of the organizational hierarchy. Both ends are optimistic, and prefer to believe people should be able to rectify problems themselves (the people problem problem again.)

Both bullets are rarely applied with vigour. Perhaps because of the previous points. When I raise the points people plea helplessness, “My boss doesn’t understand.”

Both bullets scale: in the small and large, although they manifest themselves in different ways at different scale points.

Neither is an instant fix but both start to deliver returns relatively quickly. The problem with both is you need to keep the faith and keep applying them for weeks to see a difference. In both cases, people often give up before they see the benefit.

Bullet #1: work Test First

Specifically in technical teams applying Test First coding; whether Automated Unit Testing (e.g. TDD, test driven (first) development), Behaviour Driven Development (BDD) or some other form of Acceptance Test Driven Development (ATDD). Away from code, at team and organizational levels OKRs are implement the test first principle.

Test first will not fix all problems but it will remove a substantial number of problems. That makes managing the remaining ones easier. And as to where the “extra time” comes from, that is easy: the time you don’t spend fixing defects and misunderstandings. Test first is faster than debug later.

I’ve written a lot about test first so I won’t say more just now.

Bullet #2: reduce Work in Progress (WIP)

Most commonly WIP limits are applied through limited columns on a Kanban board or limiting the work taken into a sprint. Done right OKRs limit WIP too. However, reducing WIP requires discipline.

At the higher levels companies and Government entities seem quick to reduce staffing numbers but slow to reduce work. Accepting new “projects” is easy but resourcing them difficult. Rather than prioritise, say “No” and push back on work, everything is taken on. Individuals who push back as seen as pessimists, “not team players” and “obstacles.” Pushing back does not help your chance of getting promoted so leadership ranks tend to be populated by those who accept.

The result is salami sliced people and slow progress across a broad front rather than rapid progress across a narrow range. But, reducing WIP also seems to be the hardest medicine to administer. In fact, I sometimes find myself hiding WIP reduction measures.

As an aside, I feel WIP has gotten worse since the pandemic struck, the move to remote working means every conversation is now a meeting in the diary. Our diaries are now overrun with “Meeting WIP”. An ad hoc 10 minute conversation at the coffee machine is now a 30 minute Zoom call planned days in advance.

WIP reduction is applicable at all levels: reduce the number of pieces of work the individual is switching between, reduce the number of pieces of work teams are tackling, reduce the number of projects a department has in flight, and most of all: reduce strategic WIP.

Next time

There are lots of benefits of reducing WIP so let me ask: why is WIP so difficult to reduce? – that is the question I’ll address next time. So too is Why don’t people Test First?

Finally I’ll just note: I sometimes wonder why I stop being an OKR-cynical to learned to like them. The thing is, I see OKRs as a tool to address both these problems: OKRs are test first, and limiting OKRs is WIP limiting.

Two unspeakable Silver Bullets? Read More »

Why OKRs require a strategy rethinking

Agile, Digital business, OKRs, Strategy / / / , , , / 2 Comments

OKRs offer a way to connect strategy – high level abstract goal type things – with delivery – low level concrete detailed task level things. OKRs offer a middle level planning. They are replanned often enough to be flexible while lasting long enough to give enough stability to take on bigger, more ambitious work.

As with so much else about OKRs there is a more agile way of going about this and a less agile way of going about it. Connect strategy to OKRs in the less agile way and you end up back at command and control. The give away sign is that OKRs cascade down the company so teams don’t control their own destiny, ambition is neutered and motivation is lost.

Which approach you take will largely depend on the seemingly academic question: “what is strategy?”

Many people see strategy as a one way street. Strategy making and execution is hierarchal with decisions made at the top are passed down. Alternatively strategy can be seen as emergent property of a cooperating network. Strategy is a two way street, each node both informs strategy making and execution is guided by the resulting strategy.

Depending on how you view strategy you are going to implement OKRs very differently.

Is strategy a kind of planning?

Sad to say, the predominant view of strategy is that it is some sort of grand plan. The plan sets out the “place” the company aims to get to (price, position, etc), plus the route for getting there. Anyone who has studied a little strategy will recognise this as the “Porter view of strategy.”

Strategy as planning inherently sees strategists as master planners, all the relevant information is fed into the strategy/planning department. Experts analyse the data and rationally decide what needs doing. The plans are sent out.

This is inherently hierarchical so it natural to use cascading OKRs as the implementation mechanism. But because teams have little say in setting their OKRs motivation is lost and ambition is neutered.

The is a machine like view of organizations, inherently top-down, deviation from the plan, the strategy, is an error. When OKRs do not directly support strategy OKRs need to be changed.

Study a bit more strategy and you will find that while Porter’s view has appeal it is not the only view. There are in fact many different schools of thought on what strategy is.

Emergent strategy is more agile

To my agile mind the “emergent view of strategy” fits better. Strategy emerges over time from the activities of the organization, part planned, part reactive and part backward looking to explain the past. Professor Henry Mintzberg describes strategy as “a pattern of behaviour over time” which chimes with my pattern thinking.

Strategy is a two way street, teams are edge sensors: detecting technology changes, production techniques, putting products in the hands of customers and gathering feedback. This allows learning and adaption. The organization as a whole is a learning entity: discovering customer need and mastering new capabilities. Teams have the authority to act in the best interests of the company and customers. Over time strategy emerges.

When OKRs do not reflect stated strategy it is a learning opportunity. Ask: why do team OKRs deviate from strategy?

Is the team seeing something which the strategists do not? – in which case the OKRs are signalling back from the edges to the centre.

Is the team able to follow strategy? – maybe it lacks skills or capacity, or maybe it is overloaded with “business as usual.”

Has the intended strategy has been clearly communicated? Or maybe there is no explicit strategy?

Strategy, OKRs and agility

OKRs, like other agile tools, are problem detectors exposing opportunities for improvement.

Perhaps obviously, the “Strategy as a plan” view is going to limit agile to a back-room delivery thing because it passes over the opportunities for feedback and centralises decision making. Conversely, the “Emergent strategy” view entirely compatible with devolved authority, independent teams, experimentation and “the agile mindset”.

When teams act on their own initiative the organization will be more agile. When teams wait for instructions everyone is less agile. There may be a price for agility: teams may repeat work, teams may pursue the “wrong” goals but the price of that efficiency is lost agility which costs in missed opportunities and improvements.

If you want high levels of efficiency and believe in planned strategy you will look to decide strategy and align OKRs with the strategy before you do anything else. However, that results in less agility.

If you want to using OKRs and maximise agility then you need to take an emergent view of strategy. In many ways, we back to the Theory X or Theory Y question.

Download Continuous Digital for free when you subscribe for Allan’s updates

Why OKRs require a strategy rethinking Read More »

New year resolutions & improvement days

Agile, Agile Process / / / , , ,

Happy new year!

Traditionally new year is the time for making new resolutions. We resolve to change our ways, try new things, give up bad habits and make an effort to do things differently, for the better.

So why not try that in your work? Why not try that with your team?

A few years back I organised a “New Years Resolution” session at the company I was working for. Engineers gathered, we suggested ideas, we talked them through and we resolved as a group to do some new things. The fact that everyone was still fresh from a break and had been hearing about, and perhaps deciding on their own, new year resolutions, gave it an extra boost.

Yes, it was a bit like a retrospective and you could set it up as a retrospective on the past year.

Which leads me nicely on to: Agile Improvement Days – maybe I can help you?

Last year I visited Scandinavia several times to run a series of improvement day workshops for a client. The days were based around a series of well tested exercises, group discussion, reflection and action planning. Most of the days focused on teams but one of the days was specifically for product owners and another for business representatives.

These workshops came to mind when I was reviewing the survey I ran a few weeks ago: over 27% of respondents said their agile initiative “needs a reboot”. (Another 27% said it was early days and 33% said they were “in search of great.”) In thinking about how I could help these teams I realised I had a ready made, tried and tested answer: the improvement days!

As much as we talk about kaizen and continuous improvement it doesn’t always happen. Teams need reminding sometimes. I’ve long been a fan of the lesser know kaikaku – also called a “kaizen-blitz”. Even the best teams can benefit from trying something different. In fact, the best teams probably need something different simply because they have tried everything else.

So, I’m now offering my Agile Improvement Days workshops in their own right. You can have a single one off day, a package of days for multiple teams, different days over several weeks or have the days customised to your own need.

Feel like rebooting your team? Help your team move from good to great? Or deal with a specific issue? Have a look and let me know what you think,

And please, forward this on to anyone who you think might benefit from such days.

New year resolutions & improvement days Read More »

What we can learn from Wildebeest about being agile

Agile / / / , , , ,

“Your only as young as the last time you changed your mind”

Timothy Leary

As the end of the year approaches I’m about to write-off all the blog entries I never wrote this year, all the ideas, notes and in a few cases complete entries which never made it to publication. As I described last year only a few blog ideas will be carried from 2022 to 2023. I’ll wipe the slate clean.

But as it happens this is a perfect example of something I’ve observed a lot of this year: how the past stops us form being agile. The baggage we carry from the past stops us from changing.

Think about it, if you want to be agile – in the original sense of the word, what do you need?

Fitness and more

Right off you need a certain fitness, you – human beings – need the ability to flexible your muscles, to move and to react. If your muscles are stiff and inflexible you can’t reacting. The same is true of teams and organizations need level of fitness in order to react. You need both the habits of reacting and the skills to react with.

But fitness isn’t enough, you also need to be aware of your environment: capable of detecting changes to start with, deciding to act and putting that decision into action. In an animal that means senses (sight, hearing, touch, smell and taste) and a nervous system. An organization requires similar senses to watch competitors, technology changes, customer tastes and so on.

Organizations also requires a nervous system to communicate input from senses, translate it into action and communicate the action out. Unfortunately many fail, one department sees a new competitor but fails to communicate, and when it does people won’t listen, action falls down as people cling to the past ands existing plans.

The organization as an individual animal analogy breaks down because organizations have many decision makers – everyone decided for themselves how to react to new information and instructions. We might be better off thinking of a herd.

Recently I watched a wildlife programme were a herd of Wildebeest were attacked by lions. The herd needs collective agility, each member needs to be agile but they need to be able to act together and act cohesively with group agility.

Thats were things like agile practices and processes come in, team work too, and, yes, practice (training and rehearsals) so everyone knows how the herd will react. But agility isn’t just about out abilities and fitness. There are things that hold even the best teams back, and for lesser teams they make agility impossible.

Our teams and organizations are immobilised by the past: by the baggage we carry around.

Technical teams blame technical debt – a metaphor I dislike – but that is not the only form of debt.

As individuals we carry the debt of past experience: we remember when we were hurt, we remember when we took what we were told at face value (“This team is committed to high quality work”) and then criticised for the same thing (“I keep telling you, we don’t need perfect, only good enough”).

Organizations too are held back by organizational debt: sometimes actual monetary debt which incurs interest, or lender covenants which constrain action. Sometimes the debt is manifests as lack of trust – either between employees and employers, or companies and customers.

At a very basic level team backlogs are an example of the debt that prevents us being agile: the need to do backlog prevents teams from reacting – or if they do react, then not doing the backlog damages the trust they need.

And backlogs are just one, quite weak, form of promise that holds us back. Roadmaps and legal contracts are stronger. But breaking our promises reduces the trust we need. I didn’t say this was easy.

Then there is the problem of purpose: animals and herds exist to live, they aim to preserve life. Even though they may not admit it many companies are just the same, they aim to last as long as possible – even when they say “Increase earnings per share”. Then there are the many start-ups aim to sell out. Put that all together and the herd lacks common purpose, when attacked by a lion should you run or negotiate a higher price?

So why aren’t you more agile?

Are you fit enough? Are you exercising enough?
Is your team exercising together, training and rehearsing together so you can react effectively?
Are you carrying too many burdens? Technical debt? Excessive backlog? Too many promises?
Is your nervous system able to react? Or do you need to obtain too many agreements, sign-offs and authorisations before you can do anything?
Are you trusted to do the right thing? To react first and explain later?
And do you all share the ultimate goal?

Learning to be agile is the easy bit, I can teach you sprints, stand-ups, planning and stories in day. The difficult bit is unlearning: removing all the impediments, sorting out the debts, abandoning the old processes and learning to live in the now.

If agility is your future then don’t be scared of abandoning the past. In the words of John Cage: “I can’t understand why people are frightened of new ideas. I’m frightened of the old ones.”

You can’t be agile if you are carrying a lot of baggage. Which is why next month I’ll write-off most of my unfinished blog posts.

Wildbeest image by Jasmine Nears, Creative Commons license (Wikicommons)

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

What we can learn from Wildebeest about being agile Read More »

My customer wants a roadmap with dates

Agile / / / ,

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

My customer wants a roadmap with dates Read More »

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

Agile Process, Digital business / /

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?

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.

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