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.
No comments:
Post a Comment