Apr 222014
 

Describing the end state of a successful Scrum rollout can be very exciting for beginning teams. It can also seem a little daunting, particularly after that first sprint, in which the team could feel some of its potential but wasn’t yet able to reach it. I find this can be especially true for teams adopting Scrum in a larger environment that’s not yet an ideal environment for Scrum. Perhaps the whole team cannot dedicate itself full time to the Scrum project yet, or the product owner is still transitioning out of previous product management responsibilities to other parts of the organization. As much as we would like our beginning Scrum teams to have every advantage, these and many other imperfections are common in the real world.

A tool I use in these situations is to draw out a series of baby steps. Mini milestones for incremental progress can help a team in a challenging environment claim small victories as the team moves along a path to Scrum nirvana. Far from being a cop-out, I’ve seen teams use baby steps to get them going and keep them going in tough environments — as long as the environment, too, is evolving from less perfect to more perfect.

You can think of these stepping-stones as the most important components and functions of an environment conducive to Scrum and a well-tuned Scrum team. Ideally, we want all these steps to occur. In fact, for many of these milestones, if the team hasn’t achieved them, then we can’t really say (yet) that the team is doing Scrum.

Let’s think of it as incremental progress. If a team can manage only a couple of the steps for now, that’s better than nothing. Having the rest as goals, and moving toward them, is the important thing.

The stepping-stones, expressed here as desired end states, aren’t in any particular order. Each team might be able to achieve a different set at different times in its evolution, depending on its environment and the makeup of the team:

  • The team has regular daily check-ins to share status and move toward continuous improvement. Some teams say that they know what’s going on well enough without checking in. More likely, they aren’t yet working together as a team. The ScrumMaster should facilitate the team toward this goal early, because it’s an important part of the belonging level.

  • The team is self-managing, rather than managed by the project manager or development lead. Giving the team the responsibility and authority to get its work done the way it thinks is best is perhaps the most central component of Scrum. Responsibility for outcomes helps people step up; assigning accountability to the whole team instead of individuals activates the team dynamics at the higher levels of Maslow’s hierarchy.

  • The team is self-sufficient and is able to do product development “full-stack,” in an integrated way. This goal is hard for teams in environments that have been compartmentalized for a long time, with back end separated from front end, and testing and deployment separated from design and development. It’s important for the esteem level for the team to see its accomplishments take form for the customer, — not just in a tiny isolated part of the product development chain.

  • Sprints — the team does its work in iterative cycles of a few weeks. Getting into a rhythm of planning, work, and reflection will help the team work on its esteem level — gaining achievements and building confidence.

  • The team’s work is described in Agile stories, not requirement documents. Sometimes the team’s environment is requirements-heavy, and it can take some time for the organization as a whole to trust Agile stories instead of requirements documents. Since this is an organizational change outside of the team’s organic growth, we think of it as the environmental level.

  • Agile stories are written by the team, not product management or (only) the product owner. Remember, Agile stories aren’t the totality of product requirements; they’re really artifacts of the process of team discussion and story-writing exercises with both the product owner and the entire team. Having the whole team involved in story writing is important for the belonging level. With a little practice, story writing is a knowledge-building exercise. Stories begin to make sense to the team and other parts of the organization, activating the esteem level.

  • Continuous improvement with a goal. In beginning teams, it’s hard for the team to focus on continuous improvement. That’s because that really occurs at the self-actualization level. ScrumMaster and stakeholders have to be gentle and model good continuous improvement practices until the team works up to the top level of the hierarchy.

  • The product owner and ScrumMaster are separate people. Stakeholders sometimes have trouble understanding Scrum roles. Noticing two “overhead” people in the team makeup, they may be tempted to combine the roles, not realizing that the creative tension between product owner and ScrumMaster is very important. Making the roles separate will help the team move along the belonging-esteem-actualization path much more quickly.

  • The product owner is highly available to the team. Sometimes product owners are tempted or tasked with other responsibilities. Taking the time to concentrate fully on the Scrum backlog, the team, and its questions helps the team with the esteem level, and its evolution toward actualization.

  • The backlog is well groomed, with enough stories for a couple of sprints, with estimates. This component starts to come together as the team comes together in its belonging level, and continues to improve into the esteem level. Backlog quality is also a rich area to mine for improvement in the self-actualization level.

For team members, mini milestones can provide a measure of self-awareness while going through the process of developing maturity as a Scrum team.

avatar

Peter Kaminski

Peter Kaminski is a Senior Consultant with Cutter's Agile Product & Project Management practice. He has served as technical cofounder for five Internet startups, including Socialtext, a leading provider of enterprise social software, and Yipes Communications, a pioneering provider of Ethernet WAN services.

Discussion

 Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

(required)

(required)