100 Days of Agile transformation and building DevOps team

Anil kumar Sharma
5 min readOct 22, 2019

--

My experience of breaking silos and building an Agile team

There are many challenges one faces as a manager and sometimes you need the experience of others to make the right choices and strategies. Sharing my experiences in the hope that it helps someone to make an easy choice:)

Last year, I started managing a team with a majority of Developers and a few others like Sysadmins, Analysts and DB admins. My team was handling all E2E tasks of application development and operations individually. The team was using an internal ticketing solution to track their work and didn’t require much interaction. Everything was working fine and the team was happy about the way things were going.

A company-wide agile transformation was initiated and I was asked to implement the same in my team. Since it was a mix of work responsibilities within the team, I was also asked to use the DevOps (or everyone does everything mode) model.

When the idea was first bounced off me, my initial thought was “Why us? Why would you want to disturb a team that’s already performing well” and secondly, “It’s going to be very challenging to change the team’s existing mindset/culture”.

Change Mindset/Culture? Yes, the first thing required to succeed in the transformation was to change the mindset of the team members and make them open to the idea of adapting something new.

Agile and DevOps mindsets

Image source: https://www.guru99.com/agile-vs-devops.html

The above image clearly highlights the mindset and culture changes required in the team. The basic idea is to break the silos and work together to deliver as a team. Agile explains and is primarily focused more on the team’s external communication and how to manage delivery as a unit whereas the focus of DevOps is more on internal team communication and working together to provide end to end services.

100 Days implementation strategy

It was essential to build a strategy for successfully implementing Agile in the team without impacting the ongoing deliveries and the team’s motivation. I decided to build a strategy for the first 100 days of transformation. I knew that any form of transformation is lengthy but I decided to take a risk with a shorter plan.

After racking my brains a bit, I thought of building a transformation strategy using the Tuckman model of group development.

The Tuckman model

For every stage, I started writing down:

1. My anticipation of the timeline

2. Action items for myself

3. Challenges I may face in that phase

4. How to approach those challenges

5. The expected outcome of the stage

I divided those 100 days into four stages of the Tuckman model as mentioned below:

Forming: Day 1– Day 10; Storming: Day 11–Day 40; Norming: Day 41– Day 80 and Performing: Day 81 to Day 100

After a brief discussion with the Enterprise agility team and my team, we agreed on implementing SCRUM and started working in the sprint from the storming phase itself.

Initially, we started with a 3 weeks sprint to enable the team to understand the whole idea and then switched to 2 weeks sprint for better agility.

DevOps

During the 2nd Sprint, I decided to introduce the DevOps model to the team which I was initially reluctant to do. I knew this would be a difficult discussion with the team and they would raise many concerns. But I decided to introduced “T-shaped” profiles for DevOps implementation.

T-Shaped Profiles

As already stated, I have great experts in my team but they were delivering only what was expected by working solely on their area of expertise. Asking a sysadmin to develop code or vice-versa was a challenge. This is where I pitched in and explained the benefits of DevOps and how it would be helpful in the long run.

Challenges and remediation

I would not like to overburden you with all the challenges and remediation but I can list a few of them which I feel are common and applicable to all:

1. Identifying people for SCRUM roles: Encourage people to take up the role rather than pushing someone.

2.Training: Involve expert talks during different phases so that the team felt confident about the phase/transformation

3.People Challenges: Involve is causal talks with team members to understand if they are a track or need some support.

4.Slow learners: Give some time for them to settle and understand the process for effective implementation.

What happened after 100 days?

The overall planned strategy helped me and my team overcome the initial hiccups, face the challenges and situations and finally achieve our objectives. Transformations are a lengthy process but we were able to successfully reach the Norming phase and were prepping up for the Performing phase. It will still take some time to create “T-shaped” profiles but the team was convinced after 100 days that we were moving in the right direction towards the overall goal of successful project completion.

Agile and DevOps are vast terms and there are many tools and methodologies to implement these both. Everyone has their understanding of both and my implementation was purely based on my understanding and the requirements provided.

Continuous Improvement

“There’s always room for improvement no matter what.”

--

--