#32 Developing an Agile Leadership Mindset
Empirical process control and understanding people were and are Andrea Tomasini's biggest passions. After starting his career as an Engineer and leveling up to VP Engineering, Product, and CTO, he reached the point where he wanted to build his own agile organization.
These days Andrea's agile consultancy Agile42 operates in more than 13 countries across the globe, helping companies of all sizes to establish an agile mindset. Even the Product Bakers have been trained and coached by Andrea already.
In this episode, Andrea shares his wide and deep experience and best practices on where to start with an Agile transition and what pitfalls to avoid.
Get in touch with Andrea:
Linkedin: @andreat
Twitter: @tumma72
Website: https://www.agile42.com
Podcast Minutes
Table of content
0:30 - Intro Andrea
08:40 - People over processes & tools
14:45 - Organic agility & understanding people/culture
24:25 - Becoming more agile as a Leader
28:31 - Experimenting in safe-to-fail environments
33:25 - Trust as the basis for change & transformation
42:15 - The 3 focus areas to introduce agility
45:05 - 3 biggest mistakes leaders do
48:25 - Debrief Alex & Christian
How did you gather the agile knowledge and what motivated you to start an agile consultancy?
Andrea: There's a bit of a mystery but I try to keep it short. As you said, my background is software engineering and I loved software because it was for me a way to be creative and help people at the same time. So I always consider it an art. I had my own startup already out of the university where I added a few people. We were so crazy that in 1994, we decided to build an internet application and nobody was even knowing what the internet was but we were so much higher than people who are still connecting with the U.S. robotics 9,600 volts to the internet. These were the different times and then I grew up, as you said, and I was pretty much at the old meter management and deal CTO career in technology.
I was always intrigued by complexity. In fact, I am being passionate about complex adaptive systems and also part of my study was dedicated to that. And what I learned is actually in a human system, there's a lot more complexity than in a software system. That is the moment where I as a CTO I started focusing on understanding how can I help people work better together.
How can I help them integrate even if they are from different backgrounds, different functions, and even different companies sometimes? Then I started looking at approaches to integrate and increase collaboration and I stumbled upon the agility thing by some of my friends who is still today our friends and colleagues who were passionate about engineering techniques and they started looking at agile and I looked at extreme programming already in 98, 99.
And we started adopting some of those practices. Then in 2001, I came across scrum which gave me a little bit more of an organizational perspective, at least from a team level to what agility can bring.
You can always make compromises and you always get mediocre results in the end. So I said there must be a better way than that. And then I decided to explore more with some friends and researchers into the whole idea of empirical process control and understanding it.
It doesn't matter how you do it as long as we agree, on how often we want to review and integrate our output so that we can create an outcome that is value, then it's fine. You can work it the way you want, you can work the way we want, as long as you can commit and deliver a certain amount of value within a certain amount of time.
We started looking at systems from a complexity perspective and we started looking at how can we combine the output of all the systems, even if the systems are not coordinated and not synchronized, which is what instead we try to do with the project. And I got very passionate about it so much that at a certain point in my career, I realized that 50% of my time was politics and 50% was fun.
Where do you draw the line between people, processes, and tools?
Let me introduce one concept or if you want a statement that might be bold about the biggest mistake people do when it comes to organization and change is they think at their organization and at the change as a single entity.
It is right, when we talk about change and organization we are talking about people. Every one of them has a name. Every one of them is a new story. Every one of them has a character as values and whenever we impact them we have not impacted them as a single entity. We are impacting them as many individuals.
And this is the first problem. So scrum, like many agile approaches provides a set of constraints of rules, as you said, which are called in complexity terms called enabling constraints. Some of those are enabling because they allow you to collaborate better. Some of those are what we call it governing constraints because, for example, you can't release if you don't fulfill the definition of done> You can't pull something in your sprint if you don't fulfill the definition of ready. So those are governing constraints, a rule you can't or you shouldn't violate.
But then there are things like working agreements, which are behavioral rules that the team can agree on between themselves, and those are more like enabling constraints …
… tune in to learn more 🎧
