Category Archives: teams

Daily Scrum

Team holding a daily scrumThe daily scrum is the event where the development team inspects and adapts their work plan in order to make the most progress possible towards their sprint goal each day. It is one of the most misunderstood events in the scrum framework, and often implemented ineffectively. By understanding the purpose of the event, your team can realize much more value from their daily scrum.

Often, the first thing a person learns about scrum is the traditional way to run a daily scrum. They learn the three magic questions: What tasks did I get done yesterday? What tasks will I do today? What impediments am I aware of?

What people often don’t learn is why the team holds a daily scrum. If team members don’t understand the purpose, it’s very easy for the daily scrum to devolve into a meaningless status meeting, where each team member walks away wondering why they just wasted 15 minutes of their day.
Read the full article…

Share it!

From Component Teams To Feature Teams

Components I recently facilitated a software development group’s transition from component scrum teams to feature scrum teams. The new structure reduces cross-team dependencies, which had been causing significant delays in shipping new features. Over the course of a day, we dissolved the existing component teams, groomed a shared product backlog, created a shared definition of done, self-organized into new teams, and held LeSS-style sprint planning meetings. The excellent work everyone did left me in awe, and I felt honored to have the opportunity to facilitate the day. The participants left energized and excited for their new adventure.

What follows is a description of how we structured a one-day event to transition the participants from being members of component teams to being members of feature teams.
Read the full article…

Share it!

Scaling Scrum With Scrum

Leadership Scrum Team

One of our clients recently reached out to us asking for advice about how to manage their organization’s scaled scrum adoption. They wanted to know if they could use scrum to manage the adoption of scrum in the organization. The short answer is yes.

Guiding an organization’s adoption of scrum is a big project. It’s a project that will require a cross-functional team. It’s a project where the full scope of work can’t be known when the work starts. It’s complex, exactly the kind of endeavor that you want to use scrum to implement. When I’m working with organizations that are adopting scrum at scale, I always start by recommending that they create a scrum adoption team, and that this team use scrum to do the work of rolling scrum out to the organization.
Read the full article…

Share it!

A Scrum Master Is A Teacher, Mentor, Coach, And Facilitator

A scrum master wears many hats including teacher, mentor, coach, and facilitator. Each is a different stance the scrum master might take when interacting with the scrum team, or others in the organization. Part of the art of being an excellent scrum master is being able to select an appropriate stance for a given situation. We also need to be able to flow between them, inspecting and adapting based on the situation and the needs of the people involved.

Teacher

This is the act of showing or explaining something to someone so that they acquire new knowledge. The scrum master is an expert in scrum and related agile practices. The scrum master spreads this knowledge throughout the organization, enabling people to engage in their work more effectively.
Read the full article…

Share it!

Creating Scrum Teams – Choosing Who Is On What Team

Question

How should we form scrum teams as our organization adopts scrum?

Answer

Deciding how to form teams, and which people should be on which teams is the work of management. Of course there are many ways management might choose to do this. One of the most effective ways I’ve found to figure out roles in a scrum transition is to let people decide for themselves! This may sound shocking (who lets employees or even worse, contractors, decide what role they will fill), but we’ve seen it work very well. The operative word is transformation. The power in scrum comes from its focus on self-organizing teams producing value rather than individuals doing work.
Read the full article…

Share it!

Estimating Tasks and Management’s Role in Scrum

Here’s an interesting question that just came in from a local scrum master. It’s about estimating tasks and management’s role in choosing the practices that a scrum team uses.

Question

Chris,

The team I am working with wants to do an experiment where they will stop estimating tasks in hours. Their sprint burn down will then be tasks vs. days instead of hours vs. days. The team believes that they will be successful with this and they are also thinking of creating an initial working agreement for this experiment e.g. any task that will be added will not be longer than a day of effort.

I am supporting this but somehow I have failed in explaining and convincing management. They want me to explain the benefits and the purpose of this experiment. They point to scrum books that say tasks should always be estimated in hours and a burn down chart can only be shown using hours. How do I convince management to allow the team to proceed with this experiment?

Answer

Your team is on the right track in moving away from task-hour estimates. We used to think that estimating tasks in hours was a useful practice, but over time, we have learned that it causes more harm than benefit.
Read the full article…

Share it!

Should Engineers Take Scrum Product Owner Training?

I was recently asked if engineers or other members of the scrum team would get value from a Certified Scrum Product Owner workshop.

Our Certified Scrum Product Owner workshops are designed to build knowledge and skill in three main areas:

  • How scrum works and how to use it effectively
  • How to build shared understanding of the requirements between stakeholders and the development team so the team builds the right thing
  • How to identify and focus the team’s efforts on the most valuable deliverables

These are topics every member of a high-performing team should be versed in. Having engineers participate in product owner training helps them understand the context within which they do their engineering work, and helps them understand how to interact better with product owners around topics such as the business value of paying down technical dept.

For products that are extremely technical, engineers usually work closely with the product owner in order to define and refine the user stories. If the engineers lack story writing skills, then the resulting ‘stories’ are often little more than a restating of the architecture and technical design. The problem with this is that many of these ‘technical stories’ need to be implemented before there is anything meaningful to the stakeholders. Once those engineers have been exposed to the story writing and splitting techniques in our workshop, they are better able to define/refine stories in such a way that they stay pertinent to stakeholders at all times.

I’ll also point out that all scrum masters should take the product owner training, as scrum masters are the scrum experts who provide guidance to the scrum team and the greater organization. Frequently, the scrum master will be called upon to coach the product owners in the various skills needed to be effective in product owner role.

Cheers,

Chris

Share it!

Scrum Sprints: How Long Should They Be?

How long should our sprints be? This is a question I am frequently asked by new scrum masters and scrum teams. Here is how it showed up in my in-box recently.

Question

After we participated in Agile Learning Labs’ Certified Scrum Master (CSM) workshop, my colleagues and I have begun practicing scrum very seriously. We chose one week as our sprint length. Some developers feel one-week sprints are too short, since we have a very strong definition of done. Delivering visible work in one week, along with all of the time in scrum meetings, is too stressful. One team member suggested increasing our sprint length to two-weeks. What are your thoughts?

Answer

Thanks for the question! The short answer is keep your sprints short; find and fix the sources of the stress you are feeling. All too frequently, when scrum uncovers a problem, we seek to change the way we are doing scrum in order to cover the problem back up. Have a look at this post about story point accounting for another example of this tendency. A better response is to address the underlying root-causes of the problem.

For your team, it is unlikely the underlying problem is not enough time in a one-week sprint to get user stories done. More likely, the team is dealing with one or more of the following problems:
Read the full article…

Share it!

Dixit Sprint Retrospective Game

Dixit Game BoxI was inspired to create a retrospective game for agile teams, based on the game Dixit. Dixit is a game that makes use of picture cards. Each of these cards has an unusual drawing on it. The Agile Learning Labs team used it recently in one of our sprint retrospectives and it worked well. Give it a try with your team and leave a comment to let me know how it works for you.

Materials required:

A full set of Dixit picture cards is used. The rest of the supplies from the standard Dixit game are not used.
Each team member should have at stack of index cards, at least five.
Each team member will also need a pen.

Game Play

The team sits around a table. The deck of Dixit cards is shuffled and each team member is given six cards (this can be adjusted up or down as desired). The rest of the deck is placed in the center of the table face-down. Players will take turns being the leader. The tallest person (or shortest, or what-ever) is the first leader.

The leader looks through their six cards and chooses one that represents something that happened during the sprint. For example, let’s say that the team had to create a lot of documentation this sprint and so the leader selects this card from their hand.
Pile of books Dixit card

The leader places this card face-up in the center of the table.

Each player, including the leader, writes what they think the card represents on an index card, and then the index cards are placed face-down in front of each player. When each player has an index card in front of them, the player to the left of the leader turns their index card over and explains what they believe the Dixit card represents. That player leads a brief discussion of the event on their index card, and the discussion concludes by recording any potential action items for the team to consider.

The next player to the left then reveals their index card and the process repeats until it is the leader’s turn. The leader then reveals what they intended the card to represent. If the topic has already been identified by one or more team members, then each team member that correctly guessed the meaning of the picture gets a point and so does the leader. If no team member guessed the intended meaning of the Dixit card, then the leader facilitates a discussion about the topic and potential action items are recorded; no players receive points in this case. The leader then discards the Dixit card and draws a replacement from the top of the deck. Now the player to the left of the leader becomes the new leader and the process repeats. Continue for as many times around the team as feels productive.

Once the main game play is completed, the team considers the various action items that they have collected and selects one or two of these to schedule into the coming sprint as the outcome of the retrospective. Oh, and the player(s) with the most points win a fabulous prize.

Team playing Dixit retrospective game

Share it!