Deeper In the Engine Room
Fundamentally changing how people work isn’t easy. When you’re midstream on a large strategic integration initiative, it’s even more difficult. (See here to get up to speed on how far we've come). Due to these challenges, there are a couple of things we kept in mind as we progressed as well as learning a few additional things. So we wanted to dive a bit deeper in the engine room and share with you two of the biggest lessons: how to operate with globally distributed teams (I’ll follow the sun) and keeping in mind what really matters (the Importance of being Earnest).
I’ll Follow the Sun
Sometimes we’ve heard comments from agile practitioners that to be successful an agile team has to be located in the same physical space. As technology has improved, though, teams have become more flexible. Now there is video conferencing, instant messaging and screen sharing technologies that allow for the instantaneous communication and collaboration around the globe.
If artists and animators can use this technology to produce great works, why not agile development teams too? Where the distributed team approach becomes even more interesting is when you’re talking about a globally distributed team across three continents and potentially twice as many time zones and working in scaled agile. How do you deal with a situation like this?
Three essentials:
- In-Time Communications: establish the key mechanisms for real-time communications for everyone and set expectations. For example: chat (chat rooms are great for this), email, and video conferencing. You want to ensure that everyone is able to communicate when they need to across the globe while working on items and in transition times.
- Out-of-band Communications: in cases of globally distributed teams, there is a likelihood of gaps in coverage (especially when the Eastern hemisphere comes online Monday morning while the Western hemisphere is still asleep after the weekend). Make sure the teams have a clear approach and direction as to how work will be picked up and continued after these types of handoffs. We found that using agile team tools updated with the proper information is a huge help for this.
- Role Clarity: Some agile purists may not like the idea that there are a couple of key roles to which specific highly-skilled individuals must be assigned to ensure successful delivery:
- Architect - has the cross-IDT visibility to ensure that all elements deliver cohesive solution that addresses the business capabilities.
- Technical lead - provides the guidance to the IDT on specific implementation details when needed and helps to ensure that the overall business capabilities are realized.
- Business lead - is empowered to clarify detailed requirements and to make the final decisions for the IDT
The Importance of being Earnest
It surprises us how often we’ll hear comments like “the team is the most important thing” or “we need to have all of the same people to maintain our velocity”, and in the next breath: “we don’t need specialist roles like architects, anyone can do it.” I’m going to say straight out that the most important thing is the “product” that the team is building, not the team. Being earnest for the development of the product allows a whole new world to unfold before us, unconstrained by inhibiting principles.
If the business capability is the most important thing and we are under extreme pressure to deliver that capability to a set deadline, then we have to ask: “What is the best way to deliver this capability.” And what did we learn here? That the best way to deliver today may not be the best way to deliver tomorrow.
Simply put, you need to stay agile with your approach. Two key ways in which we accomplished this:
- Moving individuals from one IDT to another to fill gaps and meet deadlines. We didn’t do this in the middle of a sprint, but with the SUOSUs we talked about last time, we were able to identify early enough where we needed to move people to build the capabilities.
- Switching from Scrum-based agile to a Kanban approach during the integrated testing cycle. This allowed for focused, just-in-time resolution to the defects that were identified during the test cycle that a pure scrum-based approach would not have allowed.
Like a Shark
Sharks never stop moving. They do this so they survive. If a shark stops moving, it won’t get the oxygen from the water that it needs to survive. There’s an important lesson to learn here with regards to business agility and delivery of business solutions: Never stop moving.
Be flexible, adapt, and accept change. This is how you succeed.
In our next and last chapter, we’ll tell you about how we kept the ball rolling across the finish line.
#guerrilla_ea
Last updated: April 18, 2018