Mike is a certified PMP project manager and a certified ScrumMaster. Mike was involved with the creation of the DSDM Agile Project Leader certification, holds this certification at the Foundation, Practitioner, and Examiner levels. Mike was named an honorary member of the DSDM consortium and served on the board of APLN and the Lean Software and Systems Consortium. He currently co-leads the PMI Agile Community of Practice. Mike is a DZone MVB and is not an employee of DZone and has posted 148 posts at DZone. You can read more from them at their website. View Full User Profile
It was kind of neat to spend the
time yesterday going back over all those old posts and interesting to
see how the process of writing this out has shaped how I look at the
whole Product Owner and scaling issue. The timing of the Scrum
Gathering was good too. It was nice to get down to Orlando and talk to
folks about how they are applying this stuff out in the field.
time around I said that the Product Owner at scale was really an issue
of Product Ownership in the enterprise. How are we going to get all our
teams working on the right things so we end up with a cohesive and
integrated product? The key to having this conversation at an
enterprise level is to have a thorough discussion around how we are
going to handle the three key enterprise Scrum teams: the design
scrum... the development scrum... and the QA scrum.
Ownership becomes a matter of deciding how to identify all the backlog
items, at the beginning of the project, so we can effectively assign
work and make sure the entire scope of the project is accounted for.
role of the Product Owner... or the Product Owner Team is to break each
backlog item into a design story... a development story.. and a test
story. This is critical for normalizing the input to the team and
making sure that each team has plenty of backlog items to work on...
and most importantly... the right backlog items to work on... in the
right predetermined order!
I mean... how can you write software before you have created the specification? At some point this becomes just common sense!
said... because of the nature of Scrum at enterprise scale, some teams
will inevitably have less to do at certain times in the project.
was really cool to hear Ken Schwaber (during his keynote at the
Gathering) finally discuss that to effectively scale Scrum, we need to
put more definition around how to matrix people and teams across
multiple projects. Ken's point was that multiple project assignments
and matrixed management is the only way to normalize velocity in an
enterprise Scrum implementation.
Next post we'll talk about the
other mission critical teams that enable enterprise Scrum. We'll talk
about the BUFD scrum team... the Governance scrum team... the PMO scrum
team... and the centralized process improvement scrum team. We'll
introduce some key tooling concepts like the Scrum Market Requirements
Document and the Enterprise Scrum Gantt Chart.
you do a daily stand-up and call requirements backlog items... you are
probably doing Scrum! See you guys on the 2nd.