There has been some interesting discussion on this topic recently.
Two things I wanted to add to my prior post.
1. The business side cannot force the Doers to "do all that I say" in the Sprint.
This is of course a well-known rule of Scrum. But this rule does eject the PO from the Team.
So, in one scenario, the PO cannot force the Team to do all X stories that he or she wants done in the Sprint.
But even before that, the PO should want reliability, meaning, if the Team commits to 8 stories, then at least 8 stories will get done (or done, done -- if you prefer) in that Sprint. The PO does some of the 'real work' (in the form of providing information about the stories and feedback, mainly), so the PO has a say about what he/she can or cannot do to support the Team that Sprint.
What I usually find in the real world, is that the Doers (eg, the coders and testers) want to over-commit. And the PO (at least) should be saying "no, let's not over-commit -- I and we need to predict for the customer, and we need to know what the Team can really do at sustainable pace".
But at least the Business side (often in the person of the PO) cannot force the Team to do 8 stories when, in their professional judgment, they can only do 7. As an example.
Exactly how the Team self-organizes to reach that judgment is up to each team, but ejecting the PO is not an option. The PO has at least some lights on the problem, and so should be heard, just as, for example, the junior tester has some lights on the problem.
There are many possible scenarios, but these are the basics.
2. The issue of whether the PO is part of the Team (yes!) is far greater than just the issue of Sprint commitment.
Yes, Scrum teams have problems with the Sprint commitment. All kinds of problems, with multiple root causes. This was partly discussed (indirectly) in a recent post.
But in the shorter term (eg, intra-day) and in the longer-term (eg, release), the PO is an important part of the (full) Team.
Let's take the Release, and the use of Pareto's idea of the vital few. So, the whole team must be optimizing the 80-20 rule at every level of work (tasks, stories, epics, etc.). And discovering how to do the least amount of work to deliver quickly the best possible product. (See the Agile Principles.) This is a Team effort, led in large part by the PO. But still a full Team effort. The key related idea is cost-benefit analysis (hey, there's another new one!)... how to get the most benefit or business value for the least effort. Again, a joint effort by the full Team.
When troubles arise (and troubles in some sense always arise), who is the Team that will address them? ....well, both the Business side and the Technology side together must collaborate to address them. We might too easily say that in general, both sides must compromise. Each side must accept "lack of control" but high "power to influence", and create some modus vivendi....some way out of the problem together. How do we do this in a practical manner? The simple way of saying it is that the full Team (with the PO) must figure it out.
Again, there are many scenarios, but those seem to us the basics.
***
Yes, I know there is much 'legacy code' in our wetware (our brains, etc.). But this I think is the way forward.
Two things I wanted to add to my prior post.
1. The business side cannot force the Doers to "do all that I say" in the Sprint.
This is of course a well-known rule of Scrum. But this rule does eject the PO from the Team.
So, in one scenario, the PO cannot force the Team to do all X stories that he or she wants done in the Sprint.
But even before that, the PO should want reliability, meaning, if the Team commits to 8 stories, then at least 8 stories will get done (or done, done -- if you prefer) in that Sprint. The PO does some of the 'real work' (in the form of providing information about the stories and feedback, mainly), so the PO has a say about what he/she can or cannot do to support the Team that Sprint.
What I usually find in the real world, is that the Doers (eg, the coders and testers) want to over-commit. And the PO (at least) should be saying "no, let's not over-commit -- I and we need to predict for the customer, and we need to know what the Team can really do at sustainable pace".
But at least the Business side (often in the person of the PO) cannot force the Team to do 8 stories when, in their professional judgment, they can only do 7. As an example.
Exactly how the Team self-organizes to reach that judgment is up to each team, but ejecting the PO is not an option. The PO has at least some lights on the problem, and so should be heard, just as, for example, the junior tester has some lights on the problem.
There are many possible scenarios, but these are the basics.
2. The issue of whether the PO is part of the Team (yes!) is far greater than just the issue of Sprint commitment.
Yes, Scrum teams have problems with the Sprint commitment. All kinds of problems, with multiple root causes. This was partly discussed (indirectly) in a recent post.
But in the shorter term (eg, intra-day) and in the longer-term (eg, release), the PO is an important part of the (full) Team.
Let's take the Release, and the use of Pareto's idea of the vital few. So, the whole team must be optimizing the 80-20 rule at every level of work (tasks, stories, epics, etc.). And discovering how to do the least amount of work to deliver quickly the best possible product. (See the Agile Principles.) This is a Team effort, led in large part by the PO. But still a full Team effort. The key related idea is cost-benefit analysis (hey, there's another new one!)... how to get the most benefit or business value for the least effort. Again, a joint effort by the full Team.
When troubles arise (and troubles in some sense always arise), who is the Team that will address them? ....well, both the Business side and the Technology side together must collaborate to address them. We might too easily say that in general, both sides must compromise. Each side must accept "lack of control" but high "power to influence", and create some modus vivendi....some way out of the problem together. How do we do this in a practical manner? The simple way of saying it is that the full Team (with the PO) must figure it out.
Again, there are many scenarios, but those seem to us the basics.
***
Yes, I know there is much 'legacy code' in our wetware (our brains, etc.). But this I think is the way forward.
No comments:
Post a Comment