Q: "What is your advice on becoming a good ScrumMaster?"
A: This is a good and difficult question. The main difficulty is where to start and how best to express it.
First, what is a good ScrumMaster? What makes one better than usual?
You may think it odd, but the first thing I want to say is: the team is having more fun. Why do I say that? Mainly because more fun will lead to higher business value. And it leads to a virtuous cycle or circle of cause and effect.
We do not mean silly fun. Well, it could be silly a bit (as in a quick joke and some stress relief). But we mean more the 'serious fun.' People are enjoying their work. They think of work almost as play or fun. They would almost pay the company to be allowed to do their job. That kind of fun.
For example, they enjoy working in the Team. And while they are serious, they often smile and laugh as they work with each other and talk to each other.
Second, more self-organization.
This is hard to explain, I think. "You make people self-organize" is my joking way of saying it. It is a joke, because you cannot really make the team self-organize. But you can, as a SM, coach and advise and set up the right conditions for self-organization. And then address any people (or other issues) that inhibit it.
You let people be free. Well, yes and no. You help people to become the best each person and the Team has ever been before.
And you do not inhibit self-organization yourself. (Actually, we all want to control things, and while some control is good, most of us want to control too much. At least, that is a common problem, even among the well-intentioned.) You do not 'tell' people to do things, although you might ask 'could you help with X?' But, gosh darn it, do not act like a 'command-and-control' style project manager. "I have a list of things for all of you to do, and I will be checking the list daily to see what you got done." Not that. Not even anything close to that.
Still, you might need to explain why they need to have detailed tasks and answer the questions in the Daily Scrum. And why that is useful for them. Paradoxically to some, they do need to self-manage themselves rather closely.
Third, more impediments are removed, and the Team is gaining velocity.
You have to aggressively attack the most important impediment. And when that one is 'fixed,' attack the new most important impediment aggressively. So that the velocity of the team easily doubles in no more than 6 months. (OK, some of you are in organizations that really are hard to change, so you will work hard to double in 1 year.)
And then keep on improving!
Fourth, more business value.
What? That is the SM's responsibility? Yes, as we have already hinted. But let us say more.
The SM should be helping the Team get better in every way. The Team of course includes the Product Owner, so the SM is helping the PO get better.
And the goal of the Team, of course, is to maximize the Business Value (in whatever way they define that) from the Team to the Customers. (There is no maximum.) And release more quickly and frequently.
Obviously, if the velocity increases the BV will increase. But we really mean more than that. The SM should be helping the PO learn to do all those things a PO should do to help the Team maximize the BV. Examples include: clearer requirements, focus on one release at a time, a clear Minimum (minimum!) Market Feature Set (aka Minimum Viable Product), slicing the stories smaller and re-Pareto-izing them, maximizing the feedback to try to improve the odds the customer will really be excited when they get it, maximizing the feedback (see Lean Start-Up) after the release and then 'adjusting' (pivoting, as appropriate), etc, etc.
I do not mean to suggest that the SM does the PO's job. I mean 'only' that the SM helps the PO become a better PO. And not only the PO. The ScrumMaster helps all the people (on what we often call 'the business side') to work better with each other so that the BV is maximized more. And delivered more frequently (which also helps maximize it).
So, at least as general goals, the SM wants to make the Team the best possible team ever.
More specifically, that means:
<ul>
<li>More fun</li>
<li>More self-organization</li>
<li>More velocity</li>
<li>More business value</li>
</ul>
It is, of course, more blessed to give than to receive, so actually they will start to feel that delivering more business value faster is more fun.
It can be said that 'removing impediments' is the way to make those 4 things happen. Put another way, anything that is holding those things back is an impediment for the Team. Fix it!
Have we fully answered the question? No.
Thursday, February 25, 2016
Sunday, February 21, 2016
Scrum makes work a game.
You know, of course, that Scrum is named for the Scrum formation in rugby.
More generally, Takeuchi and Nonaka were inspired by the 'rugby' they saw in several great companies and how they did new product innovation. And Sutherland and Schwaber read that article in HBR: The New New Product Development Game. And that was a key input to creating Scrum.
Here's where we are I think: "Life is hard, life is confusing, and I can never tell if I am making progress. It starts to be no fun, no real people to talk to usefully, no way to see if we are making progress. I am always late and it seem never-ending!"
If some of your colleagues feel that way sometimes, you can imagine that that is: Not Good.
So, Scrum changes it to a 'game.' It is still real, so not a game in a sense that it is divorced from real life. But it is, as they say, gamified.
We have a 2 week sprint. We have some defined roles. We put a person on a Team. We ask the Team (not one person) to be successful. We suggest that they self-organize and work together (collaborate).
And we allow they to make first downs (as in America football). They get feedback quickly (as in any game)...are they making progress.
Are the measures of progress that we have in Scrum perfect? Well, actually I think they are very good, but they are not perfect. But something that is fairly frequent feedback and fairly accurate is far far better than 'nothing.' Or a couple of 'at-a-boys' that were said half-heartedly.
The key thing is that we have made things 'fun' in a way. And that feedback is useful for course correction, but perhaps more useful as motivation.
Why?
- we get positive feedback
- we see that other people care
- we can feel proud of ourselves with small wins
- we work together, and it no longer feels lonely
- usually they team starts laughing during the day. It is fun in that way too.
Let me remind you how games are seductive. As any behaviorist psychology major can tell you, they give intermittent (positive) feedback. To be honest, not always positive feedback. But the positive feedback in intermittent.
And this, according to the research, is key to making the game 'fun.' Now, when they are playing the game, they do not always have a smile on their faces, but still they are engaged, and typically more focused, more 'giving their all' than they usually do working 'in their cube' (as we often see in waterfall).
As with any good game, we need to be able to see frequently, transparently, easily if we are making progress or not.
The managers need to talk about work as a game. A game we wish to win.
Tuesday, February 16, 2016
Wide-Band Delphi Estimation for Business Value - 3
This is the third in a series of three. See part 1 and part 2.
***
In fact, I recommended this, to see patterns or to make any mistakes obvious.
But I do not recommend doing the work in the order of the BVPs, the story with the most BVPs first. This is much too simplistic.
The key thing we are missing is cost. For centuries now, man has talked about the trade-off between costs and benefits. And in business we have the concept of return on investment. You invest $1000 (the cost) and get $2000 back (the benefit).
Can we use that concept here? Yes!
For each story, we can calculate an R factor by dividing the BVPs by the SPs. This gives us a rough ROI for each story. We could call it CBA (cost benefit analysis, or bang for the buck).
We think this is useful.
By no means does the R factor completely determine the order of the Product Backlog, but one can readily see that following the R Factor could help us maximize the business value per release, other things equal. (Of course, other things are not always equal, but we will not try to address that here, except to say that the Product Owner or others must re-order the Product Backlog some to account for the other things.)
At first, it is relative, strictly relative. That is Story X is 50 BVPs, which means it has half the value of the reference story (which has 100 BVPs).
But let's imagine a very simple situation and see what it shows us.
Imagine a product backlog.
Imagine it has a total of 1,000 BVPs across all the stories.
Imagine that we know that the total Product Backlog is worth $2,ooo,ooo.
In that case, we can calculate that each BVP on average is worth $2,000.
You can't cash in your Story cards at the bank for money (based on the BVPs on each one). You must release and there are MVP or MMFS issues as well, but one can at least feel (fairly accurately) that the BVPs are not just fantasy, but actually a foretelling of a future reality. Well, if the customer still wants it when we deliver, and if we had good BV estimators.
Objectivity and Visibility
In our opinion, whatever business value is, it is ultimately in the mind of the customer, and in the future.
So, to us as business people trying to solve a business problem (help people and also not go bankrupt), this seems altogether too subjective.
The BVPs start to make it a more tangible thing. And this helps.
Whatever number we decide ob is then no longer a 'feeling' inside us (or one of us), but rather a number 'out there' on the story card.
This helps.
It helps in many ways, but let's give one example.
In former days, we would ask two experts for Story X: Is it high, medium or low? And of course they would both typically say high. Now, we ask the two experts to vote with cards. One says 21 and the other 89. We and they can quickly see that one high is not another high. And they can start to have the famous conversation about how high is high. We can laugh, but actually this is a useful conversation.
In fact, one of the most valuable things about the numbers is that it makes the conversations better.
When they vote, and they disagree significantly (wider than 3 Fibonacci cards), we want the two extremes to talk. Others may talk as well.
What do they talk about? Well, we think it is best to think of this as sharing the Tacit Knowledge.
One definition of tacit knowledge is "all that stuff we know, but we don't even know we know it, and it has not been made explicit it." And, obviously, this is knowledge that we think is relevant and even useful in a given domain, or to accomplish a given set of work. Explicit knowledge is knowledge that has been written down or put in a formula.
Do you want a Team to share their tacit knowledge? Of course! In all the relevant domains.
Is it easy to get them to do so? NO! It is extremely hard. In part because they don't know what they know, and in part because each person doesn't know what the other people are missing.
Priority poker forces them, in a fun way, to share the tacit knowledge.
In my opinion, this is the most valuable thing about the whole exercise. Not that other things would not justify it. But the sharing of the tacit knowledge is the single most useful thing.
In what way? Without priority poker, the PO had to make tough choices in ordering the Product Backlog.
Let's assume, in former days, that he talked to all the business stakeholder individually. And they disagreed, of course, on the values of different stories.
So, the PO has to use up his political capital in just saying: This story is #1, this one #2, etc, etc.
This was 'risky' and often there would be some tense conversations. Too often the PO would be wrongly overridden by one or two business stakeholders.
Now, with the priority poker, all the business stakeholder educate each other. (Again I say, bring the popcorn. This is fun to watch.)
Still sometimes, in relatively rare cases, all 4 of the business stakeholders are being stupid at the same time, and the PO's number will make only a small difference in the average. And let us assume the PO's number is right. Only then does the PO have to use political capital to 'move' the story to a more correct BV number or more correct ordering.
This reduction in effort frees the PO to focus his work in other areas.
I hope you try priority poker soon. And tell us how it went. I hope you will tell us how much it helped you.
How can we use the BV points
We could organize the Product backlog strictly by BVPs, at least initially.In fact, I recommended this, to see patterns or to make any mistakes obvious.
But I do not recommend doing the work in the order of the BVPs, the story with the most BVPs first. This is much too simplistic.
The key thing we are missing is cost. For centuries now, man has talked about the trade-off between costs and benefits. And in business we have the concept of return on investment. You invest $1000 (the cost) and get $2000 back (the benefit).
Can we use that concept here? Yes!
For each story, we can calculate an R factor by dividing the BVPs by the SPs. This gives us a rough ROI for each story. We could call it CBA (cost benefit analysis, or bang for the buck).
We think this is useful.
By no means does the R factor completely determine the order of the Product Backlog, but one can readily see that following the R Factor could help us maximize the business value per release, other things equal. (Of course, other things are not always equal, but we will not try to address that here, except to say that the Product Owner or others must re-order the Product Backlog some to account for the other things.)
What is the value of a BV Point
Sooner or later someone will ask: What is a BV Point worth?At first, it is relative, strictly relative. That is Story X is 50 BVPs, which means it has half the value of the reference story (which has 100 BVPs).
But let's imagine a very simple situation and see what it shows us.
Imagine a product backlog.
Imagine it has a total of 1,000 BVPs across all the stories.
Imagine that we know that the total Product Backlog is worth $2,ooo,ooo.
In that case, we can calculate that each BVP on average is worth $2,000.
You can't cash in your Story cards at the bank for money (based on the BVPs on each one). You must release and there are MVP or MMFS issues as well, but one can at least feel (fairly accurately) that the BVPs are not just fantasy, but actually a foretelling of a future reality. Well, if the customer still wants it when we deliver, and if we had good BV estimators.
Objectivity and Visibility
In our opinion, whatever business value is, it is ultimately in the mind of the customer, and in the future.
So, to us as business people trying to solve a business problem (help people and also not go bankrupt), this seems altogether too subjective.
The BVPs start to make it a more tangible thing. And this helps.
Whatever number we decide ob is then no longer a 'feeling' inside us (or one of us), but rather a number 'out there' on the story card.
This helps.
It helps in many ways, but let's give one example.
In former days, we would ask two experts for Story X: Is it high, medium or low? And of course they would both typically say high. Now, we ask the two experts to vote with cards. One says 21 and the other 89. We and they can quickly see that one high is not another high. And they can start to have the famous conversation about how high is high. We can laugh, but actually this is a useful conversation.
In fact, one of the most valuable things about the numbers is that it makes the conversations better.
Tacit Knowledge
We just gave the example of the more useful conversation that arises.When they vote, and they disagree significantly (wider than 3 Fibonacci cards), we want the two extremes to talk. Others may talk as well.
What do they talk about? Well, we think it is best to think of this as sharing the Tacit Knowledge.
One definition of tacit knowledge is "all that stuff we know, but we don't even know we know it, and it has not been made explicit it." And, obviously, this is knowledge that we think is relevant and even useful in a given domain, or to accomplish a given set of work. Explicit knowledge is knowledge that has been written down or put in a formula.
Do you want a Team to share their tacit knowledge? Of course! In all the relevant domains.
Is it easy to get them to do so? NO! It is extremely hard. In part because they don't know what they know, and in part because each person doesn't know what the other people are missing.
Priority poker forces them, in a fun way, to share the tacit knowledge.
In my opinion, this is the most valuable thing about the whole exercise. Not that other things would not justify it. But the sharing of the tacit knowledge is the single most useful thing.
Helping the Product Owner
Priority poker makes the PO job easier. And it is a very very hard job, so any help is welcome.In what way? Without priority poker, the PO had to make tough choices in ordering the Product Backlog.
Let's assume, in former days, that he talked to all the business stakeholder individually. And they disagreed, of course, on the values of different stories.
So, the PO has to use up his political capital in just saying: This story is #1, this one #2, etc, etc.
This was 'risky' and often there would be some tense conversations. Too often the PO would be wrongly overridden by one or two business stakeholders.
Now, with the priority poker, all the business stakeholder educate each other. (Again I say, bring the popcorn. This is fun to watch.)
Still sometimes, in relatively rare cases, all 4 of the business stakeholders are being stupid at the same time, and the PO's number will make only a small difference in the average. And let us assume the PO's number is right. Only then does the PO have to use political capital to 'move' the story to a more correct BV number or more correct ordering.
This reduction in effort frees the PO to focus his work in other areas.
Overall benefits
I want to reiterate the key overall benefits I mentioned earlier.- They all see the same elephant (better)
- They all are more motivated
- They all have shared the tacit knowledge
I hope you try priority poker soon. And tell us how it went. I hope you will tell us how much it helped you.
Saturday, February 13, 2016
What is Scrum?
I am starting a series of posts to explain quickly what Scrum is.
It turns out that Scrum is very simple, and yet also very hard to explain concisely.
The main purpose of this series is to give my course attendees a bit more of an introduction than the Scrum Guide does.
***
Scrum is an agile method co-created by Jeff Sutherland and Ken Schwaber in the early 1990's.
It was known then, and has been known since, to enable Teams to achieve much more productivity, to find work more satisfying, and to produce wonderful products for customers. Scrum is not a miracle, it is not a panacea, it is no guarantee, but Teams regularly do impressively better by using it.
Scrum is one of many agile methods.
Agile methods are usually defined as those methods that follow the Agile Manifesto and the Agile Principles. Jeff Sutherland and Ken Schwaber were both there when the Agile Manifesto and Agile Principles were created. They helped create them.
One of the key things about Scrum is that it is simple.
Scrum is only providing a bare framework for a Team to work in. The fewest possible constraints to enable the Team to pop up to a new level of functioning.
What is Scrum most essentially? Ah!, this is hard to say. It was created by two guys in New England, and they usually like to express themselves very practically, so you may have to experience Scrum for awhile before you can answer the question.
Team Sport
Scrum is a Team sport. Scrum tries to enable a Team to be more successful. Or at least to see how they are doing, and then decide what to do about that.
We mean a real Team. That is, all members of the Team are expected to collaborate. And each is supposed to take full ownership of the full success.
This does not mean that everyone is equal or that they all have exactly equal skill sets, or that they all have skill sets in all areas. But that, together, they are taking on the goal of success. They are taking on the Vision as defined (usually and mainly) by the Product Owner.
We mean a real Team. Virtually everyone in business has been told 'you are on team X.' But mostly those are work groups or something similar, not real teams.
Among the attributes of a real Team is that each member is 100% dedicated to only one Team. And the Team has a common purpose, and all members of the Team are bought-in to that purpose. To accomplishing that goal.
Team Roles
Within the Team Scrum defines 3 roles:
Product Owner
ScrumMaster
Implementer (role)
Note that the current Scrum Guide calls the Implementer role the 'Team' role, which I think is confusing to beginners. It gives the impression that there is a Team within a Team. And I find this is unhelpful.
Scrum lore has the 'chicken and pig story.' I am told some cultures do not like this story (I do not know which ones or why), and so it is used less. But in the US (where I live), it is still a useful metaphor. (Let us of course agree that no one truly wishes to be compared to a barnyard animal.) I will not give the story here, but the idea is that the pigs are committed and the chickens are 'only involved.' From the point of view of the pigs and their work, to be 'only involved' is not bad, but it also not good. The chickens are normally less reliable in delivering what we want on time with high quality. But we find that chickens are always necessary. The pigs can never, in my experience, complete their work without some help from some chickens.
Roles Outside the Team
I want to mention two more roles outside the Team.
Customer. Customers are those real people who will use our product. They may be internal or external to the organization we work in. It is in delivering something wonderful to them that we get the greatest satisfaction. Very typically, the customers are in 'pain' (in some sense or other) and we are delivering pain relief. One can appreciate the urgency in doing that.
Business stakeholders. I use this term to represent the people that must work with the Team part-time, but every sprint. Mainly to give us feedback. I will say more about them later.
***
Thursday, February 11, 2016
"It's a mixed up muddled up shook up world"
I suppose we can all agree, after reading any newspaper, that the outside world is ...mixed up, muddled up, and shook up.
Do we let ourselves see that this is also true of the world and the people more immediately around us? And maybe, ah!, even ourselves?
Agile and Scrum are ways to work through all the change and stuff, and strive toward success. In business. (Some say it can be used at home, but we won't go there today.)
Maybe you will enjoy reflecting on the quote.
Do we let ourselves see that this is also true of the world and the people more immediately around us? And maybe, ah!, even ourselves?
Agile and Scrum are ways to work through all the change and stuff, and strive toward success. In business. (Some say it can be used at home, but we won't go there today.)
Maybe you will enjoy reflecting on the quote.
Friday, February 5, 2016
Question: Explaining Impediments to the Sprint Goal that happen
I received this Email with a Question:
Hi Joe,
I wanted to follow up and let you know how much I enjoyed the agile class and how much I've enjoyed implementing it at my office.
The team has really seen the improvement with their own eyes, and they are getting more and more brought in each day. We are already on our second release plan since the class. Our start velocity with 7 developers the first sprint was only 18, but by the last sprint we were getting close to 50 points. This current release plant we are averaging right under 60 points per sprint. It's been amazing the turnaround in such a short time.
Now to my question, how do you relate loss of staff time to your stakeholders, due to sickness? For example, we had a user story planned for a sprint, but the staff person who needed to be involved in it's design has been sick. I've let the stakeholders know that it may not be finished in the sprint due to illness, but beyond that, I'm not sure what else I can do.
Just reaching out for advice, thanks Joe! Regards, Tony [...]
ANSWER:
In the title, I use the words '...that happen...' By this I mean, an impediment that was unexpected that arises during the sprint. If it were a different situation, I might give a different answer.
First, we want the velocity to be meaningful. Remind them there is no value in fudging the numbers. It is good and useful to be honest. If you all do things 'according to the book' it is actually hard to fudge the numbers. But not everyone explains enough so that it can be seen that they are (or are not) playing 'by the book.'
Second: Great! Very good improvement.
Third: These things happen. People get sick. And, of course, to some degree every decent human being understands.
You say that 'you let the stakeholders know.' To me, depending on exactly how you did it, it is a potential weak point, or area for improvement. For example, if you 'just' sent an email, and they never read emails, then this is not very good.
Here's what I suggest. The PO should sit down with the business stakeholder (and any key managers) and discuss the project. Help them understand that we expect to make progress every sprint, but that the long-term success is key, not that we 'hit or exceed' each and every sprint. Stuff will happen, and we will have ups and downs.
You want to keep them informed. When and how should I inform you about impediments in the sprint that mean (or might mean) that a given story may not get done (done, done) in that Sprint?
There are lots of situations. Sometimes they will say: 'Don't bother to tell us until the Sprint Review.' They might say 'text me immediately.' Or other variations.
Discuss the business purpose or impact of informing them, or inform them sooner or later. For example, if you are lacking something and those people might get that 'lack' fixed (maybe knowledge, maybe a screw, whatever), then informing them quickly could be very helpful. But, if they cannot do anything with the information, why bother? So, discuss this.
Discuss also how much detail they need on some sample impediments like this that have happened. Sometimes they want to know, but without much detail. Sometimes they may want more detail, and having the detail would actually help.
Let's say you agree to inform them by email asap, with a special subject line (so it sticks out in the inbox). And usually in not more than 30 words.
Now, also talk about how these impediments will be discussed in the Sprint Review.
Probably agree that the PO should not assume that the business stakeholders or managers read the emails. Likely they did not read them, or forgot about them. So, to some degree (ask how much), these impediments need to be mentioned and (lightly?) discussed in the Sprint Review.
As you see, I am proposing a working (living, changing) collaborative relationship between the Team (PO) and the business stakeholders (and/or managers).
The key goal is to make that relationship more effective. This 'inform about impediments' issue is just one discussion point in that relationship.
Put another way, the answer to your question partly depends on where that relationship is and can be about now.
One more thing. The Team (the whole Scrum Team) is always expected to work together and overcome impediments (in priority order) where possible. So, at some point you might need a discussion of other impediments, of what the Team (SM?? Others?) did about them, etc. After some trust is developed, maybe all of this does not need to be explained every time. But the key idea is: you can't just say 'I have an impediment, sorry!' The Team has to always be trying to overcome the top impediments.
In this case, what might that mean? Well, maybe someone in the Team could help out with the design. Or the Team borrows a 'chicken' or another chicken to help out with the design. Or at least went to a manager and asked for advice on this one. Depending on the situation, this might need to be discussed. At least there needs to be a discussion of 'ok, but what happens now? What do you recommend? Is he well now? Or 'next man up!' Or what?'
Long enough answer for today.
Please tell me if you want to give more information and/or ask it a different way.
BTW, I am fairly confident that you (Tony) did the right things. In part my answer was for others..., others less experienced and successful with Scrum, you might reach the wrong conclusions if I had not explained more.
Hi Joe,
I wanted to follow up and let you know how much I enjoyed the agile class and how much I've enjoyed implementing it at my office.
The team has really seen the improvement with their own eyes, and they are getting more and more brought in each day. We are already on our second release plan since the class. Our start velocity with 7 developers the first sprint was only 18, but by the last sprint we were getting close to 50 points. This current release plant we are averaging right under 60 points per sprint. It's been amazing the turnaround in such a short time.
Now to my question, how do you relate loss of staff time to your stakeholders, due to sickness? For example, we had a user story planned for a sprint, but the staff person who needed to be involved in it's design has been sick. I've let the stakeholders know that it may not be finished in the sprint due to illness, but beyond that, I'm not sure what else I can do.
Just reaching out for advice, thanks Joe! Regards, Tony [...]
ANSWER:
In the title, I use the words '...that happen...' By this I mean, an impediment that was unexpected that arises during the sprint. If it were a different situation, I might give a different answer.
First, we want the velocity to be meaningful. Remind them there is no value in fudging the numbers. It is good and useful to be honest. If you all do things 'according to the book' it is actually hard to fudge the numbers. But not everyone explains enough so that it can be seen that they are (or are not) playing 'by the book.'
Second: Great! Very good improvement.
Third: These things happen. People get sick. And, of course, to some degree every decent human being understands.
You say that 'you let the stakeholders know.' To me, depending on exactly how you did it, it is a potential weak point, or area for improvement. For example, if you 'just' sent an email, and they never read emails, then this is not very good.
Here's what I suggest. The PO should sit down with the business stakeholder (and any key managers) and discuss the project. Help them understand that we expect to make progress every sprint, but that the long-term success is key, not that we 'hit or exceed' each and every sprint. Stuff will happen, and we will have ups and downs.
You want to keep them informed. When and how should I inform you about impediments in the sprint that mean (or might mean) that a given story may not get done (done, done) in that Sprint?
There are lots of situations. Sometimes they will say: 'Don't bother to tell us until the Sprint Review.' They might say 'text me immediately.' Or other variations.
Discuss the business purpose or impact of informing them, or inform them sooner or later. For example, if you are lacking something and those people might get that 'lack' fixed (maybe knowledge, maybe a screw, whatever), then informing them quickly could be very helpful. But, if they cannot do anything with the information, why bother? So, discuss this.
Discuss also how much detail they need on some sample impediments like this that have happened. Sometimes they want to know, but without much detail. Sometimes they may want more detail, and having the detail would actually help.
Let's say you agree to inform them by email asap, with a special subject line (so it sticks out in the inbox). And usually in not more than 30 words.
Now, also talk about how these impediments will be discussed in the Sprint Review.
Probably agree that the PO should not assume that the business stakeholders or managers read the emails. Likely they did not read them, or forgot about them. So, to some degree (ask how much), these impediments need to be mentioned and (lightly?) discussed in the Sprint Review.
As you see, I am proposing a working (living, changing) collaborative relationship between the Team (PO) and the business stakeholders (and/or managers).
The key goal is to make that relationship more effective. This 'inform about impediments' issue is just one discussion point in that relationship.
Put another way, the answer to your question partly depends on where that relationship is and can be about now.
One more thing. The Team (the whole Scrum Team) is always expected to work together and overcome impediments (in priority order) where possible. So, at some point you might need a discussion of other impediments, of what the Team (SM?? Others?) did about them, etc. After some trust is developed, maybe all of this does not need to be explained every time. But the key idea is: you can't just say 'I have an impediment, sorry!' The Team has to always be trying to overcome the top impediments.
In this case, what might that mean? Well, maybe someone in the Team could help out with the design. Or the Team borrows a 'chicken' or another chicken to help out with the design. Or at least went to a manager and asked for advice on this one. Depending on the situation, this might need to be discussed. At least there needs to be a discussion of 'ok, but what happens now? What do you recommend? Is he well now? Or 'next man up!' Or what?'
Long enough answer for today.
Please tell me if you want to give more information and/or ask it a different way.
BTW, I am fairly confident that you (Tony) did the right things. In part my answer was for others..., others less experienced and successful with Scrum, you might reach the wrong conclusions if I had not explained more.
Monday, February 1, 2016
Multitasking
I think the key goal of Scrum is to help the Team maximize the business value from the Team to the Customers.
But another, of several subsidiary goals, is to enable the Team to focus.
Focus is more or less the opposite of multitasking.
Perhaps even more to the point, multitasking is one of the great destroyers of human productivity. That is, your own productivity, to make it personal.
Please see this webpage for further discussion and a short video.
Enjoy.
But another, of several subsidiary goals, is to enable the Team to focus.
Focus is more or less the opposite of multitasking.
Perhaps even more to the point, multitasking is one of the great destroyers of human productivity. That is, your own productivity, to make it personal.
Please see this webpage for further discussion and a short video.
Enjoy.
Subscribe to:
Posts (Atom)
