The Scrum methodology of agile software development marks a dramatic departure from waterfall management. In fact, Scrum and other agile processes were inspired by its shortcomings. The Scrum methodology emphasizes communication and collaboration, functioning software, and the flexibility to adapt to emerging business realities — all attributes that suffer in the rigidly ordered waterfall paradigm.

23rd
MAR

Guest Column: Scrum Transitions, Part 2 of 3

Posted by admin under Scrum Basics, Scrum Discussion, Scrum Transitions

Scrum Methodology’s Guest Column feature asks individuals throughout the Scrum community to address an issue that is a common obstacle for Scrum teams. In part two of the inaugural column, entitled “Scrum Transitions: Do It Once, Do It Right,” Katie Playfair, director of client services at Danube Technologies, Inc., discusses how teams can work toward making a Scrum transformation a success—long before the transformation actually occurs.

Scrum Transitions: Do It Once, Do It Right, Part Two
Don’t fail before you start – avoiding common pitfalls prior to the pilot stage

By Katie Playfair, director of client services, Danube Technologies, Inc.

It’s all about buy-in

Teams that are successful at Scrum are usually teams that want to be successful at Scrum. If you’re a team member and your team wants to try Scrum, you have the right ingredients to start thinking about a pilot. How can a manager convince a team that Scrum is worth trying? More importantly, how can a manager motivate a team to want to be successful at Scrum? Building buy-in for Scrum at the development level is really about getting teams to embrace that Scrum will be better for them personally and professionally. Note the world “embrace” is not the same as “understand.” The goal of the buy-in phase is to get team members and, specifically, volunteers for your pilot team to become genuinely excited about Scrum. To accomplish that, consider the following:

Teams need to understand why what they’re doing now isn’t working.

First, ask the team what isn’t working for them. Examples include:

  • BA’s are overloaded at the beginning of the project, while developers and QA are bored. QA is overloaded at the end of the project, while other functional groups may be “done” with their contribution and unwilling to help.
  • Team members may be frustrated that requirements seem to change regularly and have a heavyweight change process, resulting in changes “jerking them around.”
  • As in the case of our Intel client case study, there may be unnecessary turnover at the end of a project because of burdensome deadlines falling on particular groups.
  • Work just isn’t fun anymore.
  • The team can’t release a product due to technical debt (when we change something, something else breaks).

Secondly, tell the team what isn’t working for the organization with regard to their product:

  • Development is too slow.
  • The team isn’t open to change due to current processes.
  • The project is constantly slipping deadlines.
  • Software quality has gone down – bug reports are way up.
  • Due to technical debt, the team can’t develop new features anymore.
  • Team member attrition has gone up and the cost of replacing good people is too high.

Team members need to have adequate information about this Scrum framework a manager would like them to try.

What the team needs to know:

  • Working in a Scrum environment is more fun than traditional project management.
  • In Scrum, the input of every team member matters and the organization will ask for your opinion, often on your area of technical expertise. Scrum helps create more equality between team members and each person’s input is considered equally important.
  • The Scrum framework helps ensure that the technical team is responsible for the technical quality of their output and that the business team is responsible for the quality of business decisions.
  • Engineering practices that go hand-in-hand with Scrum will help make late change cheaper and less painful.

How can you get them this information?

  • Distribute case studies from similar companies who have experienced success.
  • Invite an experienced Scrum coach or trainer on-site to share success stories.
  • Encourage developers to attend local agile, Scrum and XP user groups to discuss how their counterparts at other companies feel about it.
  • Invite them to read blogs, participate in online discussions, and generally research Scrum online.

Seek volunteers who agree that current processes could be improved and that Scrum might be worth trying.

  • Express support for doing things differently and ask for motivated folks who want to try it.
  • Demonstrate concern for the welfare of the team and their success.
  • Assure volunteers that they are safe to try and fail at first, while they learn this new way of working.

Does volunteerism work in the real world of Scrum transformations? Yes. Let’s take the case of a 35+ person development organization, divided into two basic categories, “technical leadership” and “everyone else.” “Everyone else” members were treated as lackeys, not allowed to make technical decisions or have any input into how to estimate difficulty of their tasks. Many of the “everyone else” team members were bright and capable, longing for more responsibility and independence. When a Scrum pilot was offered as an option, members of the “everyone else” team rushed to volunteer to be on the team.

Be Sociable, Share!
Comments Feed

Leave a Reply

Scrum Training Courses