Enterprise Transformation — One Pod at a Time

By Jason Mills

Digital Transformation is here. It’s expected to be a $1.97 trillion market by 2022. Is this just a fad, does it actually work? After working on a large scale, 2-year transformation project, I wanted to share these thoughts and lessons.

First, let me say that transformation absolutely and positively can change your company for the better. After working on multiple transformation engagements, I know this to be true. However, there are many things to look out for when choosing a transformation partner to help navigate these uncharted waters.

Choosing what’s right for you

Some transformation partners will present a set of well-refined processes and optimized architectural blueprints tailored to your organization. This is usually a lot of great information, it is proven, and it provides a feeling of comfort and confidence. The one thing that may be lacking is the actual help with the implementation of these blueprints.

The other type of transformation engagement does not have a set of pre-defined processes or blueprints. It uses the power of extreme programming (XP) to adapt to an ever-changing, real-world development lifecycle. Through the power of paired programming, it takes your team through an accelerated learning cycle, helping to build both hard and soft skills. This competitive edge of paired programming is important to note because only 5% of companies practice this style of software development. The XP methodology naturally couples with transformation, providing a significant edge over typical consulting firms both in prescription as well as execution. I am fortunate to be a part of a company called TribalScale that provides this service.

Why do we need to transform?

In order to fully explain the how-tos of a transformation, let’s first walk-through a background story of a fictitious company. We will call this company RetroTech. At RetroTech, legacy code was running wild, but it worked. It was slow, but it got the job done…rebuilding some of the complex algorithms that have been honed for decades seemed unfathomable. Changes were introduced to production on a 2-month release cycle. Development was slow. All seemed to be going well until MagiTech entered the picture. MagiTech was a new customer in the market space. They did not yet have a mature product, but they were very customer-centric and able to adapt to changing needs on a daily basis.

Alice, the VP of Engineering at RetroTech has been tasked with cutting costs, optimizing processes and modernizing the tech stack being used. She opens a dialog with John, the Director of Engineering:

“We are losing our customers to MagiTech. They are doing the same thing we are doing, but they can deliver reports to their customers in seconds, rather than the 24 hour turn-around time it takes us. We need a way to deliver our data faster and we need a way to stay ahead with our feature delivery. Our 2-month release window is just too long.”

John replies, “But our product is much better than MagiTech. I know we can compete and modernize our code. Getting a plan in place would take months, and implementation could take years as we’d need to migrate all of our interconnected legacy services.”

“We need to work with a transformation partner,” says Alice. “We need to find a way to get things done quickly. I’m confident your team could work through this, but we need a jumpstart with someone that has done this before. My friend at TruTech is doing something similar. I’m going to set up an introduction with the partner they are using.”

Three months later…

“This is really exciting,” John said to Alice. “We have a project and team identified. We have an open concept XP development area in place. The pod is ready. Getting some help to identify and push the transformation forward was a great idea. There is a long road ahead, but I feel confident in the choice we made!”

The scenario above could be a potential way to get to the first transformation pod, “Pod One”.

The Pod Setup

Our first transformation pod consisted of 3 pairs of Engineers and 1 pair of Product Managers. A dedicated open-space area was retrofitted into a room that was originally all cubicles. The area was quite large and consisted of 1 large table in the room, surrounded by 2 walls with floor-to-ceiling whiteboards and a small meeting room on one side. Natural light filtered through from the far wall. The layout of the main table consisted of 4 pairing stations and one area at the end for the PM or Designer to share. A small table to the side was filled with snacks such as fruit, chips, chocolate, etc. for anyone that needed to take a break from the intensity of pairing. About 20 feet down the hall, there was also a common area for water, coffee, or a place to have lunch if desired.

This space promotes open communication between the entire team: PM’s, Engineers, Designers, and Architects. It’s not enough just to change the floor plan. Having the entire cross-functional team sitting next to each other allowed anyone in the group to roll their chairs right over to any other person in the room to review code or work through any design details during the rapid iterations the XP methodology endorses.

Choosing the Project

It was important to understand our goal for the 13-week project we were about to undertake. Our transformation project mission was not driven by timelines. It was to teach modern development principles and help promote leadership within the team. Pressure from management to deliver a product on time would not be tolerated. It may be hard to let go of deadlines, but taking shortcuts at any stage of the project will always come back to haunt you. Having the patience to set up continuous integration, linting, and most importantly a good framework for unit testing, has always accelerated our project delivery.

We focused on process, but not to the extreme where we did not deliver any value to the company. We delivered value every day, but we did not confine ourselves to the pressure of a time-boxed sprint where we were required to output a certain number of story points. We made time to explain the “why” behind everything or as I like to say “eliminating the magic” of what happens when you type in a CLI command or use an open source package.

Our project was simple. There was a specific task within the organization that was taking longer than it should. There were dependencies on several legacy systems and some manual cut/paste operations. We estimated that we could build out a product that would shrink the entire process to under 10 minutes and eliminate the manual work involved. We didn’t try to solve everything; just one simple task that was taking upwards of 5 hours to complete.

The transformation process

Once the 3-month engagement was underway, it was the transformation team’s job to do what we do at TribalScale everyday: pair programming and agile product management using lean principles. But additionally, we needed to listen, learn, identify individual strengths and areas for improvement. We would then use these learnings to optimize pairing assignments as well as feature assignments in order to level-up each team member as quickly as possible.

The transformation team was aggressive. Our number one goal was to change culture by working with the engineers to solve their own problems via experiments/research, versus waiting for an “expert” or “IT” to answer their questions. A secondary goal was to work on a real project and deliver value to the company. It was very important that the priorities happened in that order. If we put the project deadlines first, we could ultimately sacrifice the quality of the code and create a stressful environment for learning, which would result in a transformation that was not successful.

We taught both basic and advanced concepts around GIT. Right from the start, there was no manual deployment. We created fully automated CI/CD pipelines. Clean code and TDD were strictly enforced. We leveraged the power of Kafka as our messaging service to bind the legacy systems to our modern tech stack. All of our micro-services were simple.

We understood the value of rapid iterations, weekly to start, but by the end being able to deploy at any time with confidence as an outcome of TDD. Any blockers were brought up daily at stand-up and the team was not afraid to pivot quickly if there were any issues with our approach. We showcased our work weekly to stakeholders, end users, and any other teams that had an interest in what we were building.

Our front-end was built using React, adhering to corporate styling guidelines managed through Storybook components. React and Functional Programming was new to the team and we made sure not to rush through the explanation of concepts. If there was an important learning opportunity, the entire team would head to the whiteboard for an hour or longer and deep dive into the core workings of JavaScript or other areas, explaining why things worked the way they did and comparing them to how they may have worked in the past.

By the end of the 3-month engagement, the team members were writing blogs and sharing knowledge with the rest of the company; technology training sessions were held to teach others in the company. And then, just like that, the transformation engagement with the team was over and I moved onto another pod within the company. It went by quickly. I felt a strong bond with the team and the pair programming really accelerated the friendship. Even though the project was over, the effects of the transformation were just starting to take hold.

Side Note on Pair Programming

Pair programming is an interesting topic. Bill Scott wrote a great article on it here if you would like a little bit more context.

For me, I didn’t realize how mind-blowing pair programming was until I switched pairs. It took a while to get into a rhythm with the first person I paired with. After a week, I felt like I understood their pace, their personality, and their style. After a few weeks in, you feel like you are finishing your pair’s sentences and you can pair with anyone that sits down next to you. Then, the time comes to mix it up and switch pairs. Suddenly, there is a bit of discomfort as you feel a bit out of sync. Your new pair wants to do things differently than the last person you were with and the pace has completely changed. This is the truly amazing part: your knowledge level jumps significantly at this point. We learn the most through change, but change is difficult and it can be hard to push through the challenges. As humans, we naturally want to find that comfort zone. Switching pairs keeps you in a state of constant learning.

After “Pod One”

So, onto pod number 2 in the transformation engagement. I would like to say that it was just a repeat of the experience in “Pod One,” but it was not and this is the point that I would like to stress about an Agile XP transformation: having a “script” or a one-stop recipe for transformation will not suffice. We are all unique people, from our personalities to our experiences. There is no recipe that can solve the needs of everyone and everything, however, we are agile and we adapt. We can port some of what we learned, but in the end, it’s a different group of people and we must embrace differences and change.

Transitioning to the second pod is where the magic happens. We have acquired all of the learning in Pod One, but additionally, we start to address the next level in the transformation process which is cross-team communication. By mixing up the teams and shuffling people around, learnings transfer across the company faster. Learnings from the second pod find their way back to the initial team; communication flows in both directions and the large company suddenly becomes just a bit smaller. This process continues until barriers are broken down and the company becomes closer to that “one team” ideal.

But moving onto the second pod was not the end. We repeat the process for the third and fourth and fifth pod, adapting to different tech stacks, finding commonalities with CI pipelines and finding the joy of communication on Slack. All of the training sessions that our company was teaching around functional programming, Kafka, .NET Core, Git, React, and Concourse to name a few, were no longer being taught by us, but by the members of the pod that we were once teaching. They have become the teachers and it’s a great feeling.

Challenges

Throughout each step of the transformation, there were unique challenges. We needed time to adjust to our new workspace. As the team tried to be more independent, there were some dependencies on other departments which were unavoidable. For example, security reviews to ensure code was not vulnerable to attacks when going to production. Corporate cloud services, such as access to Kafka topics, may require permissions that must be granted from another team. Provisioning of updated hardware and software takes time as there is a dependency on IT. VPN access to internal resources may be required and this may make it difficult to access essential 3rd party sites that the company may not have used in the past. Fortunately, we took the time to identify these challenges up front so we could address them before they became blockers.

Why TribalScale?

In any transformation, it’s essential to remember that all people, and their experiences and modes of learning vary. The one-size-fits-all approach to transformation won’t stick and certainly won’t suffice in the long-run. Enterprises looking to better compete with disruptors and new entrants should consider working with a partner that understands and embraces this truth in how they approach transformation, working through a tailored plan, providing hands-on and 1:1 coaching, and ensuring post-engagement self-sufficiency.

If you would like to learn more about transformation or have any questions about how transformation might fit into your organization, please contact me via TribalScale and I would be happy to share more.