An interesting realization I came to.
Maybe this is a very obvious, Scrum 101 understanding for someone... But I think this may actually be helpful for some, so here it is.
In a large-scale product, with different teams working on different tiers, there should be 2, or even 3 types of Product Owners (POs).
"Wow!" - an experienced Agilist would exclaim. "Hold your horses! Are you talking about giving up on the idea of cross-functional, feature-oriented teams (as opposed to architectural layer-based teams)?!"
No, of course not. But let's dive into a real-life example to make the things clearer.
Imagine a complex product, with a serious back-end platform, and a thick client application.
To make the things even more interesting, assume the client and the back-end using different dev platforms and operating systems (MS Windows, Android, iOS).
It may simply be just not feasible to have a single team working on such a plethora of technologies. A team of such kind will, most probably, end up being mediocre in everything it does - instead of excelling in a narrower set of tools and technologies.
I don't think it would be reasonable to expect each and every universalist developer in a team to master mobile, embedded and back-end applications equally well.
And this means that there ought to be several "tiers" (I deliberately don't call them "layers") into which development efforts will be grouped.
Now, let's look at this product through the eyes of "normal", by-the-book Product Owners.
What kind of stories should they produce? That's right, *user* stories. "As a user, I want ..., so that ...".
But with the sort of the product described above, such user stories will most likely have to be translated into a large amount of work. Too large to be worked on by a single Scrum team in a single Sprint. Moreover, the work is likely to be spanned between theclient application and the platform servers, and hence will be done by different teams (specializing on the different "tiers", as described above).
All this leads, inevitably, to the need to have multiple technical stories that "support" (or "enable") the original user story.
Who will formulate those? I don't think the "normal" Product Owner may be expected (or even qualified, in many cases) to do that. And how will these stories be demoed to the PO, in order to claim their completion?
That, I believe, is a work for an Enterprise Architect (EA): analyze all the requirements and dependencies, define the APIs, draw sequence diagrams...
This is the second type of PO, "Enterprise Architecture Product Owner".
Their stories will sound more like "As an EA, I want use case X to be implemented as the flow Y using API Z".
And still, that's potentially not the end of it...
With a sufficiently complicated product, even an EA won't be familiar enough with the intricacies of the real, hands-on implementation.
Hence, the stories created by an EA PO may have to be further broken down into even smaller technical stories that can actually be consumed by the Scrum teams.
This task can probably be entrusted to a Technical Lead of a sort - someone knowledgeable enough about implementation details, and having a good grasp on the Enterprise Architecture on the other hand.
Only at this level the Acceptance Criteria may be formulated in a form detailed enough for the teams to successfully understand and implement the stories - and to be able to do so in a single Sprint.
So, here we are, ending up with: "User Features PO", "Enterprise Architecture PO", and "Tech Lead PO", each of them turning into a next level "customer".
Of course, applying this model will require a lot of meticulous coordination and sequencing.
The technical stories will be worked on first (and demoed to the Tech Lead PO upon getting "done" - most probably by demonstrating the automated acceptance tests suite).
The "EA Stories" will then be approached, and demoed to the EA PO (again, using higher level automated acceptance tests, or integration tests).
And finally, the original user story will be completed (mostly by integrating the results of the supporting EA and technical stories), and demoed to the User Features PO.
It's important to remember that even in this model the EA and the Tech stories are still driven by the original user story, and don't have a justification of their own.
In some cases, EA stories may be omitted (if no high-level architectural involvement is required).
Thoughts?
Am I creating unnecessary entities, and should make a better use of my Occam's razor?
Or is there some rational idea here?
Maybe this is a very obvious, Scrum 101 understanding for someone... But I think this may actually be helpful for some, so here it is.
In a large-scale product, with different teams working on different tiers, there should be 2, or even 3 types of Product Owners (POs).
"Wow!" - an experienced Agilist would exclaim. "Hold your horses! Are you talking about giving up on the idea of cross-functional, feature-oriented teams (as opposed to architectural layer-based teams)?!"
No, of course not. But let's dive into a real-life example to make the things clearer.
Imagine a complex product, with a serious back-end platform, and a thick client application.
To make the things even more interesting, assume the client and the back-end using different dev platforms and operating systems (MS Windows, Android, iOS).
It may simply be just not feasible to have a single team working on such a plethora of technologies. A team of such kind will, most probably, end up being mediocre in everything it does - instead of excelling in a narrower set of tools and technologies.
I don't think it would be reasonable to expect each and every universalist developer in a team to master mobile, embedded and back-end applications equally well.
And this means that there ought to be several "tiers" (I deliberately don't call them "layers") into which development efforts will be grouped.
Now, let's look at this product through the eyes of "normal", by-the-book Product Owners.
What kind of stories should they produce? That's right, *user* stories. "As a user, I want ..., so that ...".
But with the sort of the product described above, such user stories will most likely have to be translated into a large amount of work. Too large to be worked on by a single Scrum team in a single Sprint. Moreover, the work is likely to be spanned between theclient application and the platform servers, and hence will be done by different teams (specializing on the different "tiers", as described above).
All this leads, inevitably, to the need to have multiple technical stories that "support" (or "enable") the original user story.
Who will formulate those? I don't think the "normal" Product Owner may be expected (or even qualified, in many cases) to do that. And how will these stories be demoed to the PO, in order to claim their completion?
That, I believe, is a work for an Enterprise Architect (EA): analyze all the requirements and dependencies, define the APIs, draw sequence diagrams...
This is the second type of PO, "Enterprise Architecture Product Owner".
Their stories will sound more like "As an EA, I want use case X to be implemented as the flow Y using API Z".
And still, that's potentially not the end of it...
With a sufficiently complicated product, even an EA won't be familiar enough with the intricacies of the real, hands-on implementation.
Hence, the stories created by an EA PO may have to be further broken down into even smaller technical stories that can actually be consumed by the Scrum teams.
This task can probably be entrusted to a Technical Lead of a sort - someone knowledgeable enough about implementation details, and having a good grasp on the Enterprise Architecture on the other hand.
Only at this level the Acceptance Criteria may be formulated in a form detailed enough for the teams to successfully understand and implement the stories - and to be able to do so in a single Sprint.
So, here we are, ending up with: "User Features PO", "Enterprise Architecture PO", and "Tech Lead PO", each of them turning into a next level "customer".
Of course, applying this model will require a lot of meticulous coordination and sequencing.
The technical stories will be worked on first (and demoed to the Tech Lead PO upon getting "done" - most probably by demonstrating the automated acceptance tests suite).
The "EA Stories" will then be approached, and demoed to the EA PO (again, using higher level automated acceptance tests, or integration tests).
And finally, the original user story will be completed (mostly by integrating the results of the supporting EA and technical stories), and demoed to the User Features PO.
It's important to remember that even in this model the EA and the Tech stories are still driven by the original user story, and don't have a justification of their own.
In some cases, EA stories may be omitted (if no high-level architectural involvement is required).
Thoughts?
Am I creating unnecessary entities, and should make a better use of my Occam's razor?
Or is there some rational idea here?
The original discussion can be seen here (LinkedIn "Scrum Practitioners" group membership is needed to see the page).
No comments:
Post a Comment