Our Fuller Picture of the Scrum Team

Basic Scrum Model1This is our basic picture of a single Scrum Team working on one release. (For example, this picture does not try to address ‘scaling’, if that were relevant.)

Let’s start with the Product Owner, who is responsible for the quality of the Product Backlog.

Then we mention the ScrumMaster, who is responsible for aggressively attacking the impediments.  Or leading that charge.  Specifically, the SM should help the team self-organize and self-manage in a competent manner in an environment that typically is not as supportive as we would like. The SM helps remove the impediments.

We have of course the Implementers.  They do the real work of building and testing the environment.

Of course we have a Vision, which we all are working toward.

We have a Product Backlog that makes the work concrete. The basics are a simple list of all the work we might do, in order. Mostly the features, but really anothing this Team must do.

Representing the customers and the business side we have some part-timers.  We call them Business Stakeholders.  The essential thing they must do is showup at the Sprint Review and give good feedback about what the customer will want in the future.  No one knows the customer that well, not even the customer, and especially not about the future.  But these BSHs are better than most.

But the key group we want to point out is the Chickens.  By chickens we mean part-timers who help the Team, and mostly help the Implementers in building or testing the product.

These circles that represent chickens can represent many things.  First, at a high level, they represent the idea that the Team is never totally autonmous. In my experience, the Team is always dependent on people outside the Team.  The Team never has all the skill sets, for example.

Who can these people be?  A circle can be one person.  A circle can be a group (eg, a department or function).  A circle could be another Scrum team.  A circle could be a vendor.  A circle could represent people in many different configurations.

What might these people do for us?  Many things, alnmost anything that one might imagine.  A person could advise us. A person could have knowledge.  A person could work with us.  A person could do some work.  A person could produce a widget that goes inside our product.  Many possibilities.

The key thing is that we must put them in the picture, identify those people, name names.  Then the Team must figure out how to manage people who do not have “skin in the game”, who do not think that the product we are working on is their main priority.  This is trouble, or at least often can be.

Facebooktwittergoogle_plusredditlinkedinmail

« « Agile Transformation – 2 || Agile Transformation: What is it? Success? Metrics? » »

Posted in: Better Agile, Scrum
Tagged:

Leave a Reply

Your email address will not be published. Required fields are marked *