At Thales Group, our IT organization has been working on a transformation known as NextGen IT for a couple years. One of the key elements is to change from a waterfall delivery model to an agile one.
As part of this enterprise initiative, my North America leadership team and I took on the challenge of reworking our entire operation to adopt agile principles for both product and service delivery. We knew what we wanted to achieve: squads, operating using agile methods, driven by user stories, and ultimately delivering incremental value.
As we embarked on this journey, something dawned on us early on: The only way we could truly be effective in leading the organization through an agile transformation is if we transformed our leadership team first.
We did this by adopting agile principles and adapting the agile process to our leadership team. Here’s what we learned.
Our agile transformation: 6 steps for IT leaders
To transform our leadership team with agile, we took a number of steps that helped us plan, strategize, and execute.
1. Perform a framing exercise
The first thing we did was ask ourselves, “What are the services that the IT leadership team provides to the enterprise?” This was a powerful question to ask because it made us look at the actual work that we as a leadership team are accountable for – not the work being done by the people who work for us.
[ Want more advice on agile adoption? Read Agile strategy: 3 hard truths. ]
Our service offering is to provide all of the IT stakeholders efficient, effective leadership of the IT function. That’s why we exist. Without a clear understanding of the why, we could not get to step two.
2. Define the service catalog and user stories
After the “why,” the next question we had to answer was the “what.” We identified seven services that we provide as a service team. These included:
- Providing regional IT strategy and planning
- Managing our project portfolio
- Managing the IT finances
- Managing the people in IT
- Managing service delivery
- Managing security and compliance
- Integrating and coordinating the activities of the agile squads in our purview
For each of these services, it was also important that we determined what we wanted to accomplish in a macro sense during the year. Those goals became our epics.
3. Determine the service owner and the scrum master
The service owner assignment was clear from the start. As CIO, I am responsible for the services that the IT leadership team provides, so the answer is me. Right away, I understood that I had to be accountable for defining the user stories within each epic and prioritizing those for my leadership squad.
That meant that I needed to learn how to use Jira (our agile tool) and write effective user stories, including the “definition of done” and the initial estimated story points. And since an agile squad needs a scrum master to facilitate its operations, the operations director who is leading our agile transformation agreed to act as our scrum master.
4. Plan and test sprints
Now that we had epics and user stories, we needed to figure out how to execute them. Because agile teams run sprints, we held a sprint planning session and agreed that our sprints would each be a month long.
5. Plan 15-minute stand-up meetings
Another ritual of squads is holding stand-up meetings, during which we ask everyone on the team three questions:
- What have you done since the last stand-up?
- What are you doing next?
- Are you blocked by anything?
In other words, in a stand-up meeting, we don’t want to know how you plan to build a toaster – we want to know whether you made toast or you didn’t. And if you didn’t, what was the reason?
We had these meetings twice a week, which my team didn’t think was possible. We’ve done so successfully every week since.
6. Appoint an agile coach
While both our appointed scrum master and I have been certified as Scaled Agile Framework program consultants in the past, we still hired an agile coach from one of our external suppliers. He coached us through the first four sprints, and once we got comfortable with it, we no longer needed his services.
The benefits of agile in our leadership team
We’ve experienced a number of benefits since applying agile to our leadership team. First, it boosted morale in our IT organization – largely thanks to an agile approach to meetings. At first, some of the team members balked at the idea of holding two 15-minute meetings each week and a longer planning meeting once a month. It both seemed like too many meetings (frequency), and not enough (the short duration).
As it turned out, we actually have fewer meetings than we did before, they are more efficient, and there are no surprises. If we need to course-correct, it happens in real time. There’s less stress and less fuss because we have a solid process in place.
These processes do not necessarily help us get more work done. Rather, we are getting work done more easily, with less confusion, and in a more integrated fashion. A big problem I used to have was keeping my leadership team consistently on the same page, for example. This isn’t uncommon; any time you lead a team, everyone usually starts on the same page, but ultimately begins diverging as they work through issues in their own ways.
In my traditional IT management approaches, we’d periodically bring everyone back together with review meetings that required chart preparation and lengthy agendas – all of which are time-consuming. With agile, teams are re-connecting weekly and working together to prioritize and accomplish goals.
We’ve also managed to turn people who were skeptical about agile into advocates. Some of these individuals doubted that this process would work; they understood how agile works for software organizations but couldn’t grasp how this might work for a security, infrastructure, or a user support team, for example. It was hard for them to envision how these operating principles would enable the changes we wanted. Once we began to see the benefits of agile for our leadership team, and communicate wins throughout the organization, the enthusiasm for agile began to grow.
Take it slow
Our success with agile was rooted in two principles: Don’t try to do everything at once, and lead by example.
When we embarked on this journey, we started only with a goal of trying to run our agile implementation using agile methodologies. We intentionally did not create a backlog of everything that needed to be done – that would have slowed us down. Along the way, when new initiatives came up that needed to be done, we re-prioritized and created user stories as part of an incremental backlog.
The more leaders can dissociate with the idea that you need to have a complete understanding of what perfect looks like before you start, the more successful you will be with agile.
Also, early on, we made the commitment that we were going to lead by example. This has been the accelerator for our agile transformation because the entire IT team knows that the leadership team is not only on board, but actively following agile principles.
Today is a great time to start experimenting with the steps outlined above. Be a little better on agile tomorrow than you were today, and don’t let perfect be the enemy of good enough.
[ Get exercises and approaches that make disparate teams stronger. Read the digital transformation ebook: Transformation Takes Practice. ]
