Posted on

More Continuous #NoProjects questions

Allan Kelly from Allan Kelly Associates

QA-2018-10-24-14-20.jpg

Three short questions and answers to finish off my series of left over questions about #NoProjects, #NoEstimates and the Continuous model.

Q4: How do we prioritize and organize requests on a product that are from opposite business owners? – for example legal (who wants to reduce the risk and annoy more customers) and sales (who want to increase the features and simplify life) can be arbitrated in a backlog?

You can think of this as “which is worth more apples or milk?” It is difficult to compare two things which are actually different. Yes they are both work requests – or fruit – and each can make a case but at the end of the day you can’t make everything number 1 priority.

In real life we solve this problem with money.

Walk into your local supermarket. Apples, oranges and milk are both price in the same currency, sterling for me, Francs for the person who asked this question, maybe Euro’s or Dollars for you. So if we can assign value points to each request we are half way to solving the problem.

Now sales will argue that without their request there is no real money so whatever they ask for is worth more. And legal will argue that nobody wants to go to jail so their request must be worth more. You can set your analyst to work to calculate a value but a) this will take time and b) even when they have an answer people will dispute it.

Therefore, I would estimate a value – planning poker style. With an estimates value there is no pretence of “right” or “correct”. Each party gives a position and a discussion follows. With luck the different sides converge, if they don’t then I average. Once all requests are valued you have a first cut at prioritisation.

Q5: How to evaluate the number of people you need to maintain software?

I don’t. This is a strategic decision.

Sure someone somewhere needs to decide how much capacity – often expressed as people – will be allocated to a particular activity but rather than base this on need I see this as another priority decision. If a piece of software is important to an organization then it deserves more maintenance, and if it is not important it deserves less.

You could look at the size of the backlog, or the rate of new requests and contrast this with the rate at which work gets done. This would allow you to come up with an estimate of how many people are needed to support a product. But where is the consideration of value?

Instead you say something like: “This product is a key part of our business but the days of big changes are gone. Therefore one person will be assigned to look after the software.”

If in three months more people in the business are demanding more changes to the software and you can see opportunities to extract more value – however you define value – then that decision might be revised. Maybe a second person is assigned.

Or maybe you decide that maintaining this product isn’t delivering more value so why bother? Reduce work to only that needed to keep it going.

Q6: How do you evaluate the fact that your application becomes twice as fast (or slower) when you add a new feature in a short period of time?

Answering this question requires that the team has a clearly defined idea of what value is. Does the organization value execution speed? Does the organization value up-time? Does the organization value capacity?

Hopefully some of this will have come out of the value estimation exercise in Q4, if not the analysis is just going to take a bit longer. The thing to remember is: what does the change do for the business/customers/clients? Being faster is no use in itself, but doing X faster can be valuable.

The real problem here is time. Some changes lead to improvements which can be instantly measured. But there are plenty of changes where the improvements take time to show benefit. Here you might need to rely on qualitative feedback in the short run (“Sam says it is easier to use because it is faster”). Still I would keep trying to evaluate what happens and see if you can make some quantitive assessment later.

Notice that Q4 and Q6 are closely related. If you have a clear understanding of why you are doing something (Q4) then it becomes easier to tell if you have delivered the expected value (Q6). And in trying to understand what value you have delivered then you refine your thinking about the value you might deliver with future work.

Another feedback cycle.

These questions concludes the series of question carried over from the #NoEstimates/#NoProjects workshop in Zurich – see also How should we organize our teams? – Dealing with unplanned but urgent work – How do we organise with a parallel team? – if you would like me to answer your question in this blog then please just e-mail me.


The #NoProjects books Project Myopia and Continuous Digital discuss these and similar issues in depth and are both available to buy in electronic or physical form from Amazon.

CDMyopia-2018-10-24-14-20.jpg

The post More Continuous #NoProjects questions appeared first on Allan Kelly Associates.

Posted on

Dealing with unplanned but urgent work

Allan Kelly from Allan Kelly Associates

YellowUrgent-2018-10-3-09-36.jpg

3) Maintenance and Evolution
To keep a product alive, we choose backlog stories that will bring value, and do them one after the other.
But… as support of the application may take a huge part the work. And when the problem is critical, there is nothing you can do but stop what you do and fix it. This can blow any estimation.
How do you deal with firefighting in a #NoProjects world?
And techniques to avoid it.
How does #NoProject and DevOps work together?

Let me take the last part of this question first. Operations has never been plagued by the project model the way development has. When does a SysAdmin ever say “The project is finished so I’m not going to restart the server” ?

DevOps (aka Continuous Delivery) and Continuous Digital are a natural fit. The team is responsible and accountable: writing the code, deploying it and supporting it there after: “You built it, you operate it” as DevOps people like to say.

Of course the team needs to contain all the skills needed to service this approach. That might mean having an individual specialist on the team or it might mean that team members have multiple skills. A Continuous team is not just a DevOps team, it is also a Business-Technology team – or #BizTech to coin a hashtag. (This week I heard such a team called a BizDevOps team. That is one portmanteau too far for me.)

Which brings us quite nicely to the first part of this question: how do you manage – and perhaps even plan for: unplanned work?

What I would like to happen when unplanned work appears is that it is written on a card and placed in the backlog. It then takes its place with all the other possible work. But… as the questioner states: this work can’t wait, it is urgent.

Unplanned but urgent simply needs to be done. Quite possibly other work, less valuable work or work which is not time critical may even be interrupted.

At this point I was about to refer readers to an old blog post about Yellow Cards. But it turns out that I never wrote that post. Despite talking about Yellow cards for years I’ve never blogged about them. I wrote about them in Xanpan but for some reason or another I never wrote the blog… so here you go…

When a team is mid-sprint and unplanned work appears the team should:

  • First ask “Can this work wait?” – If so then write it on a regular card and put it in the backlog
  • If not then ask, is this more valuable than work we are doing now? – If not then someone needs to find the source of the request and explain why is isn’t going to get done.
  • Assuming it is urgent then it gets written on a Yellow card.
  • If it is really really urgent then someone drops what they are doing and works on the yellow card immediately.
  • If it can wait a little while then the next person who finishes their current work picks up the card and does it.
  • Once the yellow card is done mark it as done as with any other card and work continues as it was before.

Accepting unplanned work into a sprint impacts the other work the team is doing. I’m not a big fan of the commitment protocol so to me it is no big deal if this work displaces something else. But if your team are expected to hold fast to hard commitments while dealing with unplanned work then you have a problem, call me, we need to talk more.

At the end of the iteration we can look at the cards and reason about them. Now we can see the work we can manage it and decide what to do about it.

I count up the yellow cards – and all the planned work cards. That allows me to calculate a ratio of planned versus unplanned work. (Sometimes teams put a retrospective points estimate on a yellow but doing a card count is often sufficient.)

This can be tracked over time – graph it, make it visible again. Now we can look at the work and the pattern of work, reason about it, maybe do some root-cause analysis. Perhaps:

  • Perhaps much of the urgent work isn’t really so urgent, perhaps the team should push back more. Maybe the team, or one of the team leaders, needs to the authority to say No.
  • Perhaps most of the unplanned work comes from a particular person. Maybe this person doesn’t realise the impact of their unplanned requests, or maybe they need to be included in the planning process, or … a million other reasons.
  • Perhaps the unplanned work is coming from the same sub-system, maybe some remedial work on that sub-system could reduce the amount of unexpected work.
  • Perhaps the unplanned work is just the nature of the business and being responsive is valuable.

Looked at this way we can think about reducing the amount of unplanned work. But also, we can plan for unplanned work.

It is likely that over time a pattern will emerge. One team I know found that 20% to 25% of their work in any sprint was unplanned. They simply planned for 20% less work. They now had the capacity to cope with unplanned work. At the least they could expectation manage stakeholders.

One team found that each sprint they were doing about 20% IT support tasks (new PCs, Word problems, etc.) so they hired a support technician.

Another team who agonised about unplanned work found that actually they only had about one unplanned card a week. Their problem was not excessive unplanned work but the fact that unplanned work tended to have a very high profile in the company.

Teams which find they have very high levels of unplanned work on a regular basis (e.g. over 50% of work for several months) may well decide to adopt a full Kanban system. Indeed, Kanban folk probably recognise my description as a very simple example of quality-of-service and policies.

I say more about Yellow Cards for unplanned but urgent in Xanpan so you might like to continue reading there.

This is the third question carried over from the #NoEstimates/#NoProjects August workshop in Zurich.


If you have any questions about Continuous Digital, Project Myopia 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”

The post Dealing with unplanned but urgent work appeared first on Allan Kelly Associates.

Posted on

How should we organize our teams?

Allan Kelly from Allan Kelly Associates

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”

The post How should we organize our teams? appeared first on Allan Kelly Associates.

Posted on

#NoProjects: Project Myopia is published

Allan Kelly from Allan Kelly Associates

ProjectMyopiaNew-2018-09-10-11-17-1.jpg

Project Myopia – the original case for #NoProjects – has been a long time in the works but it is now done. Published. For sale on Amazon.

Projects fail. Some say 40% of all IT projects fail, some say 70%. And it has been that way for years. Each project fails for its own reasons but they all share one thing in common: the Project Model. Could it be the project model itself which creates failure?

Projects end. Successful software continues. Twenty-first century digital businesses want to continue and grow.

Project Myopia is available to buy on Amazon today – the physical version should joined the eBook in a few days.

Project Myopia gives the case against projects – the hard core #NoProjects arguments. A second book, Continuous Digital will join Project Myopia in a few weeks on Amazon. Right now copyediting isn’t finished on Continuous Digital, plus the physical copy needs to be worked out. In the meantime late drafts of Continuous Digital are available on LeanPub.

The post #NoProjects: Project Myopia is published appeared first on Allan Kelly Associates.

Posted on

#NoProjects: Project Myopia is published

Allan Kelly from Allan Kelly Associates

ProjectMyopiaNew-2018-09-10-11-17.jpg

Project Myopia – the original case for #NoProjects – has been a long time in the works but it is now done. Published. For sale on Amazon.

Projects fail. Some say 40% of all IT projects fail, some say 70%. And it has been that way for years. Each project fails for its own reasons but they all share one thing in common: the Project Model. Could it be the project model itself which creates failure?

Projects end. Successful software continues. Twenty-first century digital businesses want to continue and grow.

Project Myopia is available to buy on Amazon today – the physical version should joined the eBook in a few days.

Project Myopia gives the case against projects – the hard core #NoProjects arguments. A second book, Continuous Digital will join Project Myopia in a few weeks on Amazon. Right now copyediting isn’t finished on Continuous Digital, plus the physical copy needs to be worked out. In the meantime late drafts of Continuous Digital are available on LeanPub.

The post #NoProjects: Project Myopia is published appeared first on Allan Kelly Associates.

Posted on

Release or be damned

Allan Kelly from Allan Kelly Associates

iStock-166161352small-2018-09-6-12-26.jpg

Back when I was still paid to code I had a simple question I posed to troubled development efforts:

“Why can’t we release tomorrow?”

This short simple question turns out to be amazingly powerful. I remember one effort I was involved with in California where a new CEO took over and started cutting jobs. I posed this question to the team and in a week or two we did a “beta release” – we did those sort of things back then. Asking this question was the key that allows us to question everything, to cut the feature list – or rather push work back, it stayed on the to-do list but we didn’t let it stop us from pushing to release.

We rethought what we were trying to achieve: we didn’t need the whole product, we just needed enough of the product to work to show to one specific target customer. Even if they signed there and then we had weeks before they used it in anger. But until we released something, until we had something “done” our team, our product, look like just another “maybe.” We had to draw a line under it so the new CEO wouldn’t draw a line under us.

Saying “only do the essential” is easy and come up again and again, whether it is Minimal Viable Product, Minimal Subset, Must haves in Moscow rules, but it is far easier said than done. One persons “essential” is so often another persons “optional extra.” In this context, when I say “essential” I mean “the parts needed to make the system work end to end” – I’m far closer to the old walking skeleton idea.

I was reminded of this question by a couple of endeavours that came to my attention during the summer. Well, I say came to my attention, I feel a bit responsible. Both endeavours are happening at clients; clients who I had fallen out of touch with. My style of working is to help clients who want help, I don’t like selling myself. These clients didn’t ask for more help so I didn’t jam my foot in the door, in retrospect maybe I should have.

In one case the team were doing very well. They were iterating, they were TDD/BDD’ing, they were demoing, they were working with the client, they were doing everything … except releasing. Then one day the client asked “when will it be done?”

Now think for a moment: What if you could release your product tomorrow?

The thing is, without actual products those around the team look for signs that the team can be trusted, that they team will deliver, that the team are thinking about what is to be done. People ask for proxy-products: plans, schedules, risk-logs, budget forecasts and so on. When stakeholders can’t see progress they look for things to assure them that there is (or will be) progress (soon).

Who needs plans and predictions about the future when the future is here tomorrow?

Actual releases are they key to reaching the new world, they change everything.

So I feel guilty: I should have inflicted myself on these teams, I should have been there again and again bugging them “Go to release”, “Remove that barrier”, “Force it through”.

Being able to ship an update of your product has a transformative effect.

It demonstrates the team have the ability to do the job in hand.
It demonstrates you have quality. It obliterates the need for a test-fix-test-fix aka stabilisation aka hardening phase.
It blows away sunk costs because something has been delivered.
It removes “maybe” and “ready but…”
It is probably the greatest risk mitigation strategy possible.
It creates trust and provides a platform for solid conversations.

Most of all, a released product is a far better statement of progress than any number of plans or forecasts.

This does not mean everything is done. Sure there are things left undone but there will be things left undone when I’m on my deathbed, that is the nature of life. As much as we (especially men) love to collect entire sets there are few prizes in life for completing everything on your bucket list.

Having a released product utterly changes the nature of the conversation. Conversations are no longer full of “ifs” “maybes” “shoulds” “how long will it take?” “what are the quick wins?”. Those questions can go away. In its place you can have serious conversations about prioritisation and “what do you want tomorrow?”

This is all part of the reason I love continuous delivery. Teams can focus on real priorities and stop wasting time on conjecture.

In my book if you don’t have a releasable product at least every two weeks – say every second Thursday – you are not Agile. And if you haven’t released a product to live in the last two weeks you are probably not Agile.

I don’t care how close you get to a releasable product: it isn’t a release if it isn’t released to a live environment – close but no cigar as they say. (OK, I’ll accept the live environment may not be publicly know, or might be called a beta, but it has to be the real thing.)

Nor should you rest on your laurels once you have regular releases (to live) every second week. That is but first base. You have opened the door, now go further. There are at least 13 opportunities to improve.

If you cannot do that now then ask yourself: Why can’t we release tomorrow?

And start working to remove those obstacles:

  • Reduce the number of work items you are aiming to put in the release.
  • Fix show-stopper defects now.
  • Running tests now.
  • Get those people who need to sign-off to sign-off.

Software development has diseconomies of scale: many small is cheaper than few large.

And once you have your release you can turn your attention to making sure these things don’t happen again:

  • Reduce the amount of work you accept into development at one time.
  • Fix every defects as soon as they are found.
  • Automate tests so they can run more often. (Automate anything that moves, and if it doesn’t move, automate it in case.)
  • Find a way to reduce the time it takes to get sign-offs: remove the sign-off, make sure the signer prioritises signing or delegate someone else to sign (or automate the signature.)

If there are essential processes, activities, third-parties (or anything else) that has limited bandwidth which need to be done before release but inject delay then re-orientate your process around that bottleneck. For example, if your code needs to pass a security audit before release (an audit you can’t automate that is) then, downsize all the other activities so that the audit process is 100% utilised. (OK, 100% is wrong, 76% might be better, but thats a long conversation about queuing theory.)

Again and again I seem condemned to learn the lesson: nothing counts but working software which is used.

As for my team, and my job in California, it didn’t save me. I regret not asking the question sooner.

The post Release or be damned appeared first on Allan Kelly Associates.

Posted on

Agile is the process digital technology needs

Allan Kelly from Allan Kelly Associates

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.

The post Agile is the process digital technology needs appeared first on Allan Kelly Associates.

Posted on

Best practices considered harmfull

Allan Kelly from Allan Kelly Associates

NoBestPractice-2018-06-20-16-53.jpg

I’ve long worried about “Best Practices”. Sure I usually play along at the time but lurking in the back of my mind, waiting for a suitable opportunity are two questions:

  • Who decided this was best practice?
  • Who says this practice can’t be bettered?

I was once told by someone from the oil industry that it was common for contracts to specify “best practice” should be used. But seldom was the actual practice specified. Instead each party to the contract would interpret best practice as they wished, until something went wrong. At that point, after an accident, after money was lost they would go to court and a judge would decide what was best practice.

Sure practice X might be the best know way of doing things at the moment but how much better could it be? By declaring something “best practice” you can be self limiting and potentially preventing innovation.

Now a piece in MIT Sloan Management Review (Why Best Practices Often Fall Short, Jérôme Barthélemy, February 2018) adds to the debate and highlights a few more problems.

Just for openers, sometimes people mistakenly identify the practice creating the benefits. Apparently some people looked at Pixar animation and decided that having rest rooms (toilets to us English speakers) in the centre of an office floor enhances creativity. They might do, but there is so much else happening at Pixar that moving all the toilets in your organization will probably make no difference at all.

But it is worse than that.

Adopting best practice from elsewhere does not mean it will be best practice in your environment but adopting that “best practice” will be disruptive. Think of all the money you will need to spend relocating the toilets, all the people who will be upset by a desk move they don’t want, all the lost productivity while the work is going on.

The author suggests that in some cases that disruption costs are so high the “best practice” will never cover the costs of the change. Organizations are better shunning the best practice and carrying on as they are. (ERP anyone?)

It gets worse.

There is risk in those best practices. Risk that they will cost more, risk that they won’t be implemented correctly and risk that they will backfire. What was best practice at one organization might not be best practice in yours. (Which might imply you need even more change, even more disruption at even more cost.)

In fact, some best practices – like stock options for executives – can go horrendously wrong and induce behaviours you most definitely don’t want.

So what is a poor company to do?

Well, the author suggests something that does work: copying good practices. Not best but “just OK”. That works. Copy the mundane stuff, the proven stuff. The costs and risks of a big change are avoided. (This sounds a bit like In Search of Mediocracy.)

In my world that means you want to be getting better at doing Agile instead of trying to leapfrog Agile and move to DevOps in one bound.

The author also suggests that where your competitive advantage is concerned keep your cards close to your chest. Do thinks yourself. Work out what your best practice is, work out how you can improve yourself.

I’ve long argued that I want teams to learn and learn for themselves rather than have change done to them. But I also want teams to steal. When they see other teams – at home or elsewhere – doing good things they should steal practices. The important thing from my point of view is for the teams to decide for themselves.

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

The post Best practices considered harmfull appeared first on Allan Kelly Associates.

Posted on

Estimation, planning, teams and money, some data

Allan Kelly from Allan Kelly Associates

PlannedMay17-2018-05-17-11-46.jpg

When I deliver Agile training for teams I run an exercise called “The Extended XP Game”. It is based on the old “XP Game” but over the years I’ve enhanced it and added to it. We have a lot of fun, people are laughing and they still talk about it years later. The game illustrates a lot of agile concepts: iteration, business value, velocity, learning by doing, specification by example, quality is free, risk, the role of probability and some more.

When I run the exercise I divide the trainees into several teams, usually three or four people to a team. I show them I have some tasks written on cards which they will do in a two minute iteration. They do two minutes or work, review, retrospect then do another two minutes of work – and possibly repeat a third time.

The first thing is for teams to Get Ready: I hand out the tasks and ask them to estimate, in seconds how long it will take to do each task: fold a paper airplane that will fly, inflate a balloon, deflate a balloon, roll a single six on a dice, roll a double six on two dice, find a two in a pack of cards and find all the twos in the pack of cards. Strictly speaking, this estimate is a prospective estimate, “how long will it take to do this in future?”

Once they have estimated how long each task will take someone is appointed product owner and they have to plan the tasks to be done (with the team).

What I do not tell the teams is that I’m timing them at this stage. I let the teams take as long as they like to get ready: estimate and plan. But I time how long the estimation takes and how long the following planning takes.

Once all the teams are “ready” I ask the teams: “how long did that take?”

At this point I am asking for a retrospective estimate: how long did it take. The teams have perfect estimation conditions: they have just done it, no time has elapsed and no events have intervened.

Typically they answer are 5 or 6 minutes, maybe less, maybe more. Occasionally someone gets the right number and they are then frequently dismissed by their colleagues.

Although I’ve been running this exercise for nearly 10 years, and have been timing teams for about half that time I’ve only been recording the data the last couple of years. Still it comes from over 65 teams and is consistent.

The total time to get ready to do 2 minutes of work is close to 13 minutes – the fastest team took just 5.75 minutes but the slowest took a whopping 21.25.

The average time spent estimating the tasks is 7 minutes. The fastest team took 2.75 minutes and the slowest 14 minutes.

The average time planning once all tasks are estimated is just short of 6 minutes. One team took a further 13.5 minutes to plan after estimates while another took just 16 seconds. While I assume they had pretty much planned while estimating it is also interesting to note that that team contained several people who had done the exercise a few years before.

(For statistics nuts the mean and median are pretty close together and I don’t think the mode makes much sense in this scenario.)

So what conclusions can we draw from this data?

1) Teams take longer to estimate than do

Everyone taking part in the exercise has been told – several times – that they are preparing to do a 2 minute iteration. Yet on average teams spend 12.75 minutes preparing – estimating and planning – to do 2 minutes of work!

Or to put it another way: teams typically spend six times longer to plan work than to do work.

The slowest team ever took over 10 times longer to plan than to do.

In the years I’ve been running this exercise no team has ever done a complete dry run. They sometimes do little exercises and time themselves but even teams which do this spend a lot of time planning.

This has parallels in real life too: many participants tell me their organization spend a long time debating what should be done, planning and only belatedly executing. One company I met had a project that had been in planning for five years.

TeamSize-2018-05-17-11-46.jpg

2) Larger teams take longer to estimate than small teams

My second graph shows there is a clear correlation between team size and the time it takes to estimate and plan. I think this is no surprise, one would expect this. In fact, this is another piece of evidence supporting Diseconomies of Scale: the bigger the team the longer it will take to get ready.

This is one reason why some people prefer to have an “expert” make the estimate – it saves the time of other people. However this itself is a problem for several reasons.

Anyone who has read my notes on estimation research (and the later more notes on estimation research) may remember that research shows that those with expert knowledge or in a position of authority underestimate by more than those who do the work. So having an expert estimate isn’t a cure.

But, those same notes include research that shows that people are better at estimating time for other people than they are at estimating time for themselves, so maybe this isn’t all bad.

However, this approach just isn’t fair. Especially when someone is expected to work within an estimate. One might also argue that it is not en effective use of time because the first person – the estimator – has to understand the task in sufficient detail to estimate it but rather than reuse this learning the task is then given to someone else who has to learn it all over again.

PlanningDelta-2018-05-17-11-46.jpg

3) Post estimation planning is pretty constant

This graph shows the planning delta, that is: after the estimates are finished how long does it take teams to plan the work?

It turns out that the amount time it takes to estimate the task has little bearing on how long the subsequent planning takes. So whether you estimate fast or slow on average it will take six more minutes to plan the work.

Perhaps this isn’t that surprising.

(If I’ve told you about this data in person I might have said something different here. In preparing the data for this blog I found an error in my Excel graphs which I can only attribute to a bug in Excel’s scatter chart algorithm.)

4) Vierordt’s Law holds

People underestimate longer periods of time (typically anything over 10 minutes), and overestimate short period of time (typically things less than two minutes).

Not only do trainees consistently underestimate how long it has taken them to get ready – which is over 10 minutes – but teams which record how long it takes to actually do each task find that their estimates are much higher than the actual time it takes. Even when teams don’t time themselves observation shows that they do the work far faster than they thought they would.

TimeVMoney-2018-05-17-11-46.jpg

5) Less planning makes more money

One of my extensions to the original game is to introduce money: teams have to deliver value, measured in money. This graph shows teams which spend less time planning go on to make more money.

I can’t be as sure about this last finding as the earlier ones because I’ve not been recording this data for so long. To complicate matters a lot happens between the initial planning and the final money making, I introduce some money and teams get to plan for subsequent iterations.

Still, there are lessons here.

The first lesson is simply this: more planning does not lead to more money.

That is pretty significant in its own right but there is still the question: why do teams which spend less time planning make more money?

I have two possible explanations.

I normally play three rounds of the game. When time is tight I sometimes stop the game after two rounds. In general teams usually score more money in each successive round. Therefore, teams who spend longer in planning are less likely to get to the third round so their score comes from the second round. If they had time to play a third round they would probably score higher than in round two.

This has a parallel in real life: if extra planning time delays the date a product enters the market it is likely to make less money. Delivering something smaller sooner is worth more.

This perfectly demonstrates that doing creates more learning than planning: teams learn more (and therefore increase their score) from spending 2 minutes doing than spending an extra 2 minutes planning.

The second possible explanation is that the more planning a team does the more difficult they might find it to rethink and change the way they are working.

The $1,600 shown was recorded by a Dutch team this year but the record is held by a team in Australia who scored over $2,000: to break into these high scores teams need to reinterpret the rules of the game.

One of the points of the game is to learn by doing. I suspect that teams who spend longer in planning find it harder to break away from their original interpretation of the rules. How can you think outside the box when you’ve spent a lot of time thinking about the box?

In one training session in Brisbane last year the teams weren’t making the breakthrough to the big money. Although I’d dropped hints of how to do this nobody had made the connection so I said: “You know, a team in Perth once scored over $2,000.” That caused one of the players to rethink his approach and score $1,141.

I’ve since repeated the quote and discovered that simply telling people that such high scores are possible causes them to discover how to score higher.

* * *

I’m sure there is more I could read into all this data and I will carry on collecting the data. Although now I have two problems…

First, having shared this data I might find people coming on my agile software training who change their behaviour because they have read this far.

Second: I need more teams to do this to gather data! If you would like to do this exercise – either as part of a full agile training course or as a stand alone exercise – please call (+44 20 3286 4292) or mail me, contact@allankelly.net, my rates are quite reasonable!

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

The post Estimation, planning, teams and money, some data appeared first on Allan Kelly Associates.

Posted on

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

Allan Kelly from Allan Kelly Associates

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

The post Closing the Product Owner mini-series: they are all different! appeared first on Allan Kelly Associates.