Monthly Archives: October 2012

Mixing New Development and Support on the Same Team

There are lots of reasons why it is good or bad to have a Scrum team handle both new development work as well as support work. When an organization determines that the best way is for support and new development to be done by the same team, careful planning and a little bit of discipline during sprint execution can help meet sprint goals and stay on top of issues reported by users.

Planning

During sprint planning, a certain percentage of the team’s time needs to be allocated to support. For an existing system, that percentage can be based on historical metrics from the time tracking system. Of course this requires that people’s time for support and new development be tracked under separate categories. Also, the support allocation may vary sprint by sprint if there are extraordinary events expected in a sprint (e.g. major new features released to production in the previous sprint).

Based on the percentage allocated to support and non-development work such as backlog grooming, company meetings, etc. the team’s capacity to work on user stories is reduced. A sample capacity calculation is show in the diagram below:

During sprint planning, user stories are pulled into the sprint plan, tasks are identified for each story, and task hours are estimated.  When the team has reached its hours of capacity based on total task hours, the sprint plan is complete. There is no need to create placeholder tasks for support items unless that helps with time tracking (more on this later).

All concerned stakeholders (including the team!) need to be aware what percentage of the team’s time is going to be allocated to support work.  This becomes more important if a team gets hit with a lot of support work and the sprint commitment is jeopardized. This also underscores of the importance of looking at the team’s velocity as an average across many sprints since it will fluctuate depending on support needs in a given sprint.

In Flight

Ground rules must be established and agreed to by team members, product owners, and representatives of the end user community that determine what work is handled as support items to be worked on immediately or as new backlog items for future sprints.  One model for this is:

For business stakeholders who previously worked in environments where the support team would jump on any support request as soon as they received it, the ‘4 hours or less’ rule is the most difficult one to get used to. In traditional project organizations with separate development and support teams, some stakeholders viewed support teams as a way of bypassing development teams that were mired in 6 or 12-month long development cycles. When the organization adopts agile and they see that their requests can be considered (of course factoring business value relative to other backlog items) within a few weeks, they are typically much more receptive to these types of guidelines.

Who works on support requests depends on the size and composition of the team.  A couple of models are:

  • Dedicate one person per sprint to be the primary support person.  Other team members focus on sprint backlog items. This works well when the team has a good balance of knowledge and skills.
  • Pick up support tickets as they come in. This can work well and fill in some of the time gaps or delays within a sprint. However, a high volume of tickets can make it hard for team members to get traction on sprint backlog items.

Just like it is important to provide high visibility for sprint backlog items and progress, it is just as important to make support work visible. A Kanban board, complete with Expedite lane for high-priority tickets, and sticky notes for each ticket are an effective tool that can help a team stay on top of support work.

Why use a Kanban board when your company already has perfectly good help ticket tracking software? I have found that the extra level of visibility of tickets on the board reminds everyone about outstanding support work rather than letting it fall into the background. This is especially important when the team is focused on user stories and meeting the sprint commitment. Timely resolution of support issues can impact customer satisfaction as much or more than new features so its warrants the same level of visibility as a Scrum taskboard.

It is also helpful to publish the actual percentage of time that the team is spending on support while the sprint is underway. Remember how we told everyone during sprint planning what the support allocation percentage was going to be for the sprint? This is where the team’s progress on sprint backlog items is weighed against the support commitment.  With a higher than planned support load, the team may not be able to complete all of the sprint backlog items; with the lower than expected support load, the team should be able to take on more backlog items than planned.

Reflections:

  • Adjust team capacity to reflect anticipate support load
  • Establish ground rules for what is handled as a support item vs. a new backlog item
  • Track and report support effort vs. planned effort so that impact on sprint commitment is understood

Developers are from Mars, Product Owners are from Venus

Developers are From MarsJenny was a seasoned product manager who was growing into the Product Owner role.  She liked her additional responsibilities as Product Owner and the flexibility of the organization’s agile approach.  But after a difficult backlog grooming session she asked Tim, the Scrum Master, if they could speak privately. Imploringly, she threw her hands up in the air.

“Every time I suggested something in that meeting, the developers told me all of the problems with doing it. Why are they always so negative?  I also don’t think they really understand how complex some of business processes are. I’m worried that a key requirement is going to be missed.”

How should Tim respond to this? The key is in understanding the differences between how Product Owners and developers think and communicate.

Unprecedented access and communication

Remember the agile principle that states that “Business people and developers must work
together daily throughout the project?”  Before agile, buffers often existed between business people and developers.  A project manager, business analyst, or technical architect might have handled requirements gathering and posed questions to the users on behalf of the team. It seemed to make sense because they were better at switching between technical and non-technical discussions. Then agile came along, and all of a sudden users, product owners, and developers found themselves sitting around a table writing user stories, discussing detailed requirements and designing solutions. This created a new set of communication challenges…

A difference in perspectives

Writing code is a very intense, engrossing activity where the brain thinks in both logical and creative terms and attacks technical challenges from several angles until solutions are found. Defining requirements is geared towards brainstorming what the product can be. Because developers are accustomed to eliminating coding solutions that will not work, this thought process is instinctively applied to product design. What a developer perceives to be a logical approach to finding a design that will work can perceived as negativity by a product owner or user.

Solutions before requirements

While some developers are adept at hearing a business problem, formulating an approach to solving it, and breaking it down into constituent pieces that can be built into software, many do not have those analytical skills. Some developers are more comfortable in the realm of very specific solutions, and upon hearing a business problem, begin thinking in terms of how web pages should look and work.  Meanwhile, Product Owners and users are still thinking about shaping the underlying business processes, identifying user roles, defining and mapping the user stories, assessing the flow of the stories relative to the process, and determining how to logically approach the work.

Reflections

  • As a Scrum Master, Tim needs to avoid letting people outsource their conflict to him.  That means bringing the Product Owner and developers together for a talk along with doing some individual coaching.
  • The Scrum Master can help the Product Owner understand why developers sometimes think in critical terms.
  • The Scrum Master can help developers understand what needs to be accomplished during the various types of meetings. Much of this is centered on having everyone understand that it is important to discuss things at the right level of detail at the right point in time.  This usually means that discussions should not get too detailed too soon. It also means reminding people when to focus on “what” should be built and not “how” it should be built.
  • For complex business processes, it may be necessary to add a systems/business analyst to the team. Analysts know how to discover and capture the nuances of complex processes and how to facilitate re-shaping them to fit new business goals.

The ScrumMaster as Servant Leader

eadership in a modern organization is a paradox whereby leaders provide a vision of what the organization should strive to achieve but then serve those in the organization in order to realize that vision.  This is embodied in the management philosophy of servant leadership.

As defined by the Alliance for Servant Leadership, the principles of servant leadership are:

  • Transformation as a vehicle for personal and institutional growth.
  • Personal growth and its importance to the individual and the institution.
  • Enabling environments that encourage individuals to share ideas and express opinions.
  • Service as a fundamental reason that people want to lead.
  • Trusting relationships based on mutual respect, trust, civility, acceptance, and reciprocity.
  • Creating commitment rather than imposing controls in order to accomplish valued missions.
  • Community building where individuals work effective together, as teams.
  • Nurturing the spirit as a way to provide joy and fulfillment in meaningful work.

These principles fit squarely with an agile organization’s values of teamwork, collaboration, trust, continuous improvement, extraordinary service, and empowerment.

Exceptional leaders are confident enough to and capable of following a servant leader approach; those who are less skilled are autocratic. A Scrum Master can practice servant leadership by:

  • Seldom, if ever, telling anyone on the team what to do. Becoming a Scrum Master involves learning the various mechanisms and ceremonies associated with Scrum.  The most profound aspect of leading a Scrum team, however, is not in learning a methodology. Rather it is about asking very deep, probing questions and helping the team find its way to a solution rather than giving them the solution.  The benefits and impact of this are significant both in terms of the outcomes but also in the satisfaction and commitment that this builds in team members. It is one thing to say that team members are empowered; it is quite another to actually empower them.
  • Not assigning tasks to team members. For an organization transitioning to agile, other authority figures may misinterpret this as a lack of leadership by the Scrum Master.  If those authority figures attempt to direct the team, the Scrum Master should educate them regarding what it means for a team to be self-organizing.
  • Reminding the team about the product vision and sprint goals. Note that it is also key for the Product Owner for articulate product vision throughout an effort.
  • Removing roadblocks that stand in the team’s way.
  • One of the characteristics of an effective Scrum team is that most of its members have a general enough skill set to perform a variety of tasks and do whatever it takes to “move the ball down the field” as a unit. This requires that people who used to be very focused and very good at a specific type of work or technology develop and grow a broader skill set.  A manager serves their team by helping to steer them towards personal growth opportunities.  He/she enables this personal growth by encouraging team members to seek training for new skills and to take on assignments that are outside of their comfort zone.

Got an Impediment? Great!

StopPart of a ScrumMaster’s job is to remove any impediments that are preventing the team from making progress towards the sprint goal. Often, the biggest challenge is not removing the impediment – it is actually getting people to identify the impediment in the first place.
 
Perception

Sometimes it’s a matter of perception.  Some people are reluctant to raise “blocking issues” because they are afraid that it is an indictment of the people that may be causing the issue.  Solution: call them “Impediments.”  Sometimes a simple euphemism changes the perception.

Visibility

Often someone on the team knows about an impediment and mentions it to their team mates and/or brings it up during daily Scrum but it gets lost in the shuffle. Maintaining a highly visible impediments list on a board in the team’s work area servers a dual purpose:

  1. Helps to keep the focus on removing known impediments
  2. Indirectly discourages individuals from becoming impediments

Encouragement

A typical management response to impediments is concern and root causes analysis (“How could this possibly happen? We need to make sure this never happens again!”). The Scrum Master’s response when a team member raises an impediment should be to say, “Great!  Thanks for sharing.  Now that we all know about it, we can address it.” A team that is comfortable discussing impediments is far ahead of one whose first instinct is to sweep them under the rug or to switch into CYA mode and run for cover.

Reflections:

  • Build a team culture that views impediments as a natural part of any challenging project.
  • Ensure that impediments are visible to everyone.
  • The retrospective is a great place to discuss impediments and how to avoid them in the future.