Agile Transformation: How to tell that you are failing…

“So being 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 gnawing urge to supplement the post with something a little more tangible and pragmatic.

So being a geek at heart I present to you my list of anti-patterns regarding agile transformation. For the less technically minded among us an anti-pattern is typically a documented recurring software problem that is usually ineffective and risks being highly counterproductive. They serve as a vocabulary to shape discussions about design based on past industry experience. Since Andrew Koenig coined the term in 1995 it has been adopted in fields other than software design, so I feel its a great succinct format to present my views with.

Anti Pattern: “Not my gig”

If your executive or management layer views “agile transformation” as something that is exclusively the domain of tech teams and if none of the other supporting functions are involved you might have a problem. Agile is a culture not a process or activity. If you only optimize the delivery function and not the supporting business functions all you are doing is over optimizing one aspect of your organization making it incompatible with the others. Agile transformation has to be an organization-wide activity including the executive layer or you are wasting your time.

Anti Pattern: “Don’t worry we’re experts”

If your army of agile experts and trainers only talk about methodologies and process then you have been duped and should strongly consider firing every single one of those expensive consultants on the spot. Agile coaching and scrum mastery are incredible difficult skill-sets to source for. The reason for this is because these roles are geared toward intangibles that are inherently hard to track and measure. Instead of parroting process or methodology the agile experts you are looking are individuals that continually cultivating the understanding that agility is a mindset and culture. The sad truth is that many agile experts are not experts at all. They are former project managers that need to stay relevant and subsequently went on scrum training (typically given by equally inexperienced agile experts). With the blind leading the blind all focus ends up on the tangible part of the role being process and methodology. Unless your agile expert has actually run a real agile project (at scale) and proven it to be a success in from the perspective of the (proper) agile community, you are missing the point.

Anti Pattern: “Madame Secretary”

Related to the “don’t worry we’re experts” anti pattern, the “madame secretary” can be spotted when a great majority of your scrum masters are merely acting as agile secretaries to their squads. Instead of doing any real coaching (or driving any changes) these individuals spend most of their time simply following the ordained agile events in a kind of weird check-boxing exercise. This happens a lot for scrum masters sourced from other roles or people that have been trained by one of these snake oil training merchants. Your agility team members should be students of the human psyche. They should be passionate about understanding human personality theory and should continually be coming up with experiments to improve the psychologically safe work environment of their teams. They should be obsessed by tracking every metric of team happiness. They should be an undeniable expert in their field. If a developer knows more about agile development than your scrum masters, you should be afraid, be very afraid.

Anti Pattern: “Waterscrumfalls hiding”

The waterscrumfall is already a known term but this anti-pattern takes the concept a bit further suggesting the intent behind it. Waterscrumfall refers to when your development teams are doing everything in their powers to run in an agile way, but all the other phases of the project don’t operate in the same way. This typically results in an over optimization of the development phase but unchanged slow moving cycles everywhere else resulting in sub optimal results. Now for the new bit. Agile is rough, it makes everything transparent for everyone to see. Developers embrace this since it beats having nobody else understanding what on earth they are up to. But this level of transparency might not sit well with some of the other more traditional functions in your organization. Waterfall was a great way to obfuscate many of the daily duties and tasks due to its inefficiencies. If you see signs of localized agile adoption it might be the unfortunate truth that there are some in your organization that prefer to hide from view.

Anti Pattern: “Functional Culture”

When cultural concepts get functionalized (and frequently centralized) you’re doing it wrong. Devops is a great example. Devops is a culture, it is a way to describe development and operations coming closer to one another. How do organizations respond? By hiring dedicated devops competencies and raving about them every opportunity. Operations personnel that fear for their future re-brand themselves and start singing from the devops hymn book. Team level devops activities get centralized to fancy new committees tasked with solving holistic problems establishing fancy new standards everywhere for everyone to use. If you are spinning up working groups, committees or new functions left, right and center around culture based concepts, you are doing it wrong.

Anti Pattern: “Just because”

Agile adoption should be tied to a tangible and inspirational goal. Unless there is a compelling ‘why’ as to why you are doing this transformation you will not succeed. Talking only about the ‘what’ benefits (like cost reductions or greater efficiency etc) is not going to get people to embrace a new culture shift. If you are getting a lackluster response from your people you should probably watch this excellent video by Simon Sinek, and reconsider your approach to leadership.

Why corporate companies suck at agile

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

Why corporate companies suck at agile

Agile has become like a religion where everyone in corporations feverishly beat their breasts and shout at the top of the voices for all to hear how great it is.

It 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 beat their breasts and shout at the top of the 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. Its 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 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 recite SCRUM methodology to you claiming to be the answer to your waterfall world.

Why technical leaders fail

“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 process can be turned. “

Why technical leaders fail

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

Of course there are plenty of other industries that are comprised of very highly educated clumped together behind a common goal, but few have such a low barrier to entry in terms of building complete products with a relative small amount of resources. Simply put few other industries offer the intellectual challenge of the endeavor and the ability to realize ideas and products almost in complete isolation.

Due to this low barrier of entry, software tends to attract true creators. At the heart of every coffee slurping geek, is someone that is in love with using his or her mind to create something from scratch. Someone that yearns for a better world. Someone that sees things not for what they are, but the potential of what they can be.

Yet software projects and start-ups have notoriously high failure rates. How can it be that an industry with so many bright and capable people fails so darn much at delivery results? More worrying is how often leaders that come from a technical background fail. Commonsense would have you think that someone that understands the ins and outs of the craft should exceed where more traditional leaders fail? Why is it that so many technical leaders struggle so much to adapt to their role? Why do great engineers make mediocre managers?

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.

The problem is that leadership requires you to be a generalist that is obsessed with execution. There are so many facets to running a business that technical leaders always run the risk of getting lost in the world of ideas, in the process suffering 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 process can be turned. The line between visionary and dogmatic is unfortunately a very fine one.

“Simply put, as a former technical leader if you find that you spend a lot of time talking about ‘the how’ of things instead of ‘the what’ of things you might still be caught in the mindset of a programmer trying to micro optimize every aspect of a system. “

Simply put, as a former technical leader if you find that you spend a lot of time talking about ‘the how’ of things instead of ‘the what’ of things you might still be caught in the mindset of a programmer trying to micro optimize every aspect of a system. Users don’t care about methodology, architecture, design, or technologies. They care about great products that solve their needs and make their lives better. Tune your actions to always doing the things that will yield the best possible product and you will quickly realize that micro optimization to that knob in your process will most of the time not yield a faster better product and is simply a distraction.

Never lose sight of this..

What it means to be a leader

“You have taken the complex interpersonal dynamic of natural leadership formation, ripped away many nuances and intricacies and put in place a sub-optimal model.”

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.

It is unfortunate that industrialization has left us these rigid organizational structures that make no sense in a knowledge economy. When you put a hierarchy in front of someone and start talking about career paths, drawing their attention to where in the chart they are, emphasizing all the ‘growth’ that is above them you are in the process dis-empowering them. You are telling them this is you over here, and these are the people above you. These lofty people are your superiors and have this supposed ‘power’ over you for reasons that may be authentically valid or more often frightfully contrived and engineered.

You have taken the complex interpersonal dynamic of natural leadership formation, ripped away many nuances and intricacies and put in place a sub-optimal model. In the process simplifying the complex human dynamic to a laughably simple system that only vaguely reflects the natural tribal dynamic of a group of people coming together.

Like any simplified model it only works for certain circumstances and frequently fails for others. So why does it persist? In order for it to work it requires people to perpetuate and belief in the model. It requires people to embrace and live the model without question. It requires people to embrace it, ignoring the obvious faults. It requires people to make it a taboo to question it. Unfortunately tying people’s compensation to the model means that most rational people will do exactly these things.

People will always do what is best for themselves, and since money has become a proxy for survival when this terrible game is laid bare most people will compromise themselves. They will go with the flow since not doing so will threaten the livelihood of themselves and their family. So it is that learned helplessness kicks in and people start playing the game against their better judgement. They redefine their reality to trying to figure out how to beat the rules of the system and move up this artificial hierarchy. They give up on how it should be and start believing that that they cannot change it.

This results in so many issues, many of which I am sure will get explored in the blog. But the one I want to explore in this post revolves around how it bastardizes leadership. Leadership gets conflated into this misrepresentation of how high in the chart you are and how many leaf nodes there are underneath you. Leadership gets implied based on how well you play the game, not on whether people trust you and want to follow you.

The truth is that true leadership has nothing to do with rank or power. True leaders are servants to their people. A more natural model would be to invert the frequent organizational diagram with the subordinates sitting on top of the leaders, since a true leader’s responsibility is not to serve themselves and their own ego but those of his or her people.

“The truth is that true leadership has nothing to do with rank or power. True leaders are servants to their people.”

You are only as effective as the people who support you, and if you are only in a position because of you managed to game an imperfectly structured contrived system you are very quickly going to find out how hard it is to do anything of real substance. You have to have the natural trust and belief of those you should be serving in order to achieve great things. And no title or rank in a hierarchy can create this.

The Obligatory ‘Hello World’

“The problem is compounded when former technologists move into leadership roles where their formerly invested technical skill-bases have to almost be completely abandoned in favor of the soft skills that are required to be an effective servant leader.”

The Obligatory ‘Hello World’

It is my goal to create a resource that other technologists on a leadership path can use to help survive the gauntlet of fire of self management training.

And so, a new blog is born. I always found the software industry to be a counter intuitive experience. The industry is riddled with introverts that came into the industry because they draw energy from themselves and their thoughts. Software development presents more than enough problems that allow us to engage our inner thoughts.

But most of us quickly learn that in order to build anything of substance you need to work with other people. In fact, the ability to communicate and collaborate with others in the industry ends up being one of the biggest success factors for a software professional’s career frequently determining how fast and far the person can progress.

The problem is compounded when former technologists move into leadership roles where their formerly invested technical skill-bases have to almost be completely abandoned in favor of the soft skills that are required to be an effective servant leader. To make things worst organizations typically are not geared to help these new leaders to develop these softer skills required for their new role leaving them to fend for themselves. Most organizations take this bizarre approach of running their best technologists through this gauntlet of leadership adaption fire in order to identify the few that somehow learn to adapt and survive. This exercise frequently comes at great cost to the ones that fail to transition to the new skill set both in self-esteem and motivation. It is not uncommon for those former great technologists to regress and redefine themselves elsewhere meaning that their former talents and skills get lost to the organization in the end.

To be one of the few that survive it is a hard, frustrating journey where most are left to learn through continual trial and error and vast stretches of self-doubt and criticism. This sink or swim approach to management training is one of the biggest disservices we can do for our people and is the theme of this blog.

It is my goal to create a resource that other technologists on a leadership path can use to help survive this gauntlet of fire. I am by no means an expert, but I do feel that if I document some of the learnings that it would help solidify them for myself and perhaps do some good in the long run.

Let’s see how it goes…