This article shines the light on the reasons why Scrum has been important for me and how it is still a centerpiece.
The story starts two years before Scrum had been introduced in my life, right after completing my electrical engineering degree.
TL;DR
In a nutshell, Scrum changed my life at work. 🥳🤓
It just made sense! Every component of the structure added value. It moved me from being a lonely developer to a team member to a servant leader to a coach, back to a developer, to a trainer, and finally back to being a coach.
It gave me space and structure to grow my professional skills. It opened the doors and shined the light on what might be the next logical next step, revealing one move at a time, learnings all along the way. It complemented the concepts I had learned at school around ethics and professionalism. It taught me how to be a coach and a mentor, showed me the road to compassion, and empathy, and bring all of me into my daily work life.
All of this while contributing to building great products, crafting sensitive and respectful, yet ambitious work environments. It gave me the freedom to work on my entrepreneurship, balancing personal life, and business objectives.
Through Scrum, I met new friends, colleagues, mentors, coaches, and a collection of communities that were supportive and inclusive.
Scrum is a simple structure that helps people inspect & adapt while building great products.
In the end, my wish is to guide more people and organizations to implement this simple structure and witness how it unleashes possibilities for them.
That simple.
Full Story
I was an Electrical Engineer with an accentuated talent in Software Development. My first job was in a small company that designed and manufactured CNC machines within everyone’s budget. My job consisted of improving the circuitry and adding features to the corresponding software. I had a blast, it was fun, I was learning and growing. After a while, it became somewhat constraining and it wasn’t that great anymore. It was time for a change.
So the universe handed me a software engineering position in a town nearby. This was a big shift for me. I wasn’t alone anymore. My new work environment was structured, with more relationships to navigate, and more challenges to overcome. I was the new junior and I had been assigned to work on the Real-Time Processor Unit of an embedded piece of software that was integrated with some other piece of hardware. Exactly my type of challenge at the time. This was a step forward in my Professional Engineering career, stepping out of my comfort zone, diving into the corporate world.
I accepted my assignment and started coding, figuring out on the fly what I needed, asked for help whenever I would be bogged down. My supervisor was quite happy with my performance, and I felt like I was maybe contributing to something, but I wasn’t really sure what.
One day, one guy walked into my cubicle and started screaming at me; “why did you induce a defect in my code?!”. It felt weird, I was solving a bug in the system. I was walking on eggs shells.
And then appeared another person, he had been promoted as our new Team Lead. He felt different from the rest of us. He was sensitive to our interactions and our results as a group (I didn’t even know I was part of a group). Furthermore, I think this was the crux of it all, he wanted to help us grow as professionals.
His first magic trick was to get everyone together and talk about code ownership and coding standards. He didn’t dictate, he facilitated a conversation among ourselves. It made us realize that this code wasn’t our own code, it was owned by the corporation and we were all responsible for its quality. Interesting conversation, so instead of having this guy screaming at me about breaking his code, we started to engage in rational conversations on how to improve the code quality. A shift in “what is important for us” vs “Do I look good” and “what is important for me”.
And then, he made us meet at a regular interval every month to plan and review our work, and to inspect our working practices. Every day we would meet and make a plan of our day to best accomplish what we forecasted. This made so much sense for me. It blew my mind that there was a name for every part of this process, and the process itself was called Scrum. It is implicit by the name itself that Self-Organisation was a key ingredient.
At first, everyone was focused on their own product improvements. Slowly, the group sensitivity shifted to the “We” from the “Me”.
This shift was important because it allowed us to improve our communication, our practices, our focus, and our alignment as a team.
After a while, the team grew in numbers and I found myself hovering from one new person to another just to make sure they would know where to find the information. In my mind, this was critical to our overall productivity and also to theirs as individuals. I was also being mindful of their sense of being included as part of the team. I remembered when I started with minimum guidance and feedback and how I was struggling to find my way into the code. Group consensus became the only way to make decisions. I became more sensitive to the conditions that were needed to foster teamwork.
We were lucky because our boss was all-in. It felt organic, it felt natural. And we accomplished amazing things altogether, until the end.
While my colleagues were pulled into other challenges and positions, I left for a 6000km walk in the woods.
During my hike, I had the opportunity to coach at a small company. It felt natural and organic, it felt good. I decided to start my own consulting company. I wanted to provide Agile expertise to help optimize processes and deliver more value to customers. Basically, I would join a company, live through their normal turmoils, and then apply the structure and theory of Scrum. I helped numerous companies get out of chaos by implementing just enough structure and helped a few other organizations loosen their constraints, using Scrum.
And this is how I became a Scrum Trainer. Inviting team members in training so they can share the same knowledge, use the same language, and have the same expectations on how to work together. The teaching was more effective with groups of people than on a one-on-one basis.
If I would have a wish for my kids would be for them to have a workplace that is able to navigate the unknown, while supporting their growth. In a way, my work is contributing to creating this exactly.
The Last Shift
One of my latest personal developments was to acknowledge the value of Hierarchy. With Scrum, there are no titles, everyone is equal. Hierarchy is perceived as constraining. For the longest time, I saw hierarchy as evil. The idea that you receive orders and you are expected to follow them even if they don’t make any sense is counterproductive to me. I found it to be repellent, full of ego, full of anger, and full of hope.
I preferred decentralized decision making using group consensus. In self-organized teams, there is a natural leadership that sketches itself. It’s a different type of leadership often referred to as “servant leadership”.
I learned that simple structures can free our minds. But Hierarchy is a form of a structure too. It provides a clear path to become a leader up a ladder and it can be motivating to climb it.
I came to the conclusion that hierarchy and leadership are two different concepts that I concatenated together in the past.
In a hierarchical setup, there is a chain of command, orders are given and tasks are assigned. The person on top is credited with the outcome, success, and failure. Although, I observed failure is often blamed on others. Hierarchies and Command & Control have proven to be effective to manage simple work for a full century and it became the default style of structure and leadership.
Today, with the speed of change, this form of structure became too constraining and can’t keep up. Empirical evidence taught us that decentralizing decision-making to autonomous self-organized teams is much more effective. Give them what they need and get out of their way. Scrum works very well to provide a simple structure that helps navigate complexity. The new style of leadership plays an important role in this.
In the end, both structures and leadership styles are situational. What matters, is what matters “now”, and it’ll evolve over time. You can read more on different structures used by bold organizations in the work of Frederic Laloux.
So now what, coach?
Not every Scrum implementation is alike. Not every organization has a similar culture. So when helping companies and organizations implement Scrum it is important to let them figure things out while providing just the right support.
The mentorship of the Agile Expert will get you started until you find your crux. This is when there seems to be less growth, and the value of Scrum seems to be limited. It takes between 6 to 12 months for the crux to reveal itself.
Check this study from ZenExMachina, they built a tool that measures Agile IQ overtime. This graph is showing compiled data on how new behaviors get acquired for a limited amount of time before reverting to old habits when transitioning to a Scrum environment.
Is it worth noticing why is the ceiling at 60%? What is the resistance that prevents people from fully embodying the Agile principles and practices?
The flat lines may be periods of rest which are essential to have sustainable change. The downwards lines may feel like reverting back to old habits after being on autopilot.
The Coaching Vision
I think the next obvious step is to help develop capabilities and capacities that will stick for a longer time. This will build the foundational structure enabling future growth and integrating better agility at the workplace.
May this be our contribution to the next generation’s workplace. Think about it, our kids and grand-kids will be conquering inter-stellar galaxies! They better be well equipped to navigate the unknown.
The way I’ve tackled coaching was to apply sporadic practices without really having a method other than what Agile Coaching Framework was offering at the time – a few coaching stances, a few practices, and tools. I’ve noticed how powerful it can be, and also how the development was sometimes short-lived.
Other coaching organizations have identified the short-living results of the Agile Coaching Paradigm and are offering different structures to support the Agile Coaches out there.
Here’s a good summary of the differences noted in the competencies of an Agile Coach vs Professional Coach. It is with no surprise that Agile Coaches would feel lost in their stances with so many dimensions to master!
Integral Coaching Canada created a rich coaching structure that makes behaviour changes stick for a longer period of time. The change sticks longer because the method is proposing daily practices to anchor the learnings of the new desired way of being. Applying your practices with rigor will help you record deep in the body, mind, heart, and spirit the new desired way of being. That’s called embodying the new way.
The idea for the coach is to identify what capabilities have to be developed and offer a structure to learn these new ways. Expert information on the details can be found when needed, where appropriate. The coach is no longer the expert in here.
Conclusion
You see, this is why I am loving Scrum so much. It provides a simple structure that gives freedom in professional growth, both for the organization and for the individuals. Implementing Scrum may be the first step into dealing with change and complexity, while Integral Coaching will support the embodiment of what is needed to make the changes last longer.
The rest of the series will attempt to lay down the possibilities that this method can offer to people who are implementing Scrum. No matter what the culture is, or the structure of the organization, or the level of maturity of the team.
Stay Tuned.