Posts by Sarel Esterhuizen

I love building software. Or perhaps a better way of putting it is, I love building great software. Software that solves real world problems in the most efficient, scalable and practical way possible. Sometimes this means that I manage people, other times I architect other times I coach. Whenever possible it means getting my hands dirty writing code in the trenches with teams. It doesn’t matter what hat I’m required to wear. As long as it involves working with great people busy realizing great value-adding software, I’m happy.

Agile Transformation: The Warning Signs of Failure…

“As a geek at heart, I present to you my list of anti-patterns regarding agile transformation.”

Behold the agile transformation wizard, here to save the day!

I present to you my list of wizardly anti-patterns regarding agile transformation…

I recently did an article about ‘why corporate companies suck at agile‘. Since writing that post, I have had a nagging urge to supplement the post with something more tangible and pragmatic.

As a geek at heart, I present to you my list of anti-patterns regarding agile transformation:

Not my gig – If only your tech teams are involved in the agile transformation, without the support of other functions, you may be setting yourself up for failure. Agile is a culture, not just a process or activity, and it needs to be embraced by the whole organization, including executives, to be effective.

Don’t worry, we’re experts – If your agile experts and trainers only focus on methodologies and processes, they’re not doing their job. Agile coaches and scrum masters should be experts in the intangible aspects of the role, such as cultivating a mindset and culture of agility. If they’re only parroting process and methodology, they’re not true experts.

Madame Secretary – If your scrum masters are acting as secretaries to their teams, rather than coaching and driving change, they’re not fulfilling their role. Scrum masters should be students of the human psyche, constantly experimenting to improve the psychological safety of their teams and tracking metrics of team happiness. If a developer knows more about agile development than your scrum masters, it’s a red flag.

Waterscrumfall – If your development teams are running agile, but other phases of the project are not, it’s a sure sign that your agile transformation is not being implemented consistently. This can lead to over-optimization of the development phase and incompatibility with other parts of the organization.

Agile theatre – If your organization is going through the motions of agile, but not actually embracing the culture and mindset, it’s a clear sign of failure. Agile transformation requires a real commitment to change, and if it’s not happening, it’s time to reassess your approach.

Unrealistic expectations – If you set unrealistic expectations for what your agile teams can accomplish, you’re setting them up for failure. Agile is about making small, incremental improvements, not achieving overnight success. Make sure your goals are realistic and achievable.

Lack of commitment – Agile transformation requires a genuine commitment from everyone involved. If some members of your organization are not fully on board, it will be difficult to achieve success. Make sure everyone is committed to the process and willing to work together.

Micromanagement – Agile teams need space to operate and experiment, but if they are being micromanaged, they will be unable to do their best work. Allow your teams the freedom to manage their own processes and make their own decisions.

Lack of transparency – Agile teams thrive on transparency and open communication, but if these values are not present in your organization, it will be difficult to achieve success. Make sure everyone is aware of what’s happening, and encourage open and honest communication.

Ignoring feedback – Agile is all about continuous improvement, and that requires listening to feedback from team members and stakeholders. If you’re not paying attention to feedback and using it to make changes, your agile transformation will not be effective.

Functional Culture – If you’re turning cultural concepts into functional roles or committees, you’re not embracing the true spirit of agile. DevOps is a great example of this. Rather than hiring dedicated DevOps personnel or creating committees, true agility comes from fostering a culture of collaboration and communication between development and operations.

Just because – Agile transformation should be driven by a clear and inspiring goal, not just because it’s the latest buzzword. If you’re not getting buy-in from your team, it may be because you haven’t communicated why the transformation is important and how it will benefit everyone involved. Make sure you have a compelling “why” to inspire your team and drive change.

Why corporate companies suck at agile

“Sticking feathers up your butt does not make you a chicken.” – Tyler Durden

Why corporate companies suck at agileIt is amazing that 16 years after the agile manifesto came to life that many corporate software environments still talk about ‘Agile Transformation’. Agile has become like a religion where everyone in corporations feverishly beats their breasts and shouts at the top of their voices for all to hear about how great Agile is and how totally on board they are with it. For many business professionals, it has even become a career risk not to buy into the virtues of Agile.

For those paying close attention, you will notice that when corporate environments talk about agile development, (like the paragraph above) they tend to talk about it in capitalized noun form. Agile development has been reduced in substance and is simply seen as a process or framework that needs to be adopted. It is seen as a magic bullet that is finally going to solve the inefficiencies in those pesky technology departments that just don’t get the subtleties of high-brow business folk’s needs.

The problem is that this capitalized noun Agile mindsets miss the point completely. In the immortal words of Tyler Durden, ‘sticking feathers up your butt does not make you a chicken’. Similarly taking an agile (read nimble) process/methodology and following its steps to the tee without really understanding its purpose does not make you an agile organization. It was never about process or framework.

Agile is an adjective, it describes a culture and mindset. A desire to be adaptable, collaborative, lean and evolutionary. Agile is about early feedback loops, about failing early and fast. It is about constantly reflecting on yourself and coming up with experiments to improve things. It is about partnering with your client and involving them in the development process.

It is about transparency and externalizing risk at all times. It’s about building products lean and incrementally. It is about accepting that you don’t have all the answers up front and using natural ways of working to figure them out just in time when they are needed.

If these words resonate with you I implore you to go read the agile manifesto again and to start focusing on the values and principles behind agile development instead of fixating on the process. Be mindful of how people become fundamentalists about something they do not even truly understand in the first place.

We need to stop the army of Scrum Alliance trained ‘Agilists’ that parrot fashion recites SCRUM methodology to you claiming to be the answer to your waterfall world.

But the real issue is that corporations are not set up to be agile. Corporations are built to optimize control and stability. They are built to make money by minimizing risks and maximizing profits. They are built to have long-term plans and to execute them. They are built to have policies and procedures in place to ensure consistency.

All of these things are anti-agile. Agile is about embracing change and uncertainty. It is about experimentation and learning. It is about short-term goals and flexibility. It is about trust and collaboration.

In order for corporations to truly embrace agile, they need to fundamentally change the way they operate. They need to start valuing adaptability and learning over control and stability. They need to start prioritizing experimentation and innovation over minimizing risks and maximizing profits. They need to start focusing on adaptable goals and flexibility over long-term plans and control. They need to start building trust and collaboration over policies and procedures.

This is no small task. It requires a complete shift in mindset and culture. It requires senior leaders to lead by example and to truly understand the nature of the beast.

Why technical leaders fail

“On the other end of the spectrum, leadership requires you to be a generalist who is obsessed with execution and good enoughs.”

Why technical leaders fail

Good software developer != Good leader. Why do we stumble as technical leaders…

As an industry, software is unique in that it attracts true creators. At the heart of every coffee-slurping geek is someone who is passionate about using their mind to create something from scratch. These individuals often yearn for a better world and see things not for what they are, but for the potential of what they could be.

Unfortunately, software projects and start-ups have notoriously high failure rates. This is particularly true for entrant leaders who were formerly technical. It seems counterintuitive that an industry with so many bright and capable people struggles to deliver results.

The heart of the problem lies in the fact that as an engineer, you live in the world of ideas. You are used to exploring the recesses of every problem, losing yourself in the world of solutions and efficient designs.

The heart of the problem lies in the fact that as an engineer, you live in the world of ideas. You are used to exploring the recesses of every problem, losing yourself in the world of solutions and efficient designs. You value micro-optimization and doing things right. You strive to make each aspect of your code or algorithm as perfect as possible.

On the other end of the spectrum, leadership requires you to be a generalist who is obsessed with execution and good enoughs. There are so many facets to running a business that technical leaders often get lost in the world of ideas and suffer from analysis paralysis. What matters more than solving every scenario perfectly is execution. The ability to get things done trumps generating endless ideas of how some knob in the complex malaise of people and processes can be turned. The line between visionary and dogmatic is unfortunately a very fine one.

To be an effective leader, you need to be able to prioritize, delegate, and execute. You need to be able to balance the needs of your team, your customers, and your business. You need to be able to navigate the complexities of running a business and make tough decisions. And you need to be able to adapt and learn from your mistakes.

It is not easy to make the transition from an engineer to a leader. It requires a shift in mindset, a willingness to embrace new challenges, and the humility to ask for help when needed. But for those who are able to adapt, the rewards can be immense. As a leader, you have the opportunity to inspire and empower your team, to create something that truly makes a difference in the world, and to leave a lasting legacy.

What it means to be a leader

“Effective leadership requires the trust and belief of those being served. No title or rank in a hierarchy can create this..”

You have to have the natural trust and belief of those you should be serving in order to achieve great things.

True leaders are servants to their people.

True leadership has nothing to do with rank or power. In fact, true leaders are servants to their people. The rigid, hierarchical structures that have been prevalent in organizations for so long make little sense in today’s knowledge economy. When we focus on hierarchical career paths and highlight the “growth” opportunities above us, we are disempowering individuals and simplifying the complex interpersonal dynamics of natural leadership formation.

This simplified model only works in certain circumstances, and often fails in others. For it to persist it requires people to perpetuate and believe in the model, embrace it without question, and make it taboo to question it. Unfortunately, tying people’s compensation to the model means that most people will do exactly that. They will compromise themselves in order to protect their own livelihoods and those of their families.

“True leadership has nothing to do with rank or power. In fact, true leaders are servants to their people.”

As a result, leadership becomes conflated with rank and power and is based on how well an individual plays the game, rather than on whether people trust and want to follow them. The truth is that true leadership has nothing to do with these things. A more natural model would be to invert the traditional organizational diagram, with subordinates on top of leaders, since a true leader’s responsibility is to serve their people, not themselves.

Effective leadership requires the trust and belief of those being served. No title or rank in a hierarchy can create this. True leaders are servants to their people, and their effectiveness is directly tied to the support and trust of those they serve. Without this natural trust and belief, it is impossible to achieve great things. And no amount of gaming an imperfectly structured, contrived system can replace it.

The Obligatory ‘Hello World’

“Unfortunately, many organizations are not equipped to help these new leaders develop these skills…”

The Obligatory ‘Hello World’

It is my goal to create a resource that other technologists on a leadership path can use to help them navigate the challenging journey.

The software industry is often seen as a haven for introverts, as it provides ample opportunities for individuals to engage with their own thoughts and ideas. However, as many software professionals quickly learn, building anything of substance requires collaboration and communication with others. These “soft skills” can be critical for a software professional’s career, often determining how quickly and successfully they can progress.

The problem is compounded when former technologists move into leadership roles, where they must almost completely abandon their technical skills in favour of the “soft” skills required to be an effective leader. Unfortunately, many organizations are not equipped to help these new leaders develop these skills, leaving them to fend for themselves. This sink-or-swim approach to management training can be detrimental to both the individual and the organization, as it often leads to the loss of valuable talent and skills.

In this blog, I hope to create a resource for other technologists on a leadership path, to help them survive this difficult transition. I am not an expert, but I believe that documenting my own learnings can help me solidify them, and potentially benefit others. Let’s see how it goes…