With visible task boards, burncharts, and daily Scrums; the team has many tools to organize and manage themselves. But can management abuse these tools? Can it turn into a better way to micro-manage? One of the hardest habits that managers have trouble breaking is the need to drive the team by making task assignments and tracking the results. Even those who truly want to help their teams by managing the task board is not really serving them. Scrum calls for self-organizing teams. The Scrum Master’s job is to help teach the team to self-organize. We’ll talk about how to avoid the traps of micro-management and truly lead the team to freedom at work through self-organization.

The Tale of the Golden Goose: There was once a farmer who bought a golden goose. A week later the golden goose laid a golden egg! The farmer was ecstatic! He cashed the golden egg and had a wild time. The following week he finds that the golden goose laid another golden egg! Again he cashes it in and spends the money. This happens week after week until one week the farmer just can&apos;t wait till the end of the week to get the golden egg so he kills his golden goose and takes the golden egg out of it. He has another wild time with the money. But the next week he realizes that there is no golden egg, for he has killed his golden goose. The moral of the story is to never kill your golden goose.

This team was the first Scrum team with the SM and PO going to training. No formal team training.The team was formed from members of different teams, none of them with serious PRPC development experience.Team membership changed regularly, preventing a good rhythm from forming. Plus, 12 was way too big.There was also a lot of disagreement between the SM and PO and it hurt the team. They never really got out of “Storming”

Team was reduced to a core group so they can focus. Also added a domain expert developer to bring some much needed knowledge and skill into the team.

The Agile Coach was installed as the ScrumMaster to help get them back on the right foot.Focused on getting everyone on the same page with the product vision, Scrum, and how to self-organize. SM did not assign work, build the Task board, or any other administration that the team is responsible for. Team needed to figure out how to work together to get all this other work done.

We reinforced practices that the team had started but let slip a little.A physical board helps in several ways. One, it is a safe opportunity for the team to work together and collaborate on the look and usage of the board. Everyone pitches in to create it. Two, being visible allows everyone to quickly gauge the sprint status. Three, it provides focus for the daily scrum discussions.A hand drawn burndown again is very visible, usually much larger than a printed one. It gets the team to add up the work left and plot a point so people get a better sense of where they are.We spent a lot of time on the Definition of Done, its purpose, content and checking stories against it.Pairing to spread and share learning.Closer collaboration with the PO.

The bug fix sessions replaced triage meetings. It became a working session where team members (all of them) actually fixed bugs, not just talk about them.Probably one of the best team building practice was to have people write appreciations to each other and other teams during the retrospective and have those people take the stickies away as trophies. People display them proudly in the team area.

The team learned to work much more closely (PO included!) It became a true collaboration and not one side telling the other what to do. Trust grew from the successes, from the sharing of ideas, and the common goal and vision.Team members started challenging each other in a positive way. I gave the team the assessment from the 5 Dysfunctions of a Team book and they scored tops.

I think they are one of the model teams.

One minute per person, i.e., 5-6 minutes total for the group

Transcript of "Give Thanks for Scrum 2011 Transparency and Micromanagement"

4.
4Self-Organization in Scrum Development Team decides how to turn Product Backlog into Increments of potentially releasable functionality They select the amount of work in the Sprint They size the work They plan the work They design and build the solutions to the problems presented by the Product Owner Give Thanks for Scrum 11/22/2011 2011

5.
5Micromanagement Encarta “control of a person or a situation by paying extreme attention to small details” Wikipedia The micromanager monitors and assesses every step of a business process and avoids delegation of decisions. Micromanagers are irritated when a subordinate makes decisions without consulting them, even if the decisions are totally within the subordinates level of authority. Give Thanks for Scrum 11/22/2011 2011

15.
The team’s story to Freedom First Scrum team Mix of people from all over Engineering Important project with a vision Membership varied greatly 12 people at its peak

16.
Situation Scrum Master was held accountable for delivery SM “owned” task board and burndown SM directed Daily Scrum SM and PO did Backlog grooming without team New ideas and speaking up were not encouraged Poor team dynamics and rapport

17.
Results Meetings were long and painful Very emotionally driven at times Team was working for story points Wrong focus, caused feeling of judgment Scrum Master and Product Owner friction grew Quality suffered Technical debt increased

18.
First Fix Reduced team size to 7 Added domain expert developer Provided focused coaching to Scrum Master and Team

20.
20Second Fix Experienced Scrum Master assigned Re-introduced the vision Encouraged team to self-organize Pull work into a sprint Create their own plan, task board, burn chart Prime directive established in Reviews Focus on feedback and improvement, not blame Give Thanks for Scrum 11/22/2011 2011

21.
21Retrospective Prime Directive Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand. -- Norm Kerth, Project Retrospectives: A Handbook for Team Reviews Give Thanks for Scrum 11/22/2011 2011

23.
Additional Improvements Over Time Pairing on stories Strong and Improving Definition of Ready (DoR) Improved grooming – whole team, acceptance criteria Open atmosphere encouraged Appreciations handed out for speaking up and being heard Collocated space that was theirs

24.
Intangibles Product Owner Collaboration Team and PO together discuss stories and designs Team suggests changes PO encourages interaction Strong sense of team Challenge and help each other Tester became real member of the team  Even fixed bugs Team morale skyrocketed

25.
Results Velocity: From : 10-20 range with 12 people To: 30-40 range with 7 people 2x to 4x the raw velocity improvement and 3x to 7x the productivity improvement Higher quality output with stronger DoD Product Owner sees and appreciates value delivered by the team Once a team in trouble, now one of the model teams