The Road to Respect

Coaching others is a difficult business.  You need to listen and have empathy for others without forfeiting objectivity.  A coach must be responsive to the cultural and emotional difference of each person you work.  For me, I have had to change my mindset from a fixed position to a growth perspective.  I am fortunate there are plenty of people in the agile community to provide inspiration and direction. One of these individuals is Kim Scott, the author of “Radical Candor.” The more I read about her suggestions on being a better boss the more I think about the agile value of respect. 

I have blogged about the topic of respect numerous times.  It is one of the fundamental values of Scrum.  It is also something which is hard to quantify and explain.  The best definition of respect comes from the Kaizen Institute blog.  They say the following.

“Respect is ultimately about actions.  Do you really value the next person in your process to such an extent that you will go out of your way to satisfy the need of that person?”

So respect is not about creating an often false emotional bubble of niceness.  Instead, it is about acting in a way which shows other you are meeting their needs.  It can be showing up to meetings on time or authoring unit tests on new development.  It also means saying something which needs to be said.  Kim Scott calls being nice but not challenging others directly “ruinous empathy.”

If the phrase ruinous empathy sounds harsh it should. I see teams with ruinous empathy in many corporate environments.  These people have meetings where everyone spends time complimenting each other.  Everyone gets along because challenging someone is seen as not being a “team,” player.  In many cases, ruinous empathy resembles the worst moments of high school where the favorite students are fawned over by their less popular peers.

Entrance into these social circles is the path to social advancement, but it requires the sacrifice of self-esteem and personal values.  It is “everything is awesome,” and everyone is above the average world.  No one works too hard, and there is no accountability.  Sooner or later, someone is going to point out a challenge, and they are ostracised.  The good feelings return, but the problem lingers.  If the members of that group respected each other, they would try to help one another address the challenge instead of putting up a false front of nice and banish the person who raised the problem.

Where things become challenging in a group is when you care about others and test them directly, but they do not see it as a radical candor but obnoxious aggression.  I am attempting to navigate this currently.  I pointed out to someone the information they were posting on the company slack channel need to be more credible, and that anecdotal evidence was not enough to justify sharing.  I received a hostile reply saying the link shared was from a security expert.  The individual also said they felt “shamed” by my public reaction and my coaching. 

I decided to deescalate the situation and apologize.  Afterword, I thought about it and discussed it with someone I trust.  In hindsight, it is clear I should have taken these individual's concerns more seriously.  I did what is called “front-stabbing,” by Kim Scott.  I should have coached this individual in confidence.  I was obnoxiously aggressive when I thought I was radically candid.  I will not make that mistake again.  Returning to the Kaizen Institute’s blog, I was not meeting the needs of the person I was coaching; instead, I was publicly shaming them via the social media of the company which was a slack channel.  I engaged in the behavior which was the antithesis of respect. 

Respect is a delicate state to achieve.  I learned a valuable lesson about it this week. Avoiding ruinous empathy and challenging people is not enough.  A coach has to understand others and the context they work so they do not feel ashamed when you coach them.  It is a hard lesson to learn but just another step along my agile journey.  I will earn more respect along the way. 

Until next time.

Why Companies Resist the "Agile Mindset"

Bad leadership creates a mindset which is not agile.

It is difficult explaining agile to others outside my profession.  The Agile Manifesto outlines four values and twelve principles which govern how people should approach work.  It is up to people like myself to make sure the manifesto and principles are not abused.  To be successful, it is not enough to have talented professionals doing the work and following a successful formula.  Those professionals need to collaborate as a team willing to take risks and innovate.  Scrum masters and agile coaches call this the “Agile Mindset.”

I have been working in the orbit of agile for nearly ten years.  It is a rewarding and challenging line of work.  Plenty of business leaders like the results agile brings to software development teams.  Research from the Standish Group has shown projects done in an agile manner are more successful and have fewer budget overruns.  Business leaders should be falling all over themselves to implement agile based on this knowledge.

In reality, agile faces serious organizational and cultural hurdles. I say this because agile places a strong emphasis on continuous improvement and corporate transparency.  For managers who are incompetent, absent, micromanaging, or power hungry agile is a threat.  Ken Scheweber says agile holds a mirror up to the organization.  Resistance to agile happens when an organization does not like what it sees and attempts to smash the mirror.

I have experienced this resistance first hand.  A manager was reduced to spasms of rage when I said he could not poach a developer for another project until a sprint ended.  A network administrator deliberately denied technical support for continuous integration and continuous builds because they did not want developers, “…touching my servers.”  Finally, I remember someone from governance say they had been doing production rollouts the same way for ten years.  It was puzzling to them why anyone would change a system which was working correctly for them.  I have seen and heard almost every alibi and excuse NOT to be agile.  Why is it happening?

The answer is the fear and uncertainty built into each corporation.  It is not enough to be profitable.  A corporation must be profitable according to the expectations of shareholders if not share prices can fall precipitously.  Years of retirement savings can vanish in an afternoon.  The focus on this shareholder value forces companies to squeeze profit out of anything.  For instance, employees are expensive, so layoffs, “right-sizing” and automation improve profits without doing the messy work of developing the product or increasing sales.  A Keurig machine where employees bring their coffee replaces a coffee pot with free coffee.  Employees are expected to do janitorial work, or empty trash cans less frequently.  Failure to maintain these profit figures or increase them leads to unemployment which is a pathway to financial ruin.

The power-hungry pursue leadership so they can inflict harm on others rather than suffer the everyday indignities of office work.  The absent hope invisibility will protect them from accountability.  The incompetent bluff their way in the organization and pin their failures on others.   The micromanager lacks trust that people can do their job, and it is a threat to their livelihood. Each of these poor leaders is anti-agile.  Poor leadership drives away good employees and slowly choke the organization.  These individuals survive because the pace of business at a large organization makes it easy for these individuals to hide in plain sight.

With lousy leadership, the only people that stick around are bad employees.  It becomes a feedback loop of awfulness.  It is why an agile coach spends plenty of time struggling against the organization, and it can be lonely.  It is sobering because you will face it often in your career.  So be prepared for resistance to the “agile mindset.”  It is not because people do not want to be successful.  Instead, the fear and uncertainty of a modern corporation discourage the mindset from happening.

Until next time.

Working with Kanban

Two different ways to be Agile.

When you are working as an agile coach and scrum master you are dealing with innovation at the speed of the internet.  New concepts are constantly coming into being.  It is overwhelming at times.  Luckily, I have plenty of colleagues in the profession who have experience with these ideas when they crop up. 

I was introduced to Kanban when I was training in the Scaled Agile Framework for the enterprise.  I did not think much about it at the time.  It just seemed like a variation on a theme for managing work.  I was wrong.  Kanban is agile, but it is not a subset of Scrum.  It is a different way to meet the principles outlined in the Agile Manifesto. 

For those not familiar with Kanban, I strongly recommend Eric Brechner’s book on the subject, “Agile Project Management with Kanban.” Brecher is not some crazy theorist; he is responsible for the development of the Microsoft Xbox.  In the book, Brecher not only provides basics; he provides the administrative know-how to make it work at your organization.

Unlike scrum which limits work with a timebox known as a sprint; Kanban uses something called WIP limits.  WIP is an acronym for work in progress.  The team can only do so much at a time, so WIP is the limit of that work.  The team then moves work through a queue based on WIP limits.  For example, if the team sets a WIP limit of five for development and a limit of three for QA when work meets the definition of done in development, it is moved over to QA as long as they are working on three or fewer elements.

It is obvious why Kanban would appeal to the “No Estimates,” crowd.  Work breaks down as it moves through the queue and it does not require any estimates.  Scrum rituals like backlog refinement and sprint planning fall away.  Comparing Scrum and Kanban, it is obvious to me that Kanban is well suited to exist in architecture and software applications.  Scrum is perfect for a greenfield project where rapid cycles show stakeholders how the project is evolving.  I am glad that Kanban is another approach in the agile toolbox. 

The agile manifesto says, “Individuals and Interactions over processes or tools.”  Kanban is just another process and tool you can use to help your client achieve agility.

Until next time.

Gaslight does not help Agile

Business should never run by gaslight.

As a scrum master, you spend much of your time getting individuals and teams to improve.  It is the central role of a scrum master to encourage improvement.  Countless training courses have come along to help people better coach and facilitate change.  The work is deeply satisfying and provides direct value to the team and organization.  Eventually, a team will reach a plateau of improvement.  It happens because further growth requires changes to the organization surrounding the team.  The biggest frustration of my agile practice is overcoming those cultural and organizational barriers to agility.  I have noticed a significant portion of colleagues and managers have a vested interest in discouraging the spread of agile because it threatens their careers.  Every reformation has a counter-reformation, and this week on the blog, I want to discuss the most dangerous tool used by agile opponents; gas lighting.

The term gaslighting originated from the 1944 movie “Gaslight,” starring Ingrid Bergman and Charles Boyer.  The film follows Bergman as she is slowly driven insane by Boyer to obtain her inheritance.  The film highlights the cruelty and abuse required to force someone to doubt their reality.  Today, the concept applies to any situation where you have a narcissistic or sociopathic person attempting to manipulate someone else.

According to Ken Schwaber, one of the original signatories of the agile manifesto, scrum holds a mirror to the organization.  Gaslighting begins when colleagues and managers are embarrassed by what is in the mirror.  For instance, a manager could accuse you of pushing the organization or team too fast.  The reality could be you are making the manager look bad because the team is delivering software better than they ever could.  It is gaslighting because the reality is their team is shipping software, but in the manager's eyes, you are upsetting the natural order where they control releases instead of the team.  Feedback like this is insidious because in many organizations the manager’s opinion counts when it comes to appraisals, pay raises, and promotions.

The website “The Ladders,” has a blog on typical gaslighting behaviors which are employed.  If you experience those behaviors, you should leave the organization.  Life is too short to work for an organization which makes you crazy.  Scrum helps address gas lighting behavior because the transparency of inspection and adaption provide physical proof of software releases, performance improvement and pace of the team.  Finally, I have discovered shipping software silences most critics in an information technology organization.  The work speaks for itself which drives the power hungry, absent, incompetent, and micromanaging to use gas lighting to save their necks.

I am a big fan of Kim Scott and her book “Radical Candor.”  Gaslighting is the polar opposite of radical candor.  Scott calls it manipulative insincerity.  Gaslighting is the inability, to tell the truth, and care personally for the performance of the person being coached.  It is abusive.  When it happens, it should be called out, and if it continues, it is up to Human Resources and leadership to become involved.

Organizations who want to succeed should understand gas lighting behavior is wrong.  I have been in numerous situations which were examples of gas lighting.  The survival tactic I have relied upon is to count on my peers for support and seek out authentic coaching.  The first step to fighting this form of abuse is to recognize it is happening; the next is taking action.  I have I have given you a few tools to do it.

Until next time.