Rethinking Scrum and XP
Lately we’ve been exploring the idea of moving past the specific practices of Scrum and XP and focusing more on what we are doing rather than how we are doing it. Rather than focusing on having ScrumMasters and Product Owners, we need to start thinking about the value these roles are delivering and how we can deliver that value at scale. Meta-Scrums and Chief Product Owners might be part of the solution… but our organization might require more.
To that end… if we are going to create situationally specific strategies at scale… we can start by talking about the core capabilities these roles have to deliver at the team level:
Product Owner
- Set Product Vision
- Define Product Roadmap
- Define Requirements
- Sequence Work
- Communicate Requirements to Development
- User Acceptance Testing
- Manage Stakeholders
- Set release date
ScrumMaster
- Ensure Process Adherence
- Remove Impediments
- Ensure Internal Communication
- Ensure External Communication
- Maintain a Productive work environment
- Team Building
Development Team
- Assign work to team
- Make commitments
- Throttle work
- Design the solution
- Write software
- Maintain code quality
- Take corrective action
- Deliver features
- Deploy the Solution
Everybody
- Continuous Improvement
- Define working agreements
- Resolve Conflict
- Manage Risk
- Set delivery heartbeat
Over the next few weeks we’ll explore how these core team capabilities get expressed at each of our five levels of agile adoption. For now I’d like know if you guys think we’ve got this list right. Is there anything we need to add? Anything that needs to be removed? Your feedback is really appreciated.
If you have a minute… head over to Dennis’ blog to see his take on this. Similar content… different presentation.
Comments (8)
Brian Sondergaard
I like where you guys are going with this. It's going to be important that everyone really distinguish the "capabilities" from the "process", and the capabilities you're listing seem to be headed in the right direction. As you refine the model, there may be some potential for "normalization".
For example, when looking at the list of Development Team capabilities, it seems to me that some of the items are more likely qualities (or requirements) of other items as opposed to full-fledged capabilities of their own. For example, would it be beneficial to collapse "Assign work to team", "Make commitments", and "Throttle work" into a single capability along the lines of "Manage work intake and throughput"? Would "Design the solution", "Write software", and "Deliver features" all be part of "Create Product/Solution"? Finally, I wonder if it would be important to call out a specific capability related to the creation of the architecture. With an obvious bias, I'll assert that the architecture is a first-class "outcome", in part because it typically lives much longer than the delivery of an individual project.
Wherever it winds up, I hope the model will strongly emphasize the "outcomes" and results – keeping the processes and procedures (and "qualities") at the appropriate (lower) level of abstraction.
Keep up the good work!
Mike Cottmeyer
As it stands right now… I optimized for being explicit rather than succinct. My goal is to talk about these capabilities in language that is going to resonate intuitively with the everyday practitioner. I did not want too much hidden underneath a label.
Regarding architecture… at the single team level… I am assuming that architecture and design are the same. At least done by the same people in the same step. I would definitely call out architecture as a higher order expression of design at 1st order and above.
Thanks for the feedback.
Basim Baassiri
It seems that most of the roles are defined very well with the big exception (in my mind) the role of the software tester or quality assurance practitioner.
Was the role an oversight or the role of Quality Assurance / software testing does not warrant to be a core role?
Mike Cottmeyer
Thanks for the comment Basim.
Scrum only defines this abstract idea of a team. It doesn't really say who is on the team… only that they are responsible for delivering working software.
You'll see in my model that 'maintain code quality' is something that I call out. In my mind, that involves unit testing, regression testing, and any manual testing that needs to take place. Anything that is required to get to an accepted user story.
In other words, the development team has to have everything it needs to deliver working software. If that is someone from the QA group, that person is included in the development team.
Make sense?
Dennis Stevens
Baasim,
In the the product owner capabilities you will also see User Acceptance Testing. Quality Assurance would play a role in that as well.
Dennis Stevens
Mike Cottmeyer
Yep…. totally agree with Dennis. You'll find some of our traditional roles blended across all three of the primary scrum roles. Notice there is no project manager… no BA… no DBA!?
Michael Dubakov
I like the roles description! Very clear.
Alex
Really like this breakdown, Mike. Maybe would like to see some mention of anticipated value. Perhaps ROI. That may be encapsulated in a combo of "sequence work," and "product vision." Any reason you chose "sequence" over "prioritize?" Seems the latter is a stronger, clearer, and appropriate term. And also more common.