In February, Florian Gamper, a freelance CTO and agile evangelist and coach will be speaking at Leaders in Tech | Berlin. The talk is titled “Working Agile – not dead, but badly misunderstood!” and grows out of Florian’s experience, first as a coder and in game development, and then working in business software and helping companies with digital transformation. Based on his experience in consulting and serving as a freelance CTO in many different companies, building new ventures and helping existing companies optimise their processes, he brings a wealth of experience on how agile works (and doesn’t work) in different contexts and environments. In his talk, he’ll share some of the recurring pitfalls and issues he’s encountered in transforming and supporting agile teams.
This interview has been condensed and edited for clarity.
Where did the idea for your talk come from?
In agility, there’s a huge educational problem. People buy a product and then they think they’re agile. Agility is a mindset, and you cannot buy a mindset. You have to experience stuff. Every good agile project is different. People try to adapt it to environments that are different and wonder why it’s not working. It’s a bit like you buy an electric car and you wonder why in the desert you’re not going anywhere because there’s no infrastructure for it.
What’s a common misconception or mis-implementation?
For example, there are scrum masters who say, “If you’re not doing scrum by the book, it’s not worth it.” Look at what scrum does as one of the agile frameworks: scrum at the end has a meeting that’s called the “retro” [retrospective]. The idea of a retro is to find out what in your current process is not working for you and to change it. How can I do a job by the book, if the last meeting is to change it? It’s not possible! You need someone who asks:
What can we do differently?
How can we change it so that the idea of what we should do is preserved and done?
If I’m not doing it, what am I trading away?
You have to understand what you’re doing and why you’re doing it. You have to re-evaluate the process over and over. You will never be ready with getting agile, never. There is no finishing point. You cannot implement and say, “we’re done, we’re now agile and everything’s done.”
When did you first encounter a real transformation in how a company worked?
My first company was a very command-and-control company where I worked and where I wrote my thesis. The second company I was in, had consultants come in to help them build a new process because they realised the old way wasn’t working. The good thing there was that the consultant who implemented that process stayed afterwards to do it. He knew it all, and it was not just “look here’s the PowerPoint and now we go away” situation.
What is one thing that people miss when they try to teach agile?
The agile mindset transforms you, but you have to experience it. I can tell you all about agility, you can still say, that’s one opinion of the world. Someone else will tell you that waterfall is the best thing since sliced bread. These are all opinions. To change your mindset, you have to feel it. You have to do a project with me where we work that way, where you say: “This thing was actually working that much better than before. I did all the other stuff. I want to do that again and again and again and again. This is how you get a mindset into someone. I think it cannot be taught. It can be told, but you have to experience it, to inherit it.
What distinguishes your philosophy or mindset as a leader?
In IT, there are a lot of people with intrinsic motivation. If you see them leave, it’s often not because of money, but that their needs – in terms of what they want to achieve – are not fulfilled, or they don’t see that they could thrive here or come to their best. You have people that want to climb the ladder. You have people that want to build good products. You have to find a way in a team to balance that, so that everyone can have a share of this. Then you get great outcomes for the company. You have to align that a bit, move it a bit, channel it a bit, but then you can get great outcomes.
But it has a lot to do with the culture you bring in and you live. For example, if my team works late, I work late too, even if I can’t contribute. They probably have to work late because I made an error, so I stay. That, for example, makes a big difference. Also my background is engineering, and I code also as a consultant sometimes, just to know what their problems are.
Every one of us is different and has another idea how [leadership] works. But if you look at the ones that are really successful, there’s always this guy that is relatable, not just in his ivory tower who comes down to spread the knowledge. I’m good at what I do, and I still can code, so I can have a proper discussion on tech. That gives me another reputation than just being the guy that counts the numbers and says: “this is your new salary.”
Who are you directing your talk to? What kind of person would you like to come, and what kind of questions should they have in mind?
The talk is about examples of how I tackle problems I’ve faced. The first bit is origins, because most people don’t know what agile originally wanted to tackle. What is the thing that it wanted to solve? Why was it invented? Even in leadership, or especially in leadership, if you don’t come from an engineering background, but a management background you may never experienced working that way.
Seeing that other people handle stuff the same way as you do, gives you an idea if you’re on the right track. Doing stuff differently and seeing how other people relate to problems gives you a new perspective. Telling stories from what I have experienced and how I solved it, gives the new [managers] a look into, “Okay I’m on the right track.” The ones who are experienced, they can say “This is another approach I can try.” And the ones that are super experienced, can also learn that “I’ve done this and it worked out – or not.” This is a discussion I can have with them afterwards, which gives me some feedback from other people trying to solve the same problem. There’s also something for me, I’m not just there to spread my knowledge, I want to learn too!
To learn more about fostering agility both in engineering teams and their surrounding organisations from Florian, come to see his talk at Leaders in Tech | Berlin on Wednesday February 12th, 2020. Contact [email protected] for more details.