How can you liberate a meeting without using Liberating Structures?

There is enough LS which you can use to make your meeting productive. However, if you have the feeling that they are overused or you are bored with them, think about the five elements and create your structure.

  1. Structuring Invitation
  2. How Space Is Arranged and Materials Needed
  3. How Participation Is Distributed
  4. How Groups Are Configured
  5. The sequence of Steps and Time Allocation

An example of a retrospective with a new team:
Situation: we have a team of 10 colleagues. A developer and I had just started on the team.

STEP 1:
Ask the group to create two teams and give them the following assignment per team:

Team 1: take 10 minutes to think of all the reasons why this team is the worst team ever. after the 10 minutes, try to convince me that I have made a bad choice to join the team.

Team 2: take 10 minutes to think of all the reasons why this team is the most impressive team ever. After 10 minutes, try to convince me that I have made an excellent choice to join this team.

STEP 2:
After both presentations, give the next assignment:

Team 1: take 15 minutes to discuss within your team what actions can be made to keep the most positive things that team 2 had mentioned.

Team 2: Take 15 minutes to think of actions we can take to dismiss some of the reasons that team 1 had mentioned.

STEP 3:
After both presentations, ask each one in the group to think about the actions mentioned in Step 3 and take five minutes individually to find out how they can contribute to making those actions a success. You can also participate in this. We then share our contributions. Asked them to memorize their contributions, and get back to them in a few sprints.

The original post from Ziryan Salayi can be found here: https://www.linkedin.com/pulse/how-can-you-liberate-meeting-without-using-liberating-ziryan-salayi/

Questions a New Scrum Master Should Ask Her Team to Get up to Speed

  1. How large is your product backlog?
    I do not believe in product backlogs that are larger than what the team can handle in three, maybe four sprints. If the product backlog exceeds this threshold, the product owner might be in need of some support.
  2. What is the typical age of a user story in the product backlog?
    Again, I do not believe in the value of a user story that is 5 months old. And a “but I have been working on it ever since” is an excuse in my eyes.
  3. What is your average lead time from an idea being added to the product backlog to its delivery?
    No one could answer that question in the before-mentioned session. But it is actually one of only three metrics that can provide some insight on whether “agile” has been successfully adopted by your organization.
  4. Does your product backlog contain user stories none of the current team members is familiar with?
    Maybe those should be re-estimated with the current team members to make sure the estimation is still accurate?
  5. How often are you grooming the product backlog?
    That should be done at least once a week depending on the state of the project.
  6. On how many user stories are you working in parallel during backlog grooming?
    Ideally, a team should not be working on more user stories than it can handle within the next two or three sprints. Otherwise, the risk of allocating resources on user stories that may never make into a sprint backlog becomes too high.
  7. How long does the grooming of a typical user story take?
    The grooming should not be taking more than one to two sprints.
  8. How are you creating user stories?
    (Is it a joint team effort with the PO or is the product owner writing the user stories and the team estimates them?)
    There is a tendency to observe that product owners become more a kind “technical writer” of user stories which then get estimated by the team. I suggest, however, to turn user story creation into a join effort of the whole team.
  9. Where are you discussing user stories?
    Only during grooming sessions or also on Slack or via comments on tickets, for example?
    Every team has it own habits, and maybe commenting in Confluence, Jira, Github or utilizing Slack is an effective means of communication in your organization. As long as this happens before a user story is selected for a sprint backlog, this should be fine. Discussing its essentials afterward is a problem, though.
  10. Do you apply a “definition of ready” standard to your user stories?
    That should indeed be a standard. A volatile velocity can at least partly be attributed to the lack thereof.
  11. If so, of what criteria is your “definition of ready” composed of?
    Typical criteria for a “definition of ready” are: The description is available, acceptance criteria are defined, the story can be delivered within a sprint, all UI deliverables are available, all (probable) dependencies are identified, performance criteria are defined, tracking criteria are defined and the story is estimated by the team.
  12. Who is writing acceptance criteria and in what format?
    It should be the product owner in collaboration with the team to create a shared understanding of what needs to be built.
  13. How are you estimating the likely effort of a user story?
    An estimation poker would be useful.
  14. Are you estimating in man-hours or story points?
    Estimating man-hours is betting than not estimating at all. However, I prefer user story points, particularly if the application in question is burdened with legacy code and/or technical debt. Predictability and stakeholder communications becomes easier this way as they are featured with a built-in buffer.
  15. How are you practicing the estimation process, if the team shares different opinions?
    Preferably, you should observe the team’s estimation process in real life. But in case you have to ask: is it a typical vote-discuss-revote cycle? Or: when and how do you pick an estimate? (Examples: 50:50 split, e.g. 3*3 and 3*5 – which one do you take? Or a majority split: 2*3 and 4*5. Or the estimations cover a range, e.g. from 2 to 8?) It is a good way to learn more about the team building state, too.
  16. What is a typical distribution of story sizes in your sprint backlogs?
    This one tries to figure out, where the commitment sweet spot of the team is, based on the sprint backlog composition. To my observation, teams often work in a more successful way, when a sprint backlog comprises of one or two larger user stories, some medium sized stories and a few small ones.
  17. Are you re-estimating user stories at the end of a sprint? If so, under which circumstances are you doing so?
    That should always be done if a user stories turns out to be way off its original estimation.
  18. What was your velocity of the last three sprints?
    The team should know its velocity, how could it otherwise possibly improve?
  19. How many user stories are typically not finished within a sprint and for what reasons?
    If the team is bullish and picked more user stories than it could probably handled at the beginning of the sprint, so be it—nothing to worry about. Also, there are other incidents that might negatively effect the team’s actual velocity, e.g. sick leave or a critical bug a few days into the sprint. If the team, however, is regularly leaving user stories on the board because estimations were wrong, this is a sign for concern. See also: Scrum: The Obsession With Commitment Matching Velocity.
  20. Are you changing user stories once they become an item of a sprint backlog? And if so, under what circumstances?
    Well, making them smaller if the team runs into a problem is certainly not great, but acceptable—if the user story in its reduced form still delivers value. Making it larger after the sprint planning is, however, not acceptable.
  21. What are the obstacles the team is facing today?
  22. What are the dependencies on other teams?
    And if there are dependencies, are you waiting for other teams to complete their tasks?
  23. Define and discuss at least three key team goals for the project.
    Some of the answers may seem obvious, i.e. meet our deadline within our budget, but this discussion can often bring out other goals which are not obvious to the Team initially. It can help the Scrum Master understand Team motivations and dynamics.
  24. What are key success factors to achieve our team goals?
    Defining and discussing key success factors, i.e. minimizing the impact of dependencies, can help identify project-level impediments, risks, and issues which the Scrum Master can begin to address. It also is a good benchmark to review and update as the project progresses.
  25. What do team members hope to achieve with this project?
    I like to get a sense of people’s personal goals for the project in addition to the Team goals we will establish collaboratively. Having this information can help keep people motivated over the course of the project. Some people may want to learn new technologies, be part of a high-performance Agile Team, or have other goals.
  26. What type of work environment do we want to create on this project?
    This question can stimulate good discussion about how Team Members want to interact with each other to achieve the project goals. Often the discussion centers on trust, communication, collaboration, and respect, but it’s good to make sure there is some agreement (or an acceptance of differences) by the team about what is important.
  27. What can we do as a team to make sure that we support each other to achieve our team goals?
    This question can help the Scrum master understand how team members understand the importance of making commitments as a team rather than as individuals. It can also help the team establish informal agreements about the need for everyone to support each other, to take on roles outside their specialty, and trust their team when they need to ask for help.
  28. What should we do when we are not achieving our goals or not supporting each other?
    Obviously, this can be addressed in a retrospective, but having the discussion early can be helpful to understand how team members perceive how these situations should be handled. It can help establish the need for open and honest communication built on trust.
  29. How should we celebrate success for achieving our goals?
    It’s important for the team to visualize and expect success. This discussion can help the team discuss rewards that are meaningful and keep them focused on realizing those rewards.

Original post can be found here: https://age-of-product.com/20-questions-a-new-scrum-master-should-ask-her-team-to-get-up-to-speed/

How To Kickstart A Great Scrum Team (10 practical things to do)

In this post, Christiaan Verwijs shares his experiences on how to best Kickstart, Lift-off or Launch a (new) Scrum Team.

  • Understand team development (and your role in it)
    • Forming phase
    • Storming phase
    • Norming phase
    • Performing phase
    • Adjourning phase
  • Reserve time for the Kickstart
  • Getting to know each other is half the work
  • Teach Scrum
  • Formulate a Team Vision
  • Create a Team Contract
  • Pick a Team Name
  • Set expectations
  • Retrospectives, retrospectives, retrospectives
  • Involve management to support the Kickstart
  • ‘Bring it to the team’

Read the complete article here: https://medium.com/the-liberators/how-to-kickstart-a-great-scrum-team-10-practical-things-to-do-2143bdde1a8d

What does a new scrum master do within his/her first few weeks in the role?

Woody Arnold answered this question on this page and here is the quick summary:

Day 1 (Monday)

  • Admin – Paper work, meet with HR, get connected.
  • Meet with manager. Understand expectations & situation.
  • Schedule meetings for the week – 1-on-1’s with team members, customers etc.
  • Discern the situation, develop hypothesis.

Day 2 (Tuesday)

  • Start floating ideas – problems you’re hearing, solutions.
  • If you need a half day scoping meeting on Thursday, you need to schedule it today to give people a little warning.
  • Continue with 1-on-1’s

Day 3 (Wednesday)

  • Create a short presentation for the Thursday meeting. This contains for instance: What you’ve heard, changes you’d like to implement starting next week.

Day 4 (Thursday)

  • Prep for planning meeting.
  • Meeting. Quick presentation – Problems we’re trying to solve, why Scrum… etc.

Week 2

  • Monday – Sprint planning, and the start of sprint 1.
  • Daily Standups – Coach the team into making effective daily standups.
  • Sprint Review – schedule the sprint review for the last day of the sprint. Make sure to invite “customers”.
  • Retrospective – Schedule the retrospective for after the sprint review.