How did I kickstart a new scrum team?

As a Scrum Master at my new workplace Iris Software Group, I had an incredible experience mobilising a new scrum team. I would like to share my learnings and techniques I had applied which I thought might be useful for aspiring Scrum Masters.

I was assigned to double hat the role of scrum master and team manager which was quite challenging. I had to harness all my learnings and skills acquired from my previous roles in various companies starting as a hands-on developer and tester before taking up more responsibilities as team lead, manager, coach & mentor.

To me agile is a mindset rather than merely a methodology and Scrum is all about the adoption of agile which involves collaboration of self-organised cross-functional teams, products and the customers. Every team goes through a storming, forming, norming and performing phase. I believe with the right coaching and mentoring; the storming and the other interim phases can be reduced.

It has been a month since I joined the company and we as a team could achieve quite a lot purely due to 3 main factors - Teamwork, Trust and Respect.

Here is a cursory view of various activities which I focused on to build a great team.

1. Creating a safe, happy and healthy environment

I organised various team building activities that helped my team to understand each other and build trust between them. It’s key that all members should be allowed to express their opinions but be mindful of the fact that respect plays a key role in how you express your opinions and emotions. We built a strong foundation which emphasise a lot on team culture and values. This resulted in great working relationship and paved way for healthy discussions amongst team members.

2. Team Name

Team Name should reflect teams’ vision. Having an interesting team name always helps you to stand out from the crowd and reflect your end goal. At Iris, our scrum team names are based on space themes. I organised session with my team where we gathered various ideas and collectively finalised the name ‘Dream Chaser’.

Yes, we are Dream Chasers??!!!

Every time we say our team name, it reflects our passion, dedication and support towards Iris, commitment and respect towards our customers. My team’s vision is to bring the best out of Iris & serve our customers with their dream products.

3. Ways of working

We come from different backgrounds, cultures and the lessons learnt in life through our experiences varies. I believe a great team comprises of a mix of the above ingredients and brings out the best when we work in a team.

My first focus was to align the team to agree upon a common set of agile principles, values and ways of working.

In our scrum team, the development and test team work cohesively as software engineers. Team members collaborate and interchange roles & responsibilities on a need basis and tasks for team members are not fixed. The ‘One Team’ single unit environment plays a key role in agile and our team is completely on-board with this approach.

4. Team Values

I asked my team members to describe what 'good team' means to them. It was quite interesting to see most of us came up with similar values. The team values were defined by considering the common dream and vision of the team. Below are the key values that we came up with.

•  Openness/Transparency
•  Respect
•  Collaboration
• Team Excellence
•  Relaxed work culture
• Safe and supporting environment
• Celebrate success
• Learn from mistakes

5. Team caption

Many of you may ask, do we really need a team caption? What value does it bring?

To me, this reflects our team’s vision and principles. We came up with a great team caption                               

* DREAM IT * BELIEVE IT * ACHIEVE IT *            

6. Team Agreements

Once we built our team values, my next focus was to facilitate a session with the team to come up with some ground rules for ‘Definition of Ready’ and ‘Definition of Done’. Though Definition of Ready is not in the scrum guide, it is widely used and often considered as a best practice.

a.   Definition of Ready

Definition of ready is a set of criteria for accepting a user story into the sprint. Out team came up with its own definition of ready appropriate for our team needs.

• Acceptance Criteria

          o Well-defined

         o BDD format

• Clear business goals / Value statement
• Prioritised
• Sized/Estimated
• Dependencies Identified
• Risk analysed
• Environment ready

If Required:

• NFRs identified
• Licenses available
• Integration points considered
• Data available

b.   Definition of Done

Below is the list of criteria we came up with to deliver a good quality product increment. We ensure they are fulfilled before we move a user story to ‘Done’ state in Jira.

Mandatory:

•  Peer review completed
• Test should pass in all environments
• End to end regression test package completed 
• All sub-tasks of user story should be reviewed and closed
• All high and medium priority defects of the user story should be closed
• Unit tests implemented for all new functionality
• Automation Testing in BDD
• User story approved by PO and QA

If required:    

• Documentation completed
• NFRs met
• Security aspect has been considered and agreed with sec/ops department
• Scalability/performance/running cost has been considered has been considered and agreed with operations team
• Penetration done
• Code should be instrumented with logging, tracing and performance matrix

7. Scrum Events

a.   Daily Stand-Up

We timebox our stand-up to 15 minutes. We discuss what we accomplished the previous day, the plan for current day and any impediments. More importantly we discuss how we are progressing towards the sprint goal.

Tip:

An energised and enthused stand-up charge the team members with passion and motivation and thereby resulting in a great day.

b.   Backlog Refinement

Though refinement session is not a scrum event as per scrum guide, it is very popular and often considered as best practice to have this session at a fixed point during the sprint. Refinement session is an opportunity for the product owner to go through the highest priority user stories from the backlog. The entire team is involved in this session. I believe this is a great opportunity for the team to understand what they will be working on in the upcoming sprints and ask questions to the product owner. PO can then take the feedback and inputs from the team and come prepared for the sprint planning session. The goal for the refinement is go through the product backlog and ensure that next batch of high priority items are ready for the sprint planning. We also estimate complexity (Story points) using planning poker.

c.   Sprint Planning

During the sprint planning meeting, we

• Agree on a sprint goal by the PO and the scrum team
• The team then pick user stories from the prioritised backlog which meets the sprint goal
• Discuss acceptance criteria and clarify outstanding questions from the refinement session.
• The team plan on how they are going to deliver the sprint.

d.   Story kick-off process

During the story kick-off process, we

• Ensure a common understanding of the user story
• Involve right people for the kick-off process. Ideally PO/Dev Pair/QA, if required SME/Architect
• Discuss acceptance criteria
• Discuss the Integration points(api)
• Clarify assumptions made
• Discuss the technical/testing approach
• Discuss what’s in-scope?
• Discuss what’s out of scope?

e.   Story demo process

At the end of every story, QA/Dev will demo the story to Product owner. This is to get early feedback from the PO and make sure everyone is on the same page with respect to the delivery of product increment.

f.    Code Sharing sessions

Though we have a peer review for the user stories, we also review the code with the entire team at the end of every sprint. This is a great opportunity for the scrum team to learn from each other.

g.   Sprint Review

Sprint review is all about demonstrating to management and the key stakeholders, the amazing work done by the scrum team. I always believe that for the success of an organisation, the scrum team and the stakeholders should work hand in hand. At Iris, the stakeholders actively participate in these sessions and provide their valuable feedback to the scrum team. We also look at whether we met the sprint goal. It’s an opportunity for the PO to get feedback to help guide the direction of the product.

h.   Sprint Retrospectives

Do not miss Sprint Retrospective! It’s a great opportunity for the team to recap how things went, inspect, analyse and make necessary improvements for the next sprint.

If there are any action items coming out of the retrospective, we will prioritise these.

8. Celebration

Do not forget to celebrate!

A happy team is a healthy team and healthy team is a successful team.

Feb 14th, we celebrated Valentine’s day. Thank you, Iris, for cute gifts and sharing the joy of valentine’s day to all the employees.

To conclude I’d like to emphasise that the techniques and processes I applied for the team is not rigid, each scrum master might have different experiences to share. After all, one of the fundamentals of agile is inspection and adaptation.

I do hope these techniques would help some of you in your agile journey too ??

Let’s learn from each other and help our respective organisations to grow and deliver a quality software to all its customers.