· Self-organizing
teams are composed of individuals who manage their own work, pick up work based
on need, and participate in team decision making.
· Self-organizing
teams must have a common focus, mutual trust, and respect.
By being
self-organizing and self-managing, the team brings decision making to the level
of the problem. This increases the speed and accuracy of problem solving.
Self-organizing and the Scrum Framework
The Scrum
Guide gives the Scrum Master the role of coaching the
Development Team in self-organization but doesn't provide insight or
guide as how this is accomplished. So …
Tips For Management, Agile Coach, and Scrum Master to organize a team toward self-organization
· Management
(yes, management) must establish any parameters that the scrum team is required
to work within. For example, usually only managers can hire and fire people.
Otherwise, management should ensure they don’t get in the team’s way. Managers
need to support the scrum teams rather than be a distraction.
· Give
a scrum team room enough to fail in order to allow them to succeed. Managers
must not ‘step in’ every time they perceive the team is on the wrong track. The
team may very well be on the wrong track but there are several inspect &
adapt opportunities for the scrum team to correct itself. This is the big
reason sprints are short, no more than 30 days, and most often 1 or 2-weeks
long. I've seen a development team start a sprint, go down the wrong architectural
path, discover it, do a re-design, re-do work they had already done,
and still meet the sprint goal. True story. However, the chief architect had
chewed his nails down to the knuckle while not saying anything. How proud was
the development team after this? Extremely – they were trusted to get the job
done and done right.
· From
the start, guide the team to do scrum (scrum guide). Shape the mindset and expectations from the start as this will be
harder to influence and change later. Doing scrum by-the-book will not make you
good at doing scrum but it will be easier for the team to later learn and adopt
the nuances and spirit of scrum.
· Help
the team become confident in their use of scrum early on. Use examples of how
each inspect & adapt meeting can help improve the team’s work and their
environment.
· Remove
any misconceptions the team has of scrum. Most teams will perceive that scrum
is easy to do but it is actually hard to do scrum right day after day.
Anticipate the development team’s reaction to this truth.
· Use
positive reinforcement and build a sense of achievement in the team by helping
guide the team to successfully completing their sprints. Do not allow a team to
over-commit in their sprint planning meeting based on hope alone. Guide the team to select a sprint
goal that is achievable and don’t let ‘hope we’ll get it done’ be the team’s
strategy. Hope is not a strategy.
· Encourage
ongoing adherence to scrum and agile practices. Watch for danger signs the team
is reverting to older, non-agile ways of thinking and doing. For example, do
they want to skip the daily scrum or sprint retrospective. Do they think only
one person can do work in a specific area. Are they not forthcoming at
meetings.
· Get
the customers and users involved in the process. Customers and users need to be
engaged during requirement gathering but most importantly, must be engaged with
the scrum team during the sprint review. If the customers or users are
consistent no-shows at the sprint review or not showing interest at the sprint
results, the development team will more likely lose their sense of purpose and
possibly blame agile for their lowered self-worth.
· Inspect
& Adapt over blame. When someone on the team messes up, don’t say “Jane
screwed up” or anything like this. I would try and restate it along the lines,
“how was it the team allowed this thing to happen and what can the team do to prevent this from happening again?” Encourage the team to
re-examine their team processes to see if something needs to change to avoid
repetition. Every effort should be made to make the team, as an entity,
the focal point during inspect & adapt meetings and discussions rather than
specific individuals. This will help reinforce that the everyone on the team is
equally responsible and accountable for the results and outcomes of the
team. This is along the “all for one and one for all” philosophy. While it’s
important to know someone forgot to get their code, document, etc. reviewed,
it’s more important to understand how the team allowed this to happen
and to see if there’s something the team can do in the future to prevent
it from happening again.
· Identify
team members who hamper or slow down the team’s productivity because of their
personal characteristics and practices. Individual personality of team members
can be considered more important than skill sets when selecting people for a
development team. Work with the team and management to remove people who have
difficulties adjusting to agile. This is a hard decision but one that needs to
happen quickly; these are not ‘bad’ people but are people who can’t adjust to
agile and scrum ways of thinking. Many believe the most productive scrum teams
are open, honest, willing to change, and can see the team being greater than
the sum of the individual team members. If a person doesn’t have or can’t
quickly acquire these characteristics, then they may be an obstacle to
self-organization and pose a threat to productivity necessitating their
removal.
