Category Archives: Leadership

Retrospectives – Back to Basics

Retrospective

For a new Scrum Master, the mechanics of getting started with retrospectives are deceptively easy. Somebody tells them to write three columns on the whiteboard (What Went Well, What Did Not, Ideas) and to facilitate the discussion. The Scrum Master makes sure that management is not invited to the meeting. He/she Identifies the team members who are not participating and try to get them talking. Simple. The retrospective becomes a blend of problems mixed with solutions and “action items” for the next sprint. If the team is lucky, it identifies the most valuable areas for improvement. Unfortunately for many teams, they go through the motions but do not get to the heart of their biggest problems/opportunities. It becomes a stale ritual and the team plateaus.

Surprisingly, many Scrum Masters fall short on the basics of how to conduct a retrospective. They think that all it takes is writing the three columns on the board. Properly done, it actually starts as soon as sprint planning is done.

In their book “Agile Retrospectives – Making Good Teams Great”, Esther Derby and Diana Larsen suggest the following structure for a retrospective:

  1. Set the stage – get the team in the right mindset for a retrospective
  2. Gather data – identify the key things that happened during the sprint
  3. Generate insights – about those things and why they happened
  4. Decide what to do – new practices to improve
  5. Close the retrospective – take a minute to step back and reflect on the sprint, the team’s accomplishments, and the retrospective itself

Lots of different techniques exist for each of the stages of a retrospective. The art is in the Scrum Master recognizing which one fits the team at that particular moment in time.

To set the stage for the retrospective, the Scrum Master may remind the team that the retrospective is a safe environment. They could also do a check in where they go around the room and ask each person “How are you doing today?” to engage the team. Another technique is to ask people “if the team were a car, what kind/make/model of car were we in this sprint?” and record each person’s answer on the board. This can provide an interesting reference point to revisit if someone says the team was a Pinto but during the remainder of the retrospective does not point out any problems that occurred during the sprint.

In gathering data about the sprint, the Scrum Master and team consider:

  • The sprint goal
  • The sprint backlog and the results (done, not finished, etc) for each story.
  • Impediments or challenges that occurred during the sprint. Laying them out on a calendar can help illustrate how they affected the sprint and generate conversation for how to handle them in the future (the Scrum Master may get in the habit of noting these as they happen).
  • Is the team going through a storming phase? Asking team members to track how they were feeling about the sprint during specific stages of the sprint can help surface opportunities for working agreements, practices the team should adopt, etc.
  • After trying to remember what happened over the last week or two (they know better than to do three or four week-long sprints) the team and Scrum Master may start to note some events as they happen to make data gathering easier in the retrospective.

To generate insights, the team can approach the discussion a number of different ways:

  • Was every story closed? If not, what state was each one in at the end of the sprint? Ask why. Then ask why again.
  • Did the team stretch yet still meet the sprint goal? Reflecting on what the team did well could reinforce those practices and also set the stage for a discussion about how to take it to the next level.
  • Is there a lot of discussion about whether the team should adopt certain practices? The insights could be focused on things the team to start doing, stop doing, and continue doing.

Teams are usually pretty good at coming up with ideas for how to do things differently. Trying to do all of them at once or forgetting about them in the throes of the next sprint are common pitfalls.  A good Scrum Master will gather these ideas as the team identifies them during the retrospective. A great Scrum Master will sense when the team has not really gotten to the heart of an issue or opportunity and prod them to drill down to the heart of the matter.

Once the team has identified ideas or new practices to try in the next sprint, posting them near the Scrum board is an easy way to quickly remind the team about them when the team is gathered around the board during the daily standup. The remaining ideas go into the Insight Backlog. This backlog can be evaluated along with new ideas that come out of each retrospective to decide which ones to try next.

Some formats for gathering data and generating insights include:

  • (Old reliable) What Went Well, What Did Not, Improvements. Team members write ideas on sticky notes and put them in the respective columns. Dot voting for which ideas to adopt.
  • Reviewing results for each story, conducting 5 whys for each one.
  • Start Doing, Stop Doing, More Of. Again, sticky notes placed by team members can help with participation.
  • Sailboat. What things are the wind in the team’s sails, propelling it? What are the anchors that are slowing it down? Another variation is Motorboat, where the team identifies the anchors that are slowing down the boat (team) and they can even place them a different ‘depths’ to indicate their severity.

Reflections

  • There are many ways to conduct a retrospective. The Scrum Master’s job is to find the right way to help the team improve at that particular moment in time.
  • Overcomplicating the format of the retrospective can get in the way of improvement.
  • Letting the format of the retrospective get stale can result in team members who have shut down from boredom before they even enter the room.
  • The Product Owner should be there. They are a member of the team after all.
  • In closing the retrospective, take time for Appreciations. Good people aren’t just working for a paycheck.

Evolving Team Structures Through the Product Development Lifecycle

One of the most fascinating management challenges is determining the best structure for Scrum teams based on the stage of the project. This does not mean the major waterfall phases like Analysis, Design, Construction, etc. When developing software for use by customers (especially niche SAAS products) and there is some level of customization or specific features for each client, there are at least a couple of distinct stages in the project:

  1. Develop the base product
  2. Develop client-specific features and convert those clients onto the system as those features are completed

Many agile writings suggest that the way to approach system development is to develop some features and put them in production right away so that clients can start using them immediately. In reality, this does not always work. For example, when an existing system is being replaced, clients cannot be put onto a new system that only has 20% of the functionality of the one being replaced. Of course, this does not preclude some form of testing of that 20% by users within the development organization (e.g. by internal client service reps who are also part of the user base).

Organizing for Base Product Development

Typically the base product development effort focuses on developing the major feature areas. The development teams can be organized along the lines of the features areas as depicted below.

Base Product Team

Organizing for Client Conversions and Onboarding

 As the base product nears completion and the teams start to work on client-specific features, the portfolio or program manager may start noticing that the client code complete date for one of the feature teams above is much later than the other teams because the bulk of the customization for that client falls on that one team. The net result is client on-boarding dates are further out in the future that delay realization of new revenue from the product. This is a clear sign that the team structures need to change. At this stage, the focus shifts to optimizing staff utilization while retaining the benefits of teams building features or feature slices from top to bottom. This is called Focused Balance. Work is focused as much as possible on one or a few teams to gain the efficiencies that come with understanding and ownership of the epic , but when necessary client-specific epics are spread across the teams to deliver them as soon as possible.

Client Onboarding Team

Restructuring the teams

When scheduling and work allocation issues require that multiple teams work on the same epic, the following should be considered when deciding who should be on each team:

  • Knowledge about specific feature areas of the system.
  • Technical skillsets. Rebalancing may be necessary when certain feature areas from the base development phase emphasized a particular technical skillset.
  • Technical leadership – most teams need a technical leader.

Cross-Training and Collaboration

Team members will need to step out of their comfort zones and learn other parts of the system. Product owners, who have become experts in the feature areas that their teams constructed in the initial stages of development, will be overseeing a backlog that contains features and stories that are outside of their current area of expertise. Recognizing and fostering the need for collaboration across the teams is critical to the success of this model. At this stage, the job of the product owner is to connect team members with subject matter experts rather than being the subject matter experts.

Reflections:

  • Team structure may need to change to optimize the schedule for client-specific feature development.
  • Restructuring and rebalancing evenly distributes system knowledge and technical skills across the teams.
  • The Product Owner’s role changes to be less of a subject matter expert for their team and more of a facilitator.

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.