Launch Event — How to give a new Scrum Team the kickstart it deserves
According to Richard Hackman and Ruth Wageman, a Team’s effectiveness is based on the way you launch the Team by 30%. Not negligible at all, right?
The Scrum Master should organize a Launch Event for the new Team as soon as possible, if not at the very beginning. However, the Team itself could drive the event once some basic prerequisites are met.
Make sure that all members (do not forget the Product Owner) have at least basic Scrum knowledge. It is strongly advised to have a dedicated Scrum Master collocated with the rest of the team. Nevertheless, the Team should be small (2 pizzas teams), cross-functional, and stable. It is also crucial to have a common understanding of the framework to follow and that the single person of product decisions is the Product Owner.
Let’s say that by this point you have set the ground and all prerequisites are met. So take a deep breath and launch!
The goal of the event is to set the ground for the new Team, clarify any blind spots, and most importantly, engage the Team to determine their own identity and process.
Things a Launch Event should cover
Mission: It is essential for a Team to have a clear mission in order to passionately deliver value. it is the Product Owner who holds and drives the mission, though.
Don’t: Conquer the world.
Do: Provide passengers with an easy-peasy way to move around the city.
Kickoff Backlog: Prior to even think of forming a new Team, do your homework and construct a kickoff backlog. It does not have to be fully developed but rather a backlog of Epic level. It is strongly advised to actively engage the team as soon as possible in the kickoff backlog quest, since the backlog and the mission are mutually driven.
Name / Logo: A Team should have a Name and optionally a Logo (cajole your designers) that are uplifting and kind of kick-ass and fun. So, bring it to the team and let them fool around!
Examples: Bug To The Feature, Rubberducks, Team404.
Working Agreements: A set of rules originated from the Team itself that constitutes an ethical contract among the members. Good advice is to define some basic pillars and to elaborate on those. For example, Purpose, Mastery, Autonomy, Respect, and Transparency could be used as starting points.
Definition Of Ready: Simply put, these are the minimum characteristics that a User Story must fulfill in order to be accepted by the Team. It could be stuff like Description, Title, Acceptance Criteria, Identified Dependencies, Effort Estimation, or even to be groomed twice. An even better approach is to comply with INVEST.
Definition Of Done: There must be a common understanding of what DONE means. A feature is considered as done when it is developed, tested, and meets all the acceptance criteria. Done also means that it is possibly (Product Owner decision) shipped. A great definition of done is the one the Team can actually commit to and not wishful thinking.
Definition Of Success: Measuring success is difficult, let alone define it! A good practice is to focus on what the Team thinks of a successful Sprint.
For example:
- All User Stories are Done and ready to deliver
- No hotfixes after the release
- No “stand-by” time for the Team
- Happy stakeholders after Review
- Team accomplishes Sprint Goal
- Happiness factor
Definition Of Awesome: Taking success to the next level, awesomeness comes on stage! The question to be asked is what will make the Team feel and deliver AWESOME!
For example:
- Be able to build, test and ship a feature within a sprint
- QA starts the very first day of the sprint
- Get feedback on the feature and the updated version is live next week
- The work in progress is limited
Definition of Impediment: Identify, as soon as possible, any dependencies the Team will face down the road. Barriers like “I need THIS to do THAT” are definitely an impediment, but do not make the mistake to miss any behavioral impediments as well. Make sure that the Team will rise any impediments and follow up.
Baseline User Story: The Team brainstorms to identify a typical User Story that will be used as the baseline for all the other User Stories to be compared with. Pick a User Story that everyone has a common understanding and requires the whole Team with all of the cross-functional disciplines. Analyze and estimate. Many Teams pick a User Story that requires the whole Team to work for a day, others do not. I suggest to let the Team pick without having in mind any time limitations. After all, the best practice is to avoid estimating in time units.
Effort Estimation metric: The best advice is to use Story Points rather than any time-related metric. Mike Cohn puts it sharply: “Story Points are estimates of effort as influenced by the amount of work, complexity, risk, and uncertainty.” The most popular metric is the Fibonacci numbers, but I’ve seen Teams using t-shirt sizes or even animals. Personally, I choose the Ant versus Mammoth analogy to explain to the Team how relative estimation works.
Physical / Digital Board: Discuss with the Team how they want to communicate and track their progress. A digital board is good for the stakeholders and a physical board is great for the Team. So why not use both? The most important thing is that the Team is committed to updating the board regularly. An outdated board is just overhead to the Scrum Master and pain for the Team.
What about the time?
Enough said about context, but what about time? Well, the list is long, but you do not have to cover all of the topics mentioned. I suggest the Launch Event be an all-day festivity. Include lunch, coffees, beverages, and cover as much possible but do not forget to have an agenda.
Review
The topics covered at Launch Event must not be static at all. Working Agreements and Definition of Done in specific should be reviewed as the Team matures and grows. I would suggest reviewing the major topics after a significant change in the Team’s structure, efficiency, and growth.
Tips to spice things up
- Communicate the purpose and the agenda of the event to the Team
- Not only Visualize but also Personalize the space and board or anything else that affects the Team’s mood
- Schedule ahead all Scrum ceremonies to make sure everyone can participate
- Involve role models to support the Kickstart Event and provide credibility
- Apply behavior boosts: e.g. “I am late” hat, pass the ball during standups
