Communication

What’s the What?

Alec Hardy Communication, Developer, Requirements, User Stories

I recently parted ways with my Scrum teams in order to pursue an opportunity another company. One of the team members asked for general feedback about how the team had been doing. Here is my response:

Team,

I have always been open with you about things we are doing well and areas where we need to improve as a team, so instead of specific criticisms or suggestions, let me leave you with a few words of wisdom:

Always ask yourself, “what’s the what?”

Always ask yourself, “why?”

As a technical person, it’s easy to jump to the solution before really understanding the problem. Instead, always strive to understand what user or customer wants and why they want it before deciding how to solve the problem. How is this put into practice? An easy way is via user stories that reflect what the user is trying to accomplish rather than a technical solution. It could be a business task the user is trying to accomplish or a business goal that they are trying to achieve.

The beauty of agile is that you, as technical people, are not only empowered to ask these questions but are expected to. If anyone ever tries to tell you that you should not be concerned about the “what” or the “why”, do not accept that answer. Your users and customers will be much better off when you understand their needs.

Cheers!

Alec

Retrospectives – Back to Basics

Alec Hardy Communication, Leadership, Uncategorized

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.

Backlog Grooming: Scrum’s Red Headed Stepchild

Alec Hardy Communication, Grooming, Product Owner, User Stories , , ,

Backlog grooming differentiates good scrum teams from ones that are just scraping by. Viewed by some people as optional, there is often a temptation to skip it in favor of remaining focused on the current sprint. Experienced teams understand that backlog grooming can have an impact not just on the next sprint planning meeting but on the extent to what they build meets user needs.

What is backlog grooming?
The team reviews stories or epics in the backlog to be done in future sprints. The Product Owner (PO) explains the stories, the team asks questions, and additional story information may be captured as a result of the conversation. The PO may leave the meeting needing to gather additional information from users or customers about the story. The team may identify research spikes needed to understand the technical approach for the story. Typically the focus is on stories for the next sprint, but if those are well enough understood the focus may be on stories or epics further down in the backlog. The team may also adjust the sizing of stories based on what they learn during grooming. Large stories may be split into smaller ones, especially if they are going to be in the next sprint.

Note that backlog grooming can also be called “backlog refactoring”. My personal preference is to avoid the term “refactoring” because in some organizations new to agile, “refactoring” is still a dirty word associated with something that needs to be reworked because it was not done correctly the first time.

Why is it important to do on a regular basis?
I once worked with a Scrum team that literally took an entire week to finish a sprint plan. The team did zero backlog grooming. The sprint planning meetings were a combination of the PO identifying new user stories, the team members asking questions, delays while the PO sought answers, and delays while the team researched the feasibility of certain options. The end result was stories and sprint plans full of vagaries and risk. Contrast this with a team that does backlog grooming on a regular basis. Questions surface during the discussion and those questions are either answered immediately or the PO and team have time to research the answers. By the time sprint planning rolls around, most of sprint planning is about HOW the team will build it and not WHAT they are supposed to build. The PO and team can create a sprint plan to which they can commit.

How often should backlog grooming by done?
Backlog grooming should be a weekly meeting. Each meeting should be at least one hour long. A rule of thumb is never to do backlog grooming on the first or last day of a sprint. One the first day of the sprint the team is eager to get rolling the new sprint’s stories; on the last day of the sprint they may be focused on finishing off the last few sprint items. The last thing we want is for grooming to be perceived as getting in the way of the team’s success. Also, a few days may be needed after grooming to get answers to questions.

For a team that runs two week sprints starting on a Monday and ending on Friday, every Wednesday would be a perfect day for backlog grooming.

Who attends backlog grooming meetings?
The Product Owner, the Scrum Master, everyone on the team, and business representatives as needed. It is key for all of the scrum team members to attend so that they all have a good understanding and commitment to each story. Because a story is partly what is written down and partly a conversation, team members cannot expect to skip grooming and then catch up by reading the stories.

What is the PO’s role in backlog grooming?
The Product Owner’s role in backlog grooming starts before the actual meeting. The PO ensures the story prioritizations in the backlog are correct so that they know what stories will be groomed. They add acceptance criteria or user acceptance test cases to stories as appropriate, depending on how soon each story will be pulled into a sprint. While these are basic PO responsibilities, they are sometimes overlooked or ignored because of customer meetings, management presentations, etc. Regularly-scheduled grooming meetings are a great way for the PO to establish a personal cadence of prepping stories for backlog grooming.

A few days before backlog grooming, the PO tells the team which stories will be covered in the upcoming grooming meeting. This gives team members a chance to take a look at the stories ahead of time and either start thinking about the stories and possibly come prepared with questions.

The PO typically runs the grooming meeting.

What is the Scrum Master’s role in backlog grooming?
The Scrum Master can help out the PO by scheduling the meeting and taking care of meeting logistics. More importantly, the SM can ensures that the PO is on top of the backlog prioritization and knows what will be groomed. As a Scrum Master, I worked with a PO who was chronically ill-prepared for backlog grooming meetings. I addressed this via pre-meetings with her a few days before backlog grooming to help her get into the habit of prepping the backlog for grooming.

What is the team’s job in backlog grooming?
If possible, team members take a look at the stories to be groomed before the actual meeting. In the meeting, they seek to understand the requirements by discussing and asking questions. The PO may provide 50% of the story content before the grooming session. Good discussions will round out the acceptance criteria as the team and PO look at the story from different perspectives.

Reflections

  • Backlog grooming is an essential activity. Resist the temptation to skip it.
  • Schedule grooming meetings so that they fit In the middle of the weeks of the sprint.
  • The entire team should be involved in grooming.
  • Regular backlog grooming helps the PO establish a cadence for working on stories.

The Heartbeat of an Agile Team

Alec Hardy Communication, Developer, Kanban, Scrum Master, Sprint Planning, User Stories , , , , , , , ,

What is the one focal point that catches every team member’s attention at the same time every day?  Of course it is their Scrum board. Some teams go through the motions and use their Scrum board because they are told to; for effective teams the board is a way to collaborate, manage work in process, keep track of impediments and know whether or not they are going to meet the sprint goal. Effective teams turn their board into a highly-visible collection of critical information about their effort. It becomes the heartbeat of the team and helps set the cadence for each sprint.

Their board might look something like this:

Board

 

Sprint Dates and Goal – as a reminder of the goal and the timeline. Seeing the sprint dates can be helpful if users who will be testing attend the standups so that they understand the sprint timing.

Columns for each step in their development process – This can be as simple or as complex as the team wants – it usually evolves as the team learns and tweaks its process to ensure a smooth flow of stories. In the example above, the team experienced issues with too many stories waiting for user testing. They created a column to show which stories are ready for user testing to make it clear to users when something is ready for them to test. During standups, the Scrum Master points out any columns where an excessive number of stories are piling up. Even with Scrum, the team may set limits for how many stories may accumulate in each column before team members swarm to address a bottleneck.

Sprint Calendar – during sprint planning the team members estimate on which days of the sprint they think stories will be Done and also when they will likely reach any other significant milestones in the team’s process such as being ready for user testing. This is a way of performing a sanity check for the sprint plan.  It is also a way for the team to gauge whether or not it is on track during the sprint. When user testing is part of the Definition of Done, it allows the users to plan when they will be performing this testing. Putting team members’ planned vacation days on this calendar avoids surprises in the middle of the sprint. It can also help to put key SME’s or users’ vacation days on the calendar if these could impact the sprint.

Impediments – unresolved impediments. Making these visible is a way to track them and may have the side benefit of prompting outside stakeholders who attend the standup or visit with the team to help the Scrum Master by finding other ways to resolve them.

Additional Stories – these are stories at the top of the Product Backlog that are ready to be brought into a sprint but that are not part of the current Sprint Backlog. These are posted on the board so that they are readily available in case the team reaches the sprint goal early and can complete some additional stories in this sprint. Note that these are not called “Stretch Goals”. That term can be perceived negatively by the team, almost as if they are not pushing hard enough in the first place to meet the sprint goal.

Release Burnup – the bigger picture of what the team is working towards. This help avoid the sense of being in an endless churn of sprints with no end in sight.

For teams using Kanban, many elements on this board still apply but may need slight modification. Note the use of colors throughout the board.  It is amazing how teams will adopt color schemes or symbols that communicate the state of their work, highlight important events, serve as key reminders, etc. One type of information not included on the example above is an area for Technical Debt.  Creating an open area on the board for this invites the team members to note it as soon as it becomes apparent to them.  These notes can then be translated into backlog items during grooming. This encourages open discussion about technical debt and surfaces this information rather than just having it in the team members’ heads.

A note for teams that use online/electronic Scrum or Kanban boards: additional information such as the PTO calendar, Impediments and release burnup can be captured in story cards and placed in a column dedicated to that background information. The sprint calendar can be captured by putting Due Dates on each electronic story card. On a physical or electronic board, the story cards can contain as much information as the team finds helpful. Typically the story number, title, and number of story points are included.

Reflections:

  • The Scrum or Kanban board can be used to communicate much more than just the status of the stories and tasks.
  • The information on this board should reflect each team’s personality and process. It will evolve as the team learns.
  • The Scrum Master can help the team during the standup by directing their attention to potential trouble spots on the board.

Who Should Write UATCs?

Alec Hardy Communication, Developer, Product Owner, User Acceptance Test Cases, User Stories , , , , , ,

Collaboration

Experienced agile practitioners take for granted that detailed requirements are captured as user test cases. For organizations transitioning to agile, this is one of the more challenging practices for them to adopt. Some product owners or business analysts still view the traditional “requirements document” as the way to capture detailed requirements. Because of their attachment to this traditional form of documentation, many resist replacing them entirely with User Acceptance Test Cases (UATCs).  They view UATCs as additional work on top of writing their traditional requirements.

UATCs better convey a sense of how the system is supposed to work by using examples rather than abstract, ambiguous business rules. In a mature agile organization, the end users are best qualified to write the UATCs.  This underscores the product owner’s role: they do not need to gather every detailed requirement – their job is to connect the development team with subject matter experts rather than being a conduit between the two.

Working Software over Comprehensive Documentation

Taken to the extreme, only the highest-level details are written down. This can work for small, simple applications. For large, complex applications, this is insufficient and quickly leads to chaos, disappointment, and frustration. The key is not avoiding writing down requirements, it is capturing them ONCE so that they can be used by product owners, developers, users, and testers and be the one living artifact besides the software.

What options do teams have for adopting the practice of capturing requirements as test cases?

1)      Developers write UATCs – while some might consider this sacrilege, in reality this is a great way to get started with UATCs and establish collaborative bonds between the development team and the end users.  Of course the developers’ initial version of these will usually only reflect what is in the acceptance criteria and what was discussed during grooming, but it provides structure for gathering more details from the users.  Users quickly see the value in this approach because the requirements are written in terms that they can understand – system behaviors. They also see the value in working directly with the developers. Product owners like this because it does not add to their workload and they quickly realize the benefits of the enhanced collaboration. One caveat: developers may need coaching about expressing things as tests and expected results since they may also be accustomed to thinking in terms of catch-all business rules rather than tests.

2)      Developers and users write UATCs together – given some starting point such as a sketch of a web page, the developers and users talk through the expected behaviors for a user story. This feels time-consuming but it directly involves the users in the process of devising the test cases.

3)      Users write UATCs – while this is UATC nirvana, it is important to remember that the developers and users still need to review the UATCs together and in detail. The test cases and end product always benefit from each group’s experience and perspective.

4)      Users and testers write automated UATCs – for applications that are able to leverage automated end user testing tools like Fitnesse, users will likely need assistance with the testing toolset, format, etc.

Reflections:

Be pragmatic about who writes the UATCs. Remember the goal: collaboration that leads to deep understanding of expected system behavior.

Essential Agile Skills

Alec Hardy Communication, Developer, Grooming, Product Owner, Scrum Master, User Acceptance Test Cases , , , , ,

As organizations adopt agile practices, there are several key skills that differentiate high-performing teams from mediocre teams:

1) Working in short timeboxes

For a team that is accustomed to delivering working code every six or eight months, two or four week long iterations can be unfathomable. But doing this is essential to the success of the project in order to get the benefits of continuous code integration into a testing environment and frequent user feedback. The sprint’s timebox forces the business stakeholders to constantly question the scope of each feature at a micro level and decide when to carve out functionality.

2) Splitting work into small pieces

The most common excuse for teams wanting to plan sprints using large user stories is that it is “more efficient” to do all of the coding work together and test it at the very end or in the next sprint. This perceived efficiency is self-deception. Successful agile teams know that they must put working code in front of their users early and often. Remember the old saying that “users often don’t know their requirements until the software fails to meet them?”

3) Communication and transparency

Old-school silos between IT, Product/Marketing, and business operations groups are an agile anti-pattern. Political games, finger pointing, and one-upmanship are a huge waste of an organization’s resources and energy. A grown-up culture of transparency allows all of these players to collaborate and solve difficult challenges. For the Scrum Master, this means posting project information in high-traffic areas of the office. More importantly, it means being open with stakeholders about the challenges that the team or project is encountering. Team members can feel secure speaking freely about impediments and project risks in a public forum without fear of reprisal. The essential skill here is knowing how to voice issues in a way that does not sugar-coat them but does set the stage for a constructive discussion.

4) Swarming, collaboration, team first

“Your side of the boat might be leaking but my side is fine” attitude just doesn’t cut it anymore. Lone gunmen need not apply. The most effective agile team members will gladly work outside of their skill sets and comfort zones if it helps the team succeed. Agile developers welcome and seek opportunities to discuss functionality with end users to understand their goals and needs. They leverage techniques such as User Acceptance Test Cases to capture and understand detailed requirements.

5) Focus and finish mindset

This is another one of those things that is counter-intuitive at first for people new to agile. Coders are used to getting all the coding tasks done so that they can get all of the stuff to the testers. Understanding that high work in process = low throughput is key. Developers working in lockstep with testers results in higher throughput, even if that means that the developers have to swarm on non-development tasks every now and then.

6) Scope negotiation

Scope negotiation means being relentless both when talking about items in the current sprint or when doing release planning. Sometimes it takes two, three, or four conversations about an item to admit that it is not really needed.

7) Talking about requirements at the right level of detail at the right point in time

Skilled agilists recognize that the conversation that happens in a user story writing workshop is at a much higher level than the conversation about a story right before that story is pulled into a sprint. They also shun detailed requirements until the sprint starts, knowing that a large collection of detailed requirements is inventory that is subject to decay.

8) Automated testing

Refactoring is a fact of life as requirements are progressively elaborated. Effective implementation of test-driven development and automated testing blunts the effort for regression testing as the application evolves.

Introducing Scrum to a Team

Alec Hardy Communication, Developer, Grooming, Product Owner, Scrum Master, Sprint Planning, User Acceptance Test Cases, User Stories , , , , , , , , , , , , , ,

GoFor a Scrum Master introducing agile to a team, there is a balance between implementing concepts and practices at a pace that does not overwhelm the team and demonstrating the benefits as early as possible to build momentum and support within the organization.

Each situation is different, but let’s assume that an organization wants to use Scrum and there is an experienced Scrum Master who has been asked to lead a team of people that are experienced with waterfall approaches and are new to agile. Also assume a reasonable level of management support. How should the Scrum Master go about implementing agile practices on the team? For an experienced agile practitioner, the practices are second nature so it can be tempting to try to introduce it all at once, but the reality is that it must be gradually introduced in bite-sized chunks. The key question is which practices should be introduced first and which practices must be implemented in the longer term? Here are some suggestions:

Groundwork

Before starting the first sprint, there are some things that need to be put in place:

  1. Secure a Product Owner (PO). In many organizations this might be a product manager or representative from a business unit. This requires a serious time commitment and product insight so it should not be an afterthought.
  2. Secure a team where the people will be dedicated just to this team, rather than juggling several different projects at once. This can be a big shift for organizations accustomed to managing project assignments via resource utilization/optimization models tied to specific skillsets.
  3. Educate the team (including the Product Owner) about agile principles and Scrum. Hiring a Scrum trainer to conduct a two or three day course is ideal, but if lead time or budgets do not allow this, prepare an overview that touches on the agile principles as well as the mechanisms and ceremonies of scrum. The Scrum Reference Card and Build Your Own Scrum  are good tools to facilitate this.
  4. Be careful in comparing agile to waterfall. Disparaging waterfall will not endear agile to people who have delivered successfully using waterfall.
  5. The new PO will require additional training about what the role involves.  If they were a product manager accustomed to working with a project manager (PM), they will need to understand the additional responsibilities that get transferred from the PM to the PO. To get them started, help them understand that they will need to work with the team on a daily basis.
  6. Change the team’s physical workspace to foster improved collaboration.  Sometimes it is as simple as taking down a few cubicle walls. Other times, it involves locating people in the same area if they are spread out around the building. Be thoughtful about this. Done wrong, too many people are jammed into a small area and they can’t move around without bumping into each other. This builds frustration and resentment that leads people to resist and question the approach that brought this change. Also, an area with plenty of wall space is best.
  7. Pick an iteration length. Start short so that the team can get used to the different ceremonies and rapidly learn from its experiences. This also quickly gives the team and the organization a feel for what happens before/during/after an iteration.
  8. Populate the initial product backlog:
    • Conduct a story writing workshop. Utilize a technique such as story mapping to organize the stories. Don’t get hung up on teaching story mapping techniques – just do it by organizing stories that way on the wall. It will actually be very intuitive to people who are accustomed to structured analysis techniques. A big challenge here will be in writing the stories. If a work breakdown structure (WBS) exists as a result of the initial business case or previous project planning that was done before deciding to use agile, it may be possible to use it as a starting point for populating the product backlog.  This depends on the extent to which the WBS aligns with product features vs. technical tasks.  The more aligned it is with features, the easier it is to translate. This is an opportunity to reinforce that product backlog items are features and not tasks. Also, team members may correlate this to the design phase of a waterfall project. The focus needs to be on “what” the requirements are and not “how” they will be implemented. Stories need to be written in just enough detail for sizing, not with detailed requirements.
    •  Get the PO to prioritize the backlog by business value. Don’t be surprised if every item is given a priority of ‘1’ the first time around.
    • Create a Definition of Done. This provides the basis for sizing stories. This should include user acceptance testing (avoid the use of “done” and “done done” at all costs!). This will be challenging for a team accustomed to a UAT phase after long design and development phases. Doing this reinforces that the team should write stories that represent testable feature increments rather than individual technical layers of the application.
    • Conduct a planning poker session where the team sizes an initial set of backlog items using story points. This can be a big change for teams accustomed to having senior team members provide the estimates. During this process, the Scrum Master needs to make sure all voices on the team are heard.  Planning poker is ideal way to do this. The Scrum Master solicits input from all team members, especially when there are significant differences in estimates. So that the team does not feel as though it needs to define every last detail of each story, help team understand that this is not the last time these stories will be discussed; detailed requirements will be covered in depth once the sprint starts.
    • This next step depends on the project and organization.  If the organization views the project as an agile incubator, the team might have the leeway not to commit to an overall release plan for the product until a few sprints have been completed and the velocity is understood. If not, you may need to use an old project planning approach to derive a delivery date to satisfy the organization until a release plan can be formulated. Be very careful about providing enough buffer for unknowns – any dates that are published may become the benchmark against which success or failure of the effort will be measured. If possible, characterize any release dates as preliminary until the team has had a chance to run a few sprints.

The First Sprint

  1. Plan the sprint.
    • Set firm start and end dates for sprint. Go with either a 1 or 2 week sprint. A 3 or 4 week sprint length is not recommended because it is harder to convince PO not to change the contents of a sprint if it is longer. Also, longer sprints involve larger numbers of stories for a larger team, which can be difficult for them to manage. A shorter sprint length allows the team to demonstrate results quickly.
    • Calculate the team’s hours of capacity to do work on user stories during the sprint, factoring in sprint length, time for meetings, vacation time, etc.
    • Conduct the sprint planning meeting. The first part should involve the development team and the PO. Review the user stories on the backlog starting with the highest priority items. The team should ask the PO any questions they need to help them understand how to task out each story. The PO can stay for second part if they want. Create tasks for each story. Make tasks granular enough (max 6-8 hours) so that it will be easy to have multiple people working on each story. Continue to add stories until team’s hours of capacity for the sprint are used up.
    • Ask everyone on the team if they are comfortable committing to delivering these stories in the timeframe of the sprint and if they have any concerns or reservations.  Go around the table and ask each person – it can reveal some insights that people might not otherwise volunteer.
  1. Set up a story/task board in the team area. Even though the team might have software for sprint planning, go with high-visibility, tactile information radiators. This is important because it helps the team learn that it needs to be self-organizing/self-assigning. The team should update the board throughout the sprint, not the Scrum Master. The Scrum Master needs to change culture of having the project plan buried in project planning software like MS Project and only being maintained by the PM. This also starts to build culture of transparency with stakeholders. Invite stakeholders to visit the team’s work area to view status of current iteration. Of course, be careful that they don’t interfere by trying to change priorities or introduce new stories.
  2. Start the first sprint.
  3. Do daily standups. Start by helping team understand the purpose and the basics.
  4. Some people on the team may have heard the agile myth about “no documentation”. This is the time to start establishing culture of lean, maintainable documentation that has value through the lifetime of the product. A new team will only be able to bite off so much new stuff at one time. If they are accustomed to some type of UX or use case document, use that artifact (during the first sprint) as a transition into user acceptance test cases.
  5. Coach team members that the first thing that they need to do when they pick up a new user story to work on is to get with the PO and applicable users to discuss detailed requirements (since the team didn’t hammer out every last detail of the story during grooming or planning, right?). Reinforce with the PO that they need to be prepared to work with team members on a daily basis.
  6. While the Scrum Master’s eventual goal is a team that limits WIP and individuals self-assign tasks, don’t necessarily expect that to happen in the first sprint. Remember – people on the team are probably accustomed to having their tasks assigned to them by the PM or tech lead via project plans.  Initially, the Scrum Master may need to ask for volunteers for tasks, or as team members report that they are wrapping up a task, the Scrum Master may need to ask them which task they will work on next. Team member will typically look at the next available story that no one is working on. Steer them instead to first look for tasks they can work on for stories that are already underway but not yet complete.
  7. Start tracking the team’s burn down and post in the team work area.
  8. Run interference if the PO or other business stakeholders try to change the stories in the sprint. This is another reason to keep sprints short (max 2 weeks) at first. It is easier to argue against changing the contents of a sprint when the next sprint is less than 2 week away.
  9. Conclude the sprint on the planned end date.  DO NOT extend the sprint under any circumstances, even if it will take ‘just one more day’ to finish all of the stories. It is important to establish this early as it speaks to the sprint commitment being firm and the importance of sizing/organizing the work so that it can be completed within the iteration.
  10. Do the retrospective.  Keep the format simple initially. “What went well, what did not go well, ideas for improvement” is an easy format. Do not allow anyone from outside the team to attend. Make sure the PO attends because they are part of the team and this meeting is an important way to build trust between the PO and the developers. Ensure attendees know that the Vegas rule applies. At the conclusion of the retrospective ask attendees if it is okay to share ideas that were generated with outsiders – stakeholders will naturally be curious.  Ideas that the team does not want to share are not shared outside the team.
  11. In preparation for the sprint review, prepare a sprint summary document.  Show the team’s burn down, stories committed and status of each story at end of sprint.
  12. Conduct the sprint review. Encourage as many people from around the organization to attend as possible. This is about
    • Demonstrating results
    • Team members taking pride in their work by showing it off
    • Showing the organization that the team is transparent

The development team members (developers, QA people, etc.) should conduct the demos.

The mechanics of the first sprint described above are relatively straightforward, but the reality is that this is all occurring against the backdrop of organizational change:

  • Team members are experiencing dramatic change.  Their physical work area has changed. They are being asked to commit to delivering something without detailed specifications. No one is telling them which tasks to work on.
  • The relationship between business and IT may be very different when using an agile approach. If the PO comes from a business unit and because of the organization’s culture there exists a lack of trust or poor communication between the business unit and IT, the lack of trust and communication issues will not necessarily disappear overnight.
  • The organization’s culture may not value or emphasize teamwork. Part of management and the Scrum Master’s jobs is to build a culture where teamwork is highly valued.

The Second Sprint

In the second sprint, the Scrum Master continues to emphasize agile principles and the mechanisms of Scrum.

  1. The Scrum Master continues to coach regarding self-assignment of tasks. As the Scrum Master backs away a little bit and the team starts to self-organize, others (such as the PO) may feel that the team needs to be directed and step in to direct the team and tell them what to do.  The Scrum Master must also coach them not to direct the team.
  2. The Scrum Master continues to encourage team members to swarm on stories by default rather than only when necessary. Lessons learned from first sprint (e.g. too many stories in progress at the same time) make the purpose of this apparent.  Swarming will not happen overnight, but the Scrum Master needs to keep encouraging it.
  3. Conduct user story grooming meetings during the sprint. In the meetings, continue the mantra of discussing features at “the right level of detail at the right point in time.” Use these meetings to size out the rest of the backlog and to revisit stories likely to be worked on in the next sprint. The product owner may be unprepared for these meetings because they are already overwhelmed by working with the team on the current sprint’s user stories. Sometimes it helps for the Scrum Master to meet separately with the product owner a day or two before a grooming meeting to survey the backlog and discuss the next set of stories to be groomed.
  4. Encourage the PO to regularly tend to the backlog – not just before grooming or planning meetings.
  5. Using the team’s velocity from the first sprint, begin working with the product owner to formulate the release plan. It may not be appropriate to go public with it yet. Velocity cannot necessarily be trusted after just one sprint, but doing a preliminary release plan is valuable to get the PO thinking in terms of using the velocity and backlog to formulate a plan.
  6. Start tracking the team’s burn up and also post in the team work area.  The burn up emphasizes that hours worked do not provide business value, only completed user stories do. A graph that shows a steady burn up of completed story points during the sprint (rather than a ”hockey stick” where most of the stories get closed at/near the end of the sprint) is the goal. Don’t necessarily beat the team over the head with this…at this point just introduce it to them and call attention to each story as it is closed during the sprint.

Beyond

Over subsequent sprints, the Scrum Master should consider introducing some of the following techniques.  Of course each situation is unique so he/she will have to gauge whether or not the team is ready for each new practice.

  • For teams that are having trouble swarming and have too many stories in progress at the same time, reinforce the concept of WIP limits.  For teams that already have a task/scrum board with steps in the process laid out, the WIP limits can easily be established for each step. The team can decide whether they are firm limits not to be exceeded or soft limits that are triggers for conversations.
  • Help the team learn the finer points of writing user stories. A book study (e.g. “User Stories Applied” by Mike Cohn) is a good way to do this. Be sure to include the PO in this.
  • Test-Driven Development (TDD).  The benefits of this can be difficult for a team to grasp. Once the team (including the Product Owner) understands that it is okay to refactor and that it is simply part of progressive elaboration, the benefits of TDD become much more apparent.
  • Acceptance Test Driven Development, manual or automated.
  • Introduce additional retrospective techniques to help the team learn about itself and identify areas for growth. The Scrum Master will need to judge what type of retrospective is appropriate depending on how the sprint went.

In addition to learning new practices, the team overall needs to learn to be agile, not just to use agile practices.

  • Work with team members’ managers to help them develop a broader, t-shaped skillset that allows them to perform a larger variety of technical and non-technical tasks.  For specialists, this can be a big shift.
  • Help the team to develop an agile mindset by only learning enough about a feature to size and plan it and then really dig into the details of it once it has been pulled into a sprint. One of the most gratifying moments for a Scrum Master can be when the PO says, “We did not think of that aspect of the feature in when we discussed the story. We will just create a new story and handle it in the next sprint” – without taking the team to task for not delivering it in the current sprint.
  • When the Scrum Master has been steering the team towards new practices but the team has resisted using them, the Scrum Master may need to let the team fail for a sprint. The Scrum Master needs to help stakeholders understand that this is part of the learning process, and two-week sprints will minimize most of the damage if the team gets off-track.

Reflections

  • Every situation is different so of course there is no “one size fits all” approach to starting with agile. Organization and team dynamics impact the speed and extent to which agile is adopted.
  • As the team becomes more comfortable with the agile approach, the Scrum Master should adapt his/her approach to be in more of a supporting role for the team.
  • Occasionally the team will forget lessons learned from a few sprints ago and revert to old habits.  The Scrum Master can bring previous retrospective conversations back into focus to help the team avoid making the same mistakes.