CASE STUDY

@ 2017 Xebia | All rights reserved. All other trademarks, logos referenced herein belong to their respective companies.@ 2017 Xebia | All rights reserved. All other trademarks, logos referenced herein belong to their respective companies.

Background

Objective

Transforming teams from Waterfall to Agile in 6 weeks

Our client is a leading Telecommunications giant in the US. With over 100 million wirelesscustomers, it is a Fortune 100 company both in terms of revenue and profit. The client approachedXebia to run a 6-week coaching & mentoring program for one team

The client wanted to upskill their IT staff and enable them to deliver better quality software. Insteadof training the teams in each and every practice, they wanted them to learn about deliveringincrements of their existing product by incorporating Agile and Devops practices. The goal was toimpart knowledge to their teams by picking up MVPs of their existing products, and creating asubstantial and sturdy knowledge of modern technologies within the organization. The complete 6-week intensive coaching program was set up in a dedicated area and was named as ‘Dojo’.

Methodology

To ensure that maximum value is provided to the client through coaching the team on Lean, Agile,and Devops principles, tools and practices, Xebia positioned 3 coaches as ‘Dojo Masters’ to cover theentire 6 weeks of coaching & mentoring program. The 6-week program was divided into 3 chapters:

Chapter 1Day 1 & 2

Chapter 2Day 3 to Day 29

Chapter 3Day 30

What is a Dojo?

Dojo is an immersive hyper paced learning program that helps the teams to adopt agile values &principles, build engineering acumen and deliver technology solutions more effectively. It’s aboutlearning new tools that would lead to speed towards the end of the Dojo. Learning through shortiterative cycles gives a team the ability to build muscle memory over the course of a 6-week period.Therefore, when the time arrives for them to transition back to their work environment and start thesprint and story planning, they are completely aware of what it means.

Value Speed Quality Happiness

Teams are equipped to grade progress accordingto four measures:1. Value2. Speed3. Quality4. Happiness

CASE STUDY

@ 2017 Xebia | All rights reserved. All other trademarks, logos referenced herein belong to their respective companies.

The 6-week journey

On Day 1, the entire team worked with the Dojo masters to do a chartering exercise for 6 weeks.The team decided on the following:

1. Delivery objectives of the product

2. Learning objectives of the team (each individual)

3. Baseline skills of the team (Agile, Development, QA)

4. Working agreements

Learning Objectives1. Writing effective unit tests

2. React.js

3. Jenkins

4. Story writing

5. How to deliver in shortsprints?

6. Efficient Planning

7. Functional test automation

Do’s1. Come and leave

office on time2. Commit to delivery3. Learn tools and

ensure compliance

Don’ts1. Avoid blame

games2. Don’t fail on

delivery because of learning

Chapter 1

The skills were outlined under three broad areas: Scrum, Development and Quality Assurance.

Scrum

• Roles

• Culture

• Ceremonies

• Product Management

• Metrics

Development

• Unit testing

• Refactoring

• Pair Programming

• Coding Standards

• Continuous Integration

Quality Assurance

• JavaScript

• Automation framework

• Writing automation scripts

• Integration with CI

The Sprint schedule and cadence plan (shown below) were decided in consultation with all thestakeholders. Topics for 1 hour sessions by Dojo masters were also agreed with the team. Calendarswere blocked for each ceremony till Sprint 9.

Cadence Plan (3 day Sprint)

DAY 1 DAY 2 DAY 3

1st Half 2nd Half 1st Half 2nd Half 1st Half 2nd Half

Sprint Planning 10:30 to 11:30

Daily Scrum 10:30 to 10:45 10:30 to 10:45

Sprint Review 5:00 to 5:30

Sprint Retrospective 5:30 to 6:00

Refinement 4:00 to 5:00

Dojo session 5:00 to 6:00

CASE STUDY

@ 2017 Xebia | All rights reserved. All other trademarks, logos referenced herein belong to their respective companies.

The 6-week journey

Chapter 2

WEEK 1

• Day 1 started with the introduction of the team with the Dojo Master responsible for Agile coaching.

• The initial exercise of Project chartering helped in understanding the Product and the Learning objectivesthat the team members had in mind.

• The next day started with the Sprint planning meeting in which only one story could be refined. Thishappened due to unavailability of the PO and the inability of any other person in answering teamsclarification.

• Sprint started and the team started work on the committed stories.

• Coaches gave a detailed walkthrough on how a model stand up should happen on Day 3

• The team was educated on relative estimation through story points during Sprint refinement. Out of the 8stories that were discussed, 2 stories were sized in story points. The Dojo master worked with the team tocreate a technical SPIKE. UI mockups were missing in some stories so they were not discussed.

• On the last day of the sprint (Day 4), none of the stories were completed and shown during the demo. 7action items were decided during the retrospective.

• Sprint 2 started on Day 5 with a better sprint planning session. All except for one story were discussed inthe planning with 13 stories committed. The Agile Dojo Master highlighted that the amount of work wasquite huge for the team to complete, but the team was confident in delivering all.

WEEK 2

• The Technical Dojo Master joined the program on Day 1 of Week 2.

• Stand-up on Day 2 had 70% of attendance. The team understood the importance of having the entireteam around. Some of the dependent tasks couldn’t be discussed. The Dojo masters highlighted the riskof not delivering the commitment. The team decided to move away from the Visual task board and havethe JIRA board projected for the next stand-up.

• JIRA compliance was very low as the team was not updating the tasks and the remaining work for eachstory in progress.

• The first clue of improvement in the team was drawn from complete attendance during the stand up onDay 3 of Sprint 2, Most team members started sharing their updates in Scrum format. The Code Review ofone story was completed during Sprint 2 and the review comments were explained to the team.

• Few developers were coached on how to write effective unit tests by the Technical Dojo master.

Challenges (Week 1)

1. The Product Owner was remotely working for the 1st week

2. There was only 1 QA member for 6 developers

3. The team lacked basic Agile knowledge

4. The user stories were enormous without adequate information

CASE STUDY

@ 2017 Xebia | All rights reserved. All other trademarks, logos referenced herein belong to their respective companies.

The 6-week journey

Chapter 2

WEEK 2 (continued)

• 2 stories were completed & demoed from the 7 committed stories. 1 story was accepted, the other storyhad some bugs and the PO gave some feedback. The Agile Dojo master took an additional 30 minutes, atthis moment, to explain the relevance of clearly written acceptance criteria. The team was educated withthe concept of Definition of Done too.

• During the Sprint Retrospective, 3 action items emerged. Also, the team was made aware that 1/7 actionitems of Sprint 1 Retrospective were closed.

• Sprint Planning for Sprint 3 was conducted by the Scrum Master. The Definition of Done was finalizedwith the team agreeing on Unit testing and Code Review as part of DoD. In addition to 6 stories from theprevious Sprint, there was 1 additional SPIKE which was added to the Sprint backlog.

• The Dojo master conducted 1 hour JIRA session and made the team understand what are the essentialinputs required from by them for ensuring good compliance of the tool.

• Jenkins session was conducted to explain the setup and its configuration. The intent was to operationalizeit from Sprint 4.

• 2/9 stories were completed at the end of Sprint 3. By now, the team understood the criticality of notmeeting a commitment. Firstly, there was a lot of integration and merge issues. This was due to workingin silos and the incorrect ways adopted by the team to write unit test cases. Secondly, the team didn’t askrelevant questions during the planning to further refine the story which resulted in ambiguity in theacceptance.

• Dojo masters stressed the importance of refactoring the code.

WEEK 3

1. The QA Dojo master joined the team. His task was to setup the automation framework, train the team towrite test cases in JavaScript and ensure the ready test cases get executed upon successful deploymentto the QA environment.

2. The Agile Dojo master worked with Product Owner during Sprint 4 (Refactoring Sprint) and refinedstories for next 2 sprints. He introduced some story splitting techniques and educated the PO on how toprioritize the stories. He guided the PO to create a Vision and a roadmap for the product. This exercisewas done to bring clarity to the thought process of the PO.

3. The Technical Dojo master worked with the team in refactoring the existing code so that whicheverfunctionalities delivered through stories till Sprint 3 should we working.

4. Jenkins was integrated with the build tool and dashboards were created for Jenkins and JIRA.

5. The 3-day effort was evaluated through the demo of the developed functionality till Sprint 3 and theteam was able to close all retrospective action items of Sprint 3 as an outcome of Sprint 4.

Challenges (Week 2)

1. Developers lacked in basic programming skills while some of them had very less experience in Java

2. The deployment server was in the US. Any issues found during the deployment resulted in delays

3. There were a lot of changes in the priorities of user stories

4. Dojo masters didn’t have access to customer’s tools and application

CASE STUDY

@ 2017 Xebia | All rights reserved. All other trademarks, logos referenced herein belong to their respective companies.

The 6-week journey

Chapter 2

WEEK 3 (continued)

• With 16 days remaining, the team, stakeholders, the management and the Dojo masters agreed to run a4-day sprint cycle and complete 4 sprints in model concept in 16 days. Commitment and positive energywere felt as the team eagerly waited to kick-start the sprint planning for the last day of week 3.

• Sprint planning went as expected with all necessary ingredients to commit to 5 stories. The Sprint startedin JIRA before the team ended the session.

WEEK 4

• To keep up the momentum, the Agile Dojo master introduced a 10 min huddle concept at 4:30 p.m. in theevening. This was to keep the focus and remind everyone on the daily goals that are required to be met tocomplete the Sprint goal. A buzzer bell was run 3 times everyday to remind the team to update the JIRA.

• The progress until Day 2 end of Sprint 5 was slow, but Day 3 ended with 2/5 stories moving to QA.Everyone was happy to see the benefit of moving to 4 day sprint.

• 4 out of 5 stories were developed, but 2 of them failed the code review process. The Dojo mastersenforced this discipline, and only 2 stories were demoed and approved by the PO.

• The last important practice introduced was pair programming. Till now, the team had been hesitant inadopting this, but now the trust in the process compelled them to try this as well.

• Sprint 6 commitment was to develop and deliver 7 stories and improve on 5 retrospective action items.By now the planning session had become quite smooth with the Scrum Master taking control of theprocess from the Dojo masters.

WEEK 5

• 5/7 stories were delivered by Sprint 6 end and 4/5 retrospective action items were closed.

• Pair programming did wonders for the team’s productivity. It helped the team to break the silo way ofworking individually on one functionality and shortened the code review process due to bettercollaboration while coding and writing unit tests.

• Sprint 6 was the time when there was a tacit sense of satisfaction among everyone involved in the Dojo.The concept of quick sprints in a focused environment now seemed a success to all.

WEEK 6

• The last week focused on sustaining the momentum. Sprint 7 helped in deriving a stable velocity since 4/5stories got delivered. With 10 to 12 story points delivered in both Sprint 6 and 7, the PO felt comfortablein forecasting based on the pace of delivery of the team

Challenges

1. Product Owner pushed the team to work overtime due to project delivery timelines.

2. Some team members showed some resistance in doing pair programming.

Challenges

• To keep up the pace, some team members tried by passing the code review and unit testing.

• Environment setup of QA and Jenkins took longer time than expected.

CASE STUDY

@ 2017 Xebia | All rights reserved. All other trademarks, logos referenced herein belong to their respective companies.

The 6-week journey

WEEK 6 (continued)

• In the last sprint review, all 5 stories were demoed, but only 4 stories were approved by the PO.

• There was a retrospective of 1 hour conducted on the last day and the feedback was overwhelming. TheHappiness Index of the team was 4.8.

• 6 out of 7 learning objectives were completely achieved and the remaining one was (learning React JS)partially achieved.

• Toward the ending of the Dojo program, it had been a terrific experience for all direct and indirectparticipants. There was enough word in the organization that made the management believe in this newon the project learning program.

Chapter 3

Learnings

• Reduce project delivery pressure to balance out time for learning.

• There is a basic training on Process, engineering practices, tools at the beginning of Dojo (like a Sprint 0).

• 1 hour learning session every day, starting from the beginning of the 6-week program.

• Dojos can highlight more instances of mistakes at a designated time everyday and share solutions duringthe planned training sessions.

• Dojo masters should engage with the PO and SM before the 6-week program to have an effective Sprint0.

End assessmentProcess and Technical Assessment has been done on a 6-point scale (Level 0-5) after baselining each of the

parameters in the graphs shown below in the beginning 1-2 weeks of Dojo. The assessment has been

categorized into Agile, Development practices and QA Automation.

Scrum

•Roles

•Culture

•Ceremonies

•Product Management

•Metrics

Development

•General Practices

•Backend

•Frontend

Quality Assurance

•JavaScript

•Nightwatch framework

•Galean Framework

CASE STUDY

@ 2017 Xebia | All rights reserved. All other trademarks, logos referenced herein belong to their respective companies.

End assessment

The 6-week journey

CASE STUDY

@ 2017 Xebia | All rights reserved. All other trademarks, logos referenced herein belong to their respective companies.

End assessment

The 6-week journey