https://orderlydisruption.com/blogs/scrum.atomORDERLY DISRUPTION - Scrum2023-12-29T11:07:37+00:00ORDERLY DISRUPTIONhttps://orderlydisruption.com/blogs/scrum/hypotheses-what-are-they-why-are-they-important-in-xagility2023-12-29T11:07:37+00:002023-12-29T11:07:38+00:00Hypotheses - what are they? Why are they important in Xagility?John Coleman
It is essentially re-wording an assumption or set of assumptions in a way that is put more like a question, or something that needs to be tested,eg.we believe this particular set of assumptions to be true, and we will know if we are right if X happens.
I talk a lot about hypotheses, but what is a hypothesis?
What is a hypothesis?
It is essentially re-wording an assumption or set of assumptions in a way that is put more like a question, or something that needs to be tested, eg.we believe this particular set of assumptions to be true, and we will know if we are right if X happens.
With hypotheses, it is important that you decide how you are going to measure whether the hypothesis is valid or invalid.
We do not want to be just trying things. That is kind of like what we call “whack-a-mole” where you are whacking the moles in the funfair and just reacting. In that context, you are not thinking systemically.
What should you consider when you have a hypothesis?
We want you to be considerate when you have a hypothesis:
what assumptions are we testing?
what do we expect to happen?
If that happens, what do we take from that? (I guess, we validate or invalidate the hypothesis).
The importance of building evidence
So in the same way that we have hypotheses for product development, product management, and service delivery — not all of our ideas are good ideas and we need to build up some evidence whether these are the right ideas or not.
This body of knowledge that I am sharing with you is essentially a set of hypotheses. With hypotheses, I need to see if when you replace one behavior with another, will it actually make a difference? It would be lovely if we could have pure cause and effect like that, but in complexity, it’s not so simple. It would be difficult to do randomized controlled trials with something like this.
I have consulted with well over 40 people in Agility and Executive Leadership and there is some form of alignment that these might be good hypotheses. I would really like your support in gathering evidence on whether some of these hypotheses are valid or invalid so we can improve the overall series of behavioural replacements.
I am not telling you that this is a recipe. Some of these things might work, some of these things might not work. On balance, we are saying try these things. We are saying avoid some of these other things. What I will be doing later in this series is I will be re-wording each of the behavioral replacements as a hypothesis. So, hopefully, by seeing each of these behavioral replacements as hypotheses, you will understand that this is not deterministic. We do not know for certain what will happen. We have strong feelings and opinions, but just like in Product Development and Product Management, opinions are one thing, evidence is something else.
What I would like you to do is to come on this journey with us and see what evidence we can acquire together.
Thank you.
]]>
https://orderlydisruption.com/blogs/scrum/where-does-scrum-master-end-and-agile-leader-begin-differences-similarities2023-12-13T14:21:00+00:002023-12-13T14:23:09+00:00Where does Scrum Master END and Agile Leader BEGIN? Differences/similaritiesJohn Coleman
They’re very similar. I think the key difference really would be: the leader leads the way in terms of direction and then creates the space where that might happen. A leader is understanding that it is not just about delivery, that two-thirds of things are rarely or never used and so maybe we should be trying to have a heat-seeking missile to find the value in the market and maybe use cheap experiments so we do not lose our short and massive bets.
Before we talk about the comparison and contrast between Scrum Master and Agile Leader, people often compare and contrast Scrum Master and Agile Coach, and they often ask me, what’s the difference?
The oversimplified answer is $200 per day because a scrum master should be working at an organizational level. The oversimplification comes from assuming that people have to do scrum. Of course, they might use some other approaches. However, I think in the current setup, scrum is the most popular approach (rightly or wrongly) in the market. If an “agilist” is unfamiliar with it, I think it says a lot.
That said, people can use other approaches and a decent scrum master should be aware of such approaches. They should be well versed on product management, design, other agile and lean agile approaches.
As a scrum master, you should not only have scrum in your toolbox. Scrum.org offers a scrum with Kanban workshop and scrum with UX workshop as well. This demonstrates that they are open to other approaches.
Let us go into the conversations that you might have whether you are a leader, a scrum master, or an agility coach. A friend of mine said to me years ago, that he used to draw a line, and:
at one end of the line, he would draw a little circle and say, give answers (as in give advice, when asked a question, give the answer).
at the other end of the line, he had another little circle saying, ask questions (in other words, I want you to ask me questions so that I find out the answer for myself).
This “sliding scale” approach to coaching defeats the notion that “professional coaching is a bit binary”.
My friend used to say to people:
where do you want to be in this conversation?
do you want me to ask questions?
I think there’s actually a triangle.
You could be a mentor;
You could be giving answers; or
You could be asking questions/you could be educating people.
For all of these, my position is, that I want to ask for permission.
Tom Mellor gave me a tip some years ago, he said, “John, don’t ever give advice unless people ask for it”(He was giving me advice when he said that, so there was a bit of a paradox there) but I appreciated that tip.
In other words, let us not inflict help on people.
People might want you to give advice. Typically, when people are less familiar with agility, they expect answers. As they get more agile, they expect to be coached (maybe), to find the right answers for themselves.
When you as a scrum master or leader detect that the people in front of you aren’t aware of some additional options, where essentially they do not know what they do not know, what I would do in that scenario is I would ask for permission to just go into a 10 or 15 minute teaching moment.
I tend to base my conversations on pull, not inflicting help on people, inviting, not imposing, asking for permission to either give advice, to ask questions, or to educate.
What do I expect a Scrum Master or an Agility Coach to do?
Disclaimer: This would be like a 2021 personal opinion in terms of what a scrum master should be doing. I think the nuance you might see here is the focus on understanding product management and design more.
Observe and Listen
The first thing I would expect is that you would observe. You would listen and you would learn about the domain as well (the technical domain, maybe also the business domain).
Do not be so quick to jump in with solutions, particularly in non-software, and non-tech. There can be a tendency for people to jump in, and a lot of the Agile approaches were designed for software.
Be careful about assuming that it will just work in any other domain. You need to understand the context and learn (I’ve had people teaching me about rock pressure, for example, when I was working in an oil company).
Help your team to continually improve, you are on the hook for their effectiveness
The second thing is, you should be helping the team to continually improve:
If they are using Scrum, your team will probably be doing retrospectives.
If you are doing some other kind of Lean Agile, you might be using Kaizen, where you agree to continually improve or continuously improve.
Regardless, there should be improvements. Encourage that improvement.
In the 2020 Scrum Guide, the Scrum Master is actually on the hook for the effectiveness of the Scrum team. So if the team is not improving, we can look at the Scrum Master.
Accept that the situation that you are in will have its own “washing instructions” and deal accordingly
The other thing I would say is, from a Cynefin Sense-Making point of view, you need to accept that the situation that you are in will have its own washing instructions. I love the “washing instructions” metaphor from Pia Maria Thoren used when I interviewed her on the Xagility podcast. People have their own washing instructions. Teams have their own washing instructions. In other words, you treat them differently. They do not all use the same approach. They might not even all use scrum, for example.
From a a Cynefin Sense-Making point of view (if you are not familiar with Cynefin, maybe just Google Cynefin executive and a video will come up where I explained it in 15 minutes), there are five domains there. Depending on which domain you are in, you might want to act differently. So accept that the situation will have its own reaction type.
Fix problems
A scrum master should be fixing problems, but I hope people in the team are fixing their own printers. I hope the team has already tried to fix the problems they’ve come across. Once the scrum master takes this up, we really are trying to fix that problem (remove that impediment, as we say in Scrum) and they never give up.
The Scrum Masters that irritate me are the ones who give up. They just accept that things are crap around here and they do not continue to improve, and then they just become part of the problem rather than really trying to help. They are just getting into the mechanics rather than really trying to improve.
You are not really agile if you’re not improving, if you’re not fixing problems.
In one context, I had two teams and when I onboarded them to support them, they expressed a desire for me to help them. I discovered that each of those teams had an impediment that was seven years old. That is not a good sign. I was all over those issues like a rash. People were wondering what was going on as this had been like this forever. It is not good enough. So as a scrum master, I would be all over that.
Facilitate conflict
Scrum masters should be facilitating conflict. If there is healthy conflict, that is fine because we want people to find the truth, the right idea. If there is unhealthy conflict and people are making personal comments to each other and getting a bit emotional and talking based on principles and so on, that’s not so good. As a Scrum master, you need to be managing that, facilitating that conflict, I would say, and also facilitating a purposeful rhythm.
Be rhythmic
You get teams where people would say “ah well, such and such was on holiday this week, we should do a retrospective next week instead”.
They’re just excuses. There’s always somebody on holidays or something going on, so just be rhythmic, really, about your events, whatever events you have. If it is Scrum you’ve got the daily scrum every day, if you’re planning that day, you still have a daily scrum. Be really rhythmic about that.
Facilitate team decisions
Facilitating team decisions when teams are struggling to make decisions, not being the chairperson, but facilitating the discussion so that we can be fruitful. You might pull out six thinking hats out of your hat, for example, to help the team unlock some decision-making and also as a Scrum Master facilitating large groups.
Facilitate events?
I do not really expect the Scrum Master to be facilitating the events. Maybe the retrospective is the only one and even then that might be rotated amongst the team members. I think a good scrum master should have large group facilitation skills, and probably should be familiar with liberating structures, open space, lots of innovation games, and so on, different ways of making sure that we can be productive as a large group.
Don’t be focused just at team level
The scrum master should not be just focused on the team level, they need to be working at an organizational level, team of teams, teams that we interact with, and so on to make sure that the issues that are beyond the limits of the team are being dealt with, that we are not just accepting processes that are incongruent with agility.
We are trying to either delete or change some of them so that there is less friction. Scrum masters should be broad and deep, focused on outcome oriented agility, not just pure feature factory-type delivery. They must be clued into what is going on in product management design and also technical (I would say).
While a scrum master does not have to be technical as per the Scrum Guide and LeSS (large scale scrum), we prefer the scrum master to be technical to have more credibility in terms of what is going on and understanding what is actually going on.
Avoid
A few things that we would probably like you to avoid as a scrum master/ agility coach are:
not being a kind of police person;
not being a secretary or admin;
not inflicting help on the team;
not being the chairperson; and
not being a superhero.
These are things that we would discourage in a scrum master.
We need to move past agility being about delivery. It was never really all about delivery, but it has become misunderstood as that. So discovery, the focus on discovery is going to be crucial as we move forward.
That’s the scrum master or agility coach.
What about a leader? It’s quite similar actually.
Observe and Listen
Still observe, still listen. Except maybe we expect you to go a bit deeper in terms of observation. Go see and really see what’s going on.
Acquire knowledge and fix problems
Acquiring knowledge about what is going on in the system. Focus on still fixing problems. A leader has more power to fix problems. Again, the leader needs to be (I will not say use situational leadership because that has a meaning) accepting that the situation will have its own “washing instructions” just like with the Scrum Master looking at what Cynefin domain we are in and thinking about which way we react accordingly.
Scout for unmet customer needs, new customers, new products
A key difference I would think between a Scrum Master Agility Coach and a Leader would be, that the Leader would be scouting for unmet customer needs, would be scouting for new customers, new products, and they would do that through discovery.
A good scrum master would support this, but a really good leader would understand that most ideas should never be born. We should do experiments to assess whether some of these are really going to fly or not, and even then they might not fly, but we try to use evidence to inform our decision-making.
Be a performance coach and be technical
A leader should be a performance coach, not just in terms of individuals, but in terms of teams, helping the teams to be more effective. A good leader would be technical and would understand what’s going on. So if they do not really understand the technicalities of what they are doing, (particularly if people’s lives could be at risk), my view is that a leader should be technical.
Be a gardener
A leader is a gardener. They are trying to cultivate the environment for agility, and they might be changing or deleting processes and workflows that impede agility. It is very similar to a scrum master in that regard, just that the leader is more of a gardener, whereas the scrum master is trying to convince the leaders (convince is probably the wrong word)/ encourage leaders to be gardeners. So almost like the coaches for the leaders.
Inspire
A leader should inspire, which would be another difference as well. A scrum master or agility coach would inspire from the point of view of why we are doing agility — understanding you are trying to get alignment in the organization about why we are doing agility and then helping teams to figure out what way they can achieve that and encouraging self-management and so on.
A leader should:
inspire herself and others; and
co-create the direction of travel — where are we going; and
be a catalyst for what we call aligned autonomy.
So encouraging autonomy and teams, but also alignment. Alignment behind some kind of direction that we are going in. So very, very similar.
Create new leaders
In addition to that, you have “creating new leaders”. A really good leader will create new leaders without leadership actually being a position. There would be promoting self-management, promoting self-designing teams, focus and flow.
You cannot really have flow if you do not have prioritization. So focusing on:
prioritization;
having less backlogs;
encouraging the backing of the Scrum Master when we are trying to be really rhythmic about our events and so on;
promoting improvement (the opposite of complacency);
promoting people being comfortable with being uncomfortable. That maybe we don’t know when we’re going to deliver. Maybe we need to be living with a probabilistic forecast, which still might be smoke and mirrors, but a lot better than a cast iron guarantee we will deliver by a particular date and then get a ransom note one month beforehand saying we need another 5 million.
promoting backstage leadership;
promoting people being technical and promoting data informed decision making.
Consider stopping
The things that I would not say not to do, but maybe consider stopping would be:
pushing work into teams before they are ready. They will pull it when they’re ready. I am not saying never do it, but it’s something you should consider stopping;
giving 100 percent guarantees when it will be done;
focusing on precision and perfection. Sometimes good enough is good enough. Context matters and so on, but just be careful about that;
again, not inflicting help, although sometimes as a performance coach, a leader will need to step in;
the broadcast communication type style and maybe focus more on two way communication between people. So really trying to understand what is actually going on, be careful about that. Just ensuring that you are really trying to listen to what is actually going on;
not being the superhero;
big bets — so you could win big, but you can also lose very big. So try to focus more on experimentation, discovery, figuring out whether we’re on the right track, rather than putting a massive bet saying we’re definitely on the right track.
So what does the Scrum Master/Agility Coach do? And what does an Agile Leader do?
They’re very similar. I think the key difference really would be:
the leader leads the way in terms of direction and then creates the space where that might happen. A leader is understanding that it is not just about delivery, that two-thirds of things are rarely or never used and so maybe we should be trying to have a heat-seeking missile to find the value in the market and maybe use cheap experiments so we do not lose our short and massive bets.
Even if we have loads of money, we can be making even more money, and have much happier customers if we try to laser in on the customer and meet customers.
The focus on inspiration in terms of direction, scouting through discovery and meeting customers, and also basically being a gardener, they would be the key differences, I would say.
But then the Scrum Master/Agility Coach would be encouraging the leader to do exactly that under the organizational wide change agent responsibility that I have pointed out in this particular article.
So they are, what I see as the key differences between Scrum Master, agility coach and a leader.
Thank you.
]]>
https://orderlydisruption.com/blogs/scrum/scrum-how-long-should-your-sprint-be-single-vs-multi-scrum-teams2023-12-05T17:42:16+00:002023-12-05T17:42:17+00:00Scrum: How long should your Sprint be? Single vs Multi Scrum TeamsJohn Coleman
Did you ever notice that a lot of scrum teams are having two-week sprints? Is that the right thing to do?
A lot of people say we need to be consistent, we need to have the same sprint length so that we’re all on the same rhythm, etc.
I think there is a fundamental problem with that.
Why would you have every team having the same sprint? There might be some situations where that would be valid. The first thing I would say is, let’s just start with a single Scrum team.
A single Scrum team working on a product because Scrum is for product development, not so much for project management. This team is delivering a product.
How long should their sprint be?
Single Scrum Teams
I wouldn’t be going for the most popular sprint length. I would be asking a few questions, most importantly, how long does it take you to deliver a done increment?
How long does it take you to deliver a done increment?
Do you have a decent Definition of Done (DoD)?
In Scrum, we have a definition of done (DoD). This is like the checklist for how we do things around here. This includes the quality standards and maybe with elements of product quality in there as well. Technical standards and product quality.
Assuming a decent Scrum team has a definition of done, one which the team respects (because if they respect it, they can then have some hope of continually improving it), how long does it take them to deliver a done increment?
How long does it take them to deliver a done increment?
If it takes them three weeks, well, maybe you should have a three-week sprint. I do not see the point of having a two-week sprint for a team that needs three weeks to deliver a done increment.
If it takes you three weeks to get something to done (according to the definition of done) we do not want people taking any shortcuts with that. We do not want people building up accidental technical debt or making the product increment a lower quality. On that note, stick to how long it takes to deliver a done increment.
Does it take longer than 30 days to deliver a done increment? Make your product backlog items smaller, here’s how
Now, where it becomes problematic is where it takes longer than 30 days to deliver a done increment. In that case, I think you have got bigger problems than the length of your sprint. You probably have issues with the product backlog items that you’re taking in, they are probably too big. Then you probably need to be looking at some kind of splitting guides.
There are lots of heuristics out there in terms of how you can break some items down. Failing all of that, you can use example mapping from behavioral-driven development, where maybe you list out 25 examples for this product backlog item that will be needed by the time you go live. In response to people saying “We can’t deliver this in a sprint, it’s going to take six weeks, we can’t deliver it in 30 days”. I say “Can you just do the first example?”
“What do you mean? We know we have to do the second and the third example as well”.
“Yes, I know, but you can just do the first example?”
Let’s just get some feedback and see how we get on with the first example because the Sprint Review is like an event where people find out what they don’t want when they see it. People struggle to articulate what they want.
Consider example mapping as a technique to maybe get the item size a bit smaller so you can do things in 30 days. I had a chat with Tobias Mayer on the Xagility Podcast and he challenged me. He said we can always do something in 30 days. I think the man is right. I think you can do something in 30 days.
There’ll be some rare exceptions where that’s not the case. So one consideration is have you got a done increment? How long does it take you to deliver a done increment?
Dealing with Product Owners injecting change into the Sprint
Another consideration would be the product owner changing his/her mind about what needs to be done and injecting change into the sprint. Now, it is possible. You are allowed to bring change into a sprint. You are allowed to introduce product backlog items during the sprint, as long as you’re not compromising the sprint goal. But people don’t do that because normally we don’t have enough evidence to say that we’re not going to compromise the sprint goal.
So unless you are using Scrum with Kanban, you will not have the information to answer that question. As such, we tend to avoid bringing changes in during a sprint, and we probably want to keep it that way so the team can be focused, so they can get what they started finished and we can get some feedback sooner.
If you have a situation where you have a four-week sprint, you can deliver a done increment in three weeks and the product owner wants to put change in, if you change your sprint time from four weeks to three weeks, what you’ve done is you’ve changed the average wait time for a new sprint from two weeks down to a week and a half.
Ordinarily, I would say a product owner will probably be willing to wait a week and a half on average. It could be the wrong end of the sprint, in which case the spring goal might be obsolete and that’s a different story. I’ve only had one of those occasions in my career. So I would say the length of your sprint should be how long does it take you to deliver a done increment?
Other considerations for how long your Sprint should be
Also, maybe how long does it take you to do customer user research, maybe UX, and so on? Maybe you want to get some response from prototypes, interviews, all that kind of stuff. So there’s that consideration as well if you’re using Scrum with UX.
But for most Scrum teams who are not so much into experimentation (I wish more were into experimentation), then you would ask “How long does it take you to deliver a done increment?” and no shorter than that so that the product owner has maximum flexibility, so when new changes come in into the product backlog, there’s an opportunity to bring those into a sprint sooner because the next sprint planning is going to be sooner.
It’s not as straightforward as that though, because most of us don’t work in single-team products. We’ve got multiple teams working on the product.
What do you do then when you have multiple teams?
Well, the scaling frameworks that I am most comfortable talking about are Nexus and LeSS.
Nexus
In Nexus, if, say, for example, the overall product group had a four-week sprint, it’s fine for some teams to spin around inside that with a one-week sprint or a two-week sprint or for slower teams, a four-week sprint.
As long as you’ve got the same boundary that, in other words, the multiplication needs to work one, two, four, one, and three, they would work. So you could have faster teams spinning around faster within the Nexus Sprint.
Why would you have a team that could deliver stuff in a week, being stuck to a three-week sprint? Nexus allows you to do it that way.
Large Scale Scrum (LeSS)
On the other hand, in LeSS, the entire product group has the same sprint length. So if we all have a four-week sprint, every team has a four-week sprint, or they have a three-week sprint or two-week sprint. Whatever the sprint length is, we are all doing it at the same time.
That’s not a bad reason, you don’t want a situation where you come looking for help in my team and I’m not available because I’m in sprint planning for my team. That problem is avoided when every team does their events at the same time, including product backlog refinements being done at the same time in LeSS.
So there, I can see the upside of that where everybody would have the same sprint in that case, but I would hope that no team has a sprint length that’s shorter than it takes them to deliver a done increment. As such, be careful, I would say, about having this default position of just having two-week sprints because it’s the most popular sprint length.
Concluding Remarks
I think the first question you should be asking is, how long does it take us to deliver a done increment? It should be no shorter than that. If you’ve got problems delivering within 30 days, you’ve got bigger problems than the size of your sprint. You have got problems with your product backlog refinement.
Meanwhile, consider example mapping, consider maybe looking at the first example to break down part of backlog items so they fit into smaller sprints so you can deliver a done increment in a shorter period in 30 days or less.
First of all, what is meant by release planning? (An old-fashioned term, but we’re still stuck with it).
What is “release planning”?
What people mean by “release planning” is trying to forecast when we will deliver certain things when certain releases might happen, and we might not know for sure what’s on those releases.
In Scrum, the product owner will decide when the releases are but might not know for sure what will be on those releases. In fact, because of so much uncertainty, the real answer is we don’t know. We don’t know what will be delivered, what functionality will be delivered, and we don’t know when we will solve particular problems.
We’re dealing with so much uncertainty. BUT we do make some efforts sometimes to figure out when certain things might be delivered, and the most useful way that I have found to do that is using Monte Carlo Probabilistic Forecasting.
Navigating uncertainty: What is Monte Carlo Probabilistic Forecasting?
When using probabilistic forecasting, one option is to essentially guesstimate as a team how small and big the backlog might be for a given goal/release.
I like to say, give me a 90% chance you’re right, 10% chance you’re wrong kind of guess. Give me a range. How small could the product backlog be? How big could the product backlog be?
You could also guesstimate how few items you deliver in a sprint and how many items you deliver in a sprint. I prefer to do it based on data — so if you actually have some data in terms of what was delivered in a sprint, that is really forecasting because if you don’t have data in terms of what you’re delivering, you are still just estimating.
Estimates are just estimates. They’re not commitments. Scrum has moved on. Check out my InfoQ article onSizing & Forecasting in Scrum.
Even forecasts aren’t commitments. We are so used to getting weather forecasts that way, and we’re used to the uncertainty in the weather forecasts. We understand that it can be wrong; the same is true for product development.
Using Monte Carlo Probabilistic Forecasting & Throughput
You can use Monte Carlo Probabilistic Forecasting, you can use commercial tools, or you can use free tools. Random numbers are generated between how small the backlog might be and how big the backlog might get, and the min/max of throughput for the relevant period is (how many items you deliver in a sprint to how big the throughput gets per sprint).
Throughput = how many items you deliver in a (time period, e.g., a) sprint to how big the throughput gets
You might even look at the median of throughput as well as min/max in some tools. Great tools consider the work already in progress.
EXAMPLE:
Say maybe 10,000, maybe a million simulations are run. From that, you get a projection of different dates when it’s likely the work will be delivered by different dates.
Side note: avoid picking the middle because that’s like 50–50 heads or tails, a 50% chance of delivery based on the data. But ACTUALLY you’ll find it’s not 50–50 because we know we’ll have a different forecast next week; things will change.
So I like to say if I don’t get 50–50, I go more to the right-hand side of the histogram forecast. Maybe 70%, 85%, let’s say the 85th percentile — I’d say 85% chance that we can deliver by that date.
That means a 15% chance we can’t, but I’ll give you a better forecast next week, which essentially means we don’t know. It’s just a nice way of calculating it.
You can also do this as well based on relative positions on the product backlog, but we also know that the backlog could change. At a sprint review, new ideas are usually much better than the old ideas, so it’s like a new set of clean plates on top of the old plates in a restaurant. Those old plates get pushed down, and so items lower down the backlog get pushed down. Consequently, the items on the backlog might get pushed further and further away.
But if people are concerned about particular items in the backlog, it might never happen. This is because those new ideas are usually better than the older ideas, and we do want to be chasing value.
The best thing we can get with a traditional approach is what we asked for. The best thing we can achieve with an agile approach is something much better because the sprint review is where the customer or end-user gets to see what she asks for but doesn’t want. We give them frequent opportunities to figure that out.
Where is the best place to look at the forecast?
The best place to collectively look at the forecast with stakehodlers would be the sprint review. That’s because the stakeholders, including the customers and the end-users, are at the sprint review.
You can also look at a few sprints ahead in sprint planning, BUT that’ll be private within the team because stakeholders aren’t invited to sprint planning. We might have some technical experts that are invited to give us some extra knowledge in sprint planning, but if you want stakeholders who are trying to understand what’s going on with the product AND they want to understand when things will be done, THEN those stakeholders would attend the sprint review and maybe some other ad hoc sessions.
BUT in Scrum, there’s an event called Sprint Review, and out of the four inspect and adapt events, the sprint review might be the best place to review what’s going on, where we’re going, whether it’s time to trim the tail due to diminishing returns, and move onto the next product goal.
Burn-up charts: are they in or are they out?
There is another option as well — quite an old-fashioned approach in Scrum. Burn-up charts allow us to look at how we’re doing, how much work we are burning, how many items we are finishing, and so on. Then you can draw a trend line. You can say, well, if that trend keeps going, and you could have a scope line across the top and where those lines meet, the trend of what we’re burning against the scope line at the top. Then you drop it down to the calendar date in the future, and you’ll see that we might deliver by this date.
But that’s 50–50 heads or tails. It’s not very good. And remember, we’ll have a better forecast next week. So it’s actually under 50–50, really.
Depending on how much noise you have in your throughput as the team, how many items the team is delivering will kind of dictate the gaps between the optimistic and the pessimistic lines of the burn-up chart.
Concluding Remarks
I find burn-up charts to be quite dangerous because people tend to see what they want to see. Optimistic people will see the optimistic line; pessimistic people see the pessimistic line. It’s difficult to get people aligned. We also call this the cone of uncertainty, where there’s a gap between the most optimistic date and the most pessimistic date for a given amount of scope if you like.
The word “scope” is alien to Scrum as well because we are trying to fix problems and avail of opportunities, not deliver outputs. We’re trying to deliver value. We’re trying to deliver value as quickly as possible to discover the value sooner.
So forecasting and release mapping can be done as part of scrum, which is a typical practice. I’m nervous about roadmaps other than Now, Next Later or Transformation Maps with elongating and more vague timelines. The Product Goal is in the direction of travel, and we discover through good empiricism if the goal is wrong. There is a human tendency to persevere instead of pivot or stop when the evidence is compelling. We should not persevere. Give Scrum its due; the Sprint Review is a great opportunity to pause and reflect if the Product Goal is still worth pursuing.
My preferred approach to forecasting is Monte Carlo Probabilistic Forecasting.
One health warning with Monte Carlo Probabilistic Forecasting is if the throughput of your team is irregular, if your team is maybe not delivering so often, or if the team has sprints where they don’t deliver anything, or the team is delivering everything on the last day of the sprint, for example, the quality of your Monte Carlo Probabilistic Forecast is going to be less because from a statistical point of view when it’s looking at your historical throughput, most days you deliver nothing.
So that will not be a great forecast, but if you have problems with your forecast with Monte Carlo because of irregular throughput, you’ve actually got bigger problems with forecasting; you got a plumbing problem. You need to fix the plumbing problem before you’re worried about your forecasting problem.
Never ever use flow metrics for sub-tasks. We’re maximizing potential value, not activities.
Thank you.
]]>
https://orderlydisruption.com/blogs/scrum/the-product-owner-product-leader-product-manager-and-the-scrum-accountabilities2023-07-15T09:30:00+01:002023-07-17T09:32:08+01:00The product owner, product leader product manager and the scrum accountabilitiesJohn Coleman
Explore how Product Owners, Product Leaders, and Product Managers align their efforts, leveraging their unique perspectives and skill sets to drive product success. Learn about their interplay in agile environments and how they contribute to creating customer-centric, market-leading products.
I welcome product managers and product leaders to the session in my product owner classes. However, there are differences between product owners, product leaders, and product managers. When people come to my class, I’mnotteaching them about product management or product leadership. I might introduce them to some concepts in the same space, but I would not want people to believe that I have taught them about product management or product leadership.
Marty Cagan, with his Silicon Valley product group, has a great set of workshops to help people understand more about product management and product leadership.
Preliminaries
What does a product leader do? (At least my understanding of what a product leader does)
When thinking about a product leader, I want you to imagine a situation where:
we have a product, a vehicle for delivering value;and
that is recognized by the customer or end-user i.e., that you understand what it is, and when you mention it, they know what you’re talking about;and
they pay for it, either with their money, their time, or their data.
Somebody is producing it, and somebody is consuming it.
So if you have:
a real product;and
that product is externally facing, just like I mentioned;and
if you have multiple teams working on that product…
…you are going to have a situation where you might have multiple product managers.
If you had product managers working in teams, the product manager might act as a developer and a team.
A tech lead from a product management point of view would operate as a developer from a Scrum point of view. The design lead would act as a developer.
From a Scrum point of view, there’s a bit of tension between Scrum and product management because, in Scrum, there are no defined roles.
That said, Kanban and Kanplexity are other options to consider to avoid that tension.
In a multi-team situation, if you have product managers and teams, you still only have one product owner from a Scrum point of view, and you probably only have one product leader.
There’s a lot of overlap.
Below is a Venn diagram of the accountabilities in Scrum and then overlapped on top of the product leadership responsibilities.
Product Leader
The first thing I want to note is that the product leader operates in the problem space and the discovery space.
Product leader also gets involved in discovery to deliver.
What do we mean by the problem space? Many people ask what’s the point in delivering if you don’t understand whether you haven’t discovered whether we can actually get that value, whether people actually want that.
But even discovery is mute if we’re looking at the problem through the aperture of a solution, as Indi Young would say.
Sometimes you need to understand more about what problem we’re trying to solvewithoutwanting to make it sound like we’re doing any big design up front or anything like that. We do need to make some effort to really understand the problem, and the product leader is really strong in that space.
For example, they might have:
something like a briefing document in terms of explaining, e.g., there’s a one-pager explaining what problem we’re trying to solve and what the options are, etc.
a business model in the product or a class. We often make a lean canvas, for example, and we often make a customer value proposition. Those two concepts are really from the product management space.
speak the lingo. It’s not good enough to be good. We need to be perceived to be good. Do we really understand the lingo of our stakeholders in other departments in the company and also our customers and end users?
a roadmap. And would be very comfortable showing a roadmap, maybe over a number of years.
The product leader would also act as a performance coach. I like what Marty Cagan says “A product leader is only as good as her worst product manager”.
Product Manager
So the product manager is somebody who needs to be performance managed, just like every developer on the team needs performance management.
Further, there’s a product wall as well, a concept from product management where you go to one place where you see all sorts of information about what’s going on with the product.
The product manager, in particular, will be looking at the customer analytics, product backlog management, even though it’s owned by the product owner, would typically be delegated to developers in a very good scrum team.
Product Owner & Product Leader
There are some things that a product owner would do that a product leader would also do. For example, creating a vision in product management. I don’t hear much talk about protocol, but in Scrum, there would also be a protocol, which would be an intermediate step toward the vision.
If there was a vision, and I guess that’s sort of aligned with the whole idea of a strategy as well. The strategy is, “You want to implement that vision, and the product goal could be one step towards that”.
The product owner, just like the product leader, would maximize value and manage expectations in relation to uncertainty. They bring lots of market knowledge and would be killing products.
That was one of the first things that Steve Jobs did when he went back to Apple. He killed lots of products so that the organization could be really focused. The product leader and proper product owner would scout for unmet needs, try to understand satisfaction gaps, and, most importantly, say no.
There are other aspects as well, like inspiring people. That means you need to be inspired yourself. You need to observe, you need to listen, you need to learn, you need to improve, and you need to be able to support the whole notion of self-management. But the scrum master will be helping you with some of these inspiring people, observing, listening, learning, improving, and self-management.
The scrum master would also help the product leader in terms of the following:
facilitating team effectiveness;
being an agility mentor;
being a complexity coach;
acting as a change agent;and
removing impediments.
In addition, developers and product owners would also take on some additional responsibilities. If you had one, the product manager might be taking on some of these ideas in the set of developers on a scrum team.
I would be expecting if you did have that triad Marty Cagan refers to of:
tech lead;
design lead;and
product manager.
If you did have that kind of responsibilities within a Scrum team, those people could really do a very good job of leading on that product management and facilitating the situation where the rest of the team really has a common understanding of what it is we’re trying to achieve, how we’re going to solve problems for customers and end users, and how we are going to avail opportunities.
Product Owner
Don’t get stuck in doing all the time; pause to think
There’s a lot of time to think as well. Be careful that we don’t do it all the time. Don’t always focus on delivery. There’s also discovery.
Think about what we need to do; the developers, the product owner, and the product leader will be focusing on what we are actually going to deliver that’s going to deliver on the why. That vision and the strategy to implement that vision, which might be implemented partly through a protocol.
Focusing on the “how”
In addition, developers would focus on the how. The product manager, tech lead, and design lead, from a product manager's perspective, would be very involved in that.
They would be involved in sizing with the rest of the developers in the team, and they would make sure they deliver a done increment.
Concluding Remarks
In Scrum, there’s a definition of done, and I hope that when product management and Scrum merges, the whole concept of done doesn’t get squeezed out like mustard out of a hot dog when you try to take a bite out of it.
So the developers on the team, of which you would have a tech lead, design lead, and product manager from a product management perspective, would build and deliver it.
In addition to this, the product needs to be supported.Butone of the things that Scrum would do that I don’t see mentioned so often is product management is the whole idea of a sprint goal. The sprint goal and the product goal are mandatory in Scrum.
]]>
https://orderlydisruption.com/blogs/scrum/struggling-with-project-management-challenges-kanplexity-might-help2023-06-26T10:00:00+01:002023-06-30T09:55:26+01:00Struggling with project management challenges? Kanplexity might helpJohn ColemanMore]]>
Here are three primary challenges that traditional project managers and project management have that complex Kanplexity solves… yes, you read that right, it SOLVES.
1. FLOW
Traditional project management is more about resource efficiency than flow efficiency, and the Kanban aspect of Kanplexity can help you to:
improve your throughput;
reduce how long things take (cycle time);and
improve how much time we have to think.
So that we can actually come up with much better ideas and better satisfy customers.
I think by keeping people busy, a lot of traditional project managers end up actually shooting themselves in the foot and not delivering stuff sooner.
We can get some feedback earlier. You don’t even have to be using something like Scrum to do that. You can, using Kanplexity and the Kanban part of Kanplexity, you can find out and get feedback from your customers much sooner about what’s really going on.
So improving the flow, and improving feedback would be one of the challenges.
2. How do you react to challenges?
We’re dealing with an uncertain world and challenges get thrown in front of us every single day. What do you do and how do you react? A lot of what we do is we react the way we always did.
If you’re big intoprocess, you might think, if you change the process, everything’s gonna be fine.
If you’re verytechnical, you might think if you just have more people working on the problem, we’ll get it sorted.
If you’re apoliticianor battlefield commander, you might say, let’s just get everybody in the room, we might sort it(which is actually a very good way of dealing with a complex problem).
If you’re dealing withnegativechaos, you might say, well maybe I need to turn into a dictator and tell everybody what to do so that we can sort things out.
The thing is that if you do what you always did, your mode of action will probably not be appropriate for the situation that’s in front of you.
What we need is some tool that will help you to figure out what is the right course of action. The Cyenfin sense-making framework is used in Kanplexity as a compass to help you to figure out what’s the next right thing to do. If your normal approach is to get everybody in the room, but actually Tom and Ben are the experts of this particular issue, we just need Tom and Ben to figure this out together, we don’t need everybody else. They know what to do. It’s complicated but they’ll figure it out. They’re the experts.
If it’s a situation where Ben knows what to do, he’s been doing this for years, we just trust him to get the job done, and nobody needs to work with him. He just needs to crack on and do it.
But if there’s a situation where actually we don’t know what we don’t know maybe just relying on the experts won’t solve it, maybe we need some fresh thinking from another person to freshen up the way we’re thinking about a particular problem. Perhaps have a different perspective on what kind of problem it might be because it might not be the problem that we think it is.
So flow and earlier feedback (see point 1 of this blogpost) and also having a compass to help you to figure out what you do next is an orientation reference in the Kanplexity guide for exactly that reason.
What do you facilitate?
What do you optimize for?
What do you measure? What do you focus on measurement-wise?
3. Figuring out what to do as a leader when you are dealing with a project
The third challenge is, if you think of Scrum for example, there really is no home for you in Scrum as a traditional project manager. I’m a Scrum trainer myself. The standard answers are you can be a developer on the Scrum team. You can be doing the work. You might be very good at, for example, dealing with compliance stakeholders, the work that needs to be done as part of the product backlog. So you can do that. You can be a developer.
Or maybe you’re actually making some product. You could be a product owner, but the danger of that is if you don’t switch your mindset from short to medium-term time, budget, and scope to long-term customer value thinking more about owning the product, not just project, but the product, you actually conflate the words project and products as though they are the same thing.
You might be the wrong person to be a product owner. If your style tends to be more micromanagement, you might not be a very suitable scrum master. Now, we probably wouldn’t want you to be micromanaging in any case, and we probably would want you to balance the short term with the long term, but what’s really nice about Kanplexity is it gives you a guide about what you do as a leader when you’re dealing with a project. There’s actually a description for a responsibility, where there’s an agile leader that acts as a guide and you don’t need an artificial role like scrum master or product owner to move things along.
You could argue as a project manager is also an artificial role, but you have someone who is a leader who can help the team to figure out who can help, who can understand how to read that compass. Who can understand well what way the flow is working and help the team to become more effective. You can still get out of the way but you’ll be operating much more like an agile leader.
Kanplexity gives you guidance on exactly what you need to do, what you need to be focused on.
So how can we improve that flow? How can we get quicker feedback?
How can we read that compass to figure out the right thing to do?AND
How can we give you the knowledge so that you know how to read that Compass?
Kanplexity.
]]>
https://orderlydisruption.com/blogs/scrum/should-a-scrum-master-become-a-product-owner2023-04-25T10:30:00+01:002023-06-30T09:59:28+01:00Should a scrum master become a product owner?John Coleman
Short answer: no. But let me explain why.
Scrum Guide
There isn’t anything in the scrum guide that prohibits this. But it’s probably not very wise.
Scrum Accountabilities
In Scrum, there are three accountabilities:
developers→ the people doing the work, delivering a high-quality done increment.
2. product owner→ maximizing value.
3. scrum master→ looking after the effectiveness of the scrum team.
So what’s the problem?
When the scrum master who’s looking after the effectiveness of the scrum team starts to wear the hat of maximizing value, conflict ensues.
This could lead to a situation where the developers and the team deem it that the person who is now a Scrum master product owner combined, has a lot of power and needs to be followed.
There might be less inclination from the developers to have healthy conflict because the person who is the Scrum master and product owner has a lot of power.
It’s something I advise against, but it is possible. In the same way, you can actually have a Scrum team of one person if you want to.
But is that really a team?
It’s Scrum master, product owner, and developer in one person.
Sometimes I say the best team is one person because you’ve got fewer communication channels, you can just do everything yourself.
I’m being ridiculous because we all know that you usually have more than one person in a team, and you’ve got people working together towards a common objective to try and avail some opportunity or to solve some kind of problem, together with the customers.
So I don’t advise it.
Let’s go through all possible combinations
Technically, you are allowed to be scrum master and product owner. You are allowed to be a developer and scrum master. You’re allowed to be a developer and product owner. You could be a developer and scrum master, and product owner.
But how effective can you be?
Exploring the Scrum Master Role
There’s a lot of work in Scrum Master.
Michael James has a lovely expression:
Agoodscrum master can look after three teams. Agreatscrum master can look after one.
There’s a lot of things that a scrum master is expected to do, but it’s misunderstood.
A lot of people misunderstand that the scrum master is like a jockey, they’re doing reporting and booking meeting rooms, essentially acting like a coordinator, almost like an agile project manager.
There is no agile project manager in Scrum, and so a lot of people expect the Scrum master to be doing these things. These are misunderstood stances of the scrum master.
What the scrum master should be doing is:
observing through listening, sensing, smelling, whatever senses they’ve got available;
mentoring, giving advice, coaching, maybe asking Socratic questions teaching, coaching, mentoring, with permission. Don’t inflict help on people;
acting as a change agent;
keeping an eye on the scrum implementation;
working with the rest of the organization to help them to understand how scrum and agility works; and
removing impediments that are beyond the control and influence of the team.
That’s a full-time job.
Exploring the Product Owner Role
I’m okay with the product owner refining product backlog items but not writing them.
The product owner does not clarify requirements. The product owner clarifies problems to be solved and maybe opportunities that we want to avail of.
The product owner introduces the developers to the customers and end-users, and other stakeholders so they can clarify what they were looking for.
The importance of checking in
Just by checking in with our customers and end users and other stakeholders, we can reassess whether we’re on the right track and what problem we’re trying to solve.
Ensure you are not just following the prescription of what someone thought a customer wanted at some point in time.
The product owner really should be doing a lot of work in product management;
Product ownership;
Commercial pricing;
Looking at customer analytics;
Visiting customers; and
Managing the expectations of stakeholders, and connecting with them. Managing their expectations in terms of uncertainty. Setting their expectations that we don’t know when we will be done. We’re committing sprint by sprint. We’re using an iterative, incremental approach. We’re trying to work empirically here.
We can use statistics like Monte Carlo probabilistic forecasting to have an idea when a particular amount of outcomes might be done, but actually, we don’t know. We’re just going to continually re-forecast and so on.
So there’s the big job there from the product owner to manage the optics and perception.
Why shouldn’t scrum masters be product owners?
Product owner is a big job. Scrum master is a big job.
In my opinion, it’s like mixing Scrum master with developer. What I often see is when a developer is also a Scrum master, the Scrum master becomes the poor cousin. The person tends to do the misunderstood stances of a Scrum master and not the expected ones.
They do what people want them to do instead of what they should be doing, instead of acting like an ambassador for what Scrum is.
You can but shouldn’t.
Thank you.
]]>
https://orderlydisruption.com/blogs/scrum/how-will-ux-and-design-thinking-influence-how-executives-fund-product-development-in-the-future2023-04-05T18:00:07+01:002023-04-05T18:00:07+01:00How will UX and Design thinking influence how executives fund product development in the future?John ColemanPredicting the unpredictable is difficult. But if I had to guess, I would say experiments are very much in.
Why? Because we need to stop building things we do not know if our customers/end-users even want. Gather that data and then decide how to move forward. Pay particular attention to slide 5, you'll see what I mean.
Design thinking has been around for a while. UX has been around for a long time.
Human-centered engineering was being talked about even when I went to university a long, long time ago, but it seems that the world has cottoned on to the whole idea of discovery.
UX
In UX, one of the patterns is Lean UX from Joshua Seiden and Jeff Gothelf. There’s a couple of different versions of design thinking out there. One from Stanford and one from IDEO.
All pretty much have the same ethos:
How can we really fill the funnel with work in product development when we don’t have that much confidence that we’re going to get the value?
Treat ideas as assumptions to be validated
A lot of the time people build business cases for some piece of product development, that they’re going to earn so many millions, that they are going to build it in this market. All sorts of wonderful things.
Really clever executives treat a lot of the ideas as assumptions that need to be validated.
In particular, the Lean Start-up started this maybe 10 or more years ago by saying what is quality if you don’t know who the customer is?
One more time: what is quality if you don’t know who the customer is?
The idea was why would you build a high quality, full-fledged product? Why would you fill your funnel with all that stuff when actually we haven’t validated whether people actually want that idea, whether they want that product?
Minimum viable product (MVP)
People have used minimum viable product as well, and it has become a little bit distorted.
It has turned into:
what is the worst product we can deliver in the timeframe?
INSTEAD OF:
what’s the least amount of work we need to do to learn the next most important thing?.
The learning revolution in the sea of agility
I think learning is the big change. I see a wave in the sea of agility at the moment from delivery to discovery to delivery or discovery to not delivery, to find the ideas that you should not build.
One of the reasons why the Lean Start-up came about was as a reaction to the .com bubble burst.
10 years before Lean Start-up came out, people had been raising loads of venture capital money and burning loads of money. I remember people used to have bragging rights for how much money they raised and burning hundreds of millions of dollars.
The idea when the Lean Start-up came along was why do you have to burn all this money? Why don’t we just do really cheap experiments to figure out if people even want this?
Why don’t we just do really cheap experiments to figure out if people even want this?
Are these the right customers?
Are these the right users?
Will they pay for this?
Maybe the price point that we have in mind is $15 but the customer may only be prepared to pay 15 cents, or maybe they want it to be free.
Maybe it’s the wrong solution. Maybe the market isn’t ready yet. Maybe we need to do something more complete.
If you have lots of evidence as an executive that we should build this product and all the ideas within the product, you should just build it.
But the reality is that there will be lots of ideas in your product where you won’t really have that much confidence about whether you’re going to harvest the value.
They might seem like good idea. But as an executive, you do not want to put those ideas out there and it’s like crickets and tumble weed and nothing happens. You’re left wondering why did customers not come to my product?
The modern approach
These days executives need to:
be talking more regularly to customers, end users;
visiting all the markets; AND
Seeing customers in the eye.
I know we live in a distributed world now, but going out, visiting people, really understanding what’s going on beyond the Teams and Zoom calls, try to get informal conversations where you really find out what’s going on.
Understand what the customers are really looking for and listen to what customers are complaining about, ask better questions like what are your coping strategies at the moment? Do you have viable workarounds?
When customers complain about things, that doesn’t necessarily mean they need you to deliver a solution. We have lots and lots of ideas but I think between 60 and 90% of those ideas should never be built. You will discover lots of better ideas by accident if you run cheap experiments to find out… is there value here?
Between 60 and 90% of those ideas should never be built.
Experiment example
The guy in Zappos who wanted to figure out if women would buy expensive shoes online. He built a beautiful website. It was lovely, but there was nothing behind it. When somebody ordered, he just received an email, went out to the store, bought the shoes, packed it up in Zappos packaging and sent it off by FedEx to the customer.
He didn’t lose his shirt, he didn’t burn millions building a big fulfillment system.
He did validate the idea.
Women with expensive taste and shoes did buy shoes online and they didn’t just return them after parting one night. They were honest and there was a general pattern of ethical customers buying high quality products, branded products on his website.
Concluding remarks
These are the kind of experiments you need to do before you lose your shirt or your blouse.
Do some really cheap experiments to validate those ideas. It’s the way of the future.
For me, Scrum.org has a wonderful class called Scrum with UX. My most popular class actually, it’s a lovely way of discovering those ideas that you don’t need to build.
Kanban is about delivering things faster, optimize the delivery of value.
But you can even optimize it more by not putting more things into the funnel. You can use UX and design thinking to discover those ideas you should never build.
Thank you.
]]>
https://orderlydisruption.com/blogs/scrum/are-you-giving-your-people-the-time-and-space-to-learn-and-improve-the-9-9-rule2023-04-04T10:40:51+01:002023-04-04T10:40:52+01:00Are you giving your people the time and space to learn and improve? The 9@9 rule.John Coleman
Executive leaders, try giving your people time to learn 9 minutes at 9:00 AM daily. Give them the space so that they don’t have any meetings booked in their diary.
Executive leaders, try giving your people time to learn 9 minutes at 9:00 AM daily. Give them the space so that they don’t have any meetings booked in their diary.
What does it look like in practice?
For the first 15 minutes of every day, they get time to grab a cup of tea/ coffee, and they sit down and watch a video for nine minutes. They’ll read some articles.
9 minutes at 9 am every day and get people into that habit. Give people permission to do that.
Why giving 4 hrs weekly may not work…
I hear so often about these programs where you give people 4 hours a week to do learning.
The problem? You give them 44 hours of work in a 40-hour week.
Theyneverget time to do that learning, and that’s why you are responsible for the personal development of your people.
Aren’t we all responsible for personal development?
Unless you give people the space, it’s not going to happen. They need the slack to learn.
That means you won’t have them planned for all the hours of the week. You’re going to give them nine minutes at 9:00 AM. That is my suggestion.
Thank you.
]]>
https://orderlydisruption.com/blogs/scrum/where-can-scrum-not-be-used2023-04-04T10:37:24+01:002023-04-04T10:37:25+01:00Where can Scrum NOT be Used?John Coleman
The background
The 2020 Scrum Guide was a major departure for Scrum in that most references to software development were deleted from the Scrum Guide.
The only reference that even hints at software development is the word Developer, one of the Accountabilities in Scrum.
The 2020 Scrum Guide was a major departure for Scrum in that most references to software development were deleted from the Scrum Guide.
The only reference that even hints at software development is the word Developer, one of the Accountabilities in Scrum.
The Accountabilities
You’ve got:
Scrum Master;
Product Owner; and
Developer.
The meaning of ‘Developer’
Developer in Scrum just means anyone:
Doing the work to deliver a Done Increment; or
Helping with the discovery to discover what we maybe should deliver.
Before you try it in your domain, think about this ONE constraint
Scrum could be used in all sorts of domains, but I would not be so arrogant to tell you it can be used in any domain.
It has been used and you can try it in pretty much any domain, but there would be one constraint holding back Scrum or holding back your ability to do Scrum: if you cannot deliver a done increment within 30 days.
Can you deliver a Done Increment within 30 days?
Scrum is designed for complex product development and for breaking down large problems, large opportunities in smaller chunks, but also not just doing work breakdown, actually doing experiments to discover better ways to deliver value to our customers, to our end-users, to the organization, to society.
If you cannot break down the work so that you can deliver value within 30 days, you will struggle with Scrum. I do see some people using Scrum to express, I saw it only this week, for example, in a team who was so predictable in their flow.
I was looking at their flow analytics and I could see that they had wonderful flow, but I smelled a problem and the smell that I got I think isn’t far off what’s really going on. I suspect the team is breaking down the work so it just fits within the two-week chunks, but actually, those two-week chunks do not deliver value.
That is not Scrum.
What does the Increment need to be?
Scrum is about delivering value, about discovering value, and the increment needs to be:
valuable;
useful; and
usable.
If you cannot deliver an increment within 30 days, I don’t think you can use Scrum.
Alternatives
There are some frameworks like Large-Scale Scrum (LeSS), for example, where you have another variant called Less huge, and it can be a struggle to deliver a done increment within one sprint within one month with many, many teams. They have coping strategies for how you can improve your definition over time, even over a number of years. Large-Scale Scrum (LeSS) does have a pathway to help you to use Scrum even if you cannot deliver value within days, but that’s in a huge scaling situation.
Consider example mapping to see if one example out of say 21 can be delivered in a sprint, in order to get feedback if we’re on the right track.
For a single-team Scrum, or even for Scrum up to just a number of teams, like eight or nine teams, you should be delivering value every 30 days.
If you can’t do that, I don’t think you should do Scrum. Maybe check out complexity instead, Kanban for complexity (Kanplexity).
Thank you.
]]>
https://orderlydisruption.com/blogs/scrum/the-1-question-to-figure-out-where-you-are-in-the-product-life-cycle2023-04-04T10:31:19+01:002023-04-04T10:32:36+01:00The 1 Question to Figure Out Where You Are in the Product Life CycleJohn ColemanDid you know there is a pattern between where you are in the product life cycle and the kind of complexity you are dealing with...
Where is your product in its lifecycle? AND how that could overlap with the complexity of the work that you’re dealing with?
How old is your product?
In the Cynefin Sense-Making framework, you’ve got:
The Ordered Space → here you have clear work where people can follow recipes, they know what to do, and they should just do it. Complicated work where you can just bring the right experts to bear or you can do more analysis to figure out what to do. You can essentially get access to the right expertise.
The Clear Space → tends to be more about products that are in the latter stages of their life because we really know everything that needs to be done about the product. We’re kind of almost on automatic pilot at this stage. A lot of stuff is automated with our product.
The Complicated Space → you might have quite a mature product, so we understand what needs to be done. We don’t have a recipe for everything. We might need to do some analysis. We might need some experts to get together, but if the right people get together, they’ll figure out what to do.
The Complex Space → it’s more likely that we’re still in the early stages of product development. We might be crossing the chasm, for example. We might be trying to move from early adoption to, getting greater deployment in the market. We are looking for opportunities to twist some previous inventions, ideas for new purposes, for new problems, and we’re trying to get some fresh thinking so we can figure out a way to overcome the latest problem and deal with the latest situation.
Positive chaos → I refer to positive chaos as being near the border, the liminal between complex and chaos, and that’s where we do really want innovation. But this is very early stages, almost start-up stages where we don’t even know what the product might be, who the customer might be, and what the right solution would be. There are so many dimensions that we’re innovating on that it’s a bit chaotic but in a positive way.
Negative chaos → You can end up in negative chaos from any part of your product life cycle. You could assume, for example, that something is clear when the product is towards the end of its life, but you’ve actually made a drastic mistake. You’ve been overconfident or you could assume that something that’s complex is predictable. We can do a Gantt chart for that and off we go.
A pattern between where you are in the product life cycle and the kind of complexity you are dealing with
I just want to illustrate that it’s not linear and the way I’ve just described it, isn’t as simple as that. It’s not a categorization system.
But there does seem to be a pattern there between where you are in the product life cycle and what kind of complexity you might be dealing with.
The Aporia/Confused Space
Cynefin is like peeling an onion — the more you peel away, the more you understand that you don’t understand.
But one of the important things in Cynefin is the aporia/confused space because you can deliberately go into aporia and you can try to figure out:
Are we in the right space?
Are we taking the right approach?
Do we actually need to go into a different space and act differently?
Thank you.
]]>
https://orderlydisruption.com/blogs/scrum/product-owner-coping-strategies2022-12-12T12:58:52+00:002022-12-12T12:59:30+00:00Product Owner coping strategiesJohn Coleman
Are you a product owner? Do you need some coping strategies? Here are two tried and tested strategies. First, become a developer and use the notion of a product owner helper from large scale scrum. Secondly, have a speak now or forever hold your silence meeting.
In a previous blog post, I talked about different categories of product owners. You can check it outhere.
But here’s a summary:
Scribe— doesn’t add any value, just takes orders.
Proxy— who maybe doesn’t just take the orders, maybe adds some value in terms of assessing whether what the customer’s asking for is really the right thing to ask for. What problem are you trying to solve? What opportunity are you trying to avail of? It is trying to understand the problem that’s trying to be solved instead of just taking a list of requirements like a scribe would.
Business representative/organization representativeis someone who is more closely connected with the stakeholders within the organization to have more influence.
Sponsor— has the money.
CEOof the product (entrepreneurial/intrapreneurial Product Owner)
The Scribe & Proxies concentration
Most product owners in the world are scribes or proxies.
Some of them are also business representatives.
All three of those lack power, although a business representative will have more influence.
So what do you do?
Coping Strategy 1: Become a developer
You could become a developer on a team because in Scrum, for example, there’s only one product owner for a real product.
What is a product?
Something that an external customer or end-user would recognize;
They pay for it with their: time, their money, or their data; and
Somebody consumes it, and somebody produces it.
In the case of a real product, there’s only one product owner. So if you are a team-level product owner within a multi-team product, one thing you can do is become a developer.
The role of Large Scale Scrum (LeSS): Product Owner Helper
Another thing you could do is take a little tip from large scale scrum, LeSS. They have this concept of a product owner helper.
Personal Opinion: We need to do some work on the title cause it’s not very appealing.
Application
The idea is that you might be able to help the product owner across the product so that if all the value is on Vanesa’s team, but you were previously on your own team looking at your filter of the backlog, were working on really low-value work because that’s what your team did instead of learning what was most valuable for the product, what was most valuable for the organization.
If you act as a helper across the product, supporting the product owner, that:
At least reduces the damage, and it means we still have one product owner;
The product owner is getting some assistance; and
You’ve got a view of what’s happening across the entire product.
Coping Strategy 2: Speak now or forever hold your silence meeting
Another coping tactic that I tried a few years ago that was really successful was what I call a ‘speak now or forever keep your silence’ meeting.
It was a situation where the product owner was a proxy. So the first thing I did was I asked for the product owner to be seconded over to the business.
Now, this is in a situation where there was IT and business. You could also have it between supplier and organization, for example.
We asked the product owner to be part of the main organization in terms of where decisions get made and so on.
That helped, but the person still didn’t have power.
The second thing we did we arranged a speak now or forever keep your silence meeting.
What happens during a speak now or forever keep your silence meeting?
The stakeholders were invited to this meeting, and the product owner, with no power, said, this is what I’m planning to prioritize in the next sprint.
Speak now or forever keep your silence; in other words, let’s debate now if you disagree with these decisions. Do not pull the rug from under me during the sprint, saying you disagree with these decisions.
Because as soon as the developers and the team realize that I actually don’t have the right priorities as a proxy, then they’ll just make up their own priorities.
And then we’re all losing.
So the coping tactic would be to have a speak now or forever keep your silence meeting and have the ranging debate within that session.
If the list changed, that’s fine, but at least you come out with a list that has been agreed with all of the stakeholders or agreed with as many as possible cause some stakeholders you can’t agree with, sometimes we need to say no. Do your best to come up with the best set of priorities.
The bottom line
Even though you don’t have power, you just bought power for a couple of weeks because you had a session where you asked people what the right order was, what the right list was, and what the right sequence was.
You came up with the best possible list. That’s a little coping tactic.
]]>
https://orderlydisruption.com/blogs/scrum/different-types-of-product-owners2022-11-11T10:47:42+00:002022-11-17T00:52:48+00:00Different Types of Product OwnersJohn Coleman
What are the different categories of product owner? This blog post outlines all the different types of product owners as well as the characteristics/pros and cons of each by considering them against the definition of a product and how you may deliver value.
Join me as I also bust a common myth: product management being taught at product ownership classes.
In Scrum, we have a product owner. It is an accountability, it’s no longer a role according to the 2020 Scrum guide.
There are different categories of product owner:
scribe
proxy
business representative
sponsor
CEO of the product.
The Scribe Product Owner
A scribe is like a really poor waiter in a restaurant. They take your order even though they know that you should not order what you are ordering.It’s probably the worst thing on the menu, and the chef does a terrible job of that dish.
A scribe just takes your order regardless, of whether it’s a good or a bad idea, they don’t add any value.
The Proxy Product Owner
A proxy is maybe someone who is like a waiter who’s taking your order but realizes that you’re ordering the wrong thing or it’s not a really good thing and in a very polite and diplomatic way, they might say, well, sir you probably should look at this dish, we’re recommending this as a special.
They add more value however they still don’t have any power. It’s usual for a proxy-type product owner to be a person who might be a very good person. I’m sure they’re a very good person, but they don’t have any power. The person with the power just couldn’t be bothered doing product owner roles so they’ll delegate it to somebody else.
A lot of product owners are actually proxy product owners quite sadly.
The Business Representative Product Owner
Then there’s business representative which is slightly better than proxy. Some organizations, believe it or not, segregate IT from the business or one department from another department.
In the case of an IT situation, the product owner who was a proxy working in IT because they couldn’t get a representative from the business, maybe now they’ve been seconded into the business. Even better, someone from the business has decided or has been asked to be a product owner and that person is in at least the right network to have more influence, but still doesn’t have any budget.
The Sponsor Product Owner
Then there’s the sponsor, which is the person who actually has the budget for the product, including:
the total cost for the product;
the whole life cycle;
running the product or the service; and
improving the product or the service.
The CEO of the Product
A person who can take risks, who can basically decide whatever they want to do in relation to the product, but they work in a very data-informed way.
What experience tells me
The best product owners I’ve ever worked with, I only had access to them maybe 10 minutes a day, sometimes only every second day, and the same for the developers and the team.
The reason we were so effective is because when we asked the product owner questions, she knew the answers. She didn’t have to:
“Oh, I’ll check with this person”.
“Oh, I’ll check with that person.”
“Oh, I need to align with these, align with those”.
They just gave an answer.
Sometimes they did still need to do alignment offline, but they manage that themselves because the biggest job of a product owner is to connect with stakeholders and manage their expectations in relation to uncertainty and basically say no to a lot of things and say, you might get these things.
“the biggest job of a product owner is to connect with stakeholders and manage their expectations”
Managing uncertainty & Creating the Vision
Managing the uncertainty about maybe when those things might be delivered. That’s the biggest job really for the product owner.
What’s our vision? Co-creating that vision, but maybe creating it and, and then making sure everyone’s inspired.I like to co-create, but you don’t have to as a product owner.
The product owner will continually update that vision, that direction of travel, and that goal in consultation with the stakeholders, the customers, and the end-users.
They’ll meet the customers and the end users a lot to inform their decision-making. They’ll walk the Gemba of value consumption. They’ll really understand what’s going on. They might even be mature enough to just witness what customers are doing without asking them leading questions such as:
“what do you think of this”
“what do you think of that”
Maybe just seeing what the customer plays with.
John Carter, when he spoke to me about his work at Bose, mentioned that they bought a music store in the city where they operated. And they just observed what people were buying, what they were picking up.
They didn’t say, here’s a shiny new product. Here’s something we’ve been innovating on and we’re really excited about it. They just wanted to see if anybody would notice it.
That’s how they innovated. They listened.
I had the pleasure of interviewing John Carter on the Xagility™podcast — the episode goes into a lot of depth on innovation and how we market innovation. Listen to the episodehere.
Indi Young would say, you deeply listen to your customers.
I had the pleasure of interviewing Indi Young on the Xagility™podcast — the episode discusses why we should not look at a problem through the aperture of a solution. Listen to the episodehere.
Most product owners are scribes or proxies
Most product owners in the world are either scribes or proxies, at best they’re representatives of the business if you like.
Most people who order my classes are in that situation, and when they come to me for product owner training, they come with a couple of myths.
Myth:Product management is taught in product ownership classes
One of them is that in the product owner class we teach about product management.
We don’t.
We do show some practices that are practiced in product management, but we don’t delude people into thinking we’re teaching them about product management. We just say, here’s a window, here’s a door. You need to find out more about this.
A coping strategy is if you are a proxy or a scribe or even a business representative, become a developer on the team.
Only one product owner in Scrum for the entire product
We only have one product owner in scrum for the entire product.
What is a product?
The product typically being a vehicle through which we deliver value but’s essentially what an external customer would buy with their:
money;
time; or
data.
Somebody consumes the product or service and somebody produces it.
So if you have a product, a real product, and you have multiple teams working on that product,we just have one product owner.
How team product owners create separate backlogs
What I see typically is we’ve got people acting as team product owners, and when you’re a team product owner, what tends to happen is you tend to look after your part of the backlog. Even if it’s all a big list, actually you just look at one filter of it. So implicitly you’ve got a separate backlog.
So I might not even see what’s more valuable on Vanesa’s backlog, and everybody would know that what Vanesa’s working on is much more valuable. But because I’ve just my own little filter of the world, being a team product owner, I just do what my team does instead of doing what’s most valuable for the company and learning how to deliver what’s most valuable for the company.
So team product owners, product owners growing like flowers. It’s a typical anti pattern in companies.
In Scrum, there’s only one product owner.
The product owner owns the product.
If I was just to do a very quick comparison with product management here,I’m going to do another post on this to go into more detail.
The comparison between product owners and product managers/leaders
A real product owner is very similar to a product leader in product management.
It’s fine to have a product manager per team because a product manager doesn’t necessarily own the product, although context is king.
If you’ve got one team, it might be the same person, but in a multi-team context, which is a situation for most products, you can have a product manager working per team and the real product owner looking after the product is the equivalent of a product leader in product management.
But I will talk more about that in another post because product managers/product leaders do much more than what we do in product ownership.
]]>
https://orderlydisruption.com/blogs/scrum/can-scrum-be-used-outside-software-development2022-08-03T10:21:12+01:002022-10-26T19:41:34+01:00Can scrum be used outside software development?John Coleman
Can scrum be used outside software development? Absolutely.
There's something very important though. In terms of credibility of you as a leader or as a coach or practitioner working with people in non-software, there is a brand that goes along with a lot of agile folks that they’re working software and they’re preaching to people outside software for ways of working that might not be suitable.
And there is merit in that argument. I’ve often worked in cases in non-software where I might have had 10 options that I would consider for the team. But actually, when I understood the work more, I reduced that down to maybe two or three options. And so it’s crucial that if you’re working in non-software and also I would argue in software you need to learn the business domain.
You need to learn the technical domain. You need to understand what’s going on. It just doesn’t lead to credibility when you don’t understand the work that people are doing when you don’t understand how the work flows and what problems people have with the work. Often we don’t know where the real wall is.
A lot of agile coaches, and scrum masters think when people are resisting some of the ideas that we’re presenting, they think that we’re presenting a fake wall that there really is no barrier that, the person they’re thinking hasn’t been opened or not. But often I find there actually is a wall and the sooner we find out where that wall is the better, and that wall can be discovered. If you understand more about the business domain and the technical domain, you understand what the team is doing. you can absolutely achieve that. You can achieve agility outside non-software but you need to understand the work.
And then you need to think about what would be the right strategies, frameworks, methods, or values and principles that you can use to demonstrate agility in that area. Scrum often struggles in this area because, in non-software in particular, work items tend to take longer than 30 days. And what I see happening a lot is people break down work items to fit within 30 days because they want to deliver something in 30 days.
But if you’re delivering something in 30 days that actually is invaluable and it’s not even contributing to value, not even enabling value, we lost the plot. Then I would prefer a team in that situation to use something like Kanban it takes two months to get the work done.
And then we look at how that value is being contributed. And you can also look at Kanban for complexity, for example, which allows you, to have, and encourages you to use reviews when you’re working in complex work retrospectives when you’re working in complicated work reviews also in positive chaos.
Standups also, when you’re doing complicated or complex work and you can have a rhythm, you can have cycles equivalent to the sprints. For example, don’t necessarily need to be restricted to four weeks. You could have longer than four weeks cycles for reviewing how things are going on in non-software.
But what I often find is once the agility improves in non-software, we do actually find ourselves in a space where we do get work items done in 30 days. It’s just initially we don’t have to be careful about trying to break work down to 30 days or less when maybe it doesn’t make sense. You’re not really delivering value at that point.
You have to weigh up what’s the right thing to do. Sometimes it’s good to bring in some frameworks like scrum, for example, because people understand it, they can work with it, they can get trained and then commoditized way on it and so on. But if you’re using a framework or method or a strategy in a way that isn’t really suited to the way it was designed you could do more damage and you could lead to people getting into this plan versus the actual mindset where they think we’re gonna break down the work items to fit within a sprint. And it just becomes breaking down the work like work breakdown structure, using scrum, for example. And that’s not something that I recommend equally, by the way, you can do Kanban badly as well, visualizing rubbish on the wall and not even visualizing all the rubbish on the wall and not limiting work in progress.
Kanban done professionally is about limiting work in progress and having policies about how the work moves through your system. And there’s a lot of discipline involved in Kanban a lot of discipline as well in, design thinking, lean UX, lean startup, all these other approaches, and you can even make up your own approach.
In fact, in one of the first teams that I worked with was a non-software team, I did make an approach. That’s how Kanplexity™ got invented. It was because a team had a cycle time for the work items of four months or longer. And I felt we couldn’t use scrum. I also felt that the values of the team weren’t compliant with the scrum values.
So I came up with something different called Kanplexity™. So it is possible. And with other skilled practitioners as well, they could come up with their own approaches as well. However, I would say to you, if you just stick to values and principles, there are different schools of thought out there about this.
Some people can operate based on values and principles. I’ll find at very large companies, two-thirds of people need some rules. They need something to follow. Of course, if you can have less rules, that’s better. I find in practice that some kind of framework or strategy or method does help a team to make some progress.
It reduces the number of choices they have to make. If you can operate purely based on values and principles, all the better for you just be careful that it could lead to negative chaos. Just make sure that the people that you’re working with, they are in that space of where they can truly operate based on values and principles.
So can you be agile outside non-software ? Absolutely. Just be careful.
]]>
https://orderlydisruption.com/blogs/scrum/when-will-scrum-die2022-07-28T17:34:26+01:002022-10-26T19:40:49+01:00When Will Scrum Die?John ColemanWhen will scrum die? Some people would say it's already dying. There's so much inauthentic, scrum being done, unprofessional, scrum being done in the world. Whereas scrum is part of what I call water scrum fall, where it's put within a predictive deterministic system. We're predicting when work will be finished.
When actually we’ve got so much work that where we don't know, what we don't know, that's really unauthentic. I see in those situations where the concept of done isn't even a concept there They think that done means we met the acceptance criteria when actually it's almost like the checklist for how we do things around here, the technical standards and the product quality standards, international standards, for example, that we might need to comply with.
Some people would say it’s already dying. There’s so much inauthentic, unprofessional scrum being done in the world, whereas scrum is part of what I call water scrum fall, where it’s put within a predictive deterministic system. We’re predicting when work will be finished when actually we’ve got so much work that where we don’t know what we don’t know, that’s really inauthentic. I see in those situations where the concept of done isn’t even a concept there. They think that done means we met the acceptance criteria when actually it’s almost like the checklist for how we do things around here, the technical standards and the product quality standards, international standards, for example, that we might need to comply with.
I would argue that scrum is dying, but also I’ve been very encouraged by the level of authentic agility that’s growing as well. I’m seeing some very advanced practitioners coming to my PSM two class. For example, I’m really inspired by the people who come and sometimes they feel a bit down because they’re within a system where they’re expected to do things that they should not be doing.
They’re expected to create dashboards. They’re expected to coordinate between teams. They’re expected to manage what’s going on. They’re expected to be delivery managers to come and practice now where you’ve got the delivery manager. Where the scrum masters are actually on the hook for delivery, not just the effectiveness of the scrum team. When they go through the PSM two classes with me, what they notice is that, oh we’re not supposed to be doing these things.
What we’re supposed to be doing is observing. And with permission, coaching, teaching, advising, acting as a change agent, working with the organization, working at all levels, helping the management and executive leaders to cultivate the environment in which agility can really grow. And I send them away from PSM two saying I want you to be ambassadors for what a scrum master should really do so that when people are looking for scrum masters, when they’re hiring them. When they’re wondering what a scrum master should be doing, you’ll be telling them what a scrum master should be doing. And if the scrum master’s on message, it improves the chances that the product owner is a proper product owner, not just a team product owner, which is the typical failure mode that I’ve seen, because there’s only one owner for the product.
You might have product managers within each team, but you wouldn’t have product owners within each team. We’ve been moving away from business analysts acting as product owners. Business analysts are very good professional people, but from a scrum perspective, they are developers. They’re people who do the work cause in scrum ‘developer’ means someone who does the work.
And so what you prefer is that we have a more authentic scrum where there’s more UX, we’re starting to see more UX people in scrum teams working. Along with everybody else in the scrum team where discovery and delivery are part of delivering the work where we’re discovering that maybe 70% of the ideas in our backlog should never be built.
And then we’re finding much better ideas that we should build on. So it’s almost like we’re a heat seeking missile out for value and finding where the real value is. And so the aspects of scrum that I really have hope for or where teams are not just delivering they’re discovering to deliver, they’re discover to delivery teams.
Instead of feature factory teams, just delivering features that people have asked for, where they are goal oriented and so on. So I take a lot of hope fromevidence-based management from scrum.org, the professional scrum training that’s taught by scrum.org that’s helping to get the message out there about being more authentic with agility.
All that said agility is now growing beyond software. It has been for the last number of years and so there’s another option coming on the table called Kanplexity which is, Kanban for complexity and is primarily aimed at non-software non-tech teams. Because in that space, it’s very difficult to deliver a product or service or a piece of product or service that’s valuable within a 30 day increment. Tobias Mayer would tell me you can deliver something in 30 days.
And I think Tobias is right. There are cases. However, in non-software where I’ve seen for myself, my own eyes, that it is quite difficult initially to deliver value. Within 30 days, I started with a team in oil, for example, they started with four months of cycle time to deliver real value. And we did get their cycle times down to under a month, and then they had the option to go into scrum.
And that’s where they could really commoditize their agility with scrum. Again, that’s the advantage of scrum by the way that there’s learning out there on what scrum is. There’s also some really inauthentic learning on scrum, but if you go to scrum.org, for example, to learn really professional scrum, that would give me more hope that you’re likely to be on the right track, that you’re likely be doing the right proper scrum and the more as well you have.
Product owners who are important executives in the organization, not just people who have got the time to do the work, but people who actually have the power to do the work that they’re not usually suited for. By the way, you might be an executive who is a product owner and you are with the team all the time.
Cause you’re working on some new innovation, but by and large, what I see is people are assigned a product owner at accountability because they’ve got the time, but they don’t have the power. The more, we see scrum masters who work beyond teams. The more we see product owners or real product owners who really do own the product.
The more we see discovery in teams, the more inspired I will feel about scrum. And I am inspired about scrum. Because I teach scrum with UX. For example, I teach agile leadership. I help advanced Scrum Masters to become much better at their scrum. So I am really committed to scrum and I’m very encouraged by that, but I’m also quite discouraged by the level of inauthentic agility and scrum is in danger of dying. And this is why I’m introducing Kanban for complexity into the market. Because I think in some cases we might need another option. I would prefer people to do something that they believe in that they’re going to be authentic about than pretending they’re doing something like following the scrum values, when maybe their values aren’t actually compatible with scrum.
I love scrum. I think it’s brilliant. I just think we need to give more people more options so that people do what’s right for them as opposed to imposing something that might not be the right strategy for that team.
]]>
https://orderlydisruption.com/blogs/scrum/leader-vs-scrum-master-what-is-the-difference-between-a-scrum-master-and-an-agile-coach2022-07-19T16:44:42+01:002022-10-26T19:42:22+01:00Leader vs Scrum Master, what is the difference between a Scrum Master and an Agile Coach?John ColemanMore]]>
What is the difference between a scrum master and an agile leader? Before I answer that question, what is the difference between a scrum master and an agile coach? $200 a day.
A scrum master should:
be working at all levels of the organization and
working with other teams of teams,
helping people to understand how scrum works,
how agile works, and
also working as a change agent across the organization to try and help expand carefully the footprint of agility,
but let’s get back to the main question. So what’s the difference between a scrum master and a leader?
If you start with the scrum master, what should a scrum master be doing?
Scrum master should be observing through whatever senses they have, for example, seeing sensing, smelling, seeing the body language, and observing what’s going on and that means a lack of judgment. So I observe that when you behave like this, something happened and so on.
Maybe helping people, but not inflicting help. Helping when help is requested, coaching people professionally, asking Socratic open questions, when there’s permission from the coachee to do that, giving advice, when advice is requested.
Teaching when people are open to hearing other options for how they can do their work.
Acting as a change agent for the rest of the organization, removing impediments that are beyond the control and influence of the teams or teams of teams
Working with leadership to help cultivate the environment where agility can grow.
These are all things that a scrum master should be doing. The scrum master can also help to make sure that scrum has been done well. In doing so, if they observe negative chaos commencing, or for example, if they notice maybe unconstructive conflict, maybe unhealthy conflict, maybe a scrum master needs to step in.
We need to help to make sure that the teams are self-managing, but if we’re noticing some negative chaos kicking in, we might need to intervene to try and re-establish some kind of healthy conflict or make sure we’re getting back into positive chaos or complexity or complicatedness or even clear work, but getting out of that negative chaos, giving the teams a nudge to get out of that.
These are all interesting things for our Scrum masters to do.
What would a leader do?
What would a leader do? Very similar, I would say, there are some additions, I would say one of them is walking to the source of value creation. Where’s the work being created. If it’s software development, you might even be looking at the source code with the team doing mob programming.
If you do non-software you’re visiting where the product is being produced, where the service is being delivered and you’re seeing what’s going on. And it’s less about a Royal tour where people know you’re coming, it’s prearranged and they stick up these posters on the wall because you’re coming because you’re so important.
You are important and they think you’re important. It’s not about that. It’s about unexpected visits so it’s much more informal. So people are much more likely to be open to you about what’s frustrating them. What’s slowing them down. How can you help them? And it also helps by the way, if you’re technical, not so technical that you understand every single thing that they’re doing, but technical to the extent that you understand what’s going on.
So you understand the technical risks that that were sitting on top of, particularly if people’s health or lives are at risk or the organizational health is at risk. So understanding what’s going on walking the Gemba they used to call it in Japan. You can walk the Gemba of value creation, but you can also walk the Gemba of value consumption where value is being consumed, visiting customers and end user, not just having one-off visits to customers and thinking that every customer represents the one or two customers that you visited getting into this habit of meeting customers in the various regions that you operate, meeting them face to face and meeting them online, understanding their perspective, understanding what jobs they’re trying to perform
You also need to be inspiring teams. Not everybody is a visionary, but you need to be in a situation where you can inspire teams through a direction of travel. Maybe you’ll co-create that direction of travel with the teams or teams of teams so that everybody feels inspired and inspiring and really helping to light the place of helping people to get better.
Your job is to help to cultivate the environment where agility can grow. For example, we might have a horizontal growth path, you can grow horizontally. You don’t have to get promoted vertically to get more pay, to get more recognized. You can grow horizontally where we have more frequent funding cycles, so we can be more adaptive of what, and where the funding should go.
We thought at the start of the year that all the value would be created in this area, but we’ve learned actually the value isn’t there it’s actually somewhere else. And we need to pivot in a different direction we need a funding cycle that is more regular, that allows us to adapt to that. We need to declutter workflows and processes that are impeding the agility of our teams.
We need to help teams to demonstrate how they can be compliant without necessarily doing it in a waterfall way. There are more agile ways of demonstrating compliance. What’s more important is that we understand what we’re trying to control, what risks we’re trying to manage and find some alternative ways how we can demonstrate that were on top of those risks.
So these would be the key differences and it kind of begs the question then:
What’s stopping a scrum master from being a leader and leader being a scrum master?
Nothing stopping it. In fact, I think leaders make great scrum masters.
As long as they act as leaders and not act as controlling managers. There are some good managers, of course not all managers are controlling, so you could do that, but you just need to be careful because if, for example, Vanessa was my manager. Maybe she shouldn’t also be my scrum master because that kind of impedes the self-management of the team.
Maybe she should be a scrum master with a different team, cause if she’s now my line manager, if she looks after my pay reviews and all that type of stuff, maybe it’s better. If she’s a scrum master on a different team but we should definitely use your skills because you know what? Managers, leaders, they often have more power to fix problems, to remove impediments than scrum masters.
That would be my summary of the difference between a scrum master and an agile leader. Not much. There’s a lot of overlap. Thank you.
]]>
https://orderlydisruption.com/blogs/scrum/who-is-responsible-for-a-scrum-teams-performance2022-07-04T13:19:47+01:002022-10-26T19:43:33+01:00Who is responsible for a scrum team's performance?John ColemanThe scrum master is now on the hook for the effectiveness of the scrum team. So the buck stops with the scrum master. And the reason that this was introduced, I believe, was to stop situations where scrum masters were asking lots of Socratic questions and doing lots of observation, which is a really good thing to do. But they were just watching this and bad behavior was happening on their watch. Unhealthy conflict was happening on their watch. The team’s performance was going down on their watch. And so it was felt that it was a good move to have somebody on the hook for the effectiveness of the team.
There was a big change in the 2020 scrum guide. The scrum master is now on the hook for the effectiveness of the scrum team. So the buck stops with the scrum master. And the reason that this was introduced, I believe, was to stop situations where scrum masters were asking lots of Socratic questions and doing lots of observation, which is a really good thing to do. But they were just watching this and bad behavior was happening on their watch. Unhealthy conflict was happening on their watch. The team’s performance was going down on their watch. And so it was felt that it was a good move to have somebody on the hook for the effectiveness of the team.
Now it gets a bit tricky because the developers need to be self-managing. The scrum team is self-managing. And really the interventions from a scrum master should be in the case where it feels like the team is descending into chaos, bad things are happening and the scrum master needs to step in to make sure that bad things don’t happen.
We’re all ultimately responsible for our own performance. The developers, are responsible for delivering a high-quality increment, the product owner for maximizing the value that goes through the scrum team, the scrum master needs to be coaching, mentoring, teaching, advising, observing, helping people in all sorts of different stances, helping the product owner, helping the developers, but also helping the organization so that the scrum team can be effective.
And that means sometimes that the scrum master needs to go beyond the team, work with other teams that we depend on. Maybe work with other functions, maybe help to declutter, some processes workflows and so on. Even de-clutter the product, cause sometimes there’s too many features in the product, keeping the product order, some hints that maybe the product, the service needs to be simplified so that we get more engagement from our customers and end-users.
Ultimately short answer is the scrum master. Thank you.
]]>
https://orderlydisruption.com/blogs/scrum/agility-and-sustainability2022-07-04T13:07:58+01:002022-10-26T19:44:15+01:00Agility and SustainabilityJohn Coleman
What level of travel is involved when people are producing your products and services? Are we getting components on the other side of the planet when they could have been sourced more locally and so on? So it’s quite a broad area and there’s lots of things you can do There are no silver bullets for this.
If you want to improve sustainability, consider it in terms of how you prioritize value, how you order your backlogs in scrum kanban, how you do your experiments and consider can we achieve more competitiveness in the market by providing a more sustainable product or service without increasing cost. Take your sustainable product, if in doing so, it’s going to cost them more. So there’s going to be some level of R and D to try and figure this out, but that would be my nudge on sustainability.
Did you know that there are 17 United Nation, sustainable development goals. Did you know that when you’re measuring value, you can consider societal value as part of that. And that could include consideration for those 17 United Nation sustainable development goals. Now those 17 United Nation sustainable development goals, they do compete against each other.
So there is an element of balance there, but if you decide to go after maybe a couple of them, for example, reducing carbon footprint or passing on plastic, that’s something that could be considered when you’re ordering the backlogs or when the product owners that you’ve empowered to, order backlogs for you.
They can consider societal value when they’re ordering the backlog. And I would urge you to go for authentic sustainability as opposed to. Greenwashing is just a waste of energy. Really. We could be delivering more value to customers and greenwashing is just a real cynical approach to pretending to be sustainable.
Instead of being inauthentic with our sustainability, let’s aim to really reduce the plastic let’s aim to really reduce the carbon footprint, not just in the product or service that’s produced, but in how that’s actually produced as well so sustainability is central to what we’re doing. There are really no recipes to improving sustainability, just like there really are no recipes to improving organizational agility.
But what you can do is you can make sure that sustainability is something that is central to how you are ruthless about value by being ruthless about value. You can be ruthless about how much we’re going to reduce carbon footprint, how much we’re going to reduce plastic, and so on. Also what you can do is you can consider what power is being consumed.
What level of travel is involved when people are producing your products and services? Are we getting components on the other side of the planet when they could have been sourced more locally and so on? So it’s quite a broad area and there’s lots of things you can do There are no silver bullets for this.
If you want to improve sustainability, consider it in terms of how you prioritize value, how you order your backlogs in scrum kanban, how you do your experiments and consider can we achieve more competitiveness in the market by providing a more sustainable product or service without increasing cost. Take your sustainable product, if in doing so, it’s going to cost them more. So there’s going to be some level of R and D to try and figure this out, but that would be my nudge on sustainability.
]]>
https://orderlydisruption.com/blogs/scrum/who-writes-the-acceptance-criteria2022-06-30T11:00:17+01:002022-10-26T19:45:33+01:00Who Writes the Acceptance Criteria?John ColemanWho writes acceptance criteria?. Should you even have acceptance criteria? It's a loaded question, because it's assuming that we're using user stories. And in user stories typically you might say in order to deliver a particular type of value, some particular persona wants or needs something in order to do so, and then you typically list off your acceptance criteria.
These are the things that if they were in place, I would be happy with it. And then you might have some non-functional acceptance criteria. It needs to comply with a particular international standard, or it needs to perform it in a particular period of time. Acceptance criteria are very useful because when the team is working on the work item, they have a sense of what work they need to do to help to deliver that.
Who writes acceptance criteria?. Should you even have acceptance criteria? It's a loaded question, because it's assuming that we're using user stories. And in user stories typically you might say in order to deliver a particular type of value, some particular persona wants or needs something in order to do so, and then you typically list off your acceptance criteria.
These are the things that if they were in place, I would be happy with it. And then you might have some non-functional acceptance criteria. It needs to comply with a particular international standard, or it needs to perform it in a particular period of time. Acceptance criteria are very useful because when the team is working on the work item, they have a sense of what work they need to do to help to deliver that.
You can actually use specifications by example. “Also given this situation given a particular context when certain events happen, this is what we expect to happen”. Behavior-driven development, automated acceptance testing, specification by example, these are all very good ways of using the ‘given when then’ format.
That's a lovely way to write your acceptance criteria, but who writes them? The people doing the work write them, not the product owner. You thought it was the product owner? I want the product owner to be working with the customers, the stakeholders, managing their expectations about uncertainty, helping people to realize that some of their work realistically may never happen.
Maybe there's multiple priorities here and that we need to be picking our battles in terms of what we're going to target right now in the next month and the next quarter, in the next sprint of years in scrum. So actually the developers, the people doing the work in scrum or the Kanban system members in Kanban they would write these items. They would write the acceptance criteria. And I much prefer that because if a product owner, for example, is writing these items with the acceptance criteria, there can be a behavior from developers or kanban system members with the saying, “no, you can't bring this in cause it's not ready”.
That's bad behavior from my point of view because the last chance for getting work ready is in sprint planning in scrum and in replenishment in Kanban; there's really no need for a product owner or someone outside the team to be writing these items.
]]>
https://orderlydisruption.com/blogs/scrum/setting-expectations-in-scrum2022-06-27T17:12:54+01:002022-10-20T19:35:50+01:00Setting Expectations in ScrumJohn ColemanWhen you’re trying to set expectations, maybe the only expectations you can set are that we don’t know when we’ll be done. That might be not very favorable in your organization, but what you could do is try asking people to look at the product, look at the service, look at what you’ve done. Look at the outputs of experiments and interviews and see how people are reacting to the product in terms of what you might have already released in the market.
When we don’t know what we don’t know, it’s kind of silly to come up with a Gantt chart saying, we’ll all be done by Christmas, but this is exactly what people do. They predict what they’re going to do in future sprints, if they’re using scrum and in future months if they’re using Kanban.
If there’s more unknown than known, you probably need to allow for some uncertainty and you need to embrace that uncertainty.
When you’re trying to set expectations, maybe the only expectations you can set are that we don’t know when we’ll be done. That might be not very favorable in your organization, but what you could do is try asking people to look at the product, look at the service, look at what you’ve done. Look at the outputs of experiments and interviews and see how people are reacting to the product in terms of what you might have already released in the market.
Maybe reflect on those and then decide what to do next. So instead of building up a big list of things that we wanna do next, maybe all we need to do is say, well, what’s the next thing that we need to do. What’s the next right thing. Failing that maybe what you need to consider is Monte Carlo probabilistic forecasting.
It’s still smoke mirrors in uncertainty. We still don’t know when we will be done, but I find that if your stakeholders cannot deal with uncertainty then they will put in some undoable date that’s beyond the limits, beyond the capabilities of the team in that vacuum, they will make something up. This is what I’ve noticed.
In that event, maybe you tried to get your stakeholders used to the idea of running forecast regularly with Monte Carlo Probabilistic forecasting. It sounds very fancy, but it’s actually quite simple. You run random number generation on how big could your backlog be? How small could it be? How big could it be?
90% chance you’re right, 10% chance you’re wrong. And then you look at the throughput how many items does your team get done? Valuable work items. How many items does it get done? 90% chance you’re right, 10% chance you’re wrong. And then look at what would be the worst performance in terms of throughput, what would be the best performance in terms of throughput and let Monte Carlo run random number generation between those limits.
How small is the backlog, how big is the backlog? How bad could we be in terms of how much work we do and how productive could we be in terms of how many outputs we could deliver. And based on that, Monte Carlo will come up with all these different date intervals and you’d be a fool to pick the date in the middle because that’s like saying 50, 50 heads or tails move, maybe over to where there’s 85 percentile, even 95 percentile. If it’s a legal requirement and say 15% chance, it won’t be done by this date, but I’ll give you a better forecast next week and in just saying, but I’ll give you a better forecast next week, we’re basically saying that we don’t know.
A bit of a health warning with this, if your team doesn’t have regular throughput, if the, your team isn’t delivering work that’s done according to scrum every single sprint. If it’s delivering all of the work, maybe on the last day of the sprint as well, or if there’s really a regular throughput, the quality of your forecast is going to be worse, but you can still give regular forecasts.
And by providing regular Monte Carlo Probabilistic forecast to your stakeholders. It’s a good way of making them realize that because you’re updating the forecast every week. It’s like the weather, the forecast for your work will change as well.
Thank you. That’s setting expectations. We don’t know.
https://linktr.ee/johncolemanxagility - social and podcast links https://linkpop.com/orderlydisruption - order training from right here
]]>
https://orderlydisruption.com/blogs/scrum/constraints-work-capability-throughput-and-flow2022-06-15T11:30:00+01:002022-10-26T19:08:13+01:00Constraints, work capability, throughput and flowJohn Coleman I could see there was a constraint there on the pizza oven. They probably could have done with two pizza ovens and that person seemed to be under a lot of pressure. But they didn’t take on any more work than they had the capability to take on. They were fully utilized but they first optimized their flow.
It was like a really tiny portion for a lot of money. And so we said, let’s get some pizza. And we went to a pizza stall and there was a big, long queue. I asked my family to go in under a tent and I just had an umbrella, luckily, and I had rain gear and I waited in the queue and I was waiting for quite a while.
Today I want to tell you a little bit of a story about a festival in England. You know what the English summertime is like. We went to a thing called Pub in the Park in Marlow, and it was raining. It rained really heavily. And we were wondering what to eat and we saw these different stalls and we were disappointed with the food we were getting.
It was like a really tiny portion for a lot of money. And so we said, let’s get some pizza. And we went to a pizza stall and there was a big, long queue. I asked my family to go in under a tent and I just had an umbrella, luckily, and I had rain gear and I waited in the queue and I was waiting for quite a while.
I was getting a bit impatient, but I was also kind of enjoying the mindfulness of just being in a queue and just observing and watching the world go by and so on. But there was something that I noticed after I ordered my pizza. I was able to observe the business of the pizza stall from a different perspective.
And what I noticed was that the person who was taking the orders was really taking his time taking the orders. He was being careful that he took the right order, that he understood what the person was ordering. Then he was checking, how is the person getting on with rolling the dough? And that dough was being passed on to another person where the dough was already flattened and they put the sauce on and they add the cheese and the ingredients and so on.
And then, the next step in the process was the dough with the sauce and the ingredients on top, the precooked pizza, if you like was put on kind of a tray and then taken by another person and put into the pizza oven, which was an old fashioned Woodburn pizza oven. And then the pizzas, when they were cooked, they were taken out and put onto another area where a lady was checking the original order, boxing them, if there was a batch of four pizzas with different styles she was then checking with the guy who originally took the order. So they were checking not only when the order was taken, but again, when the order was being delivered. So there were no mistakes. I observed no mistakes be made in the orders.
I was waiting a long time for my pizza, but I noticed something that they weren’t overloading themselves because they were taking their time taking the orders. They slowed down the arrival rate of orders coming to the pizza stall. So it meant, there was really like a very good flow, that The people were working completely in tandem.
I could see there was a constraint there on the pizza oven. They probably could have done with two pizza ovens and that person seemed to be under a lot of pressure. But they didn’t take on any more work than they had the capability to take on. They were fully utilized but they first optimized their flow.
They made sure that the work was flowing properly. And then they stepped up the utilization of each step. People were taking a drink of water every now and then, they were not completely flat out. Although the guy, at the pizza oven seemed to have less breaks than the others. and I think this is a kind of a lesson to all of us.
We also see this on motorways highways, auto routes, where in some countries they have traffic lights to stop traffic coming onto the highway. And the reason that they do that is not to just be a nuisance to us, but actually to control the arrival rate of new cars coming onto the highway so that there is optimum flow of traffic going through the highway.
So when you’re doing knowledge work, we can apply the same principles. Don’t take on more work than the capability that you have in your team or in your team of teams. Look at the throughput how many pizzas is the team delivering? How many items of knowledge work is your team delivering? You do complex work so you’re using your brain. It’s not as smooth, utilization won’t be as high because the work isn’t as obvious, there are peculiarities with your work, but you can still observe what is the throughput of our team or team of teams. And then that might dictate how much work might come in. A little bit of a health warning with that.
Sometimes there’s a lot of noise, particularly in knowledge work. And so there’s different types of projects that come in. And so people might say actually throughput is too noisy. Cause there’s different types of project going on, but you can maybe lift up the time horizon to maybe months or quarters or even semesters or years.
And look at, this time last year, this quarter, last year, how many of these types of projects or product development initiatives did we take in. So that will tell us probably what our capability is for this time, unless we’ve made some improvements in the meantime. So that’s my little nugget for you today.
Keep an eye on your flow. Also talk to the people in who are involved in the process and find out what might be frustrating them, because if you over overplay flow metrics. If you overplay throughput and cycle time, how long things take what can happen is if the process is not really within the control of the team or the team of teams, they might get a bit frustrated, even if we tell them.
That we don’t really, it’s not your fault and all that, they still feel a little bit guilty sometimes the human factors kick in. So just be careful that you also ask people, what can we do to try and make this better? Are there some things outta your control that maybe we can help you with?
And executives that’s really where they can step in. They need to walk around, listen to teams, ask people what’s really going on and really be humble and help teams to improve the system within which they operate. That’s my nugget for you today.
]]>
https://orderlydisruption.com/blogs/scrum/how-do-you-measure-value-in-scrum2022-06-14T10:28:45+01:002022-10-20T19:39:04+01:00How do you measure value in scrum?John Coleman
How do I measure value for a major IT infrastructure piece of work? How do I measure value? Before I even get into, how do I measure value? What is value? A lot of people struggle with this. I wrote an article about this here,what is value really?
I think one of the reasons why the world is in the way it is, is because we over-indexed on a couple of meanings for that.
How do I measure value for a major IT infrastructure piece of work? How do I measure value? Before I even get into, how do I measure value? What is value? A lot of people struggle with this. I wrote an article about this here,what is value really?
I think one of the reasons why the world is in the way it is, is because we over-indexed on a couple of meanings for that.
Organizational Value
One of them being organizational values where maybe you’re trying to protect the reputation of the company or trying to protect the revenue that you have or protect whatever value that you have.
Organizational, from the point of view of protecting the organization’s interests, maybe protecting the reputation of the company, maybe reducing costs, things like that. That’s quite a common interpretation of value.
We’re saving some money or something like that.
Market Value
Then there’s market value, which is where a customer, end-user interacts with our product or service and they get something there, we see a change in behavior. They can do something more easily. They complete a task more easily.
They can do it in less, with less steps and so on. There’s less friction. It’s easier to do all these kind of things.
Societal Value
And then there’s societal value, an example of which for me, would be sustainability. Have we reduced our carbon footprint? Have we reduced our nuclear footprint?Have we reduced our plastic footprint?
Plastics seem to be even more damaging than the climate crisis. What are we doing around that area? Or it could be around a risk reduction, reducing risk. Maybe we’ve got a technical mess left behind this. Maybe the product looks all nice, but it’s just hanging together by a string but a lot of people don’t know that. It could be failure demand. Maybe we delivered something and we didn’t do something right for the customer. Some piece of work went live and then the call center was just rammed with complaints and some person left the building with a major bonus having delivered on time and on budget, but we just messed up the call centers and maybe 80, 90% of our calls at the call centers are complaints.
Risk reduction could also be the cost of not doing something. If we don’t do this, then something bad might happen kind of thing. And a lot of the time we don’t know when that bad thing might happen. It’s intangible really. We can’t really say when it will happen.We know that at some point it might happen.
Learning Value
A kind of a more mature lens at value as well would be, say we have some learning, we learn something about one of these above and there’s value also in learning. And I would argue that learning is the first citizen. A lot of the time we don’t actually know for sure if we will deliver this value.
And so sometimes you can run some experiments to discover do we have the capability to harvest that value? And so that’s for me, what value is. I had a case where I could just put a monetary value on something and we didn’t use it. We didn’t use it because at the time we were using some app and I think we had a million downloads or something like that, of the app.
And we could really have zoned in on users of the app and get them to convert, redeem some offer, tailored or something like that. And then we’d see the money. We could literally see the sales going up as the offers were being consumed on the app, but we decided not to use sales as the measure of value because we wanted 50 million people downloading the app, 50 million people using the app.
And what’s the point in milking the 1 million people who downloaded the app already when we could actually have done something much, much bigger. Even then we didn’t use money so in fact, I never have used money. So really value is relative. It’s not exact. We don’t know what we’re gonna get.
And if you have a backlog, for example, you’ve got different items in your backlog and you think some things are more valuable than others. It’s relative. We have an idea that some things might be more available than others, but there was a famous case study by Maersk Cargo called Black Swan farming, where they discovered that some items were hundreds or thousands of times more valuable than others, but they only found out after they went live. So they talked about cost of delay and all that. But what I picked out of that paper was you actually don’t know how valuable something is until you actually go live. So maybe you need to do some small little bets.
It’s tiny little bets on each to see where the money is. So instead of going into a casino and putting all your money on the first four tables, which is what a lot of people do in MVP, minimum viable product, which would mean the crappiest product in the time. I don’t use that term anymore.
I prefer what’s the smallest thing we can do, the smallest thing we can do, and the next most important thing. So instead of putting all your money in the first four tables in the casino, maybe we could put money on 10 tables and maybe all the actions on table number nine, actually.
So different ways of understanding value, market value, organizational value, societal value, risk reduction, or learning, and it’s relative. But when do you reap that value?
Reaping the value
You only reap that value when you release, when you give whatever you have to customers to give feedback. And often people draw a graph over time and they might have, a value in the vertical axis and maybe time on the horizontal axis.
And when you start with an agile piece of work even if you’re using something like scrum, where you’re going in, there’s some kind of sprint cycle and you’re trying to release some product at the end of that cycle and so on. We call it the increment and that increment gets bigger and so on.
Even if you’re doing that, in my opinion, when you start doing scrum unless you’re like a bunch of Navy seals or something where you can just click together and everything’s just perfect as soon as you start, most of the time, we just suck in the first sprint. Maybe for the first two months, we suck and there’s a change curve that people are probably familiar with as well.
When you start, you try something different, a lot of the time things get worse. You can reduce how much worse it gets. But typically gets worse, in my experience, it can take two months for the performance of the team to come back up and then you really get into a nice trajectory and you leave the other people behind. So when I start with the value I would argue that value would go up a little bit in the early sprint, but it wouldn’t be stellar. It wouldn’t be going upright, cuz we’re doing lots of learning about each other. We’re learning more about the vision and the product and what we’re trying to achieve. And if we’re having goal orientation, hopefully there’s some kind of North Star that we’re striving for at the end of every sprint kind of thing.
And going for some overall kind of North Star that we’re striving for. Hopefully we’re doing that. And then we got some goal orientation, but even with all of that in the first couple of sprints, maybe we don’t deliver as much value as we would hope. You only get value when you release and you might find out that the value is negative.
You find out that you’ve actually made things worse. Don’t forget that. I really admired a guy once, who was in one of my leadership classes. I don’t recommend this by the way, but he said, John I take things out of production. I said, what do you mean you take things out of production?
He says, yeah, they’re just putting rubbish in out, I said what happens if they notice? He says they rarely notice. And if they do, I just say, oh, sorry, that was a mistake. And then they put it back in. So he understood actually that a lot of the time we make things worse, you add more bugs and you add more, just makes it more messy and so on.
But most of us, hopefully we deliver more useful stuff as we go on. Although we do know from lots of studies, that two thirds of what we build, unless we do discover to deliver, which I wrote abouthere.
If we just deliver stuff like robotically from the backlog, two thirds of those items are rarely or never used.
So the man actually is probably not in a bad track, not sure I recommend it though. Probably the better way would be to use discovery, to figure out the stuff you should never build, do experiments. But let’s say the team is they’re delivering value because they, they’re releasing something, and then things get better and then they deliver more value and you can release during the sprint as well remember? You don’t have to wait until the end of the sprint. Actually, I hope what will happen is you deliver a bit of value during the sprint and then you actually have some feedback as well at the sprint review. And so we can course correct. We’re not just like relying on the opinions of the people, the stakeholders inside the building. We’re actually, we’re talking to customers. How about that? And we’re looking at the analytics, if it’s software, for example, or maybe there’s no analytics as well. If it’s non-software you can still tell how the product is doing and yes, you can run more experiments and just find out what’s going on.
You can do interviews, you can just talk to them, pick up the phone. And so with approaches like Scrum for example, the delivery of real value increases over time. Do we know exactly what it is? No, it’s relative for me. There are techniques but I don’t make up money. It’s just relative really.
But if cash is coming back in, I guess that’s clear, you could count that. But will it be clear actually that the extra cash that’s come in is because of your team? This is one of the things I like with the logic model, you’ve got inputs, budget, people, customer needs, things like that.
You got activities, all the things we do to deliver the work and then outputs, we actually delivered something that you can release and then you release it and you get some feedback and you hopefully get some outcome out that, but impact is much bigger than us normally. And it’s profit of the company, for example.
So unless you’re a startup or something like that, how do you know actually that the improved cash position helped that. Sometimes the accounting people are very good and they can tell, particularly if you’re looking at organizational value or maybe the cost of not doing something you can see on the bottom line already the difference that we made particularly if you reduce costs but the question I was asked was how do I measure value for a major IT infrastructure piece of work? And the person who asked the question won’t like the answer unless you’re releasing something in chunks along the way, you don’t have any value, zero nada, nothing. And if that time period, is quite long, say 18 months, you’re in a pretty precarious situation because what’s probably going to happen now is people aren’t really going to measure value anymore. They’ll be looking for some proxies. And typically what I see is they’re looking at story points.
Some other kind of proxy measure and sometimes there is story point bingo. So it’s not even an output measure to done it’s like, activity, cuz they’re just playing games with claiming velocity at the end of a sprint. And so then people conflate effort considering complexity and risk with value, which is that we’ve made a difference to the organization, to the world to ourselves, or we’ve learned something more about all of these, if you don’t release, if you don’t have people and even if you do release, if you don’t have people giving feedback about whether we’ve made a difference or not, you don’t have any value. And you’re probably following more a Waterfall profile, which would be where there’s basically no value whatsoever. No value whatsoever. And then we get towards the end and then whew. And I’m actually being optimistic here because I’m assuming that with the Waterfall, that you deliver the same value as the agile guys. But if you think about it with a traditional approach, the best thing you can hope for is what the people asked for.
That’s the best you can hope for and it’s usually not that because the different levels of translation that go on in between and so on. The best you can hope for, with some kind of an agile approach, you could do this with Kanban as well. The best you can hope with an agile approach is something much better than you originally thought of.
And I love what Rich Hundhousen says . He’s one of my peers in scrum.org, he says the sprint review is where the customer gets to see what she asks for, but doesn’t want. You get it? So you go on for a long time. You can use whatever frameworks you want. There’s lots of nice frameworks out there.
Evidence based management for example is really nice. I think Chris Matts has some kind of value hierarchy as well. There’s lovely approaches out there, but the thing is that if you’re not releasing anything, if you are not putting it into hands of someone else where we can actually see if it’s making a difference.
You’re not getting anything.
I did do something in a bank, it was a major application and there was IT infrastructure under the application as well.
And a huge economy was based on it. And the risk was that if we went live that we could damage the economy, no pressure. People were talking about, oh, we need a fixed window. We need 10 hours or whatever it was and blah, blah, blah. I said, this is just too much risk.
No-one’s gonna pull that lever. I certainly wouldn’t pull that lever. So I recommended Martin Fowler’s strangler pattern and it’s a nice little pattern actually, I had a strangler fig in my back garden in Chiswick when I was living there and it was really sad. It was like this little twig.
And what it does is it lands in the little crack in a branch, little kind of takes root into the branch and it kind of sucks the nutrients outta the branch. It starts growing, even starts growing its own fruit and everything. I was confused thinking, oh, what’s going on? Oh, I didn’t think that was a big tree.
It was like, it was so good at camouflaging itself on the tree. It looked like it was part of the tree. And then what it does is it drops the roots down to the ground. And then those roots, once the roots get into the ground, the fate of the tree is dead, it’s basically dead. Cause what happens then is it just takes all the nutrients out of the ground that’s even coming into the roots of the tree, grabs all those wraps the tree, and then eventually the tree dies.
And then there’s like a hollow thing inside. So you can actually see these fig plants, you can get them in some garden centers and you should never plant them outside, cause they’ll destroy all your garden. But if you put them in a little box, I guess they’re okay. Anyway the metaphor here is I said gals, guys, what we need to do here is we need to strangle the old system. They said what are you talking about? What we need to do is we need to put just a few transactions through the new system.
But we can’t do that. We gotta be. I said, no, what you need to do is you need to design this kind of reconciliation system. So if a transaction goes through the old system, you push it through the new system.
And if it goes through the new system, you push it through the old system. And then at the bottom you have some reconciliation as well and so the idea is that it gives you a kind of an incremental goal life strategy cuz what you can do is you can say you can just open the top a little bit and just put a little bit of your market into this new system and you’ll see some problems and you’ll fix those problems.
And then you say, oh how confident are we feeling now about adding more people to this and so you open the top a bit more and so more stuff is going into the new system and we find some discrepancies. We reconcile the old system. It’s a lot of extra work, don’t get me wrong. But it’s very good at reducing the risk of the goal life.
Anyway, in that situation, within four months, I actually left after that recommendation. But they followed my advice and within four months it was live across the whole country. They actually decommissioned the old system and it was unlike previous attempts at replacing that system before where they were left, you know, when you tried to put in a new system and you try to replace the old system and then it doesn’t really quite work. So you end up with two systems. And so they were worried, that’s why they had a big bang approach. They wanted to get rid of the old systems. But with this approach, they did get rid of the old systems it’s called the strangler pattern.
So maybe you should be thinking less about how do you measure value and maybe you need to be thinking more about how do you reduce the risk with the deployment and how can you actually deliver any value in the shorter terms, you can follow a trajectory, like the agile one, rather than the kind of Waterfall pattern here, which is where you get nothing for a long time.
And then it eventually goes up. So keep feeding through your questions to me. Thank you so much for that question.
So just a reminder please donate to agile with Ukraine at agilewithUkraine.com. It’s very good cause to raise funding for life saving equipment, humanitarian and medical help, and I wish you a good day.
Thank you.
https://linktr.ee/johncolemanxagility - social and podcast links https://linkpop.com/orderlydisruption - order training from right here
]]>
https://orderlydisruption.com/blogs/scrum/trust-and-its-impact-on-the-definition-of-done-in-scrum2022-05-31T17:52:55+01:002022-10-20T19:38:43+01:00Trust and its impact on the definition of done in scrumJohn ColemanMore]]>
Why is our definition of done so long?
I don’t like to call the definition of done the checklist for how we do things around here. I used to say that because you might be including every single little thing in your process when you do that, but does it have the essential elements of how do we know that this work is done?
Why is our definition of done so long? In some cases, actually, it’s not long at all. My most common experience is that when I ask people what’s in their definition of done they say we met the acceptance criteria. There’s a lot more to done than just meeting the acceptance criteria. This typically happens when there’s a kind of a traditional approach to delivery and scrum has been wrapped inside that approach. I often call it water scrum fall and in waterfall, it’s very professional, it’s very good but it doesn’t have a thing called a definition of done. So this concept is alien to waterfall.
When people think of done, they think, oh, we just met the acceptance criteria. We just did what our customer is looking for. But we might be lacking transparency if we don’t have additional criteria there. What I often see as well is almost the opposite of that, where there’s too much in the definition of done and I did this in the past myself as well in a large bank where I with others created an organizational definition of done, which was then inherited by the teams as a minimum that they would not have to rethink how to comply with financial regulations and so on. We thought that was a good idea but what that resulted in was essentially we had a very detailed definition of done and it was so detailed that really people didn’t remember what was on it. It probably was put on a confluence page or metaphorically stuck in a drawer where people forgot about it.
I often did mini audits if you like across groups of say 400 people, just checking in, do you even know the depth of what the definition of done, do you respect it? Do you continually improve it? And I was told people improve it, but actually they didn’t even know what it was.
So how can you improve your definition of done if you don’t even know what the one is that you have, and if you don’t even respect it.
There’s no basis for continuous improvement in scrum at least if you’re not using your definition of done, but while we might want to be careful about making sure that people haven’t forgotten anything, it does say something about us when we do have a very detailed definition of done. Imagine a list that had 30 items on it. What does that say about what’s going on in that environment? And I would put it to you that what it says is that there’s a lack of trust. It typically happens when maybe there are some suppliers involved.
It might be nothing to do with the suppliers. And I’m not saying it’s their fault, but there’s this kind of organizational lack of trust in other people, it could be other teams and it could be at other sites. But essentially it comes down to lack of trust and it always begs the question where does the definition of done end and where does waterfall begin? We often hear people complaining about a definition of ready as a gate, you can’t bring it in cause it’s not ready, which is not a very scrummy approach. You still have a last chance to sort things out during sprint planning.
But the definition of done, when it’s a really long detailed list, it’s likely that people won’t be complying with it. You’ve lost the plot then, people will not understand why should they do all these things? It’s just too much. So what ends up happening is because there’s too much, nothing happens.
What would happen if we had higher trust in the system? And what impact would that have on the definition of done? So what I often do is a liberating structure called critical uncertainties, and you could pick any two dimensions of a problem. Say on the horizontal axis, I would have the level of trust. So on the left-hand side, I might have low trust and on the right-hand side I might have high trust and the vertical line would be to do with the definition of done the minimum would be you had one, a clear, but basic definition of done, not no definition of scrum, in scrum you have a definition of done, that’s it.
A basic but clear definition of done at the bottom and at the top a very detailed, definition of done. And so you draw the vertical line, you draw the horizontal line, you end up with four quadrants. You end up with a situation where we have low trust and a very detailed definition of done.
We’ve got low trust and a very basic definition of done. We’ve got high trust, very basic definition of done but clear and high trust, a very detailed definition of done, but clear, and what you can do with critical uncertainties, you can ask people, how would you think people would be behaving in those quadrants?
So for example, if you had low trust and a basic, but clear definition of done, actually things could fall between the cracks because there’s no trust. Maybe they won’t, maybe everything will be fine. Maybe we will actually earn trust, but what could happen? Things could fall between the cracks.
It becomes apparent to people and reinforces that sometimes we have a detailed definition of done because we don’t have enough trust.
And then you go to the high trust side and say, what would happen? What kind of behaviors would you see if you had high trust and a clear, but basic definition of done? And they say nice things, it’d be lovely.
What would happen if you had a very detailed definition of done with high trust?
It might actually erode trust. And so for me, it all comes back to trust then. So if you have high trust, you don’t need to have a very detailed definition of done I would put to you. How do you increase trust?
Let’s come back to the scrum values for a start. In scrum, we’ve got the five scrum values. I use the mnemonic FOCCR. It’s funny. Meet the Fockers then change the K to a C. Focus, openness, courage, commitment, and respect. Have the scrum team and its stakeholders really committed to those scrum values and if they’re really striving to improve on those, trust should increase. Trust is also at the base of the triangle of the five dysfunctions of a team. If you don’t have trust there are lots of things that don’t happen.
So how do you increase trust? I guess is the question and I don’t have all the answers, but I think one of the things is, might be no harm now and again, to do a sprint review. How are we doing against the scrum values? How are we doing against the three pillars of scrum as well? Transparency, inspection, and adaptation. How transparent are we? Are people clear on what’s actually really happening? By looking at the three artifacts, the product backlog, the sprint backlog and the increment, but also I would refer back to Richard Hackman’s work as well, because he was an expert on teams.
He studied teams in the US federal agencies, and it’s not all about us singing songs all around the campfire and everybody’s happy. It’s a two-way street really. To increase trust, we also need to deliver, we need to deliver ideally what we said, we’d deliver in the spring goal.
That’s what we commit to in scrum we commit to delivering the work from the spring goal. And so I think it’s a two-way street. I think we need to be looking at how we’re behaving with each other. We need to be striving to improve how we’re doing on the scrum values and we need to be delivering. And it’s not true in my opinion, that we need to wait for the team to be happy and we need to build up trust before the team can deliver. You might not have a team for very long if that’s your approach because the team might never deliver. And we do need to face some reality.
Sometimes when we’re being open, we need to have the courage to say the things that need to be sorted.
So how do we use definition of done more efficiently at sprint planning?
So really the definition of done should already be there before you go into sprint planning. A lot of people kind of get confused that the best place to review the definition of done is actually at the sprint retrospective. But people say, hang on the retrospective is at the end of the sprint, what do we do before we start the first sprint?
It doesn’t say this in the scrum guide. My personal opinion is when I start up with a team, we elaborate. What’s the vision for the product. If there’s a vision, what’s the product goal. Let me try it. I might use a story map to break down the product goal into sub goals, into high-level items, into more detailed items.
And you end up with the product backlog on the wall. I would also encourage the team to create their definition of done before they start their first sprint planning and I will write another blog on sizing, so I won’t get too much into sizing, but when you’re looking into can we do this item in the sprint?
Do we think we’re comfortable about bringing this item in? You can use the definition of done as your reference point if you’d like to say actually to get this done, we have to do all these things. Do we really think that we can comfortably get that done within the sprint? How comfortable do we feel about that?
The mistake that a lot of teams make is they don’t refer to their definition of done at all. So then surprise, at the end of the sprint, they don’t have a lot of work done because actually they didn’t even know what done actually meant. I would use the definition of done as a reference point for planning and really, if you want to improve how the team uses the definition of done, I would say, even though you can have an organizational definition of done, and even though the intent behind that is to ensure that we don’t forget things. Be careful. I’m thinking with one of my clients at the moment of moving away from that kind of a model and moving more to a situation where the teams, the people in the teams are deciding what done means.
If multiple teams are working on the same product, they need to work with each other to figure that out, but let them figure it out. And then let’s together try to figure out a way, how can we increase trust so that we don’t need to have such a detailed definition of done so that we do comply with our definition of done and that then gives us a basis for continuous improvement. The light bulb moment here is that when we ask teams to improve their definition of done, a lot of people think, oh, I have to add more items to my definition of done, I have to do even more things.
Maybe if you improve trust maybe there’ll be fewer items in your definition of done.
https://linktr.ee/johncolemanxagility - social and podcast links https://linkpop.com/orderlydisruption - order training from right here
]]>
https://orderlydisruption.com/blogs/scrum/in-agile-scrum-who-is-responsible-for-engaging-the-stakeholders2022-05-23T16:59:16+01:002022-10-25T16:26:30+01:00In scrum who is responsible for engaging the stakeholders?John ColemanMore]]>
The buck stops with the product owner. There's three accountabilities in scrum:
the product owner,
the scrum master and
developers.
I guess we would really want the scrum master and the developers to be doing some of that stakeholder engagement.
For example, during the sprint, I hope the developers have been introduced to the customers and end-users, so they actually refine what needs to be done. What was the thing you wanted again, you asked us six months ago and we're just starting to work on it now. What problem are you really trying to solve? Oh, that's what you try and do. That's not what we understood. So trying to get a common understanding of what's required.
I would expect developers to be talking to customers and end users and not the product owner kind of like being the proxy, kind of conduit between the developers and the customers. The product owner is ultimately on the hook for customers, end users, but also compliance stakeholders for example, maybe there's some suppliers that you're interacting with. Maybe there's other teams that we depend on and we need to interact with those. And there's the whole organization, of course, but the scrum master can help with a lot of this. For example, a scrum master is a change agent and should be able to work with other teams and maybe negotiate ways of working with those other teams.
They might not be working in a scrum fashion, but we can't just arrive saying we use a scrum, so you need to give us this tomorrow. They have their own lead times have their own ways of working. We need to be respectful of other people. And so the scrum master can interact with those people.
A decent scrum master should be able to negotiate on your behalf as well as the product owner in terms of how do we demonstrate compliance in this agile world? Can we see each other every month? And can I ask you two questions? Are you happy? Are you engaged? And if the answer to either of those two questions is no then maybe we need to talk more during the sprint.
But coming back to who's ultimately on the hook, it really is down on the product owner. And then I hope there would be a very good discussion within the team about what can the scrum master take away in terms of
responsibility there and what can the developers do? And how can we make sure that the product owner is effectively connected with the stakeholders that she needs to be connected to, to such an extent that we're kind of keeping an eye on the politics if you like in a positive way where the optics we might be doing very well as a scrum team, but if we're not being perceived to be doing well, that's important. So what are the expectations of these stakeholders? Do we need to help them embrace uncertainty?
Does the scrum master need to help them to understand uncertainty? And that sometimes we don't know when it will be done. So we need to use some regular forecasting to kind of give them some kind of information, still saying, we'll give you a better forecast next week. I think if there's one job I really want the product owner to be doing is to be really connecting properly with stakeholders.
I don't want them writing user stories. I don't want them writing product backlog items. I don't want them kind of stuck in with a team every single day, unless it's a really technical product or so on. The product owner has other things to do as well in terms of product management, commercial stuff, pricing, and so on, marketing.
And unless that stuff is all part of what the work is done on the scrum team product owner is going to be doing lots of other stuff. And so I hope there's some really healthy discussions within the scrum team about how do we deal with all these stakeholders and stakeholder mapping is one of the techniques that you can use.
So who's on the hook really? Ultimately the product owner.
]]>
https://orderlydisruption.com/blogs/scrum/what-do-the-developers-do-in-the-last-week-of-the-sprint2022-05-03T10:30:02+01:002022-10-20T19:38:05+01:00What do the developers do in the last week of the sprint?John ColemanYou shouldn’t be handing work anywhere, you should be collaborating, but you just work together and try to understand that together. And that’s what we expect in scrum. We expect you to collaborate and not run onto your next thing. There are no roles in scrum. We do have accountabilities, but you don’t have like sub roles if you like.
I think this is a software development question, for the persons involved in software development. In software development, they have these kinds of steps of how the work gets done.
And if you’re not in software, you might also have some kind of workflow. The work gets done in a particular sequence and in software development, the prevailing wisdom before was that you talk to a customer, and you find out what she’s looking for. You might do some analysis on that.
You might do some design, could be architectural design, could be UX research, could be some user interface design, and then maybe some tests would be written and if people are using driven development, they’d write some tests, even though no code has been created yet to pass those tests, the tests would all fail and then they’d write code to pass the tests.
Once the code passed the test, they go back and tidy it up. It’s like three hats really, you’re writing the test, then you’d try writing code to pass the test. And then you’re refactoring, it’s known as test-driven development, some people don’t do test-driven development in software.
They got kind of a manual approach, a very old-fashioned approach where the developers do the code, write the code, and then maybe the developers do some testing. I hope they do. I hope they’re not just throwing stuff over the wall. And then some tester people check that it’s all working properly.
To give waterfall some credit, the traditional approach to doing this kind of stuff, you just did it once. You did it twice actually cause you did it once and it didn’t work and then you do it again, you could do it twice.
‘Done’ doesn’t just mean met the acceptance criteria
But when you have scrum, for example, you need to deliver an increment every single sprint and that increment needs to be done. So the team needs to have a thing called a definition of done and done does not mean met the acceptance criteria. Doesn’t just mean that, there should be other considerations as well.
So there’s the definition of done. I don’t want to really call it the checklist for how we do things around here, because that might be a bit too process-oriented and maybe a bit too detailed. There’s a nice balance between trust and being clear what we need to do, but as such the team would know what they need to do for something to be called on at the end of the sprint so they can show something at the end of the sprint. That’s all fine. But what do the developers do in the last week of the sprint? It feels like a loaded question because the assumption that I’m reading from the question is that the developers, in your case, write the code, and then they hand it off to some people who do some testing.
And then those people are busy doing testing and probably raising bugs in the stuff that you created. And so you should be off doing something else. You should run onto the next thing. And it reminds me of a chap that I really respect. His name is Brendan Vochkow from, I think he’s from Tennessee, that area of United States.
And he was on the stage there a few years ago at a conference. I think it was agile Indy, Indianapolis. And gave an example of the kind of behavior that you want to see in the team. And he said basically, let’s say I’m a developer. The behavior that Brendan looks for is when the developer is ‘finished’ their piece of work that developer would stick up her hand and say, who’s ready to take this away from me.
Collaboration is key
I want to take on the next piece of work. Who’s ready to take this away from me. That was really smart, what Brendan said there, because it could be tempting for the developer to move on to the next thing. The best time to actually iron out any misunderstandings or any bugs that there might be and so on is you’ve just worked on it and so before you context switch onto something else, maybe you need to collaborate with the tester, so making sure that everything’s going okay, and that you’re working on it together. So you don’t move on to the next thing maybe you help the person that you handed all the work to.
You shouldn’t be handing work anywhere, you should be collaborating
You shouldn’t be handing work anywhere, you should be collaborating, but you just work together and try to understand that together. And that’s what we expect in scrum. We expect you to collaborate and not run onto your next thing. There are no roles in scrum. We do have accountabilities, but you don’t have like sub roles if you like.
Accountabilities in scrum:
So really what we’d be encouraging is what Brendan would have encouraged when he was on the stage in Indianapolis, which is when you have something and you feel like someone needs to take it away from you within the team, or you want to collaborate with someone on the team to get it to done. You stick up your hand and say, who’s ready to take this away from me. And who’s ready to collaborate with me to try and get this thing to done. That’s what I would recommend. That would be my answer to that question. Also, there’s lots of other things you could be doing. Product backlog management in scrum and a really good strong team would be delegated to the developers.
‘Developer’ in scrum means anyone doing the work regardless of whether you’re a tester, analyst or UX or whatever you are. And so product backlog refinement in a really good scrum team would be delegated to the developers and the developers would be clarifying the problems to be solved with the customers and end-users, maybe you can be looking at what’s coming up next.
Do we understand that? Do we have a common understanding? You might have one person on the team who has a really good understanding of what that work is, but actually, do they really understand it? When you hear people having an argument, are they arguing about the same thing?
First of all, product backlog refinement, are we talking about the same thing? Do we understand what the opportunity is, what the problem is to be solved. So that’d be my little tip.
What do developers do in the last week of the sprint? They’re part of the scrum team, they work to get us to the sprint goal, they collaborate, you don’t just hand that off to someone else. You pause for someone to collaborate with you to get that work to done and failing that, there’s lots of product backlog refinement that can be done. You could even be writing tests for the next sprint, actually, you could be getting ready.
You don’t arrive in the next sprint with your hands in your pockets. So maybe that’s refinement as well, having the test written so that when you have a chat then with the customers and users and say, if we do these, if these tests pass, is that what you’re looking for? And if they say yes, then, you’re in business.
That’s my suggestion. Thank you so much.
https://linktr.ee/johncolemanxagility - social and podcast links https://linkpop.com/orderlydisruption - order training from right here
]]>
https://orderlydisruption.com/blogs/scrum/agile-111-balancing-ux-with-shipping-fast-in-scrum-a-deeper-look-into-each-box-of-the-lean-ux-canvas2022-04-12T17:30:53+01:002022-10-20T19:37:01+01:00Agile 111- Balancing UX with shipping fast in scrum? A deeper look into each box of the Lean UX canvasJohn Colemanwhat’s the point in delivering good stuff when you don’t even know who the customer is? Is there such thing as balancing UX with shipping fast in scrum? Is there even such thing as shipping fast in scrum? How can we know what is value when we don't know the end-user? What happens in each box of the Lean UX canvas?
How do we balance UX with shipping fast in scrum? It’s a loaded question really because it’s suggesting that we need to ship, that we need to build anything.
Ellen Gottesdeiner has a book by the title, discover to deliver and it’s a bit oversimplified but I like the strapline because a lot of ideas should never be built. And you can use discovery to discover maybe more than 70% of your ideas that should never be built. You can run cheap experiments.
How about this? You can actually talk to people. You might think that certain personas or proto personas would use your product and that they’re looking for these particular outcomes, but maybe you’ve got the wrong people.
Maybe you’ve got the right people, but they’re looking for something different. Maybe they’re not willing to pay what we’re looking to charge. It could be all sorts of things.
How do we balance UX with shipping faster in scrum?
First of all, how does UX and scrum work together?
The first thing we need to do is we need to get rid of the family feud, the UX’ers have some assumptions about the non UX’ers and the non UX’ers have some assumptions about the UX’ers and most of these assumptions are wrong, primarily because the level of transparency between the UX’ers and non UX’ers is quite low.
UX is not UI
I see a pattern of people working in some kind of UX center of X sensors, some central UX team, and we’re dividing up those people as though they are pizzas, 10% over there and 5% over here. And then that leads to the misperception by non UX’ers that UX is UI. UX is not UI. UI is about the user interface. You can have a user experience without necessarily having visual user interface.
So the first thing we do in scrum is we say, hang on a second, we need a UX’er in each team. There’s loads of UX work. As soon as we make the UX work visible in the product backlog, and we should make it visible on the product backlog, the non UX’ers will realize how much work there is. And some sprints, we will do mostly discovery because we discover something, that we’re on the wrong track.
So we need to pivot. We need to go back to the drawing board to do some new experiments, to build up some evidence about what we should build next.
In scrum, every sprint you have some increment, but at the sprint review, you’d be looking at the results of the experiments, maybe the results of interviews you’ve had as well as looking at the increment itself.
There are three options for managing the product backlog with UX in scrum.
One of them is have separate backlogs, which I would say never do that. Never say never and all that, I did find an exception yesterday, where there was a team working on the design studio for the whole company.
So they were designing the tool where you grab little widgets, here’s this menu and here’s that button and all that kind of stuff. And it was branded with company’s brand style guide and so on. And so that’s something that they were dedicated to for a while, but in almost all situations you want all of the UX work to be in the product backlog.
And within that, you’ve got two options striped or blended.
STRIPED PRODUCT BACKLOG
Striped essentially means that the whole backlog would be like a barcode of UX and non UX work. So maybe, we need to do a customer interview, or we need to do a wire frame.
We need to do low-fidelity prototyping, we need to do a high-fidelity prototype. We need to do a wizard of Oz experiment. We need to do a concierge experiment. We need to recruit some people that match the proto-personas that we think might be using our products. These should all be in the product backlog.
When the backlog is striped, it leads to a problem that you don’t know what you’re going to discover, but that’s going to be the situation anyway. When you’re trying to discover you actually don’t know who’s going to be using this and you don’t know what they’re looking for. So we need to be comfortable with not knowing stuff anyway. So striped for me is actually fine.
What I like about striped, this is my personal opinion, we get rid of this execution bias where we think everything needs to go from discovery to delivery, which is not true.
BLENDED PRODUCT BACKLOG
Blended is the other option where you have product backlog items that are a bit bigger, you’ve got some discovery and then you’ve got some delivery and you need really good capability in the team, almost telepathy within the team so that we’re not reviewing the designs like 10 times.
It’s almost like I say something like to Vanesa , she just gets it. She turns it around and it’s perfect. It’s even better than I would’ve thought. Unless you have that kind of telepathy and skill level in the team, blend is going to be difficult, but you could also do a mix and match between blended and striped, but you would have one product backlog.
And we’re going to be putting UX on the agenda for each of the events, the daily scrum, does anybody want to come along to our customer interview today? And does anybody want to take notes? Because if I’m doing the interview, I want to be focused on the customer so maybe non-UX’ers are willing to do that.
Is anybody willing here? And that’s really nice. Cause a lot of non-UX’ers think, oh, I don’t want to see the customer. I just want to put on my headphones and all that. Not all non-UX’ers are like that, but a lot of them are.
But what they realized as soon as they go along and they watch the customer interacting with the prototype, they realize ‘oh, wow. I didn’t know you were using the product like that.’ Yeah dude we’re using it like that. So light bulbs go off really for the non-UX’ers and the key message is that UX’ers will be coaching, teaching, mentoring, willing non-UX’ers on the scrum team all things UX because there is too much UX work to be done.
In my personal opinion, the learning’s going to be one way, the UX’ers will be teaching, coaching, mentoring, the non-UX’ers, all things UX. I don’t really see it going the other way cause there’s actually too much UX there. UX is never finished.
So then in the daily scrum every day, like I mentioned, UX is on the agenda if you like.
For me, there’s two questions at the daily scrum, this is my opinion:
What do we need to work on together today? That includes UX.
Is there anything that we forgot about? That’d be, we started, we didn’t finish it and there’s some things blocked or something like that.
Sprint planning we’ll be talking about what do we need to discover this sprint? What increment do we need to deliver? And by the way, if you’re trying to decide, some items, how do you know whether you need to do any experiments? But if you’ve got loads of evidence, just build the bloody thing.
Learn humility.
But if you don’t have evidence, maybe there is high value, but maybe we’re not so comfortable with our ability to harvest that value. So maybe you need to do some experiments. And a lot of the time, even really confident people, I did this with 228 people at a London university earlier this year, a lot of people really cocky about hybrid learning, what we meant by hybrid learning was people are on teams and zoom and people face-to-face at the same time, that working how well that would work and people, oh, we’re going to use metaverse. And then when they did the interviews, they found out no one would want to use Metaverse. I knew that, but like they learned humility.
That’s what it’s all about. Learning is the first citizen when you combine scrum with UX. At the sprint review, we’d be looking at the results of the experiments, the results of the customer interviews, as well as looking at the increment. At the retrospective, we’ll be talking about, how can we be more effective as a team?
The scrum masters’ game has to jump up as well because she needs to understand more about UX probably should be trained. I see a lot of people come into my scrum with UX workshops, what happens is they send one person from the team. I’m thinking of doing something like the mob programming crew does, maybe have a team price cause the whole team should come. You don’t just learn as one person, then that person transfers that knowledge.
You need to experience it. And we use the lean UX canvas. We go through the lean UX canvas, a very simple eight box canvas.
Box 1: what problem are we trying to solve?
You can write it in free form text. You can use the elevator pitch from Jeffrey Moore. We like to use the business problem template because it’s very clear. Really clear and also expresses what problems we’re trying to solve and how do we know that, some goals aren’t being achieved and how would we measure success and so on.
Box 2: Business Outcomes
And then we look at what are the business outcomes? What would change for the organization? How would we know that we solved that problem?
Box 3: What proto persona will you use?
Box three is, what proto personas will we use? Proto persona doesn’t mean prototype of a persona. It’s just a made up word actually for our best guess at who the persona might be. There’s no point really in going into six months of high polish, high ceremony, research into who the personas might be.
If you have it, you can take it as an input and it might be very useful input, but really, the scrum team collectively would take a view on what would be the best guesses in terms of who might be interacting with us.
Box 4: User outcomes & Benefits
And then our best guess as to what outcomes they’re looking for, the customers and the end user, customers are someone who pays and an end user is someone who uses for example, there’s a car downstairs, Magda owns the car, I’m a user. Magda is the customer.
Box 5: Solutions
It’s only box five out of eight that we start talking about solutions. So yesterday I was doing wire framing. We did crazy eights from Google design sprints, where you fold a letter page, or an A4 page if you’re in Europe page in half, you fold it in half again, fold it in half again, you fold it back out and you’ve got eight squares, if you like, or eight rectangles. And every minute you do a new sketch And it’s really nice to just brainstorm some ideas, your ideas get crazier as you go along. That’s why they’re called the crazy eights. The politically correct people call them the active eights.
And then you might do some wire-framing, some prototyping. You might even do a service design, McDonald’s restaurants, I believe the people who got that going at the start, you can see that they were actually trying different designs for the restaurant on a tennis court.
So check that out, the founder, I believe it’s on Netflix.
Box 6: Hypotheses
Box six, after collecting all of those assumptions, what problem are we trying to solve, what organization outcomes are we looking for.
Who might we be targeting this at?
What outcomes are they looking for, what solutions might we offer those?
They have a lovely, simple template in box six. It’s like clicking together Lego bricks, it’s really very well done.
Fair play to Josh and Jeff for putting this together in the Lean UX, the third edition book is out by the way, Lean UX.
Box 7: What’s the most important thing we need to learn first?
Box 7 you say, okay, what’s the most risky of all these assumptions that we have here, you might pick the riskiest hypothesis and the hypotheses by the way, click together the assumptions from boxes one through five. They’re all assumptions that need to be tested.
In box seven, we’re saying, okay, which one of those is the most risky and do you really want to wait until the end of the year to find out it is a big risk and it’s going to kill us?
You probably want to tease that out earlier. So we do that in Lean UX canvas box seven.
Box 8: What’s the least amount of work we need to do to learn the next most important thing?
Box eight, this is really where the penny drops for people. I’m looking forward to this in the class tonight with some people where you say, okay, what’s the smallest effort to learn the next most important thing?
And they think of wild ideas. What can you do in 30 minutes, 30 minutes? What can you do? What can you do in a day? What can you do in a week? What can you do in half an hour? Pick up the bloody phone, talk to a customer, you dream up all this stuff, just talk to someone, find out will they actually use it. And a lot of the time….
you’ll find they won’t.
You should never do a proto persona by the way, on someone you know.
I had a class last year with people from the Netherlands, it was hilarious. You should never do a proto persona by the way, on someone you know. Anyway, they decided to do it on me, they said, okay, you’re Irish. And they said, I’m cranky because I’m cranky most of the time and they made some assumptions about me. They had this persona, I had some exec MBA students as well last July, they did the same thing, they did this proto persona, her name is Caterina, she does this and she does that, these are her needs and these are her wants, and this is her friction.
And then I said did you recruit a Caterina? Did you actually pick up the phone and talk to someone like that? Really?
So anyway, after the course, I said, gals, guys, would you mind interviewing me on Monday morning? It was a weekend class.
They said, yeah, okay, let’s do that. So they had a chat with me and they assumed that I was a BMW driver, that I drive like crazy, that I break all the speed limits, that I have this little gadget over my visor for detecting the speed limits, the speak ons and all that from the cops and so on.
I said guys I’m not like that. If you met me 15 years ago, I was like that. You drive fast in a BMW cause you can, you’ve got the power, it’s got brilliant machines, but now I drive a Land Rover. It takes two seconds from the time I hit the pedal before the thing bloody moves. I said to Magda last week and she said, you should’ve moved there.
Magda, this is a Land Rover. It’s a little bit slower. Make allowances here. And also there are cameras in the UK. I used to live in Ireland. I used to get away with lots of things, but you’ll just get fined that, you can drive on the road, you get five fines within two miles and you’re done.
So I don’t drive like that anymore. The cameras have changed my behavior so their assumptions were all wrong about the persona. And then they discovered that I would never have bought the product. So they were thinking of building something for someone who’d never buy this thing.
So the Lean UX canvas is lovely.
Where’d you review that? You review it in product backlog refinement. Product backlog refinement becomes the nerve center in scrum it’s an activity. Good scrum teams would actually have it almost as an event, in multi-team scrum, it is an event. Nexus, unless it’s an event, you have to do. It would be chaos if you didn’t.
And so within product backlog refinement, you look at the Lean UX canvas, you say okay. We interview these people. When I had students earlier in the year going through a canvas for four days, they went through the first time, they found out their assumptions are wrong when they had interviewed people. We need to go back to the solutions, other teams had to go back to the personas.
You’re learning all the time
Some teams had to go back to the business problem statements. They had the wrong business problem statement. That’s the thing, it’s iterative. You keep going back. You’re never done. You’re learning all the time. Learning is the first citizen, think you’ve got enough evidence, you should build this thing, build it.
what is quality if you don’t know who the customer is?
For me combining scrum with UX deals with the fundamental flaw of the lean startup. With the lean startup, give Eric Ries some credit, he said, what is quality if you don’t know who the customer is. Fair point, genius comment actually.
what’s the point in delivering good stuff when you don’t even know who the customer is?
When I was at a lean startup conference in 2013, streamed into London from San Francisco, there was some company rented a room, 30 people in the room and I looked around and we were chatting and all that kind of stuff and I said, look me in the eye and tell me that when you validated your assumptions that it was the right product, you had the right personas, you had the right outcomes, you have the right solutions, they would pay for it, look me straight in the eye and tell me that you turned down the quality switch, cause in Lean Startup startup, you deliver crap because what’s the point in delivering good stuff when you don’t even know who the customer is.
scrum has this definition of done and that’s your quality stamp right there.
With lean UX and scrum, when you get those experiments converted into evidence, then scrum has this definition of done and that’s your quality stamp right there.
It’s genius. The combination is beautiful. And actually, if you ask me, you also need to combine it with Kanban. Some people just do Kanban with UX actually. What I like about scrum is at the end of the sprint, you do look at what stuff has finished. Kanban looks at stuff that is maybe gone over a boundary if you like, there’s no boundary if you like from one time horizon to the next.
How do I balance it? I don’t want to ship fast necessarily. I want to discover fast. I don’t want to deliver fast and I want to deliver what we discovered is maybe the right thing to build. Let’s go back to Russell Ackoff, that famous consultant who taught at a number of universities in the United States.
I would love to have been in his class while he was teaching. Must’ve been such a privilege for the people who were taught by him because he was like a storyteller, you’d listen to the guy all day. He had this statement, I’ll say it twice.
‘The righter you do the wrong thing, the wronger you become”.
I’ll say it another way.
The more right you do the wrong thing the more wrong you become. So do you just want to be a feature factory, delivering sausages that are completely wrong? Delivering stuff and shoving it out to the market completely wrong, or do you want to be figuring out what the right thing is to do?
So if you’re doing the wrong thing, you’re kind of screwed. If you do the right thing and you’re doing it a bit wrong, you can use these retrospectives to correct your team effectiveness and you can use the sprint reviews in scrum to course correct in terms of what we should pivot next. You have to make decisions ‘do we persevere?’, which is what most people do, they go into execution bias, or should we pivot, which is the smarter thing.
Scrum with UX, is looking for value. It’s like, where’s the value? Where is it? It’s not over here, it’s over there.
But it’s really really cool, and I hope you check it out.
That’s the question for today, I’ve got loads of other questions coming in.
If you want me to deal with any question on your mind, just comment on whichever channel you’d like, whether it’s on Instagram, Twitter, YouTube oe Medium, wherever you’re watching this, I’d be delighted to get your questions and answer them.
https://linktr.ee/johncolemanxagility - social and podcast links https://linkpop.com/orderlydisruption - order training from right here