Allan Kelly's Blog, page 9

When is work done?

Ever seen a Kanban board with 26 columns, or was is 22? I can’t remember. Half of them were queues anyway. (And here is a video of the full board.) How does a board get so big? Well…

After two blogs on flow and board design (It’s the workflow, stupid; When workflow isn’t column, column, column) I received a question on LinkedIn. It might not at first look like a question about workflow and board design but once you read the answer you will see how it is:

“I am writing our company’s “release process”. It is triggering quite a few confused debates internally. Some people think that the release process starts with the definition of release goals/KPIs, moves onto ideation, prioritisation, all the way to getting feedback after customer deployment. Others think it starts with a “release candidate of the product is available and finishes when the final release is given to customers.  I was wondering your thoughts on the topic. Between the two “extremes”, where would you draw the lines?”

I recognise this issue and in a way both sides are right. Although such questions normally appears in the context of writing a “definition of done” or a “definition of ready” it is really question of “where does work begin?” and “where does work end?” As such it is a workflow question and this a question of “where does our board start tracking work and where does it end?”

To put it another way, the question is: where do you place the boundaries?

Wherever you put the boundaries, someone can say “but you need to look at the bigger picture.” There is always something before the first step and something after the last step. On a Kanban board you can always add a column to the left and one to the right.

If the left most, work intake column, is “To do” then it is probably a sprint backlog and therefore there could be a column left of it marked “Product Backlog.” And since backlogs are driven by company strategy and product goals there could be a column before that. And goals are set reference to things like the market and company purpose and so there might be a column before that. You see, the workflow expands to the left?

Similarly, most teams consider “Done” to be the right most column, the final step in workflow. But really when they say done they mean “Code and test complete” so there should be a release step after that. And just because it is released doesn’t mean customers are using it so we could have “In use”. And then we should evaluate the usage, see if it meets the need and delivers the expected benefits so there is another column. But then, what if it doesn’t meet the need? Or what if it is so good it opens up new ideas? Before you know it you have a circular pattern.

(Maybe you see why some teams talk about Done and Done-Done, and even Done-Done-Done, and who knows …

Now this may start to sound like a philosophical problem – how many user stories can you fit on the head of a needle? – and it sort of is. What is done for your team?

Ultimately you need to put boundaries somewhere so the question is less “where should we start and end our process?” and more “what does the organization expect of the team?” Or you might prefer to think of it as “what do customers expect?”

You might also ask the team “Where does our work begin?” The answer to this question is going to depend both on the skills on your team and what team members think they should be doing. And that in turn will depend on the culture of the organization – are you a tailor or an image consultant?

So draw the line. Set your boundaries, codify them in release procedures and your board design. Then revisit those decisions in a few months time. Once teams are seen to perform well inside their “box” they get more leverage to expand the box and ask questions which expand the box. Which is all another reason why To do, In Progress and Done might not be the right board layout.

The post When is work done? first appeared on Allan Kelly.

The post When is work done? appeared first on Allan Kelly.

Ask Allan Anything – 3 May, free

I’m running my first Ask Allan Anything session on May 3 at 3pm London, BST, time – which should be 4pm for most of Europe and 10am for the East Coast. This is a free event, no charge.

Whether you want to ask about Agile – user stories, story points, estimation, stand-up meetings, retrospectives; or OKRs – good bad and the ugly, discuss Objective Driven Agile and blowing up the backlog; how to write a book, how to think about your organization, your business strategy or products, or… well… anything! – please join us.

I’ll run it LeanCoffee style with the wonderful LeanCofeeTable.

All free but ticket numbers are limited and registration is required. The booking form is below or head over to EventBrite and book now.

Blog readers and newsletter subscribers get the first chance, if there are any left then I’ll open this up to other people.

Register on Eventbrite

The post Ask Allan Anything – 3 May, free first appeared on Allan Kelly.

The post Ask Allan Anything – 3 May, free appeared first on Allan Kelly.

When workflow isn’t column, column, column

What do you make of the board above? Chaotic? Crazy? – and how would you model it online?

I’m not recommending the board above. It has a number of interesting, possibly unique, features we can learn from but I’m not dissecting it today. What I do want to do is point out: work doesn’t always happen in neat little well defined columns.

Summary
⁃ Visualising work is an important step to improving workflow
⁃ But workflow can be complex and most online tools can’t handle complex layouts
⁃ That is fine for big-upfront-change Scrum
⁃ But not for Kanban (and Xanpan) when you “start with where you are” and improve incrementally
⁃ I’m delighted to have found KanbanZone

While you might want work to flow rationally, in neat stages, columns, that is often the endpoint not the starting point. The To do, In Progress and Done “triple column” layout might be the default board layout for teams, and it might be you preferred layout. It might even be a starting point or an end-point. But none of that means it is the right layout for your team now.

The team with this board tried several other designs but they didn’t work for them. Eventually they came up with this, it worked for them and it hung around for a while. I always thought it was over complicated but it worked for them.

As an advisor, be it a coach or mentor, I often need to decide whether a team should undertake lots of change up front. Or, whether it is better to “drip feed” change in. Minimal change to start with but a longer tail of change.

Sometimes ramming change through at the start can be the right thing: when team and leaders are up for change and they want to see rapid results. Jumping straight to a triple column design and embracing Scrum cab be the right thing to do.

But this approach can fall down for several reason. Perhaps the team are not keen on change. Or perhaps there are multiple sources of work – a lot of BAU and random “unplanned but urgent” work. Perhaps when there are multiple products and projects in play, perhaps with multiple product owners. Or perhaps, because you can’t see what the end state risk is high.

The alternative is to model what we have now, change it as little as possible to make the model work and then watch it in action. The board mirrors the workflow. This is why I say “A board is a team’s lightsaber, every team has to build their own.”

Over time the design is tweaked and changing the board design now changes the workflow. The two mirror each other. The board has become a voodoo doll, or perhaps I should say “digital double”. To start with the board visualises the workflow but in time the workflow implements the board. They are the same thing.

I’m describing the Kanban principle: “Start with what you are doing now.” Rightly or wrongly I think of this as “Start with where you are” – I’m told this is very Buddhist!

This contrasts with the Scrum approach, “Scrum exists only in its entirety” says the Scrum Guide which leads to a change model of “Do Scrum, change everything!”

We are back to the Kanban paradox: Kanban is easy to start but to make it work, and to keep improving, after the initial start you need more expert help. Scrum in contrast front loads the change so all the help is needed at the start and later on there is less change and less expert help needed. But Scrum can also mean change stalls.

The Kanban incremental change model isn’t risk free. Without early wins it is harder to build trust. When leaders see a lot of change happening they are more willing to accept the argument that the changes are bedding and there will be more jam tomorrow. Without early wins or big changes they wonder what is happening.

Both approaches can suffer from the “I’m feeling better” problem. Teams see results and loose the energy to change while leaders see results and stop paying for the consultant.

Even before Covid companies and teams wanted to use electronic tracking tools. Back then I always suggested teams start physically and only go electronic with some experience. With remote working in the post lockdown world this is just about impossible.

Now we have a problem: Almost every tool I’ve ever seen works the same, in columns.

If you want to “start with what you are doing now”, if you want to model the current workflow then quite possibly you can’t. Which means you either create an inaccurate model, force workflow changes right at the start (make work fit the model), or maybe create an even more complex and subtle model which is mentally taxing and requires you to think a lot about what you are seeing. A good board speaks without the need to thinking too much.

Put it simply: there is an art to board design and most tools limit your thinking.

If I had written this blog six months ago I would have said “All tools” but I have found one which is different: KanbanZone.

Before Christmas I was struggling to model one clients work with others tools. Then I found KanbanZone that changed. I now have a tools which allows me to model complex board layouts and which teams which love it. Once teams can visualise the work they can reason about it and rethink about their processes.

Now forgive me. This is a KanbanZone partner link. You get a 60-day free trial and I make a little money if you buy it later. But money is not the reason I’m recommending it, I’m recommending it because I think this tool is different to the others I’ve seen.

The post When workflow isn’t column, column, column first appeared on Allan Kelly.

The post When workflow isn’t column, column, column appeared first on Allan Kelly.

It’s the workflow, stupid

Sausages making illustrates workflow brilliantly! – For years I used this picture of sausages makers to describe the way teams work: meat goes in, sausages come out.

If you put pork in you get pork sausages out

If you put chicken in you get chicken sausages out

If you put beef in you get… in the aftermath of the 2013 horse meat scandal I used to joke “You out horse meat in you get beef sausages out.”

What comes out bears a strong relationship to what goes in.

If you put project A meat in in you get project A sausages out

If you put project B meat in in you get project B sausages out

Sure it works best if you have a dedicated team and you only put project A requests in. When A is finished the team switches and focuses exclusively on project B. But you know what it? It still kind of works if you mix as you go along.

When a team works on multiple different projects in parallel it is not so productive – reduced focus costs, switching between things costs too. It will be a damn site harder to make forecasts about what will be done when, answering the “when will it be done” question will be tougher. But it still works, you can still make forecasts just they will be even less reliable.

By extension, if you put business as usual meat in you get business as usual sausages out. If you put DevOps meat in you get DevOps sausages out. If you put company admin in you get company admin sausages out. Get the picture?

While it is great advice to “focus on just the project/product” the vast majority of teams I’ve ever worked with are not in a position to do that. Turning work down is above their pay grade.

Seeing the whole

In Xanpan I called this “Team centric”. The project you are doing is less relevant than the workflow you are operating. Xanpan explicitly discusses how to integrate “urgent but unplanned work” with planned “project” work, I’ve extended the thinking with OKR Zero.

When things go wrong teams become like a saturated sponge. People can’t see the correlation between what goes in and what comes out. Trust is reduced, more reporting and even policing is added. The workflow becomes more complicated, less predictable and more costly.

It is no use looking at the project. Each project is only part of the picture. Neither will looking at the BAU, DevOps or urgent but unplanned work help either. They are only pieces.

You need to look at the whole: the workflow, the sausage machine that makes the sausages.

It is of little use looking at the pork sausage project and asking how many pork sausages will come out next week if the team is also doing BAU and making some chicken sausages on the side.

Nor is it any use talking about the pork sausage project if every time the team turn the handle they have to stop. Check with accounts, check with the security team and check customers – all of whom have their own workflow. Customers who just want the team to “get on and deliver it.” Every time a team needs to interact, get permission, get feedback or anything else with another team, things slow down and grind to a halt. Other teams are most likely struggling with similar things so they all block one another.

Often when this happens, because people have the best intentions, and because they want to be productive, they start doing something else. Pork sausage production stops while they wait feedback on sausage sales. So they start producing chicken sausages. Then just as chicken sausages start coming out the pork feedback comes in and everything must switch back. But now the chicken meat is unwrapped and getting warm. By the time they get back chicken sausages it has gone off.

It’s the workflow, stupid. Let me suggest again: watch Stockless Production.

No one person

Everyone, and every team, is linked together in workflow so it is difficult for one alone to make a difference. Working harder, producing more often makes things worse not better. Individually people are pretty helpless.

Such workflow streams are full of work-in-progress, WIP, they are overloaded. This is really “work hopefully in progress” (WHIP). It is bad when one team is overloaded but when it is excess strategic wip the whole organization struggles. It is difficult to know where to begin fixing thing. You still have to start fixing it at the team level but until multiple teams start fixing there is not much improvement to show.

No one person can fix this. No single technology can change it. Maybe not even a single team. Everyone is connected. Only by looking at the whole can things be fixed.

Unfortunately this is where project warriors come along. They insist that everything is a project – which increases administration. One or two projects get expedited and are forced through but everything else deteriorates.

Saddest there are know solutions: work to completion, reduce workpiece size, operate a pull system not a push, work within capacity, allow for shit to happen (unplanned but urgent work) and don’t overload the team – in fact don’t load them more the 76%.

That is workflow management. The devil is in the detail, there are no big easy solutions – if there were they would have been applied already. Workflow management cuts across projects. Managers have a role to play here but not project managers. Project management is too narrow.

It’s the the workflow, stupid.

So finally, an advert: I’d love to help, call me, e-mail me, LinkedIn, WhatsApp, whatever medium you like, just ask.

The post It’s the workflow, stupid first appeared on Allan Kelly.

The post It’s the workflow, stupid appeared first on Allan Kelly.

How can we set an OKR if we don’t know the baseline?

The baseline problem

It came up again today, actually, once you delve into OKR setting:

“When writing OKRs, and specifically the key results, how can we set a target if we don’t know the baseline?

For example, suppose we want to increase the number of site visitors, if we have 1,000 visitors a day then the target would be 5,000 but if we only have 200 a day then the target would be 1,000. But if we don’t know how many we have to start with, how can we set a target?”

I call it the baseline problem. I know it troubles many teams but it shouldn’t. There are actually, two, or possibly three answers.

The easy answer, and one I don’t like, is to sidestep the problem: instead of saying “increase views from 1,000 to 5,000” say “increase views 500%”, or, to take another example, “reduce run time from six hours to one hour” say “reduce runtime to one sixth.”

Replacing initial and final numbers with a multiplier doesn’t solve the whole problem because you need to start by finding out where you are before you change anything. So task 1 becomes: measure status quo, whether that is eyeballs, run-time or whatever.

Another way around this problem is that you could change your OKR after setting. The initial OKR could say “increase views from to .” Again task #1 is to measure and at that point you simply revisit the OKR and fill in the blanks.

Granted some people might take exception to you tweaking an OKR after the start of the cycle but personally I don’t see that as a big issue.

Baselines solve the wrong problem

Now sidestepping the problem like this might keep you moving but it is not very satisfying. That is because: it is solving the wrong problem. The real problem is not that you don’t know the baseline but that you don’t know what the number should be. When you set the target by starting with the baseline you are putting technology first and you are limiting your ambitions.

The question is not “How many visitors do we have now?” and “What target might be achieve?” but “What visitor numbers do we need to have?” Or maybe “What visitor number do we need to make us number #1in our market?” or “What numbers do we need to break even? get investment? impress clients?”

Or take the run-time example, don’t ask “How fast are we?” and “How fast can we be?”. Instead ask “How fast do we need to be?” If you don’t know the answer then ask “Why do we want to be fast?”. Or ask, “What advantage will being twice as fast bring us?”

Rather than start with the target in mind start with the outcome in mind, then ask what you need to achieve that.

If you set the target by reference to the current baseline you are going to limit ambitions and let the current technology drive. Instead think about the outcome and what that outcome looks like, then work back to understand what needs to be done and options for doing it.

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

The post How can we set an OKR if we don’t know the baseline? first appeared on Allan Kelly.

The post How can we set an OKR if we don’t know the baseline? appeared first on Allan Kelly.

Books to be Written – yippee!

I’m delighted to announce Books to be Written, my book about writing books, my guide to writing, producing, publishing and marketing you own masterpieces – if finished! Is published! Is for sale on Amazon – both print and e-book version.

This is available at a special introductory price of 2.99, thats $2.99, €2.99 or £2.99 – the offer will end next Friday, 24 March so get it now.

The post Books to be Written – yippee! first appeared on Allan Kelly.

The post Books to be Written – yippee! appeared first on Allan Kelly.

Books to be Written – done and published

I’m delighted to say Books to be Written is done. Print and eBook versions are now available on Amazon. A special introductory price of $2.99 / €2.99 / £2.99 applies for the first few day so buy it today.

And here is a short video explaining why I wrote Books to be Written and what to expect from the book.

The post Books to be Written – done and published first appeared on Allan Kelly.

The post Books to be Written – done and published appeared first on Allan Kelly.

How many OKRs should a team have?

“How many OKRs should a team have?”

“Can a bigger team have more OKRs?”

These are among the most frequent questions asked about OKRs and I will answer both here.

First question, how many? 3. My answer, my rule of thumb: three.

Better still: one, 1. Fewer is better than more

But people seem to want more, so if you twist my arm, inflict pain and I will give in, I will admit I lied and say four, yes 4.

You should be able to count the number of OKRs on the fingers one hand. 18 is too many, 10 is too many, even six is pushing it.

One OKR is probably “OKR Zero”: the business as usual OKR which highlights the revenue protection and support work a team does. “DevOps” in modern software parlance. (See Succeeding with OKRs in Agile for the full description of that.)

Another OKR might be nominated by the team themselves to improve work effectiveness and efficiency. For a software team this might be something like retooling the delivery pipeline or addressing “technical debt.” For a customer service team it might mean adopting a new improved ticketing system or undertaking more training to increase team capabilities. (Again Succeeding with OKRs in Agile discusses this.)

Which leave two OKRs, or perhaps just one, for the main business need usually nominated by the product owner type person. Not a lot. One might be the primary, high profile, most effort, objective. While the second is, well, secondary.

Put like that it doesn’t sound a lot. OKRs, unlike user stories, are big and meaningful. They create outcomes which deliver benefit.

The logic here is that it is better to achieve one thing completely than several things partially. The aim should be for “short and fat” working over “long and thin.” The sooner something is completed the sooner it can generate benefit. The sooner it can generate benefit the sooner it can pay back the time invested and the greater the return on investment.

Prioritise

One of the key benefits of prioritizing OKRs is that “things can fall off the end.” Suppose a team has the four OKRs just suggested:

0. Business as usual

1. Primary thing

2. Secondary thing

3. Team improvement

Now suppose that they are forced to take on four more:

4. Something else

5. Another thing

6. Sally’s thing

7. One more thing

When prioritisation is disputed and all are considered equal, then there may well be some progress across all eight but none are completed. If they are prioritised as above then: business as usual is covered so the team don’t slide backwards. The primary objective stands a better chance of success than anything else. In fact, the further ones goes down the list the less likely it is to be achieved. (Sorry teams.)

Remember: the aim of OKRs is to create beneficial outcomes. Simply starting more work, creating more work in progress does not contribute to this goal. In fact, those familiar with Little’s Law know that more work-in-progress has the opposite effect. So adopt the Kanban mantra: Stop starting, start finishing.

When OKRs are prioritised in ascending order, with no duplicates, then above some point it is pointless to add more. Adding more only increases the amount of time needed to set OKRs and the disappointment when they are not achieved.

Even so, adding a tenth or eleventh OKRs to a team which can only really achieve four might be the path of least resistance. However, there is something slightly dishonest about it, more importantly, it misses the opportunity to have a strategic conversation.

Can a bigger team have more OKRs?

No.

Remember the goal of OKRs is to create focus. When a team is bigger, say 16 instead of six people, it is more difficult to achieve focus. Therefore, bigger teams benefit more from fewer OKRs.

Focus is not divisible: an individual can focus on one thing. Maybe two, maybe drop everything for an emergency. But they cannot focus on 10, or even five. More work to do simply increases cognitive load and makes it more difficult to do anything.

If a team is regularly called upon to do 10 different things the solution is not to set more OKRs. The solution is something else.

This rule also applies if you lengthen the OKR cycle. If you set 3 OKRs for a 10 week cycle you will also set 3 for a 15 week cycle. Often, having more time make it more difficult to focus. How often have you missed an appointment because you had plenty of time? Yet when you have just enough you don’t let anything get in the way.

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

The post How many OKRs should a team have? first appeared on Allan Kelly.

The post How many OKRs should a team have? appeared first on Allan Kelly.

Digital transformation stuggles

“Any advice on how to bridge [the IT/Business] gap? Are there any rules/guidance on how a technology dept should be defining/presenting products to business functions in this context? Also, guidance on the relationship between projects/products in this context?”

I’ve received these questions from a reader who finds themselves inside a company undergoing a digital transformation. Actually, they describe the situation in more detail and there are questions about the differences between products and projects, the role of BAs and how to organise the whole place.

Let’s start with Projects v. Product

Projects have end dates – or, at least, are expected to end. Projects are usually a batch of defined work which is expected to bring about a defined outcome. Projects may run past their expected ends, may expand in scope and may fail to deliver the intended benefit but while managed as a “thing that will end” they remain a project.

Products are ongoing, in a commercial environment products continue to deliver revenue and continue to require work.

In the pre-digital age a project might developer a new product, the project ends and the thing is passed to manufacturing, or service agents, for delivery. In the digital world this doesn’t happen. Products require continued attention. This may be to keep them competitive – add capabilities competitors have; or to keep them operational, e.g. update libraries which have security flaws.

With digital products it is hard to define when new development gives way to “manufacturing”. Techniques like Lean Start-up, Minimally Viable Product and Product Discovery exploit this ambiguity to leverage learning and in-market learning. Before digital this “expeditionary marketing” technique was expensive.

There is a difference in funding too. Projects are typically funded in their own right (how much work is involved? what will that cost?). Conversely the teams which support product teams should be funded in their own right and trusted to do what delivers benefits. Product teams should be able to demonstrate at the end of the funding period that they have delivered more benefit than they cost.

Inside corporations IT Departments used to delivery projects which aimed to improve business effectiveness or support a non-digital product. In the digital corporation the business is the technology and the technology is the business, it no longer makes sense to separate technology departments from the business. The need for rapid feedback loops between “the business” and “the technologists” means that they are one team. Anything that gets in-between slows down the processes and hinders communication, and thereby damages competitiveness.

This means that digital product teams are responsible for sourcing and deciding their own work. Whereas before the business would decided it wanted to do an IT project and the IT department would be expected to deliver it now, the digital product team would spot the need or opportunity to change the product and decide to take action. They reason what using their resources to enhance the product will deliver more benefit than it costs.

The digital product teams will contain both the “supply” skills to do the digital work (e.g. programmers, testers, UXDs, etc.) and the “demand” skills to understand customers, monitor market changes and determine responses (e.g. product management and business analysis). The exact mix of inward facing BA skills and outward facing product management skills will vary depending on the product and market. Deciding what to do is product ownership, and the person task with making the “what shall we do next” decision is a “ProductOwner”. They may be supported in that role by additional BAs and/or Product Managers.

But all this doesn’t mean that projects cease to exist. Not everything is a digital product – the company may want to move offices and the move itself could be a project.

There may even be projects which impact digital products. For example, the company the new office needs a new phone system and decides to avoid the cost of laying cable by using a virtual VOIP system. This requires software on desktops plus audio equipment. It may also mean the products running on those desktops need to be interfaced to the new telephone system and the interfaces to the old PABX retired.

A office move project like the may well use Business Analysts to investigate what is needed to make the move and resulting changes. Meanwhile, the digital product teams, who may not even know an office move is planned, are unlikely to see the telephony changes early. So at some point the office move BA will need to work with, and inject work into, the product teams.

Because projects come and go, it may be that some BAs rotate between projects while other BAs are embedded in product teams. However, because digital companies will have more products and fewer projects it is likely fewer floating BAs will be needed while more remain with their teams. And because products have an outward facing, customer, dimension, many of those BAs will want to acquire some product management skills.

The product teams will probably have a stream of product development work they want to pursue to make their product even better. They will also have “business as usual” work to keep the product operational. Add to that the work arising from the projects that demand attention and you have a lot of work to do. Rather than privilege any one stream of work its it better to think of it all as “work to do”, work may come from different sources but it all gets done by the same team.

Where one team has to support multiple products things get more complicated. One product owner might be able to cope with them all it also means there might be several each with a different product focus. In these cases they either need to agree between themselves how capacity is allocated or, more likely, someone needs the authority to make those calls.

Ultimately the “IT department” and floating BAs may well go away because there are business lines, which are digital and are serviced by business focused teams containing all the necessary skills.

It doesn’t make sense for digital products to be run out of the IT department because digital products are more than just information technology, they are the business. You could say that the whole business needs to move into the IT department but really we want the IT department dissolved. Rather than structure a company as manufacturing, IT department, a marketing department, services etc. what we want to see is “Amoeba” teams which contain enough technical skills, enough marketing skills, enough delivery skills and so on.

That change isn’t going to happen overnight so while we are waiting to dissolve those different functional units companies can establish product teams where people from different functions work together. The programmers might still report to “IT” and the marketeers report to Marketing but success is judged at a team and product level.

In many ways what I’ve written here is a summary of the model I put forward in Continuous Digital: in a digital world the work is continuous, the product is the technology and companies need to restructure themselves accordingly.

The post Digital transformation stuggles first appeared on Allan Kelly.

The post Digital transformation stuggles appeared first on Allan Kelly.

Lets talk about money: the ultimate feedback loop

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.

Final few days to book Writing OKRs mini-workshops: 27 February, online, use code Blog20 for 20% discount

Book Writing OKRs mini- workshops

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

The post Lets talk about money: the ultimate feedback loop first appeared on Allan Kelly.

The post Lets talk about money: the ultimate feedback loop appeared first on Allan Kelly.