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…
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…
World Café is a fun, flexible, and scalable technique for group conversations that leads to creative solutions to complex problems. World Café has some similarities to Open Space Technology: both techniques work for groups ranging from a few people to a few thousand; both are frameworks that support individuals and interactions. World Café is useful for generating and communicating ideas, making decisions, and even doing hands-on work. We’ll be teaching product owners how to use it in our upcoming Advanced Certified Scrum Product Owner (A-CSPO) workshop.
How It Works
The facilitator breaks the room into groups, then sets them to explore a set of related topics, one per table. Each table has a host whose job is to stay with the table and provide continuity while the groups discuss the topic. The other participants rotate between tables on a regular schedule, perhaps every 15-30 minutes. The idea is that those who travel between tables will cross-pollinate ideas between the topics and bring fresh perspectives. By participating in each topic, the participants come to have a holistic understanding of the main issue, and are able to understand each sub-issue within this context. In the last round, people have the option of returning to a previous table so there is opportunity for closure and continuity. Read the full article…
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.
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…
This question came from a client: What is the project manager’s role in scrum?
In answer to your question about project managers, there is no project manager role in scrum. The duties of a project manager gets split between the product owner, scrum master, and the development team.
The product owner has the vision of the product and is the business representative accountable for making sure the business is kept up to date about the product, the schedule, and the budget. The product owner does this in multiple ways including:
Grooming and refining the product backlog
Understanding the development team’s velocity so he/she has a sense of when backlog items may be ready for release
Communicating frequently with the stakeholders
In the sprint review meeting, helping the team demonstrate new features and facilitating conversations with the stakeholders on the direction of the product and the product backlog
How should we form scrum teams as our organization adopts scrum?
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…
How long should we time box the prep time before the first sprint starts – i.e. the time used to decide on a product that has a good chance of meeting the goals, make effort and business value estimates and get the top product backlog items to be sprint ready?
I would look for the shortest time you can to prep. To get started in a sprint you need a team and a product backlog. You don’t need a complete and perfect product backlog – since more product backlog items will get added as you go along and existing items will be altered and sometimes removed. I would start working and refining the backlog as you go – so you don’t end up with a “design sprint” that takes longer than a sprint itself.
The Scrum Guide outlines that up to about 10% of the development team’s capacity will be used in backlog refinement activities. These activities are ongoing and collaborative between the product owner and the development team. The scrum team decides how and when refinement is done. In the initial sprints, that activity might look like several backlog refinement meetings to get the backlog to a state where there are 2-3 weeks of sprint ready product backlog items. After that it may look like one refinement meeting per week and the development team members doing research, prototyping, etc. to get information to refine the product backlog items. Read the full article…
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.
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?
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…