Thanks to Maria Diaconu and Dave Muldoon, and with the help of Catherine Louis and others, we have significantly revised our Certified Scrum Product Owner course.
This has been in progress in a way for years. I have long thought that the CSPO course should be treated as a post-CSM course, an "advanced" course.
We have decided to call it "intermediate" because, well, attendees are not advanced yet when they take the course. We are basically assuming attendees have taken the CSM, or done something else roughly equivalent.
Here is a description of the course:
http://leanagiletraining.com/RDUCSPO/RaleighCSPO+WS.html
Others and I think this is important. Because very often our biggest impediment is "PO is not good enough". Not that the person is not a good and capable individual. But the person is relatively weak at playing this new and unknown role of Product Owner. As any newbie would be for the first 2 years.
It is a difficult and also very important role. Much of the success of a Scrum team relies on the abilities and the execution of this role.
Workshop
Catherine Louis got us introduced to workshops, and now the attendees have totally convinced me this is the right way to go. Two days of 'course' is as much as they can take at one time. But the learning does not become nearly as 'real' until they do the workshop, for 1 or 2 days.
For the intermediate CSPO, we are modifying the Workshop a bit. It will work like this.
1. We will tell attendees in advance what their options are.
2. One option is to take a real project and do Release Planning (3/4) and Sprint Planning (1/4). If we do not have a real team, then the person with the real project becomes PO and forms a 'team' from workshop attendees. The ideal is to bring your real team that will start the project on Monday.
3. One option is to take all or part of the Business Value Engineering process (explained in the course), and work on that. As a team. Again, this must be real life at least to the PO leading the team in the workshop. Note: In the course we gave BVE theory and tools and some experience, which the team can then apply.
4. One option is to work as a team in solving real life impediments. We teach the A3 method for impediment removal, and typically the team does some part of the A3 process. Or something very similar. Sometimes a time spends some time doing #3 and some time #4.
5. Within reason, we are open to breaking any of these rules (above and others), so long as the person(s) has a good chance of achieving some better value.
How and why does this work?
Perhaps it is already obvious to some readers.
In the act of doing real work, all the real problems of life come up. And are either addressed by the person, by the team, or the coach (eg, me).
Sometimes it seems funny to me, but in effect they say, after we talk, "oh, so, you were really serious when you said XYZ [about Scrum] in the course?" In other words, the real work in the workshop forces them to make real connections between the ideas of Scrum and the reality of day-to-day work and getting the working product out the door to the customer.
Again, these are not my insights or assumptions. This is what attendees of the workshop tell me repeatedly. Everyone who has talked to me about it says it is very valuable. Often the most valuable thing!
People work as teams, and all the issues of teamwork come up. (Not always happily, just as in the real world.) And they learn from the team experience. They experience that they can mostly do what we talked about and did exercises on in the course (with maybe minimal help or reassurance). This gives them much more confidence in facing the real world after the course.
We coach from the sidelines. That is, I think we are smart enough to sit down and get out of the way. We are available whenever anyone has a question. (Occasionally if it is a question others will be interested in, we stop the workshop briefly to discuss with all.)
We also interject when teams are doing something new and when we know they need a bit of coaching. Or when the team is obviously 'stuck'.
Please tell us if this answers most of your questions about what the workshop is.
This has been in progress in a way for years. I have long thought that the CSPO course should be treated as a post-CSM course, an "advanced" course.
We have decided to call it "intermediate" because, well, attendees are not advanced yet when they take the course. We are basically assuming attendees have taken the CSM, or done something else roughly equivalent.
Here is a description of the course:
http://leanagiletraining.com/RDUCSPO/RaleighCSPO+WS.html
Others and I think this is important. Because very often our biggest impediment is "PO is not good enough". Not that the person is not a good and capable individual. But the person is relatively weak at playing this new and unknown role of Product Owner. As any newbie would be for the first 2 years.
It is a difficult and also very important role. Much of the success of a Scrum team relies on the abilities and the execution of this role.
Workshop
Catherine Louis got us introduced to workshops, and now the attendees have totally convinced me this is the right way to go. Two days of 'course' is as much as they can take at one time. But the learning does not become nearly as 'real' until they do the workshop, for 1 or 2 days.
For the intermediate CSPO, we are modifying the Workshop a bit. It will work like this.
1. We will tell attendees in advance what their options are.
2. One option is to take a real project and do Release Planning (3/4) and Sprint Planning (1/4). If we do not have a real team, then the person with the real project becomes PO and forms a 'team' from workshop attendees. The ideal is to bring your real team that will start the project on Monday.
3. One option is to take all or part of the Business Value Engineering process (explained in the course), and work on that. As a team. Again, this must be real life at least to the PO leading the team in the workshop. Note: In the course we gave BVE theory and tools and some experience, which the team can then apply.
4. One option is to work as a team in solving real life impediments. We teach the A3 method for impediment removal, and typically the team does some part of the A3 process. Or something very similar. Sometimes a time spends some time doing #3 and some time #4.
5. Within reason, we are open to breaking any of these rules (above and others), so long as the person(s) has a good chance of achieving some better value.
How and why does this work?
Perhaps it is already obvious to some readers.
In the act of doing real work, all the real problems of life come up. And are either addressed by the person, by the team, or the coach (eg, me).
Sometimes it seems funny to me, but in effect they say, after we talk, "oh, so, you were really serious when you said XYZ [about Scrum] in the course?" In other words, the real work in the workshop forces them to make real connections between the ideas of Scrum and the reality of day-to-day work and getting the working product out the door to the customer.
Again, these are not my insights or assumptions. This is what attendees of the workshop tell me repeatedly. Everyone who has talked to me about it says it is very valuable. Often the most valuable thing!
People work as teams, and all the issues of teamwork come up. (Not always happily, just as in the real world.) And they learn from the team experience. They experience that they can mostly do what we talked about and did exercises on in the course (with maybe minimal help or reassurance). This gives them much more confidence in facing the real world after the course.
We coach from the sidelines. That is, I think we are smart enough to sit down and get out of the way. We are available whenever anyone has a question. (Occasionally if it is a question others will be interested in, we stop the workshop briefly to discuss with all.)
We also interject when teams are doing something new and when we know they need a bit of coaching. Or when the team is obviously 'stuck'.
Please tell us if this answers most of your questions about what the workshop is.
No comments:
Post a Comment