In this article, I would like to share my experience on how I facilitated a kick-start/kick-off session for a team that is assembled for a new project at DPL.
According to Richard Hackman (Leading Teams) and Ruth Wageman (Senior Leadership Teams), a team’s effectiveness is based on the way you launch the Team by 30%.
30% refers to how you start up the Team: define the Vision, Product Backlog, team, how Team handles the conflicts, clarify the process, coordination techniques, roles & responsibilities, etc. It takes 2–3 days to do this activity properly and has a high ROI.
Kick-start is important for any team therefore all the activities under the kick-start must be researched and prepared well enough to have the right impact on the team.
By keeping in mind, the importance and the impact of Kick-start, I started to prepare a week before the event. I spent a lot of time researching and finding out how best I can deliver the session? What should be the key ingredients? What activities should be included? How much do teams need to know about agile/scrum before they “go”? What do they need to know about each other and bout the product to be built?
A scrum master takes on the job of the teacher during the kick-start. There is much for the team to learn. If kick-start is done well, it can be jet fuel to a team, helping them to go further and faster than they ever imagined.
The major challenge for me was to conduct the session online as everyone on my team is working from home. I have to be extra careful about ensuring the participation of everyone and to make sure the interest and motivation of team members never drop during the session. To make sure everything goes smoothly I approached my session as follows.
- Video chat to ensure everyone’s focus.
- Screen sharing for the presentation.
- Use of online real-time collaboration tool (Miro) for engagement.
- Microsoft teams whiteboard for clarifying concepts.
I divided the session into three parts.
- Getting to know your team.
- Scrum training.
- Creating a team working agreement.
Getting to know your team
You can find dozens of excellent activities to help people break the ice and to get out of their shyness and comfort zone so they can share their dreams, skills, perspectives, and goals with one another. It usually doesn’t matter if people worked with each other for a long time, or they are entirely new to each other. What matters is to spend some time during the first session as a team to get to know each other.
I have borrowed an excellent activity from the Lyssa Adkins book “Coaching Agile Teams”. Activity is called Journey Lines.
“A journey line graphs a person’s professional journey. Starting as far back as they want, each person draws the ups and downs of their journey on a ﬂip chart. As you can see in the figure, the journey line often looks like a roller coaster with notes at each high and low point to remind the person of that particular event. Some include details of their home life as well as their professional life. Some stick to the professional facts. It doesn’t matter. No two are ever the same, and they all work fine. Each team member will present their own journey in front of others.
Through sharing one’s journey and being truly received by the other team members in the form of the notes, each person is affirmed for who they are and what they bring. And the entire team builds a foundation for working cross-functionally because they now know each other’s backgrounds.”
I requested my team a couple of days before the activity to create their journey maps. And that they can draw it in the form of a map or just make a bullet list as per their own convince.
Few things that can be shared in this activity:
- Total Experience
- Technology stack/Key skills
- Previous projects
- Major accomplishments/Downfalls (overall and at DPL)
- Goals for this project
- Long term Goals/New skill to acquire
- Anything you want to share with the team.
Quoting directly from Lyssa Adkins book to shed some light on the importance of this activity.
“The results of Journey Lines are sometimes astounding. One such case happened for me during a “new” team start-up. The team members had worked together for years over cubicle walls and had come together for their first-ever agile experience. As one person presented her journey line, she got to a hard bit — the year she had cancer. As she talked about the impact of cancer on her life, I noticed another team member getting emotional. After a few minutes, this team member started to cry. Through tears, she said, “I sat in the cubicle next to you that whole year, and we never knew about each other. I had cancer then, too.”
Overall this activity brings a lot to the team. Even if deep connections don’t appear to happen at all, the Journey Lines exercise plants the seeds by making the skills, expertise, and overall background of each team member visible to everyone.
As we are following scrum at DPL so it is important that every team member has some basic understanding of the Scrum framework.
As a scrum master, you might need to adjust your teaching style depending on the experience of your team. In case your team members have been working on scrums teams before, then your responsibility as a teacher is to make sure everyone on the team is on the same page as far as scrum knowledge is concerned.
There are chances each member has his/her own definition of the scrum but it’s important to help and take them to textbook scrum. You have to show the original version of the scrum. And most importantly you have to do it in a polite way so no one feels offended.
You can start the session by saying something like this, “I know you all have worked in scrum projects before, but let’s take few minutes so I can show you original version of the scrum to make sure we all are synchronized in our understanding of it.“
If your team is new to scrum, you have the opportunity of a fresh start. Your session will be more detailed and longer as well. Try to cover every aspect of the scrum including roles, rules, events, and artifacts.
I covered Vision, Release planning, Estimations along with the roles, rules, events, and artifacts in my session.
Creating a team working agreement
You can call it Working Agreement, Team Norms, Team Contract, Team Ground Rules, or Team charters anything you want to call it.
Working Agreements are a simple yet powerful way of creating rules/guidelines for the team’s culture. It is a list of standard procedures which is a valuable tool for guiding team conduct. It helps the team in creating an environment that is safe for everyone. Where no one is afraid of bringing up any idea to discuss with the team. These agreements usually enable the ethically correct environment and set the team expectation with each other.
I conducted this activity using (Miro) an online real-time collaboration tool to make sure everyone was engaged in the activity.
I included the following things in our working agreement:
- Team name
- Team roles
- Team norms
- Definition of awesome
- Baseline story
Name is important as it gives an identity. Every team must have a unique name that should represent rules, values, and principles on how people on the team want to work together. A name provides a bonding and a common purpose to fulfill.
Jacque Rowden, the Senior Director of Continuum’s Help Desk, told a story about a group that worked during the overnight shift. For a while, the group members would blame each other for any shortcomings that occurred during their shift. However, after they came together and rallied under a common team name, they were able to better allocate their resources and as a result, their shift began running much more smoothly and efficiently.
The name should be different than the project name and having a logo/flag will enhance the impact. It can be placed on the walls in team premises.
Everyone on the team must be clear about the vision of the product they are working on.
The Following questions provide the opportunity to better understand the overall vision.
- What is the core vision statement?
- What value does it provide to the client?
- Why it is important for our company?
- What problem does it solve for the end-user?
Identify all the roles on the scrum team. Make sure the team size is within limits as mentioned in the scrum guide.
Write the name of members like who will be product owner, who will be scrum master, and who’s part of the development team.
You must also list the core competencies/skills of the development team members.
Specify when and where events will take place. Also, mention the event duration as well by keeping in mind the sprint length. The team must know who is required for which event. Don’t forget to specify the time of backlog grooming by the team’s coordination e.g “we will schedule it on the 6th day of the sprint”.
In this section, the team can lay down the rules they need to follow during the product life cycle.
A good way to make sure everyone remembers what they have included in team norms by displaying it on the wall in team premises.
Teams don’t have a police force to ensure that it’s followed. It’s the responsibility of the team as a whole to make sure everyone follows it and respectfully reminders to peers when trespassing occurs.
You can include things like following in the team norms:
- Daily scrum timing.
- Core hours.
- Be on time.
- Check in-outs during w.f.h.
- Zero tolerance for bullying.
- Respect other’s opinions.
- No phones during the meetings.
- Video chats for meeting while w.f.m.
- Mute mics.
- Don’t commit unknown and undone stories.
- PO availability.
- Burndown is the responsibility of the team and tfs should be updated daily.
It is worth considering Scrum Values as a source of guidance while creating this list e.g. Value of Respect fulfills when everyone makes sure to be on time in meetings.
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.
- Acceptance criteria to be met.
- The main functions must functional.
- Automation test cases must pass.
- No critical/functional bugs.
- No major UI bugs
- Design tested.
- Must be Integrated.
- Unit testing must be done.
- Feature level functional tests must be passed.
- Non-Functional requirements must be met.
Definition of awesome
After the done comes the awesomeness. I have borrowed this concept from an article by Faye Tsampardouka. I urge the team to move one step ahead and have some higher goals to hit. Teams need to answer the question: What will make them super excited and Awesome.
- Be able to build, test, and ship a feature within a sprint.
- QA starts the very first day of the sprint.
- The work in progress is limited.
- The satisfaction of all stakeholders.
- Praise from the client.
The team brainstorms to identify a user story that will be used as a reference during the estimations. A baseline story must be picked with a common understanding and requires the whole team. After picking a story analyze it and estimate it. It’s better to use story points estimations.
Most teams usually pick the smallest story for the baseline e.g. “A simple user login functionality”. But you should facilitate and discuss and let the team decide what to pick.
Baseline story should be available all the time especially at the time of planning and it’s a good habit to just revise the story during the estimations in each sprint planning.
How to maintain the working agreement
Working agreements should act as a living document. The document should be reviewed periodically as the team evolves. It is good to review it in every sprint retrospective meeting and see if teams need to add/remove anything depends upon the circumstances.
An effective kick start meeting serves the team a great deal. It helps creates a shared understanding, norms, and priorities for the team. A good kick start will help the team to achieve fantastic results a lot earlier than any other team does. Kick-start is important for any team therefore it’s your responsibility as a facilitator that all the activities under the kick-start must be researched and prepared well enough to have the right impact on the team. This is based upon my experience and a lot of research I did to find the best activities out there on the internet. I hope this article will help all scrum masters to kickstart their teams and avoid a lot of problems scrum teams face during project development.
- Coaching Agile Teams by Lyssa Adkins