Mahil Maurice, Head of Pivotal Labs

Read this article in german.

Mahil Maurice, head of Pivotal Labs in San Francisco, explains the unique concept of the paired development teams, with which Pivotal teaches agile methods to established companies. He also reveals which mistakes companies have to avoid, so that transformation processes do not come to a standstill.

The atmosphere at Pivotal Labs in San Francisco is unlike most offices we have seen so far. The workspace is packed with standing desks, huge screens jammed with lines of code or user interfaces. Every workstation is shared by two people, a result of the unique concept of paired developer teams of Pivotal Labs. While Labs provides the framework and the methodology, there is also a technology platform, called Pivotal Cloud Foundry. This platform helps to transform monolithic legacy applications into modern microservice based systems. Both services are closely tied together, as we are about to learn.

While visiting San Francisco, we had the chance to speak with Mahil Maurice, Head of the local Pivotal Labs, about the framework they provide. Mahil is leading the organization since November 2018. Coming from the enterprise world himself, he has developed an empathic understanding of what it takes for traditional enterprises to transform into digital product companies.

In this text, you will learn

• How Pivotal uses paired development teams to bring agile methods closer to established enterprises.
• On which basics Pivotal develops digital products.
• With which methods Pivotal overcomes customer resistance.
• Which mistakes companies have to avoid, so that transformation processes don’t come to a standstill.

Mahil, for a start, could you explain the basic idea of Pivotal Labs, please?

There are two things that we do: modernization and innovation. Modernization revolves around our platform that helps companies to deploy software faster. And behind that comes the methodology. It’s an advanced agile framework that can go behind the software platform.

The methodology in which we do this is practising three things. Design, can a user use it? Product, is it valuable? And three, can we build it? We have a concept called „balanced teams“.  When we go into an organization, we bring in a product manager, a designer, a couple of developers. And our customers need to provide us with the same. The idea is to enable one of their teams through the duration of the product development. Now they can go back to the organization, enabling another team and exponentially start growing the organization. This is the idea beyond our firm.

So you pair your guys with their counterparts in the company?

Yes. And we get questions like: „Why would you want to pair? I can have five solo engineers doing more work than two of your pairs.“ But within two to three months, a lot of these enterprises begin seeing value. Because with pairing, you get more productivity.

We often ask CIOs, how much time they think, the dev team is coding every week. And often the answer we get is: Probably 20 to 25 hours. Because they go to meetings. Sometimes they’re on Facebook. All these kind of things. But when we pair, we generally are pairing for about 35 hours. This is pretty intense because you come in and all of a sudden you are told to pair with somebody you don’t know. The skill-sets may be different. But after about two, three months, a couple of iterations and things going into production, people do start seeing the value of this methodology and that this is working. We see four benefits of paired programming. First: You achieve better code quality. Second: You have joint ownership. Third: The people solve complex problems together. And last but not least: The transition when the projects are completed is much easier.

Do you do it on product manager level as well?

There are a lot of customers who come to us and actually want four developers for a project. We try to minimize such engagements because it’s staff org, and the customers don’t get the full value of our methodology and mission. We are always talking about value-driven business outcomes driven by using our methodology and platform.

The product manager level is critical because the customer product manager is the voice of the business.

And do the PMs do the stories together?

They do, and they use our tools for it. We have something called „Pivotal Tracker“, that is built for our framework. Developers should always take the first available story. They cannot go to the seventh story and take it out, so the product managers need to have it prioritized at any given time. The product managers, the designers and the developers are constantly working together. A feature goes into pre-production through continuous integration and continuous development. It’s tested by the product manager and approved before it can be shipped to production.

How does your framework look like?

Our framework involves three things. Lean product, user-centric design and extreme programming (XP). The whole concept around lean product is to make sure the wrong thing is not built while moving fast. The second component is user-centric design. Behind all that comes the building component. This is the world of extreme programming, test driven development and continuous integration combined with the pairing of developers in short iterations.

The idea is not to release all of the functionality after three or four months. There’s a massive risk to doing this and also a technical debt. With our methodology and platform, customers can ship features to production every day while working in short iterations. This enables them to introduce changes with minimal risk. If our customers have one hundred requirements, we don’t go build all of those requirements on day one. We try to find out the most valuable requirements and then start building those first and then go down the cycle.

When you are talking about lean development, what tools and tactics do you use?

When we go into any project, the very first phase is called „Discovery and Framing“. The concept of discovery is: What is the problem? And there are many problems. Can we break this down to a smaller set of problems? The framing component is: There are many solutions. Can we break it down to a subset of solutions?

Narrowing the problems and focusing on a valuable set of solutions comes via interviewing users, researching the competitors, lean experiments, testing assumptions and prototypes with users, building personas and other methodologies taken from user-centric design. The outcome is a subset of stories and low fidelity frames to start the development process. From here it’s weekly iterations and shipping features until we get to MVP.

When the customer starts leaning into user-centered design, lean experiments, XP-methodologies during the project, we are on the right track.

How do you change the behaviour of the larger enterprise customers, where the transformation often will be a top-down process? The management has decided, that the enterprise must become a digital company. But how do you bring the people on board?

That’s absolutely the essence of the challenge, that is out there. I’ll be very honest. It’s not that easy with the enterprises. The CIO is fully bought into it. However, you’re working with someone who doesn’t even know their CIO.

Our methodology is a cultural injection to many. It doesn’t come easily to most at the start. However, getting them to participate is the first hurdle. There’s always the apprehension of being forced into trying something new, the fear of doing something different and the need to going back to what they are comfortable with. These are all elements we deal with on most projects. Once they start pairing with us, they start seeing the benefits of the methodology, because it drives results.

Because the pairing is so important, during our hiring process, developers go through a very thorough screening of pairing capability. We look for the fundamental extreme programming values of communication, courage, simplicity, respect and feedback. Not everyone passes this litmus test. Pairing itself is very intense. Hence having the right developers, who can empathize with their partners, nurture them along and can learn from each other is vital for success.

Are there other things you do to change the culture?

We invite all our customers to execute the projects at our Labs. In order to understand the methodology, one has to immerse oneself into it fully. By being at our location, one can entirely focus on the project without the distractions of one’s own office. There are many soft attributes which contribute to the culture. We start each day at 8.30 AM, eating breakfast together. This allows us to orient ourselves for the day with some friendly banter.

At 9:06 AM each date we have a Labs wide stand up for ten minutes. Once this is complete, the teams go into their project stand-ups and start their day. Each Monday begins with iteration planning, then stand-ups each day and finally doing a retro each Friday. Teams take short breaks, play ping-pong or go for a walk. We have 15-minute micro talks each day given by one of our co-workers at Pivotal on various topics. And the office plans lots of fun activities as well. One hour lunch is a must, and we work 8 hours. The day is over at 6 PM. We are very big on the work-life balance of our teams. Their well being is vital to function in such an intense environment. We encourage our customers to adopt these practices as part of the change.

When you leave an enterprise, they might say: „We are agile now. We work with Pivotal.“ But really being agile and maintaining the stuff you brought into the company, that’s the hard part. So, what are common traps companies fall into, once they have to build digital products on their own?

At the end of the day, the digital transformation component is not that hard. There’s hardware, there’s software, that can help you do that. I think, where they fall apart is hiring the right people, creating the right financial models and creating the right incentives. The entire organization needs to do this.

A lot of organizations think they only have to transform the technology. They don’t look at it from an organizational standpoint.

The companies that have done it well have incubated an innovation lab separately. And at the innovation lab, they’re creating greenfield models. At such labs, the changes are experienced first. They land on a working methodology, which they gradually introduce to the larger organization via projects and tools, thus creating balanced teams to transform the way they build software.

It’s interesting that you emphasize the innovation lab because, as many companies are doing it already, it has become such a buzzword. But you are saying, that it’s crucial to externalize the digital unit and give people the chance to work in a protected space.

Yes, and I can say that for a fact because I came from an innovation lab. Prior to Pivotal, I was responsible for building an innovation lab for an enterprise. I will tell you, we did a lot of things well. It was built far away from headquarters. It was in a beautiful space. The CEO said, „Go hire the right people and develop an innovation engine.“ The one thing we did not do well, we didn’t have the framework. That’s how I came to know Pivotal back then.

But often, the framework is missing. It’s just a different way of thinking. Build fast, fail fast. Don’t spend six months and five million dollars and fail at that point. You should be able to fail after spending ten thousand dollars and building a prototype. That is a hard thing for a lot of people to understand. You need to have a mindset, that is capable of doing it and understand you are on a journey to help your organization compete, stay relevant and grow.

What else is important to get through this process?

Key is complete buy-in and support from any Management team. This is from the top all the way to the individual contributors. Often, the CIO or VP of Digital wants to transform. However, they’ve not provided the security, education and vision to the middle management. This is when we run into the „frozen middle,“ and have challenges in converting them. In larger organizations, change comes gradually via many projects across their footprint and enabling many balanced teams. Management needs to empower its employees to experiment and support this change journey. Many do not partake because they are risk averse. But the biggest risk is the impact it could have on your business models if you don’t explore or have a path towards such change.

Mahil, thank you for the interview.