At the insistence of my good friend and colleague, Catherine Louis, I started doing Certified ScrumMaster courses (2 days) followed immediately by a 2 day Workshop.
This experiment (which it was for me at first) has proven completely successful.
I am now convinced that this is the best way to learn Scrum. Period. And I am convinced mainly because everyone tells us this is so. ScrumMasters, Product Owners, Team members, Managers. Including the managers who insist that it is a MUCH better value to pay extra to get them into the full 4 days.
What do we mean?
First: The best is to have the whole team and some closely related managers attend the whole 2 day Certified ScrumMaster course. Obviously, it isn't just for ScrumMasters anymore. (Was it ever?)
I won't describe that course here, but suffice to say that the way we do it includes lots of interaction, some challenging questions, some improv, some team exercises, including a very realistic Release Planning exercise.
Then, we have the same real team (well, teams, really) do the 2 day Workshop. Each Workshop is a little bit different. But the focus is on two things.
Complete a good (decent) Release Planning for the real project or effort that the team is working on. It is best if the team is just starting the effort. And it is best if the team has access to all the people and resources to make the Release Planning effective. Release Planning includes (over-simplified): Vision, Product Backlog development, Business Value (points), Story Pointing, Risks-dependencies-other, Ordering the work, Deciding the scope-date trade-off, Budget. We also talk about infrastructure, architecture, and design (IAD).
Second, complete a version of Sprint Planning. Over-simplified, this includes: Agreeing on the PBIs (product backlog items, or user stories) to commit to in the Sprint, and breaking the Stories into tasks. And fully committing. (I define this as: "We believe, 9 times out of 10, with the usual "stuff happens" around here, we can get all these stories done, in our best professional judgment. And maybe do more.")
Why is the Workshop so important?
Well, in theory, it should not be. But in practice, it is very important for almost every person.
Because it takes the "theory" of the course, and puts it into ineluctable practice. (Ineluctable is a fancy word from James Joyce, meaning "incapable of being avoided".) So that the stark and real meaning of the ideas becomes so much clearer in the real world of the team's real work.
The Workshop is done under the guidance of typically two very experienced coaches (Catherine Louis and myself, so far). We offer has much coaching as we think appropriate, which is more than directly asked for. We keep in mind Yogi Berra's advice (about hitting in baseball): "Think? How am I gonna think and hit at the same time?" That is, too much advice can actually hurt beginners more than help them.
The head-bobbing in the course no longer is good enough. One either "gets it" (to some degree) and does it. Or not.
Some times some resistance becomes more obvious. But usually in the 2 days of the Workshop, that resistance is overcome. Not by the teachers talking at them, nor by anyone else just talking at them. But because their concerns, which maybe have some basis, are soon seen to be minor compared to the benefits. (I do not wish to suggest that all resistance is always and completely overcome. Just that it is addressed much more effectively.)
Does that help? Is that enough?
FAQ
Here are some frequently asked questions.
1. What if I am not attending with my own team?
We can form a Team of people, and you can participate with that Team. Or you can join a real team, for the Workshop, as a consultant (with their permission). If you are partly of an ad hoc team, then we want the Product Owner of that team to be working on his real project or product or effect. So, at least for him or her, it is very real. And that person is responsible for making it real for you.
Is it less effective? Yes, probably somewhat. Is it still useful? Yes. We have had no-one in this category say it was not useful.
2. How many teams are you coaching at a time?
In the workshops, we think it is best to have about two teams per coach, maybe three. So, if there is a large group, there typically will be two coaches.
3. Do we need to prepare?
Yes! As much as you can. It will still be useful even if you do not prepare at all. But the more the Product Owner is prepared with all the information the team will need to do Release Planning, the more effective will be the use of your time. This ideally and typically means including the other key business stakeholders (SMEs) in the workshop team. If you can.
But "if you wait for perfection, you might wait too long." Do what you can before the Workshop, then, wherever you are, do the Workshop.
For a client perspective on the workshop, see here.
This experiment (which it was for me at first) has proven completely successful.
I am now convinced that this is the best way to learn Scrum. Period. And I am convinced mainly because everyone tells us this is so. ScrumMasters, Product Owners, Team members, Managers. Including the managers who insist that it is a MUCH better value to pay extra to get them into the full 4 days.
What do we mean?
First: The best is to have the whole team and some closely related managers attend the whole 2 day Certified ScrumMaster course. Obviously, it isn't just for ScrumMasters anymore. (Was it ever?)
I won't describe that course here, but suffice to say that the way we do it includes lots of interaction, some challenging questions, some improv, some team exercises, including a very realistic Release Planning exercise.
Then, we have the same real team (well, teams, really) do the 2 day Workshop. Each Workshop is a little bit different. But the focus is on two things.
Complete a good (decent) Release Planning for the real project or effort that the team is working on. It is best if the team is just starting the effort. And it is best if the team has access to all the people and resources to make the Release Planning effective. Release Planning includes (over-simplified): Vision, Product Backlog development, Business Value (points), Story Pointing, Risks-dependencies-other, Ordering the work, Deciding the scope-date trade-off, Budget. We also talk about infrastructure, architecture, and design (IAD).
Second, complete a version of Sprint Planning. Over-simplified, this includes: Agreeing on the PBIs (product backlog items, or user stories) to commit to in the Sprint, and breaking the Stories into tasks. And fully committing. (I define this as: "We believe, 9 times out of 10, with the usual "stuff happens" around here, we can get all these stories done, in our best professional judgment. And maybe do more.")
Why is the Workshop so important?
Well, in theory, it should not be. But in practice, it is very important for almost every person.
Because it takes the "theory" of the course, and puts it into ineluctable practice. (Ineluctable is a fancy word from James Joyce, meaning "incapable of being avoided".) So that the stark and real meaning of the ideas becomes so much clearer in the real world of the team's real work.
The Workshop is done under the guidance of typically two very experienced coaches (Catherine Louis and myself, so far). We offer has much coaching as we think appropriate, which is more than directly asked for. We keep in mind Yogi Berra's advice (about hitting in baseball): "Think? How am I gonna think and hit at the same time?" That is, too much advice can actually hurt beginners more than help them.
The head-bobbing in the course no longer is good enough. One either "gets it" (to some degree) and does it. Or not.
Some times some resistance becomes more obvious. But usually in the 2 days of the Workshop, that resistance is overcome. Not by the teachers talking at them, nor by anyone else just talking at them. But because their concerns, which maybe have some basis, are soon seen to be minor compared to the benefits. (I do not wish to suggest that all resistance is always and completely overcome. Just that it is addressed much more effectively.)
Does that help? Is that enough?
FAQ
Here are some frequently asked questions.
1. What if I am not attending with my own team?
We can form a Team of people, and you can participate with that Team. Or you can join a real team, for the Workshop, as a consultant (with their permission). If you are partly of an ad hoc team, then we want the Product Owner of that team to be working on his real project or product or effect. So, at least for him or her, it is very real. And that person is responsible for making it real for you.
Is it less effective? Yes, probably somewhat. Is it still useful? Yes. We have had no-one in this category say it was not useful.
2. How many teams are you coaching at a time?
In the workshops, we think it is best to have about two teams per coach, maybe three. So, if there is a large group, there typically will be two coaches.
3. Do we need to prepare?
Yes! As much as you can. It will still be useful even if you do not prepare at all. But the more the Product Owner is prepared with all the information the team will need to do Release Planning, the more effective will be the use of your time. This ideally and typically means including the other key business stakeholders (SMEs) in the workshop team. If you can.
But "if you wait for perfection, you might wait too long." Do what you can before the Workshop, then, wherever you are, do the Workshop.
For a client perspective on the workshop, see here.
No comments:
Post a Comment