Effective Team Chartering - Scrum Gathering Orlando March 2010
59
Three factors influence the patterns that emerge:
- The container sets the bounds for the self-organizing system. It defines the "self" that organizes.
- Significant differences determine the primary patterns that emerge (power, level of expertise, gender, ...).
- Transforming exchanges form the connections between system agents.
"Just as a person needs time and space to incubate thoughts before a new Idea can emerge, a system needs a bounded space for the emergence of new patterns."
Basic
Agreements
Multiple Teams?
"... organizing a self-organizing system is not only an oxymoron, it will very likely throw a spanner in the works."
“Simple, clear purpose and principles give rise to complex, intelligent behavior. Complex rules and regulations give rise to simple, stupid behavior.”
"company culture - not rulez"
Team doesn't internalize the charter because they don't own it.
Show me how a project starts and I'll tell you how it ends!
Sources
Harrison Owen,
Wave Rider: Leadership for High Performance in a Self-Organizing World
Edwin E. Olson and Glenda H. Eoyang,
Facilitating Organization Change: Lessons from Complexity Science
A modern English translation of the Magna Carta of 1215:
http://www.britannia.com/history/docs/magna2.html
Magna Carta 1215
23. Neither a town nor a man shall be forced to make bridges over the rivers, with the exception of those who, from of old and of right ought to do it.
Simon Roberts
simon.roberts@scrumcenter.com
Jens Korte
jens.korte@syndato.com
Effective Team Chartering
Project Charter
vs.
Team Charter
In classical project management often a project charter or project definition is used to define the project goal, the scope and the definition of success. Normally it is predefined from upper management.
In Scrum this is typically covered by the product vision.
One precondition for self organization is a clearly defined system boundary. A Team Charter helps to define these boundaries.
The system is not just the team - the (generative) rules also define the system.
By spending time helping the team to define its own rules (which are added to those that we import as part of Scrum), we can make the system boundary clear.
"Self-organization is the tendency of an open system to generate new structures and patterns based on its own internal dynamics. Organization design is not imposed from above or outside; it emerges from the interactions of the agents in the system."
Is a
Team Charter Important for Self Organization
Anti-Patterns
Facilitating Organization Change: Lessons from Complexity Science (Edwin E. Olson and Glenda H. Eoyang)
Too Detailed
Self-
Organizing
What is a
Team Charter?
Harrison Owen
Wave Rider: Leadership for High Performance in a Self-Organizing World
Dee Hock, founder of VISA
Self-organization damaged potentially
"Lean DoD"
team members during coaching
Dictated by
At a recent coaching engagement we saw this in action. The development manager distributed a detailed description of done to all team members (2 Scrum teams). During the team-chartering exercise, we facilitated the teams in building their definition of done. They agreed on and tookover all of the points raised by the development manager. At the end of the first sprint, it was clear that the teams had not really been following the definition of done. This was a major topic discussed in the retrospective.
Management
Comes from
Coach
Team
Owner?
The team writes, takes responsibility for and owns their charter. ScrumMaster and Product Owner give input.
For a particular organization, there might be mandatory entries such as:
- Technology
- Governance compliance requirements
- CMMI requirements
Not Enough
Time
Magna Carta 1215
Team Norms &
Communication Rules
35. There shall be one measure of wine throughout our whole realm, and one measure of ale and one measure of corn--namely, the London quart;--and onewidth of dyed and russet and hauberk cloths--namely, two ells below the selvage. And with weights, moreover, it shall be as with measures.
Planning &
Estimation
Technology &
Engineering Rules
Estimation
User Stories in Story Points
Tasks not larger than 2 days
Tasks in 1/4 days
Planning Poker
13. The city of London shall enjoy all its ancient liberties and free customs, both by land and by water. We also will and grant that all other cities, boroughs, towns, and ports shall enjoy all their liberties and free customs.
TDD
A group of people or animals linked in a common purpose.
New Code:
- Write JUnit before code
- Write code until test succeeds
- Refactor code
Magna Carta 1215
Rules
Bug detected:
Meetings
- Write test to reproduce bug
- Fix the code
- Refactor code
- Respectful conversation
- Active listening
- Expecations of PO:
Daily Scrum: 9:30 am, conf. room 2
Sprint review: Wednesday 2:00 pm
Acceptance Tests in Selenium
and FitNesse
Retrospective: Wednesday 4:00 pm
Bi-weekly:
Sprint planning: Thursday 10:00 am
Penalty for being late:
3 times in a sprint: bring a homemade
cake to retrospective.
- regular presence at Daily Scrum
- chance for interaction with team directly after
- timely feedback
- timely response to questions
- Daily Scrum
- Sprint planning meeting
- Sprint review
- Retrospective
- Requirements workshop
- Estimation meeting
By helping a team to create a charter we can clearly define the container inside which self-organization can take place.
Ready:
- understood
- estimated
- small
- acceptance criteria defined
- prioritised
Sprint
Retrospective
Planning
Review
- implemented
- tested
- integrated
Done
Benefits
Task
Ready
Story
- Coded
- Unit tested
- Reviewed
- Documented (JavaDoc)
- Checked in
- Integrated
- ...
Increment
- Acceptance criteria fulfilled (automated test)
- User documentation updated
- Integrated (automated acceptance test runs in Hudson)
- Accepted by PO
- ...
Ready
During each sprint:
- Requirements workshop
- Estimation meeting
- Time for research
- All story tests OK
- Installation scripts updated
- Deployed in system integration environment
- Release note updated
- Regression test OK
- Performance test OK
- ...
Uncovers unclear expectations and ambiguous goals
An agreement between the PO and team about what ready means and how to get to ready before each sprint - perhaps institutionalized by a requirements workshop and estimation meeting during each sprint as part of the up to 10% of the sprint capacity that Scrum allows for product backlog grooming. Post-estimation meeting research is also important - the team needs to have time between prioritised backlog being published and sprint planning to increase their understanding of the backlog items that will be candidates for the next sprint.
Common understanding of work
Functional communication inside and outside the team
Helps team forming
Defines a container, so that self-organization can emerge
Creating a Team Charter
Dedicated workshop before first sprint
Facilitated Brainstorming
Meetings
Team decides
Planning & estimation
Team norms
Communication rules
Dot voting
Technology
Integrate organizational
needs
Engineering rules
Ready
Definition of done
The journey is as important as the destination!