Digital business

Digital Business

Why OKRs require a strategy rethinking

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 »

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?

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 »

Pandemic in the digital age

plastic-syringe-and-test-tubes-2020-04-14-10-10.jpg

It was hoping to keep this blog virus free. Indeed my “Conflicts in coaching” was going to be the first of several on agile coaching (what else could I do in the air going to and from Agile on the Beach New Zealand?) But…. the world has changed, I’ve changed…

It is a very scary time. Both health wise and economically: I know at least one software engineer who has lost his job as a result of the slow down. But I also know random (inappropriate) coding jobs still appear in my mailbox, I continue to see job adverts on Twitter and LinkedIn and I know one company that has landed work and had to hired contractors to work on a corvid-19 project. So some observations…

Observation 1: Covid-19 will go down in history as the first digital health crisis.

Digital technology has a big role in fighting the virus. Decisions and actions are being driven by software models of what could happen. The famous Imperial model is now OpenSource and Microsoft engineers are reported working to improve the model. (At a few hundred lines of R code there isn’t that much to refactor – although there are some very long functions and I can’t see any unit tests.)

Apps are being created to track contacts and you can bet that the search for antidotes and vaccines is utterly dependent on software. Digital powered home delivery networks and internet shopping have made closing the economy just about possible.

Those who are not directly fighting the virus are continuing to work because of digital technology. Zoom, Skype, and the like might be the most obvious beneficiaries of the virus but many others will benefit too. Although the virus is simultaneously putting a strain on our digital infrastructure and necessitating human action – witness the search for Cobol programmers in the US.

Not only have most IT, sorry digital, workers decamped to home but so too have many others – in fact almost any occupation that can. Schools are delivering lessons and distributing home learning kits online. Industries which can’t move to online working will suffer the most. (Except those which put themselves in harms way like medical staff and, to a lesser degree, delivery staff.)

And when not working online media like Netflix, YouTube and BBC iPlayer keep us sane.

For us digital folk this is no big deal. It is an extension of normal life: we are at home 5 days a week not one. But for other folk, this is big. Even the most digitally inept lawyer is having to get with the technology. As people are forced to become familiar with digital technology …

Observation 2: Digital technology adoption will be accelerated by the virus

Which means, while some technology companies (like my friend’s) will not survive, those that do are set for a boom. Post virus swaths of the economy will be destroyed but technology is in for a boom.

That boom is driven by the three forces above: 1) unlike others, our industry is not destroyed, 2) technologist continue to work remotely, and 3) non-technologist will learn to use more technology.

In particular digital healthcare – both back-office big data background analysis and customer centred applications – will play an oversized part. This field was already growing rapidly but the experience gained during this crisis can only help the sector.

But also…

Observation 3: The economic devastation caused by the virus will open up many new opportunities for digital companies to enter markets and thrive

Companies which fail create opportunities for new companies – either a like-for-like replacement or a new type of company. Previously, while those companies were active, digital technology had to compete with the existing providers, the incumbents. With those companies gone the way is clear for new digital technology companies to enter the market.

I’m not saying this isn’t going to be horrible; company failures will be painful and it new entrants will take time to get established.

And what of Agile?

Observation 4: Covid-19 is the ultimate test of agility

Forget arguments about what is agile and what is not agile. Forget ScrumBut, Wagile and the other insults hurled at those judged to be less agile than thou.

Forget agile assessments and agile maturity frameworks; forget ticking off ceremonies and declaring yourself agile. In the new world the more agile you are the greater your chances of survival.

On paper you may have the most agile team in the world but, if that team, and your organization, cannot now demonstrate how it changes rapidly it just isn’t agile.

Every single plan that existed before March 1st is now invalid. Right now companies need to pivot like never before. Agility helps companies pivot. Those who can’t pivot, or can’t pivot fast enough stand to loose the most. If you can’t pivot you aren’t agile, QED.

Companies which still operate in hierarchal command-and-control mode will find it more difficult to switch to distributed teams and remote working. When everyone is remote you need to delegate decision making. Companies which don’t trust employees, companies which constantly check what employees are doing will find home working incredibly difficult and expensive.

Individuals and interactions are more important than ever before. Processes and tools are essential but few heavy weight processes will survive the instant shift to completely distributed working. Any tool which doesn’t help now is an impediment.

Those companies which are still struggling with technical liabilities (aka technical debt) will find the cost of living with those liabilities just increased.

Observation 5: Test driven medicine

Day after day I read in the papers that the UK is not doing enough testing. It seems that countries like South Korea which do a lot of tests and base their strategy on knowing who is infected (and therefore who is safe) and then tracing the virus are doing best.

That means testing needs to be rapid – a short feedback loop.

And testing needs to be cheap so it can be done at scale.

Doesn’t that sound familiar?

The cost of not testing is precautionary isolation. That cost is not sustainable.

If you could test anyone, and everyone, instantly the offices, shops and schools could reopen: you would just test everyone who arrives.

The testing strategy agile has been advocating is now needed to fix the world. And in the UK the Government seems to be as resistant to a test first approach as the most obstinate software manager or engineer.

As much as I hope the world will shortly return to how it was it will not. It will never be the same, we don’t quite know how it will be but it is already clear that digital technology and agility will be part of it.

(Test tube image taken from PublicDomainPctures.net)


Subscribe to my blog newsletter and download Project Myopia for Free

Pandemic in the digital age Read More »

How should we organize our teams?

StartingPoint-2018-09-18-12-23.jpg

Q1: How should we organize our teams?
My team is owner of different trading platforms and the core services around it. But we depend heavily on other products (e.g. financial feeds, client identification, services to send orders to stock markets, etc.). And of course each of the team managing these services have other platforms that are their clients.

When Vasco Duarte and I ran the #NoEstimates/#NoProjects workshop (or #NoNoWorkshop as I think of it) in Switzerland last month the attendees asked some good questions. With Project Myopia done and published, and Continuous Digital almost done it seems like a good time to repeat, and elaborate, the answers publicly. This will take a few blog posts to work through.

(I now have several Continuous Digital workshops and briefings available, please let me know what you think. Vasco and I are looking at repeating the workshop in London later this year, please get in touch if you are interested.)

The picture above is the way I see the question, if you have another interpretation, or another scenario please let me know.

The Continuous Digital model is for stable, long standing, autonomous, value seeking teams staffed with all the skills they need. Much of my thinking derives from Amoeba Management. Importantly each team needs to see how it adds value. In this case the business facing teams can see this – they enable the business do make money. But the back office teams find it hard see how they add value.

Now there are several possible answers to this question most of which involve some sort of re-organizations.

Option 1: Share the value

This solution does not involve reorganisation and comes straight from the pages of Amoeba management: allocate some portion of the value earned by the business facing teams to the teams they depend on. For example, the Trading platforms team might generate $10m each year. It could not do this without the services of the other three teams. Therefore some portion of Trading team’s earned value is passed to those teams.

Think about it, Trading Platforms affectively buys the services of three other teams. If those teams did not exist Trading Platforms would need to do that work themselves. Therefore those teams are contributing and deserve some credit.

This requires a serious conversation and probably needs more senior managers to intervene. Indeed, in Amoeba Management, Kazuo Inamori says that such decisions were among the most difficult ones facing Kyocera and often required more senior managers to make the final decision.

Nor is it always clear who buys from who, does a Sales Amoeba earn the value and pass part of it to the manufacturing team who build the product. Or does the Manufacturing Amoeba hire the Sales Amoeba to get their product to customers and therefore book the revenue and pass some to sales?

In the case above one might find it better to consider the value of the whole trading team including both the traders and the programmers who make the platform. Or perhaps the traders rent the platform from the technologists.

According to Inamori Kyocera standing allocations are set between teams. Alternatively one might create an internal market in which teams bought services from others on a piecemeal basis. On the one hand I like that idea model because it would allow for negotiation and trade-offs. On the other hand I imagine it creating a whole new set of bureaucracy, politics and internal sales. On balance, I’d fix the allocations and review periodically.

Option 2: Vertical slice

If you look at the picture above you might replace the word “team” with “library” or “services” and you would have a module dependency chart. Conway’s Law is at work – the organization and system reflect each other. (Although without knowing the history here it is difficult to say whether this was Conway’s Law or Reverse Conway’s Law at work.)

The services can stay as they are but we just disband the back-office teams and pass their responsibilities to the (enlarged) business teams.

Vertical-2018-09-18-12-23.jpg

The three teams will need to co-operate and co-ordinate with each other as they now have shared responsibilities. This itself can be a problem – two developers changing the same code anyone? But the world has moved on. Technology has improved.

In the days of SCCS, Visual Source-Unsafe, manual testing and monthly deployments it was a pain to have two teams working on the same code. But distributed source code control, automated testing and continuous delivery make this option far more viable than it once was.

On the plus side each team can work at their own pace on their own priorities and knowledge is spread around. On the downside teams can still trip up each other, they may duplicate work and specialist knowledge can get lost. (Note I am not saying “nobody has overall design authority” is a downside because while a single Linus can be an advantage it can also be a liability.)

One more problem here: this solution directly breaks Conway’s Law. In theory it could work but quite possibly the homomorphic force behind Conway’s Law might reassert itself. This might create some problems further down the line so needs monitoring.

Option 3: Independence

Taking option 2 to the extreme you might even separate the teams completely. Again there are plus and minuses.

Indepence-2018-09-18-12-23.jpg

On the one hand the teams are completely independent, they can move at their own pace, with their own priorities, value is clearly attributed and there is now resilience in the system and risk is reduced.

However, there is duplication. Not only does this mean more work it means that there may be inconsistencies, a client recognised by Trading might not be recognised by Yet Another.

Both options 2 and 3 demand larger teams and this option might requires more people overall. One can’t be sure because teams might come up with innovative solutions or come up with some new mechanism for sharing.

I’m sure some readers will discount this option very quickly but there are big benefits to complete independence – particularly when teams are separated geographically (e.g. Trading in London, Some Other in Frankfurt and Yet Another in Singapore) or when they are addressing different markets. One of the dangers of shared modules is that they become bloated by generic features nobody really wants but someone has to pay for.

This approach might also be advantageous when the company is in a growth and innovation mode. Let each team grow as fast as they can and innovate. In time a “winner” might emerge or common elements appear naturally.

Another variation on option 3 would be to have one team take the lead. Say Trading, this would be a larger team who developed the share services as part of their business facing work. But they would not “genericise” those services. The other, smaller teams, would do what they needed, when they needed, to service their own value streams.


That is three options. I could come up with some more, none is perfect. The important things are:

  • Create a clear way for teams to see the effects of their work and share in the value.
  • Allow teams autonomy in decision making and reduce dependencies.
  • Keep it simple so everyone can see cause and effect.
  • And of course, keep the teams stable – don’t break them up.

If you have any questions about Continuous Digital and #NoProjects please mail them over and I’ll do my best to answer them in this blog.

Receive these posts by e-mail?

Subscribe to my newsletter & receive a free eBook “Xanpan: Team Centric Agile Software Development”

How should we organize our teams? Read More »

Agile is the process digital technology needs

1200px-Workers_in_the_fuse_factory_Woolwich_Arsenal_Flickr_4615367952_d40a18ec24_o-2018-07-18-12-19.jpg

In my presentation at Agile on the Beach last week I continued my discussion of Agile and Digital. It is increasingly clear that digital and agile are intrinsically linked. Specifically, business need agile processes to get the most out of digital technology. My “Agile, Digital & the new management paradigms” presentation is online but let me give you the argument here.

There is a long standing model of technology change – so widespread I can’t find the original source – which says change comes in three steps:

  1. First new technology allows the same processes and activities to be done better, faster, cheaper, more efficiently. In this stage new technology is used to do the same things, the processes and practices change little.
  2. Next new technology allows process and practices to be reconsidered and changed to make the most of new technology. Work becomes even better – whether that be faster, cheaper, higher efficiency, superior products, whatever.
  3. Finally new innovations appear because of the technology and new processes. One can see opportunities for new businesses, new business models, the next round of technology innovation and more.

So the whole thing repeats.

Look at the photo above. According to WikiCommons this is a picture of a factory at Woolwich Arsenal sometime in the 1800s. Notice the belts stretching from the ceiling to the workstations. These carried power, or to be more precise motion. Above the workers is the line shaft which turns. The shaft is driven by a central power (motion) source somewhere, probably a water wheel or a steam engine.

This is before electricity. The line shaft and the belts carry the power the factory needs to work. And they break, the longer they are the more prone to breaking they are. Factory design is constrained by the need to have straight lines for the line shaft and short distances between the shaft and the workstation. And factory design dictates layout and processes.

Then came electricity.

Electricity allowed each workstation to have its own motion generator. At first factory owners used electricity to do the same things faster and more reliably. They could dispense with the steam engine and thus the stokers and coal it needed. But at first they didn’t seize all the advantages electricity brought.

It took time to understand how a factory could be laid out more efficiently and how processes could be changed. When they did factories got even more efficient and faster. Some might argue that it took the coming of Lean manufacturing to complete these process changes.

The same story has played out in industry after industry with technology after technology. Think of Word processors: first they helped secretaries do their job faster, then processes changed and everyone wrote themselves, goodbye secretaries. Containerisation in the shipping industry is another. First ships loaded and unloaded faster. Then the shipping companies innovated but more importantly world trade innovated. Some observers claim containerisation was a more significant factor in trade globalisation than free-trade agreements.

Digital technology is like electricity. It changes business, it creates new opportunities for doing things differently. To get the most from digital technology you need new processes. Right now most companies are stuck – even happy – doing things faster. Only when they change processes will they get the full benefits.

Agile processes are that change.

Agile ways of working help companies get more from digital technologies. Without Agile companies using digital technologies are just doing the same old thing faster.

Agile started in software development for two reasons. First software developers had a lot of problems, they had the need to change. Second, programmers had the first access to digital technologies.

Ray Tomlinson, a programmer, was the first person with e-mail. Tim Berners-Lee, a programmer, had the first web-browser. Ward Cunningham, a programmer, had the first Wiki. I could continue.

Software developers created Agile because they needed to and they could.

This is why Agile is taking off in marketing.

Outside of technology itself marketing has probably been more exposed to digital technology than any other part of business. First with digital publishing then with social media. At first digital helped marketing departments do the same work faster. Next it changed what you could do entirely. Marketing is adopting agile because those processes allow marketeers to do a better job when working with new digital technology.

So forget all those arguments about agile being a better way of working (it is but never mind).

Forget all those stories of agile like processes and practices before 1998 (yes they existed but that doesn’t change things).

Forget the debate about waterfall and upfront planning versus agile and just-in-time (that is history).

All you need to know is:

  1. Digital technology is helping you do things faster/better/cheaper.
  2. Agile ways of working allow you to get more from digital tools.
  3. More innovation is coming.

Agile is the process for digital businesses.

Sign-up to receive these posts by e-mail and free eBook of Xanpan

Image of Woolwich Arsenal factory taken from WikiCommons, no known copyright.

Agile is the process digital technology needs Read More »

Organizational structure in the Digital and Agile age

iStock_000003002725XSmall-2018-07-3-18-18.jpg

Someone asked the other day: how should an organisation be designed?

There are two potential answers, which actually aren’t as contradictory as they look at first sight.

The first is very simple: Don’t.

That is, don’t design your organization, don’t set out an organizational chart, don’t set out a plan and aim to restructure your organization to that plan. Rather create the conditions to let a structure emerge.

I suppose its the difference between “design” meaning “create a plan for the way you want things to be” and “design” meaning “the way things are arranged.” To differentiate them the first might be called “intentional design” and the latter “emergent design.”

That does not necessarily imply all emergent structures are good. As we see in code sometimes emergent designs are not always the best and over time they need refactoring. Which implies at some point there needs to be intentional design.

Put it like this: I’d rather your organization pulls the design rather than you push a design on the organization.

Organizational structure is itself a function of business strategy. And both need to be part emergent and part intentional. Although you might have noticed I tend towards emergent while most of the world tends towards intentional!

Thus it helps to have a reference model of how you think the organization should be, maybe something to steer the organization towards.

So the second answer to the question would be longer:

  • Create standing delivery teams which are embedded in the business line itself. This is sometimes call stream teams, or stream based development, or “teams aligned to the value stream”, or several other names I can’t think of just now.
  • Each business line is itself a stream of work and digital delivery teams support that work.
  • Teams contain all the skills and authority to do the work that is required for that business stream.
  • The team is part of the stream so the business/technical divide should dissolve. Something I call BusTech.
  • Teams are value seeking and value creating: the team seeks opportunities to create value for the business and delivers on the most valuable ones.
  • Devolve authority to the teams whenever you can. Teams are mini-businesses. (Notice I deliberately don’t use the word empowerment.)
  • Teams grow when the business is successful and more digital capability is needed. And teams shrink when money is tight or less capability is needed.
  • Teams may split (Amoeba style) from time to time. New teams may be in the same business line (addressing another question) or part of another, possibly new, business line.
  • Active – or Agile – Portfolio Management sits on top to monitor progress, provide extra resources, remove resources, etc. There may even be multiple portfolio processes, one at the business line level and perhaps one above multiple business lines.
  • Minimally Viable Teams are started to explore new initiatives, sometimes these go on to be full standing teams but they may also be dissolved if the idea doesn’t validate.
  • Seek to minimise common services between teams because these create bottlenecks, conflicts and delays. Each team should stand alone. This may mean some duplication, and therefore some extra costs, but accept that. Once you have your model working you can fine tune such things later.
  • Don’t worry about planning and synchronisation between teams to much, worry more about getting the teams to release more often and deal with synchronisation issues when they become a problem.

They are the main points at any rate. If you’d like to know more Continuous Digital contains a longer discussion of the topic. (Continuous Digital actually builds on Xanpan in this regard, and the (never finished) Xanpan Appendix discusses the same idea.)

Sign-up to receive these posts by e-mail and free eBook of Xanpan

Organizational structure in the Digital and Agile age Read More »

Closing the Product Owner mini-series: they are all different!

StopStart-2018-05-9-09-45.jpg
With some final words I’d like to draw this mini-series on the Product Owner to a close and open a new chapter with a new book. I’ve written six blog posts in the last two months and I have drafts for more but there are other things I want to blog about.

I have drafts for more posts and ideas for even more. So its time to make this into another book: Product Ownership. This is on the LeanPub site now and you can buy it. So far it just contains a new prologue story but I’ll add these posts soon as the first chapters.

Ever since I wrote Little Book of User Stories I’ve thought there should be a companion volume: “Little Book of Product Ownership”. The intention is for the first part of the new book to discuss the product owner role – and whether it should even exist – and then quickly get into the tools of Product Ownership.

Now some closing words…

While I’ve suggest a lot of things that a Product Owner should do, and a few that they should not do, there are really no hard and fast rules about what a Product Owner should or should not do.

In the language of business schools: there is no contingent way of being a product owner, every product owner and organization is different and they need to find their own path. I cannot give you a flow chart for what a product owner does or should do, nor can I give you a set of rules to say “When the customer says Foo the Product Owner should do Bar.”

Every Product Owner has to work out what is right for them because every organization is different. And every organization will – rightly or wrongly – expect different things from the people it christens Product Owner.

Additionally every team is different and contains different skills and experience. As a result every team will differ in what it needs from the Product Owner(s) and how the team members can support the Product Owner and share the work.

And every Product Owner is themselves different and brings different skills, experience and insights to the role.

Job #1 for a newly appointed Product Owner is to sit down and decide what type of Product Owner they are expected to be and what type of Product Owner they want to be:

  • They may be a Backlog Administrator taking instructions from others.
  • They may be a Subject Matter Expert using their expert knowledge of the domain to decide what the right product to build is and help other team members understand the details of what is being built.
  • They may need to analyse internal process and business lines using the skills of Business Analysis.
  • They may need to get out on the road to meet customers – and potential customers – to understand the market and where the opportunities are using the skills of Product Management.
  • They may need to call on skills from other fields to: Project Management, Consulting and Entrepreneurship to name a few.

But a Product Owner is not some other things:

  • If they were a developer they need to accept they will not be coding any more. There simply isn’t time and anyway, they need to trust the team.
  • If they were a Project Manager, Development or Line Manager they need to resist any urge to tell people what to do or look too far into the future. They need to re-focus on value not time, and recognise that their authority comes from their competence not from a position on a chart.
  • Product Owners from a Business Analysis background need to look beyond Business Analysis, specifically they need to immerse themselves in the world of Product Management.
  • While Product Owners who were Product Managers probably have the easiest ride they too need to change, they need to think more about internal stakeholders, processes and delivery.

Every Product Owner and everyone working with Product Owners needs to read and reflect on the role. Hopefully some of the words in my recent posts – and the new book – will help with that – and hopefully some of you might like to hire me for advice or a training course – just call 🙂

Finally, I sincerely believe there are better Product Owners and not-so-good Product Owners, and that some organizations (teams, companies, enterprises) which offer a better environment for Product Ownership and equally there are those which are downright hostile to product ownership.

Want to receive these posts by e-mail? – join the newsletter today and receive a free eBook: Xanpan: Team Centric Agile Software Development

Closing the Product Owner mini-series: they are all different! Read More »

Product Owners need 4 things

iStock_000008515543Small-2018-03-5-16-09.jpg

To be an effective Product Owner – and that includes product managers and business analysts who are nominating work for teams to do – you need at least four things. You may well need more than these four but these are common across all teams and domains.

  1. 1. Skills and experience

There is more to being a Product Owner than simply writing user stories and prioritising a backlog. Yes, you need to know how to work with a development team and how to work in an Agile-style process. Yes you need to be able to write user stories and acceptance criteria, perhaps BDD style cucumbers too; yes you need to be able to manage a backlog and prioritises and partake in planning meetings.

But how do you know what should be a priority?
How do you know what will deliver value? And please customers? Satisfy stakeholders?

Importantly Product Owners need to be able to do the work behind the backlog.

Product Owners need to meet people, have the conversations, do the analysis and thinking behind those things. Any idiot can pick random items form a backlog but it takes skills and experience to maximise value.

Product Owners need to be able to identify users, segment customers, interview people, understand their needs and jobs to be done. They need to know when to run experiments and when to turn to research journals and market studies. And that might mean they need data analysis skills too.

If the product is going to sell as a commercial product you will need wider product management skills. While if your product is for internal use you need more business analysis skills. And product managers will benefit from knowing about business analysts and business analysts will benefit from knowing about product management.

You may also need specialist domain knowledge – you might need to be a subject matter expert in your own right, or you might become an SME in given time.

Some understanding of business strategy, finance, marketing, process analysis and design, user experience design and more.

Don’t underestimate the skills and experience you need to be an effective Product Owner.

  1. 2. Authority

At the very least a Product Owner needs the authority to nominate the work the team are going to do for the next two weeks. They need the authority to choose items form a backlog and ask the team to do them. They need the authority not to have their decisions overridden on a regular basis. (OK, it happens occasionally.)

As a general rule the more authority the Product Owner has the more effective they are going to be in their role.

The organization may confer that authority but the team need to recognise and accept it too.

I’ve seen many Product Owners who while they have the authority to nominate work for a team don’t have the authority to throw things out of the backlog. When the only way for a story to leave the backlog is for it to be developed it is very expensive. This leads to constipated backlogs that are stuffed full of worthless rubbish and where one can’t see the wood for the trees.

If the Product Owner doesn’t have sufficient authority then either they need to borrow some or there is going to be trouble.

  1. 3. Legitimacy

Legitimacy is different from authority. Legitimacy is about being seen as the right person, the bonafide person to exercise authority and do the background work to find out what they need to find out in order to make those decisions.

Legitimacy means the Product Owner can go and meet customers if they want. And it means that they will get their expenses paid.

Legitimacy means that nobody else is trying to fill the Product Owner role or undermine them. In particular it means the team respect the Product Owner and trust them to make the right calls. Most of all they accept that once in a while – hopefully not too often – the Product Owner will have to say “I accept technologically X is the right thing but commercially it must be Y; full ahead and damn the torpedoes.”

It can be hard for a Product Owner to fill their role if the team believe a senior developer – or anyone else – should be managing the backlog and prioritising work to do.

  1. 4. Time

Finally, and probably the most difficult… Product Owners need time to do their work.

They need time to meet customers and reflect on those encounters.

They need time to work-the-backlog, value stories, weed out expired or valueless stories, think about the product vision, talk to stakeholders and more senior people, and then ponder what happens next.

Time to evaluate what has been delivered and see if it is delivering the expected value. Time to understand whether that which has been delivered is generating more or less value than expected. Time to feedback those findings into future work: to recalibrate expected values and priorities, generate more work or invalidate other work.

Product Owners need time to look at competitor products and consider alternatives – if only to steal ideas!

They need time to work with the technical team: have conversations about stories, expand on acceptance criteria, review work in progress, perhaps test completed features and socialise with the team.

They also need time to enhance their own skills and learn more about the domain.

And if they don’t have the time to do this?

Without time they will rush into planning meetings and say “I’ve been so busy, I haven’t looked at the backlog this week, just bear with me while I choose some stories…”

More often than not they will wing-it, they substitute opinion and guesswork instead of solid analysis, facts and data. They overlook competition and fail to listen to the team and other managers.

And O yes, they need time for their own lives and family.

I sometimes think that only Super Human’s need apply for a Product Owner role, or perhaps many Product Owners are set up to fail from day-1. Yet the role is so important.

I plan to explore this topic some more in the next few posts.

Product Owners need 4 things Read More »

Outsourcing banana skins: Warning signs that your supplier isn’t as good as they claim

iStock-500539718m-2018-02-1-11-06.jpg

So you think you want to contract out some development work? – yes, you know this area is full of banana skins to slip on, and you know others have problems but you still want to do it.

And you want to contract it out to an “Agile” development shop?

There are no laws against opening a development shop – a digital agency, an outsourcer, a consultancy, call it what you like. That is the beauty of capitalism, it allows pluralism. The hard part is choosing one that is competent, some outsourcers are pretty awful.

Everyone who can spell “Agile” can claim to be Agile, and most hire a copywriter to give them an online spin so they all end up making the same claims.

Those who are half good can coach their staff in what to say. And in truth, most of them genuinely want to do the best possible job for you – and be agile too. But how can you really tell?

Well… when I’m being cynical I think you can’t. The only way to really tell is to give them some work and see what happens. Of course once you’ve engaged someone you need to be both legally and mentally prepared to walk away.

So to help you here are some warning signs that you have stepped on a banana skin and your supplier isn’t as good as you – and they – want to be. You might even say these are warning signs that they aren’t really Agile.

1) Customer involvement

They don’t want customer involvement. They don’t want your people on site. They claim that your people get in the way. They want to be left alone to do things.

Obviously I’m thinking primarily of actual Customers, Users, Product Owners, Business Analysts and so on. These people should be working closely with the suppliers people. They should have direct contact, they should be discussing stories.

If your supplier isn’t embracing your people and treating them as their own team members something is probably wrong.

The supplier should be challenging your people – after all the suppliers are the experts, if they are simply accepting everything you ask for then something is wrong.

The same is true of other people you might want involved: a consultant or Agile coach should be welcome too. And if you decide to ask a third party to inspect their development then they should be open to this too.

Naturally they should also be open about the code too. After all the code will be yours one day.

2) Regular demonstrations

The supplier should be providing regular demonstrations – “show and tell” – as a very minimum. Every couple of weeks I expect the supplier to show the latest work. You – and your people – should be able to see working software offering more than the previous demo.

If the supplier is NOT providing regular demonstrations then you should be worried. Likewise, if the demonstrations don’t show progress get worried. Most of all, if the supplier doesn’t want to talk about why demonstrations aren’t happening, or how they can show progress then something is wrong.

3) Release, release, release

Show and tell demonstrations are good but the real test is to release to live. Releasing all the way to your live system. You might hide it on an obscure URL that nobody knows, or call it a beta release or something, I don’t care, the closer they can get to real live the better.

You supplier should be releasing to a live environment – or an exact copy – very very regularly.

The longer the supplier goes without an actual release the more nervous you should be. Sure, once in a while things go wrong and nobody is perfect. They may go two weeks with nothing to show for it. I don’t like it – and neither should you – but an occasional gap is OK.

Going four weeks without a release… I suppose it might happen in the early stages of the work. But it is in the early stages that you most need reassurance that they can deliver something – anything!

Six weeks with no release… well here we are into “3 Strikes and you are out.” Sure they will be able to give technical reasons why things messed up three times in a row. But take it from me, something is wrong.

The longer they go without an actual release to more concerned you should be and the more you should offer to work with them to address the issue.

Eight weeks? – eject, eject, eject.

4) Show me the tests

Maybe this should be warning sign #1 but for this you need someone technical, someone who knows what a test looks like. In the show-and-tells your supplier should be able to show you automated tests executing. Not very exciting perhaps and certainly not meaningful to the business but if they can’t show you then how do you know they even exist?

And if your supplier doesn’t have an automated test suite then it is certainly time to get out.

Ultimately the system they are building is yours. Your people will need to maintain it, or you will need to pay someone else to maintain it. Without automated tests that is going to be hard. Skipping tests now might make it look like you are saving money but you are not, even in the short term the lack of tests will bite you hard, it will push up costs and destroy schedules.

5) “Feature complete”

The phrase alone should be a warning sign. Equally the words “75% feature complete” (or any other percentage) is a big red flag.

If the supplier doesn’t have a test suite, if they can’t show working (preferably releasable) code then its probable they are feature stuffing. They will say they are making progress because “60% of features are done”. They may even start to claim they are feature complete but remember: a feature without a test isn’t done.

A feature without a test is pure risk. At any time a defect can put a hand up and say “Fix me!”

An automated test isn’t a guarantee of bug free code but without automated tests then I guarantee you have defects waiting to appear.

If you are in a relationship exhibiting any of these five sign then it is certainly time to talk. It may be time to end. But how do you avoid getting into that position?

Let me be as clear as I can: both you and your supplier should prioritise working, usable, functionality over more functionality. As the old saying goes “A bird in the hand is worth two in the bush”, working, deliverable (even better released) features are the priority, there should be less work in progress, fewer incomplete features, fewer “almost done” and as few as possible defects.

While cynical me thinks you might not be able to avoid it that doesn’t mean you shouldn’t try, so here are four warning signs that you are about to step on a banana skin:

1) “Agile is not that different”

Don’t let them tell you Agile isn’t different. In many ways it isn’t but if a supplier is trying to persuade you that you don’t need to change the way you work then it is a sign that either a) they don’t appreciate the magnitude of the change or b) they will tell you anything to get the contract signed.

Since you want a supplier who will challenge you it might not be a good idea to hire one who doesn’t like challenging you or doesn’t prepare you for difficulties.

2) “We are certified”

An extension of warning sign #1 is that the supplier is proud of how certified they are: ISO-9001, PMI, PRINCE-2, CMMI – some in the Agile world would regard these certifications as warning signs in their own right.

Scrum Master Certified, Agile Project Manager Certified, Scrum Product Owner Certified: these are slightly better but anyone who can’t tell you the flaws in all these certifications has myopia.

Question any organization that offers up badges rather than working products.

(Disclosure: for better or worse I hold a couple of Kanban certifications, while I think Lean Kanban University have done a better job than many in making their certifications meaningful I don’t think they are a panacea either. Anyway, Kanban certifications aren’t as recognised as those I just mentioned.)

3) Fixed or long term contract

IT suppliers have a long history of locking clients into “fixed contracts” – fixed scope, cost and time. These contracts are utterly flawed. Anyone claiming they can fix everything is a charlatan. Give them a copy of “Dear Customer: The Truth about IT” (the Xanpan prologue) and say goodbye.

Similarly locking yourself into a long term contract with a supplier before you have done some work with them is a bad sign. Do a small piece of work, for a small fee, with your potential supplier and see if they are as good as they say.

In my experience the best – most “agile” – digital suppliers can pick and choose their customers. If your supplier needs you more than you need them then it is a bad sign.

Read more? Subscribe to my newsletter – free updates on blog post, insights, events and offers.

Outsourcing banana skins: Warning signs that your supplier isn’t as good as they claim Read More »

Minimally Viable Team in a nutshell

Workers_000011166993XSmall-2018-01-26-11-03.jpg

Last week I was in Holland helping a client with their agile adoption and digital transformation. When the subject of teams came up I started talking about Minimally Viable Teams. Yesterday I found myself writing an e-mail to the client expanding on the idea. And it seemed to me that the e-mail – or an edited version – was worth sharing here…

The idea of an Minimally Viable Team (MVT) is based on the observation that if a team is overstaffed then team members will find work for themselves – Parkinson’s Law.

Mix in Conway’s Law: the recognised phenomenon where team copy the organization structure they are in. So for example, if you have a database expert on the team the final design will use a database whether one is needed or not.

If one is aiming for a self-organizing, goal-directed, value-seeking team then making any decisions about the team, the software design, or even the problem before work begins is questionable. The more decisions that are made the more the team is constrained, the more the team is constrained the less it is master of its own destiny.

Further, those decisions made before work begins: one expects them to be rational, which means some pre-work is needed to understand what decisions are needed and make the decisions. That pre-work costs time and money. The more money that is committed then the more difficult (i.e. more career threatening) it becomes to reverse those decisions if things go wrong.

Some companies spend an awfully long time thinking and planning to do something: longer than it takes to actually do the thing. I once visited a company which had spent five years planning a particular project and not building anything.

Add two more things to this.

We know from experience that planning has rapidly diminishing returns. A little bit of planning creates great learning, but after a little while the rate of learning drops off. Very soon learning by doing becomes more effective, i.e. switch from thinking about what might be done to trying to do it.

This has never been truer than today – 2018: with the computing power and tools it is faster and cheaper than ever to build a prototype, a concept, an MVP, version 1, alpha version or whatever else you want to call it.

However, going to the other extreme and doing no pre-work doesn’t make a lot of sense either.

Enter the Minimally Viable Team: the team jumps to doing, all that pre-work is given to the team. They get to decide what is needed.

To traditionalists the team/project/product is launched prematurely but actually all we are doing is extending the start date backwards so that the pre-work is now part of the thing. By tasking the initial team with all the traditional pre-work the team becomes master of their own destiny again. And they can choose to approach the mission with a traditional approach (market research, architecture design, resource planning) or in an agile/digital fashion (build a small product and test it) – that is their choice.

The MVT idea is to “starve” the team and make them pull only the necessary resources as and when they need them. When organizations decide who (which roles) will be on the team in advance they are in effect designing the software.

And since agile approaches and modern tools allow us to make progress that much faster why not move more quickly to a working product? Minimise the design, postpone the architecture.

This approach also means the initial team can be kept small which means they are cheap. So if they conclude the project shouldn’t be done the organizational inertial is less and the project can be cancelled. Which hopefully means the organization will take more chances on more ideas.

Try this thought experiment.

On Day-Zero there is nothing.

Someone decided there should be Product X. How did this happen? They may have had the idea days ago and have spent the intervening time researching the market, the competition, the problem and so on. (During which time their normal job has been disrupted, the sooner they can dedicate themselves to the new idea the faster things will happen.)

On Day-Zero they talk to an architect who considers a design.

This takes a few days at the end of which there is an outline design and the architect suggests the team needs four programmers, two testers, a UXD and a DBA. Plus a project manager and product owner. 10 in all.

It now takes time to make the business case and gather those resources.

At that point work can officially begin, call that D-Day.

Then the team need to learn to work together, build something and launch it into a market.
They also need to understand what the architect had in mind.

Officially the project began on D-Day, or perhaps the day the business case was approved.

How much time has been spent so far? Without testing the market? Allowing competitors to do something? – all this time cost of delay has been at work changing the business case.

How has all that “getting ready” time been accounted for? How has this work been managed?

The MVT approach says: Time is of the essence the team should decide all these things.

So, as quickly as you can, spend a little venture money on an MVT.

That team has to investigate the market, competition, problem, etc. The team can think about architecture but their primary aim is to build something, and MVP, a prototype, a proof of concept, whatever – build it, show it to customers, launch it, put it in the market.

By keeping it small the team can quickly invalidate ideas which don’t work. Ideas that do work can be built on. They are free to learn.

The initial MVT will do all the same things that a “pre project” phase would do but in a much more agile/digital way. The MVT also allows for continuity, when the team find success the team that can be expanded and grown – applying Gall’s Law.

This also looks a lot more like a start-up than a normal corporate project.

If the idea of a Minimally Viable Team is new to you then check out the discussion in Continuous Digital or some of my earlier blog posts on MVTs.

Read more? Subscribe to my newsletter – free updates on blog post, insights, events and offers.

Minimally Viable Team in a nutshell Read More »