Agile and Open Innovation: Building the Bridge Between Tech and Business, with Mary Provinciatto

Alexis:

Hey Mary, can you tell us a bit more about you and your background?

Mary:

Hello everyone, I'm Mary Provinciatto. I'm from Brazil but currently living in Berlin, Germany. I started my career as a software developer when I was 17 — that's what I did during five years of college. After a while I realized I really liked being closer to people, mentoring and coaching them, facilitating practices, and helping create a bridge between technology and business. It was very frustrating for me as a software developer when I couldn't understand why I was doing things and for whom I was building them. I wanted to change that.

When I started back in 2007, Agile wasn't such a big thing — most projects I was part of were waterfall, which was very frustrating. Becoming a Scrum Master at the beginning was how I saw I could create a bigger positive impact. After that I went through several roles — Scrum Master, project manager, account manager — and now I'm an Engagement Lead. I studied computer science and I have two MBAs, in project management and marketing, because I wanted to understand more about the business side.

Alexis:

Impressive. Can you tell us a little more about what mentoring and coaching look like for you?

Mary:

This is pretty much the story I tell in my book, Sprint a Sprint. I realized when I was working with that team that I couldn't just force the theory I knew. If I told them 'use Scrum now, use these practices' they wouldn't understand why, and sometimes they'd be resistant. So we went through a journey to discover those things together. I helped them understand why we were doing those practices through principles and values, so they could adapt how they applied them to their own context.

At the beginning it was hard — for me and the team — because we were failing a lot. I was patient and let them learn from experience, sharing a bit of what I'd seen so they could start applying concepts by their choice instead of being told what to do. At the end we were working as a team — not one person telling everybody what to do — and that's important because we faced scenarios where even I didn't know what to do. We had a lot of people thinking together instead of just one.

Alexis:

It makes a lot of sense. The first sentence of the Agile Manifesto is 'we are uncovering better ways of developing software by doing it and helping others do it.' Instead of telling people what to do, we embark on a journey and discover together. That's powerful, but probably more scary than someone saying 'I know what to do, do it and everything will be fine.' How do people react when they expect you to be the expert and you don't want to tell them?

Mary:

Sometimes we think that just by working in a long-lived product team things will magically flow — but that's not true. People are complex. It's not only about the product, the practices, the frameworks. We have to look at people as individuals. That sometimes demands difficult conversations as a team or with individuals. What helped us was creating an environment where people could ask each other questions without being afraid it was a stupid question, and admit when they didn't know something — a safe environment.

From the beginning we did a lot of team building activities. We had our own budget to go out together every month and we had lunch together very often, building trust because people need to create empathy and understand why others do things. One example: we were always discussing our daily standup. We had moved it later — to around 10am — and one person was always late. Other team members were getting very frustrated and saying 'what's the point of moving it if he's late all the time?'

Instead of forcing another rule, we ran a team-building activity where we discussed what each of us did before, during, and after work. We weren't trying to solve the standup problem, but we discovered that this person was spending hours in heavy traffic taking his wife to work and his kids to school. When the team heard that, they said 'now we understand why you're never on time.' They decided to move the standup to the afternoon and it worked. That's how team-building activities help a team work better with each other.

Alexis:

I was a little worried when you said 'team-building activities', because I'm uncomfortable with the throw-axes-and-drink-beers kind. We had fun, but I'm not sure the team was built. What you describe is much more intentional. Other examples that work well?

Mary:

It depends on the context, and I always try to identify what's important in that scenario. For this team, I noticed we didn't know anything about each other because we were distributed — half in one city, half in another. Even when we had lunch together, we didn't know about people's lives, whether they had families. I wanted something that would let people know more about each other.

Barbecues and going out for drinks can also help, but they need to be done often enough that real conversations happen. If people just go play something together but don't have conversations, it takes much longer to connect and build empathy. I usually try to tailor the activity based on what I want to achieve.

Alexis:

Tell me more about the book. Why did you write it?

Mary:

I always wanted to write a book, but I wanted it to be very practical — something people could read and immediately get ideas about how to apply concepts. We usually see people talking about how something works; I wanted to also tell what could go wrong. In the book we tell all the issues we had — everything that went wrong and how we dealt with it.

The first section explains the concepts in a simple, straightforward way for people who haven't worked with Scrum, Kanban or other frameworks. The second section tells the story of the team from day one through the MVP and into production. The third section has all the templates we used — for user stories, definition of ready, MVP canvas — that people can download.

Alexis:

The team in the book is a real team?

Mary:

Yes, a real team I worked with in 2018. I don't mention their names or the company because I didn't want to identify them — I wasn't sure they'd be comfortable with everything we did wrong being told. But they had a strong continuous-improvement mindset and we were sharing our mistakes openly internally every week so we could learn from them. That was important.

Alexis:

Trust is important. You mentioned safety several times. How do you know a team has reached a point where they feel safe enough to talk about mistakes?

Mary:

We were always doing safety checks — and I tell that in the book. At the beginning, you'd see safety wasn't very present: people would say they didn't feel comfortable to talk about difficult things or conflicts. They'd talk about work but avoid anything complicated. Doing safety checks at the beginning of team-building activities, retrospectives and other practices, we could see over time that people became open to talking about anything. That's how we noticed safety was improving.

Alexis:

Definitely something to implement in many teams — no judgment, just understanding where you are. You also mentioned the Engagement Lead role. Can you tell us more about it?

Mary:

Let me first tell you about Open Innovation Labs, because the Engagement Lead role was created there at Red Hat. Open Innovation Labs exists to accelerate the delivery of customers' innovative ideas. We want to empower the customer to deliver their own success stories. To do that we work in a very immersive way, pairing Red Hat specialists with people from the customer to achieve real business outcomes — and at the same time we make sure people are learning and developing capabilities so they can continue working this way (Agile, Lean, DevOps) and achieve even more after we're gone.

We call this an engagement residency. As an Engagement Lead, I make sure we apply this way of working and coach the customer so they understand why. We're very outcomes-driven. I facilitate the process, ask questions, help people understand what the outcomes are instead of just thinking about outputs to deliver.

Alexis:

How long is a residency?

Mary:

It can be 4 weeks or 12 weeks — that's the range.

Alexis:

And in 4 to 12 weeks people adopt a new way of working. You've seen that happen?

Mary:

Yes, several times. At the beginning some say 'I don't see how this is going to happen,' but we believe in continuous improvement. Since day one we have a lot of feedback loops to learn — about the process, the technology, the product, the users. That short feedback loop is how people achieve those business outcomes so fast and develop new capabilities.

Alexis:

You're in Germany now. Do you see cultural differences in how people adopt that mindset of continuous improvement?

Mary:

Yes. Sometimes I work with teams that are very new to Agile and Lean and DevOps — and in that scenario it's actually easier to help them understand the values and principles, because they're being exposed for the first time. But sometimes people had bad experiences before with Scrum or another framework and they're very resistant: 'I don't believe in Agile.' Then we take a step back and remind them that it's not about the framework or the method — we could call it something else. It's about the principles and values. When we get to that point, it doesn't matter where in the world we're working — people are always able to understand. And since we're focused on business outcomes, we change the conversation to facilitate them achieving what they're looking for.

Alexis:

Where in the world have you tried that?

Mary:

I've worked with a team in Indonesia, and several teams in Brazil, Chile, and Mexico. I just got to Germany about two months ago, so I haven't run a residency here yet, but it will happen soon.

Alexis:

How do you improve the approach across all your engagement leads worldwide?

Mary:

We drink our own champagne. We have bi-weekly calls where we talk about what we're learning, and we adapt the approach based on those learnings. We share weekly reports — when an Engagement Lead is running a residency, he or she shares internally and with the customer the learnings, with videos and pictures. So even though I'm not delivering a residency in North America, I can learn from an Engagement Lead there and apply that here in Germany.

Alexis:

So you've achieved a level of transparency where everyone shares what's going well — and what's not.

Mary:

Yes. And besides the weekly report and bi-weekly call, there are also showcases where we invite the customer. Since we're doing virtual residencies now, people can attend showcases from anywhere — being closer to teams in very different regions.

Alexis:

What is a showcase?

Mary:

The showcase is a practice we use at the end of a sprint or iteration. The team showcases the product increment they built during the sprint, and they also talk about their learnings — about the process, about automation, about other things that happened during the sprint. Before the pandemic these were in person; now they're online.

Alexis:

When did you switch to virtual?

Mary:

When the pandemic started and we couldn't be together anymore, we had to pivot and find a way to keep that immersive way of working in a virtual environment. It was a big challenge. We put together a working group from different regions to create this new product — the virtual residency. We adapted templates for Miro, figured out how to facilitate practices remotely, and how to do team building activities even when we weren't in the same room. We're now running several virtual residencies, finished some, and we've been successful in all of them so far.

Alexis:

Let's go back to writing. What did you learn in the process of writing the book?

Mary:

My favorite thing about sharing something is that I get to learn — and that wasn't different with book writing. One of the biggest lessons was to apply what I was doing with product teams to my own life. The principles and values don't only work for software development. Once you truly understand them, you can live by them — and we did apply them while writing the book.

The most important one for me was the MVP concept. It was hard to apply because I wanted the book to be perfect. Paulo, my co-author, and I were struggling to come up with a good title and cover. At some point we noticed we were putting a lot of energy into it but not on what would bring real value. Paulo said we should time-box it, and we did: 'in 20 minutes we're going to think about the title and create a cover, and that's it. This will be the first version, and we can change it later.'

And I remembered the Reid Hoffman line: 'If you're not embarrassed by the first version of your product, you launched too late.' I was very embarrassed by the first version — the cover was so ugly, the title was so terrible and so long that every time I had to talk about the book I'd say a slightly different title. But we put it out so people could read it and give us feedback. And I learned how to apply this to my whole life. After receiving all the feedback, we came up with a better title and a better cover — and if we had tried to do that upfront, we would never have reached this final version that I really like.

Alexis:

I really like that. For my first book, I fell into the perfection trap badly — I tried for several years, changed the angle, changed the title, restarted from the beginning. At some point I said 'enough', published a first version on Leanpub, and learned a lot in the process. Sharing is learning: as soon as you try to explain what you've learned, you understand better and connect the dots.

For the second book — A Software Engineer in Charge, with Michael Doyle — we wanted to tell a business fable like The Goal, The Phoenix Project, Radical Focus or The Five Dysfunctions of a Team. Working with the publisher pushed us to work iteratively, with regular checkpoints. We checked our assumptions with reviewers very early — even just the introduction or the first chapter. That worked much better, because we got opposite feedback from different people: 'start with the story' versus 'I love that small paragraph that sets the context.' We couldn't take all of it into account, but we understood why each side felt what they did. The big learning: release often and early, and have a diverse enough group of reviewers that you get really different feedback.

Mary:

That's awesome. Very similar to some of the things I learned writing this book.

Alexis:

The book is in Portuguese, right? Do you plan an English version?

Mary:

Yes — Paulo Caroli and I are translating it to English now. Time is an issue and the process is slower than we wanted because of my relocation from Brazil to Germany, but we want to publish the English version early next year. We're also planning a Spanish version, but English first.

Alexis:

What else do you want to share with the audience today?

Mary:

Continuous improvement is very important to me, and I'm glad I get to do that at work every day at Red Hat Open Innovation Labs as an Engagement Lead. I love understanding why I'm doing things and knowing the outcomes of my work. I've been on the other side and I know how frustrating it can be when you don't know why you're doing things or who you're building it for.

I'd encourage people to use the Open Practice Library — we use it a lot at Open Innovation Labs and contribute many practices to it. There are practices to discover the business outcomes you want to achieve, and practices to set the foundation for high-performing teams. If you focus on continuous improvement and learn from your mistakes, you're always getting better. That's the big message of the book and of pretty much everything I do.

Alexis:

And the Open Practice Library is open — you can contribute practices?

Mary:

Yes, it's an open-source repository, so you can submit your practices there.

Alexis:

Really cool. Thank you very much, Mary, for being on the podcast today.

Mary:

Thank you for inviting me — for giving me this space to talk about myself, the book, and some of what I've learned in this journey so far.

Alexis:

Thank you for listening to this episode of Le Podcast. Go to blog-alexis.monville.com for the references mentioned in the episode and to find more tips to increase your impact and satisfaction at work. Drop a comment or an email with your feedback, or just to say hello. Until next time, to find better ways of changing your team.