David Anderson
Transcript
Okay, good morning.
I think we should start in the interest of keeping the program moving.
Okay, thanks for coming. I just heard that the attendance this year is more than 100% up on the previous years, so a great result from the organizers. And I'd like to thank them again for their perseverance doing this every year. It's great that we have an opportunity and a platform to share our ideas with the audience here in Paris.
Those of you who were here last year will remember at the end of my talk, I talked about an idea called Enterprise Services Planning. As the future of Kanban and this year I'm back to talk about what that really means. So enterprise services planning, scaling the benefits of Kanban.
So what are we thinking about here? Well the key to this is You work in a professional services organization.
For about 100 years now, accountants have had methods for managing businesses, and back in those days, all businesses were physical.
So when types of work came along that were not physical, they needed a way of expressing what that was and accounting for it. And they adopted this term intangible goods.
All businesses that deal with intangible goods are classed as professional services. So if you do anything that involves thinking for a living, you're in a professional services business.
And professional services businesses are ecosystems of lots and lots of interdependent services.
These interdependencies are complex in nature. And this makes managing businesses of this type much different from managing a physical business, whether that's a manufacturing business or an event venue or a hotel or a cafe or a restaurant or a distribution chain.
Retail chain and so on, all of those businesses are physical businesses. Professional services businesses have intangible goods. That means you can't pick them up, you can't store them in a warehouse, you can't walk around and count them. You can't do obvious simple things that managers and physical businesses can do. So the challenge of running these professional services services, businesses, isn't just that the work is of this intangible nature. You can't see it, you can't store it, it doesn't use physical space. And because of that, it limits our ability to use in more common language or common sense to manage the business. But in addition to that, the environment, the external environment is constantly changing. Now that could be political changes, economic changes, changes in market, changes in customer taste, competitive changes. The market is constantly changing external to the business and that has a ripple effect across the entire ecosystem of services. The consequences of this are that priorities change, the capabilities you need in your company are constantly changing and evolving, and your service levels need to rise in response to competition and changing customer expectations.
So managers ask questions like, what should we start next? Do we have the capacity to do everything we need to do? When will it be delivered? And will it come when we need it? How are we going to manage the dependencies across this network of interdependent services? And is that going to affect our ability to deliver? And if we delay starting something now, will we have capacity available to do it later? And will it still arrive on time or at least when we need it for? And how many activities should we have running in parallel? The more things we have running in parallel, probably the more people we need, the bigger the organization, the greater the working capital, the more expensive and risky it is to run our business. Except we're doing lots of things in parallel in order to hedge risk.
So are all professional services businesses inherently capital intensive, despite the fact that they're only ever dealing with intangible goods?
So imagine we have some network of services and I have vastly simplified the problem here with only three and I'm representing each one of these as a Kanban system because this company is clearly very sophisticated and has been attending the Lean Kanban France for several years. So they have these independent, highly effective services running, but they still have interdependencies between them. And if you're someone on the front end here receiving external customer demand, you want to be able to look downstream here and say, okay, Where are the dependencies going to occur and what effect will that have? And hence, when should we start a piece of work here? When do we schedule it?
On the other hand, if you're one of the other managers somewhere else deep in this network, You would like to be able to look upstream and anticipate what's coming so that you can have the right people with the right skills available at the right time to do the work in a timely manner.
So, in the very early days of Kanban, the managers who worked for me used to call this looking left or looking right.
If you're anticipating demand coming, you're looking left. You're looking left on the board, upstream. On the other hand, if you're trying to anticipate dependencies happening in the future, you're looking downstream, you're looking right on the board. If we can combine these two ideas, we can greatly improve the management of a network of professional services.
So enterprise services planning is this concept that we're managing a network of services. And therefore it's an enterprise services wide management solution and it leverages Kanban because we use Kanban to improve each service within that business. But if you improve the services independently, you won't necessarily improve the overall performance of the network. Because we know that dependencies happen. We know things get delayed when they're dependent on other items. There's a lot of queuing in between the different nodes on that network. So the goal of enterprise services planning is to pick the right things at the right time, do them the right way, with an appropriate risk exposure. Because you're not managing your company if you're not managing risk. How many things should you be doing in parallel? That's just one risk management question. If your business has very little risk, The answer would be probably none, just one thing at a time. The reason you do things in parallel is because there is risk in the environment.
So the name Enterprise Services Planning was inspired from the physical tangible goods world. In manufacturing, Toyota adopted the use of Kanban systems in 1947. And they in turn were actually inspired by two existing ideas. The idea of using signal card tokens in Japanese society for limiting quantities of scarce resources. And the just-in-time replenishment of American grocery store shelves. Combine those two ideas together and you've got Kanban systems in Toyota factories in 1947. In 1964, an American called Joseph Orlicky proposed an idea called Manufacturing Resource Planning, or MRP. It took him 11 years to write a book on it. 1975, quite timely, the same year that the microprocessor was invented. And hence a large software market developed for MRP solutions.
Well, in 2004, we tried a Kanban system in a professional services environment, in an intangible goods environment.
Software maintenance. at Microsoft's IT department. Here we are 11 years later and now I'm proposing enterprise services planning essentially as the equivalent of MRP but for professional services for intangible goods environments.
So ESP, if you want the quick elevator pitch for your boss, it's MRP for professional services. It's managing capacity and scheduling intangible work. Now if you know anything about MRP, you'll know there's a lot of mathematics, there's a lot of algorithms involved in figuring out how to schedule, sequence, select work, how to make commitments on work, and in manufacturing environments that also includes things like what things to batch together, how big a batch size should be, and so on. So enterprise services planning, the word planning involves scheduling something, sequencing something, selecting the right things to do, making commitments to customers, anticipating and managing the dependencies, managing all sorts of kind of risk. And understanding what's essential based on both your business strategy and what your customer thinks will make that intangible product and the way you do it. deliver it fit for purpose. And those of you who were here last year will know that my talk was about fitness for purpose.
So now I'm going to get into a little bit of detail of how we do these things, how we figure out what to pick, when to pick it, whether we're hedging risk appropriately or not. And the key to this is risk assessment. We use it for scheduling, sequencing, selection, risk hedging, capacity allocation, demand shaping, too many things that I couldn't fit it neatly on the headline here.
The first thing is to realize that we're using a qualitative approach to risk assessment. In most project management or agile software development literature, we're at one or other end of this spectrum. Either everything's completely heterogeneous, everything's unique, and therefore we need to analyze it all independently, we need to make estimates for it, we need to make very detailed deterministic plans, we need to divide things down through different levels of hierarchy and the requirements in order to get to the atomic level and make a detailed plan at the atomic level.
Traditional planning, expensive, time-consuming, it's full of fake precision and made-up numbers. And while it gives managers the feeling of control, it feels like risk. has been well managed, it's probably still very high risk because there's a lot of bullshit built into that style of planning. The other end of the scale is treat everything as though it's homogenous. Hey, it's all just a user story and we have a velocity. How many user stories do we have multiplied by velocity? There's your answer.
Senior managers inherently know that's a very risky strategy. It was cheap and fast, but they understand the idea that their business is not homogenous. And therefore they're scared of cheap and fast simple plans. And this creates an incongruence between low-level people who want to just multiply user stories by velocity.
And senior managers who think it's full of shit.
So we need something that makes senior managers feel more comfortable without going down the path of treating everything heterogeneously. The big planning up front, long delays, etc. So what we have is a system that uses qualitative taxonomies, typically two to six categories in each dimension. And are fact-based. Assessing a fact in something which has arrived, some request that has arrived, is usually cheap, it's fast, it tends to be accurate, and because of all of those things it also tends to be consensus forming. If you ask four or five people for an opinion on which category in a taxonomy something belongs, they generally give you the same opinion. If you asked them for an estimate, you'd get more estimates than the number of people in the room.
And it allows us to manage risk. So, one of the ways we do this is to assess cost of delay qualitatively, and there's a few people in the room and at this conference are going to talk to you about quantitative cost of delay, which is perfectly fine in circumstances where you can do it and you can get access to real facts to make it possible. But a lot of... of the rest of the time we discovered that marketing people can tell you qualitative information about the utility function of a piece of work. If you asked them for an estimate, you'd get more estimates than the number of people in the room.
And it allows us to manage risk.
So, one of the ways we do this is to assess cost of delay qualitatively, and there's a few people in the room and at this conference are going to talk to you about quantitative cost of delay, which is perfectly fine in circumstances where you can do it and you can get access to real facts to make it possible. But a lot of the rest of the time we discovered that marketing people can tell you qualitative information about the utility function of a piece of work. And though that qualitative information is factual, it is lacking in precision, but it's still accurate. So imagine that we're going to market an Easter holiday campaign for a hotel chain. We're going to launch web pages and emails. When do we need that for? Time on the x-axis. Imagine this is when we need it, middle of January. And if that's true, if we start the email campaign and the web pages, how many extra hotel rooms will it help us sell over the time period until Easter? And the function for that will look something like this. When you get to Easter, surprise, surprise, people start... Stop booking for Easter.
So at the beginning of the campaign, people take time to think what they're going to do. And then gradually they start making reservations, so we actually record hotel room bookings.
What happens if that campaign was not ready in the middle of January? What if that campaign arrived a month later?
Like here. Well, the number of hotel rooms we actually sell might look more like this.
Now, the difference was caused by this delay and the difference in the two curves. From our estimated additional rooms sold to the actual rooms, that is the cost of delay.
Now there's other people who might be at this conference are going to talk about cost of delay as a rate. I'm talking about it as an absolute amount here. Now if we take this red area and we graph it, you get a shape that looks like this over the same time period. It's this S-curve shape. So there's some folks on the conference circuit will keep telling you cost of delay is a rate, like it's a constant. Well, this is not a constant. If it was constant, it would be a straight line. There are times where approximating it as a linear regression is acceptable, and there are other times when it's not.
The shape of this S-curve tells us a lot about when we can schedule something and our sensitivity to schedule uncertainty.
So if we take a look at three variants, this back-loaded function like the one I just showed you, a front-loaded function where you launch a new version of your thing, whatever it is, and everyone wants it at the beginning when it's launched. This happens with seasonal products. Don Reinertsen, if he's in the room, he likes to talk about SRAM, the bicycle component manufacturer. Another case study we have is Blizzard Sport, who make downhill skis. And they launch new products every year. SRAM and Blizzard are about the same time of year, interestingly. And if you're a professional race cyclist or a neo-pro or a high-end amateur, or you're a professional race skier or someone who's perhaps a ski instructor, you take delivery of your new equipment right at the beginning of the season. And then a whole year goes by and then you take delivery of the new equipment again. So the peak in those businesses is on the front, where if you're running a conference, the peak is at the end. And then there are other types of businesses where the adoption is a bell curve. Typical.
New product development, product life cycle, bell curve. And there are other variants. This is not a complete set. Well, it turns out that the ones at the top here are more schedule sensitive than the ones at the bottom. This tells you something about how you might sequence things.
Well, if you have taxonomies like those, you can build up a whole map of them. And with the companies we do this with, typically we find between four and nine of these taxonomies is sufficient. Dimensions of risk each with... With categories on them. And this is actually a map for an ERP project that was done in 2007. And the way this is drawn, the schedule sensitivity of the taxonomy is drawn towards the outside of the picture. So something that plots towards the outside would imply we need to start it early. We need to sequence it first. We need to schedule it early. On the other hand, if it's drawn towards the middle, the implication is that it can be delayed until later. We can commit on it later, we can schedule it later, we can sequence it last.
Well, life would be simple if you did this for your portfolio or your product backlog and you got nice little pictures like this.
The blue one would obviously go first, and the orange one would go second, and the green one would go third, and wouldn't life be just wonderful? How simple it would be to sequence things. A bit like calculating the business value divided by the cost, call that the return on investment, and stack rank everything in a spreadsheet. Believe me, that is complete nonsense. And real life doesn't look like this.
Here's some real life. This is from a company called Bazaar Voice. Do any of you use their service? One hand up, two hands up. So this is only mapping four projects in Bazaar Voice's portfolio at the time when we did it, but the risk profile, the six dimensions, were developed for Bazaar Voice. Four of them are from our standard set and two of them are custom. This one is legal implication with the highest level being class action lawsuit. And this one is the number of end users affected by the project, where the highest level is all Bazaar Voice users, and the lowest level is a single client or a niche market.
These four projects are plotted. The names are syndication, accessibility, something called deploy times two, and then this one is cunningly disguised as executive ask. Because this particular project was the CEO's pet project. The CEO had shown up one Monday morning with a, guys, I've had a great idea type of weekend epiphany. And we have to do it right away.
So risk profiling, the... The senior executives request, it's this pale blue one here.
So taking a look at this, should we do it at all? And if we should do it, do we need to start it now or should we defer it until later? This is a non-trivial thing. There's basically a narrative in this request and all the other ones, and we need to talk about it. We need to have some framed discussion.
And the consequence of this is actually, yes, we should do it, and it's the purple one here that we should sacrifice. For reasons which I'll explain very briefly and very quickly, too quickly maybe for you to fully comprehend in this talk. The category, this category here, is called the market risk of change category. And it divides features in a product or projects in a portfolio into whether they're table stakes for a given market, whether they're differentiating, whether they're copying or catching up, effectively spoiling another competitor's market, or whether they're intended to reduce our costs.
And from this information, table stakes are highly unlikely to change and there's a low risk of rework. Therefore, we can commit to them early, but the key word is can, not should.
While at the other end of the scale, there's a high risk of rework, and we should defer commitment until later, until we've gathered more information, and we're absolutely sure what we want, how we want to implement it.
The risk of rework rises as we go this way and the scheduling goes this way. So we would typically sequence table stakes first and differentiators last. But we don't have to schedule the table stakes first. This particular purple project was table stakes. Everything else is low risk and can be scheduled later. The fact that we can schedule this now doesn't mean we should. So we can defer it. We do the blue one, the purple one waits till later. That conversation might take 15 or 20 minutes and everyone leaves with a consensus understanding. This is a way more powerful approach to scheduling and sequencing work than anything, frankly, I've ever seen in my career.
Now, we discovered this by doing it with people, because there was a time when I believed in this.
You discover that real life isn't as simple as this by actually doing it and seeing pictures like this and then listening to the narrative on how they resolve it.
So that's basically what that amounts to. Sometimes we want to visualize the inherent risk rather than the schedule risk. And that involves reversing some of these. So that this is the picture for the same project, but showing its inherent risk, which is actually lower.
And therefore, relatively low-risk project, although it's major capital expenditure.
When we do it that way, we can use risk to shape the demand. Now, how many of you in the room here work in software? If you have your hand up, do you do bug triage in your company?
Quite a few of you. So you already understand the concept of demand shaping. Triage is the whole business of should we fix the bug or should we just not bother? The just not bothers would be inside this red area on this picture. So each one of these dimensions would represent some different reason for fixing the bug. Like how many users are affected by it, for example.
So, although this is an abstract drawing, we have basically drawn the threshold, and in bug triage, that's known as the bug bar. The bug bar is this line here, and if the bug exists inside this, you don't fix it. Wonderful. Demand shaping threshold. Here's some not so real life situation. Well, number one here, that looks obvious. We definitely do this one.
And this one, well, we're definitely not going to do it. The problem occurs with these ones.
Do you do it or do you not do it? going to have to talk about it. And from talking about it, we'll learn something. We'll learn which of these dimensions we care about more and under what circumstances and how things play off against each other. Oh, and then there's that other very fickle thing of, do we always have our average velocity?
No, we don't.
So there are times where we've got some spare capacity this week because we were going a bit faster, and that means that some of these guys get done. But if it was another week where we really don't have any spare capacity and we're already borrowing from next week, then no, they don't get done. So sometimes it's just timing. Real life is full of a lot of luck and timing. Not everything gets done. And when you're writing books on this stuff or standing on stages and trying to teach people how to do it, There isn't a right or wrong way to do it every single time. There isn't a prescription that works every single time. There is a set of guidance to help you, and then there's narrative. Talk about it. But talking about something in a framed way like this helps you get to an answer a lot quicker with a much higher level of consensus.
So the next thing is forecasting. When will it be done by? Or more accurately, if we know when we need it, when do we need to start it?
Well, what we've learned from Kanban is that tickets moving through a Kanban system follow a Weibull distribution. And if you want more information on this stuff, there's Demetar's talk tomorrow. There's also Daniel Vacanti's talk, but they're back-to-back.
So pick one or the other.
This is a typical Weibull looking curve. This is from one of my clients from last year. We just randomly sampled this from a department I was visiting one day. We pulled it out of their JIRA tracking system. And lo and behold, it's a Weibull distribution with a shape approximately of 1.4.
These are the typical distribution ranges we see for Weibull distributions through Kanban systems. And the important thing to realize about these is the risk is always in the tail. Here's another one. The mode in this data is one quarter of the value of the tail.
85% of these items are completed in 60 days. The tail goes out to 150. The spread of variation is 22 to 150. So when do we need to start something?
Before we get to that question, ESP relies on two main forecasting approaches. The first one is called reference class forecasting, and that part of which I was just showing you. In order to build that histogram, you need to select a period of time to take the data from, and that's your reference class. Reference class forecasting is the technique for which Daniel Kahneman won the Nobel Prize. It's a fairly solidly tested approach. And then there's Monte Carlo simulation. And we tend to use these two in combination. We use reference class forecast distribution curves as part of the Monte Carlo simulation approach.
So scheduling something. Imagine from the cost of delay and the utility function, we know when we need something. We want our Easter holiday marketing campaign to launch on the 10th of January because that's the second Tuesday in January and we always launch marketing campaigns on Tuesdays.
When do we need it?
Well, if we have a curve that looks like this, and the scale on these axes is the same, we can back out from that. And we can say, well, with a six out of seven chance of on-time delivery, we need to start on November the 11th. Imagine that your agile software tracking system could actually give you that advice.
Well, from the middle of this month, there will be a product on the market that can give you this advice.
We can start to study sensitivity.
So what if we only wanted to give ourselves a 50% chance of on-time delivery? That gives us November the 25th.
What if we want to be risky? this and the scale on these axes is the same, we can back out from that. And we can say, well, with a six out of seven chance of on-time delivery, we need to start on November the 11th. Imagine that your agile software tracking system could actually give you that advice. Well, from the middle of this month, there will be a product on the market that can give you this advice.
We can start to study sensitivity. So what if we only wanted to give ourselves a 50% chance of on-time delivery? That gives us November the 25th.
What if we want to be risky? When's the latest we could possibly start? There's some debate about algorithms here. And actually, the algorithm I have built into the slide is not my favorite anymore. But using this algorithm, which says, let's give ourselves a 0% chance of on-time delivery. Now I prefer that you select a number like, let's give us a 15% chance of total failure. That gives you an 85% chance of achieving at least something.
But those two algorithms in this example give relatively similar but slightly different answers. This one gives December the 19th, and it's assuming Christmas and New Year don't happen, so you need to factor that in. because this reference class data probably didn't have Christmas in the middle of it.
And if you do the other algorithm, the let's give ourselves a 15% chance of total failure, you end up with something like December the 27th. Well, with this information, oh, one more thing. What if we want to be absolutely sure the thing will be delivered on time? Well, the answer to that is we need to start on August the 11th with this example data. Well, that gives us a window of opportunity definition. This particular item becomes eligible for selection on August the 11th. Until that, it might be in our backlog, but we do not want to see it at planning meetings. It's just noise. The optimal time to start, assuming we feel that 85% is about as risky as we feel comfortable with, that would be November the 11th, and the last available start date is December the 19th. If we are beyond December the 19th, we should not even bother. That's also known as the option expiry date.
And therefore after December the 19th, we want our system to close that ticket as option has expired and we do not want to see it again at planning.
This type of filtering really simplifies large backlogs. Just show me the candidates that are eligible for selection today. Now show me them based on a particular risk profile to shape the demand. Suddenly we've filtered the thing down. Hundreds of things might be filtered down to 20 or 30. Now let's pick one. That conversation might only take us 20 or 30 minutes. We get to really good quality decision making really, really fast using this stuff. People I know that have 800, 900 things in their backlog can spend two days with 17 stakeholders in the meeting trying to decide what they should do next.
Scaling out across the organization. So we've already talked about this. It's a network and we're going to Kanban each one of these and we have this as a defined approach. We teach it in the basic Kanban system design two-day training class. It's known as static, the system thinking approach to introducing Kanban. And when people come to Kanban training, they learn how to do this so that they can go off and they can Kanban bits of their organization.
And this procedure here that they learn in class tends to be iterative because as you do it, you learn better ways of doing it. Usually the initial Kanban system design isn't as good as it could be. You get better at it.
So we have some simple scaling principles to get from Kanban to enterprise services planning. You scale out in a service-oriented fashion one service at a time. Now, we like service orientation for the same reasons that software engineers like it. What is the advantage of service orientation? Architecturally, from a scaling perspective, it's flat.
That it doesn't require to be a scale-free solution because there's only one level of scale.
That makes the whole idea of enterprise services planning using Kanban inherently scalable because it's flat. The skill is in learning to see your organization as a set of services. When you've been brought up to think of it as a matrix managed portfolio or as a set of functional silos. Different mindset. Imagine you walked into the office with a new pair of glasses and that pair of glasses allows you to see services. Every time you see someone asking someone else for something, you probably just saw a service request. Go figure out what workflow is involved in delivering that request back to the requester and then Kanban it.
So anticipating and managing dependencies, people worry a terrible lot about this. You know what? If you have a distribution curve for this Kanban system here, and there's a whole set of dependencies onto these other ones, that lead time distribution curve already contains the risk of a dependency occurring. And if you use that particular lead time distribution for all your planning, you have already taken account of the possibilities of dependencies. You do not need to plan this stuff deterministically. That will there be a dependency or not? Do we really need to know? When do we need to start it by?
Well, if you're willing to accept 6 out of 7 chance of on-time delivery and therefore a 1 out of 7 chance of some cost of delay being incurred, let's start on November the 11th.
On the other hand, oh no, I don't want to take any risk at all. Well, we need to start on August the 11th. Oh, well, I can't possibly start on August the 11th. That's too early. Okay, so let me get this straight. You don't want to take any risk, and to take no risk, we have to start on August the 11th, but you don't want to start on August the 11th. Yes, that's correct. At that point, we now need to know whether there's a dependency or not.
Otherwise, we didn't need to. to know, because we need to know whether there's a risk of being in the tail on the distribution curve.
So you've seen these slides. We model dependencies on Kanban boards using buffers, the weighting between one system and another. And typically these are unbounded queues. That means there is a long risk in the tail. Well, we might start to gather evidence about how much time we spend waiting. We might develop an SLA with the other group. They become reliable and predictable, and we change our unbounded queue into a bounded one. And the result of that will be that you will massively shrink the tail. In the distribution curve for the first system that calls the second one.
And do we have a dependency or not? We can get most of that information from risk assessment, qualitative taxonomy-based risk assessment. The real key to it is, is there a cheap, fast way of asking a question that will tell you with a high level of certainty, that's the wrong way to put it, a high probability, high confidence level,
that a dependency is likely to exist.
If you believe it's not, you can filter your lead time distribution curve to say, show me the items that don't have that dependency involved. You then get a different distribution curve and you use that to schedule the items differently. And all of this stuff is algorithmic. In other words, you can program it into a piece of software. The software can start telling you all of this stuff.
So how do we make this network start to behave intelligently at the network level, not just the individual nodes in the network, the individual Kanban systems? Well, we do that with feedback loops. And these feedback loops in Kanban are known as the Kanban cadences. And four of these were in the Kanban book written six years ago. And the other three, this one in the middle, it existed, I just didn't write it in the book because it didn't occur to me that it was important. And the other two, the risk review and the strategy review, are things which have emerged over the last few years.
So of these seven meetings, replenishment, Kanban meeting, delivery planning, these are about getting stuff done. Focus on service delivery. Then we have service delivery review, operations review, risk review. And this is about are we doing it right and could we be doing it better? And then over here, strategy review coupled to replenishment and commitment, the selection process. This is about are we doing the right thing? Are we picking the right things at the right time?
By using these feedback loops, our network of services self-levels. In the Toyota literature, they talk about Kanban systems being self-leveling. That only happens if you have human beings as a feedback loop, and it's the same for us. Because you make adjustments, adjustments to WIP limits, adjustments to capacity allocation, adjustments to demand shaping policy, to risk assessment.
You change policy on when to schedule things and how much risk you're willing to take and so on and so on.
We can visualize dependencies, we've seen this slide already.
This is visualizing an integration dependency by splitting columns in a Kanban board into some rows.
And what effectively happens is that our integration point here becomes a fixed delivery date item, an interim fixed delivery date. So the class of service for these, the orange one or the purple one here, will have a fixed delivery date for when we want to enter the integration testing.
This is showing a hierarchical dependency. This is a big project that ran in my portfolio in 2007. Dan Vacanti. was the manager of this project and quite a lot of the stuff he presents is based on what he learned during this time managing. This was an $11 million project. The green tickets are the parents of the yellow tickets. There's a parent-child dependency, so we have five teams building these green tickets, and to do that they have to build the the smaller items which are user stories.
This board's from 2009, client in San Francisco, and they used colored dots to signify different types of dependency.
We can also signal a lot of dependencies on the ticket design. So you could use the color of the ticket, that's unlikely. We can actually show specific service dependencies like graphic design, copywriting, database administration, customer sign-off. Are these required and have they been completed? We can use decorators like you saw in the picture just before. We can use letters sometimes to signify some types of dependency. We can have a progress bar for the lead time. So this might be our SLA, our target date. Each one of these is a day. And when something's blocked, we can use a different color to record the number of days it was blocked. Equally on the blocker tickets, we can record how long did the blocker exist for.
We can show things like interim system integration test dates, as I said, of dates on the ticket. And we can use this information to change the way that we select the queuing discipline that we use for the tickets, effectively dynamically altering its class of service. From time to time. That something enters the system with a class of service, there are periods of time where it has a temporary different class of service as a consequence of risks that we're managing and particularly as a consequence of dependency.
So to wrap this up, a definition of enterprise services planning. The simple thing is you learn to see services and we teach this in our training classes. It's the fundamental enabler. And then you can ban each service and we've had that training class for five or six years. And then you implement the feedback loop system and now we have a new training class called Kanban Management Professional that teaches people how to implement the Kanban cadences. A lot of that concept was modelled on the Toyota Kata.
So we learn to see services, and there's lots of these.
HR can provide services, marketing provides services, IT often called services or Some of them are obvious, some of them are not obvious.
If a senior executive signs off on something, they're providing a service. It's a sign-off service. Sometimes services are individual people. You can have a personal Kanban that represents a service. Sometimes they're just two or three people who work collaboratively. You can have a team Kanban that represents a service. Sometimes it's a whole chain of people who do specialist work, passing the work off between them. It's a workflow. So you get workflow, service delivery, workflow Kanban systems, and they represent services. That sometimes you wouldn't create a board for it, but you still recognize that the person is a service and you represent them as an avatar on your existing board. But the key is recognizing that they are providing a professional service and saying, okay, who was the customer? Who was the requester? What did they ask for? And what are their expectations? What's the service level expectation? How fast? At what level of quality?
With what level of risk management
will make that service delivery fit for purpose. that sometimes you wouldn't create a board for it, but you still recognize that the person is a service and you represent them as an avatar on your existing board. But the key is recognizing that they are providing a professional service. And saying, okay, who was the customer? Who was the requester? What did they ask for? And what are their expectations? What's the service level expectation? How fast? At what level of quality?
With what level of risk management
will make that service delivery fit for purpose.
We can ban the services with the static method, we teach it in class, and then we have a whole class to teach six out of these seven. The strategy review we reserve for our enterprise services planning classes. The reason is quite simple. When attendees at Kanban classes generally do not have the pay grade to affect the strategy of the company, there is no point in teaching them something that they can't do. Where when we hold enterprise services planning classes with private clients, we often get the chief executive or executive committee members actually attending the class. Not every day for the full five days of the whole week, but for the two days that are actually called portfolio management and strategy, we often get the senior executives in the room, and therefore it does make sense to teach how we would like them to be doing strategy review, which is typically different from how they're doing it today.
And this picture really highlights four functions of management. I talked about this as we were passing. There's service delivery, the bottom three boxes. There's driving improvement, which is primarily these two. There's strategy and there's risk.
These are four things that senior executives will strongly recognize and resonate with. Yes, of course, we need to be able to manage service delivery. We need to be able to improve it. We need to be able to manage our strategy and manage our risk.
Our enterprise services planning material is designed to appeal to a senior executive audience. It should sound like something they need, something their business needs, something that's going to help them. The Kanban literature has typically not. Sounded like that and frankly all the agile software development, agile project management literature does not resonate with senior people. It is not aimed at them. And that's a significant problem because we've had to rely on some Gartner analyst walking into the executive committee and saying, what's your agile strategy? If you're not doing agile, you should be doing it.
The people laughing in the audience have actually experienced that Gartner analyst visiting, haven't you?
All right, so of course, senior people will recognize these as higher level management functions. In other words, there's something in it for them. Maybe something that's a little fresher than what they learned in business school.
This is a refresher from last year on Fitness for Purpose. Imagine we're in the pizza delivery service business. We make pizzas. We deliver them to your office or your house. What makes that business fit for purpose? Now, I'm analogously using a physical business here. But we designed the pizzas. Somebody created the menu, some executive chef. We make pizzas. And then this guy here gets on a scooter and he delivers them to your premises. In order to have a successful fit-for-purpose pizza delivery business, we need to be good at all three of these. And what does good mean? Well, we need to offer the right flavours of pizza that the customers want to buy. In other words, they decide what good means. We make the pizza and it has to be hot and tasty pizza. And the customer decides how hot and how tasty, how crispy, all those non-functional requirements. The customer decides what represents good enough. And then how long does it take? take us to deliver the pizza and with what level of accuracy? In terms of your pizza will be there in 20 minutes? Was it really there in 20 minutes?
So how satisfied are people with the selection we offer, how well we cook the pizzas, and how well we deliver them? And if we can be fit for purpose, if we can meet the customer's thresholds for those three things, we will win in the market.
And we teach all of this in enterprise services planning training.
As we went along here, I talked a lot about planning. There are six activities, really. Scheduling and sequencing work, forecasting dates. This says delivery dates, but primarily it's about forecasting start dates.
Expected outcomes, managing the risk, the what if we're not on time, how much of the cost of delay are we going to incur, allocating capacity, managing dependencies, understanding and managing risk, and the last one here, which I don't have time to get into today, ensuring sufficient liquidity so that we can react to unfolding events. Now, if we can do these things competently, we have a very robust, resilient, anti-fragile business that will cope in the face of an ever-changing, rapidly changing external environment. environment.
So in summary, Enterprise Services Planning for us is a five-day training class. This is the curriculum. The black box here is mostly Kanban. The colored boxes are all the other stuff. Strategy, risk management, planning, scheduling, demand management, resilience and survivability. We tend not to use the word anti-fragile with executives, a little scary for them. But would you like your business to be more resilient and survivable? Oh yes, we'd love a bit of that. Particularly with privately held companies where they care a lot more about the long-term future of the business.
You saw these slides before. Anticipating demand, being able to look left, look downstream and figure out where are the dependencies. And to look upstream and anticipate the demand and look at will we have capacity available, will we have the right people with the right skills available at the right time.
Combine those two together and all of a sudden service delivery got a whole lot better. That we're a lot more fit for purpose than we used to be. So, enterprise services planning in four bullets. It's doing the right thing at the right time, the right way with appropriate risk exposure.
In total, if you add the Kanban training, it takes us 10 days to train this into organizations. And we typically deliver that over a period of months.
Next year, we anticipate most of this functionality will be built into software. So the training will be the theory, and the doing of it will simply be learning how to use the software. The software can only ever give you advice. It can only ever suggest, I think you should do things in this sequence, or you should start something at this point, that you should schedule it against this other thing, or you should do these many things in parallel.
Ultimately, you need to make the decision because the software is still a very deterministic ordered domain system and you're operating in a complex domain world. We see risk profiles where it's obvious you should do 1, 2, 3, but for the fact that the government minister who's the project sponsor is really upset with the project manager right now. And number three is really easy to do, low risk, and we can do it quickly. So number three gets promoted to number one. There's no way the software could ever know that. The software will only ever make recommendations. But the reality of enterprise services plan software packages starts in two weeks time with the launch of the product in Munich at the Lean Kanban Central Europe. And with that, thank you very much.