Listening, Compassion, and Shared Context make coaching rewarding.

Healthy Ownership requires plenty of tools.

I have spent a majority of my life around educators.  I have family members who were teachers and administrators.  Many of my peers in college are teaching at the university and high school level.  I also spend my time on social media following teachers, trainers, and educators of all stripes.  A common refrain I hear from all these people in my life is satisfaction they receive when students they serve understand a difficult concept or master a skill.   For many of them, this feeling of satisfaction is why they got into education.  It is the same reason I am an agile coach and why I am championing the notion of “Healthy Ownership.”

My attendance at the agile coach’s retreat earlier this year was an awakening for me.  I spent time with other coaches and learned some valuable lessons about myself.  I also worked closely with ten gifted people who held each other accountable and created something called “Healthy Ownership.”  Born out of frustration in my agile practice, “Healthy Ownership: was an opportunity for me to learn better techniques of coaching. It was also a chance to step aside and learn how others lead and motivate teams.  It is surprising what I learned. 

The most important lesson is to listen to what people are saying.  I struggle with this ability at work.  Put me in front of a PBS documentary, Anime show or Kaiju film, and I am perfectly attentive.  In work situations, I struggle to listen.  My inability to pay attention to verbal and non-verbal cues hurt my coaching.  Thus, I am committing myself to be a better listener, so I understand the hidden and apparent challenges to the teams I am serving. 

After listening, I need to work on guiding others to have more compassion for their colleagues.  You cannot fundamentally change how empathetic a person is but you can help someone it is their self-interest to help others. Ayn Rand speaks about the “virtue of selfishness.”  I consider her thinking to be an alibi for callousness and contempt which will undermine any team attempting to succeed.  It is why everyone needs to understand they are working together.  You may not be able to increase team empathy, but by reducing callousness and contempt among team members, a coach will have a better success rate. 

Finally, after guiding others to help team members, it is essential to create a shared context.  It means a product owner, developer and scrum master should understand how to better focus on what they need to do together to be successful.  For instance, my teams discuss technical debt daily. The purpose of the discussion is for product owners to understand the obstacles the teams need to overcome to deliver the product.  The mindset of continuous improvement seeps into everyone’s mindset, and during sprint planning, we have frank discussions about the amount of refactoring we need to accomplish.  The shared context is building quality for the customer faster.  If the product owner sees how hard it is to get stories finished, they pay attention to technical debt. 

I am going to be in San Diego as part of the agile coaching exchange talking about “Healthy Ownership” and how it has changed my perspective.  As you can see, I am going to be talking about it for the remainder of my career. 

Until next time.

Estimation is not an alibi for failure.

Estimation is not a quotation of work.

I spend plenty of time working with people who are just learning about agile and scrum.  The agile reformation has spread worldwide; what it has not done is penetrated deeply into organizations.  Elite information technology teams quickly accept the new paradigm and start to deliver.  Executives and leadership notice and they want to replicate these effects in the organization.  It is when this happens the life of a scrum master gets complicated.  If agile is going to succeed at scale in large organizations leadership must change how it views work.  It begins with accepting all estimations are not quotations for labor. 

Ryan Ripley, a coach, and trainer I respect is an advocate of the “no estimates,” camp of agile.  I have blogged about this school of thought, and I consider myself a skeptic.  I think it is easy for a team to operate without estimating but executives who are paying the bills are horrified when highly paid professionals say they do not have an educated guess about when they will finish work. 

The reality is executives are craving certainty in an uncertain business world.  An executive wants to know the budget is not getting wasted.  Most executives do not understand the technology which keeps their organization workings, so this creates an additional level of anxiety.  Finally, technology is changing so quickly a course of action which made sense at the start of the project can backfire at the end of the project. 

Agile and scrum attempt to solve this by using rapid iterations to build a shippable product which business professionals can then inspect and adapt. It works like a charm, but for larger projects with multiple handoffs between systems, it can create a sense of apoplexy.  Teams are on schedule but with different cadences of work.  Software code on one team does not work correctly with a different team.  Meanwhile, time continues to move forward, and deadlines made without any feedback from the people doing the work begin to slip. 

Estimates are treated like quotes because when deadlines slip executives can point to the faulty projections as an alibi for failure.  Activities such as construction and automotive repairs are easy to estimate because the rules which govern those activities are reasonably constant.  Concrete dries at a particular speed.  A repair shop can replace a tire in about an hour.  The laws of gravity have been steady for eons.  The nature of software development makes it nearly impossible for smart people to provide accurate estimates. 

Multiply this reality over numerous projects which have to work together with tight deadlines and tighter budgets you have a recipe for madness.  The software teams are groping in darkness, and the executive team is demanding some light and direction.  What can be done to break this pattern of insanity?

The first thing which needs to change is executives should understand estimates are not quotes of work.  An estimate is an educated guess at best and a cruel lie at worst.  Software working in production is the only credible sign of progress.  Based on what is working in production a leader can make more informed decisions about what to do next. 

Next leadership needs to fund cross-functional teams.  Often projects are supported, and they have a beginning, middle, and end.  When a project ends the team is disbanded and with it the knowledge to maintain or improve the system just created.  High functioning teams should stay together and given different projects.  A marketing team like this will develop logarithmic expertise and use it to defeat the competition.  If you watch Netflix, I recommend the story of Barbie and the “pink berets,” who worked in Mattel’s marketing department.  

Finally, leadership should accept software development and other complicated projects should resemble the commute to work.  Somedays the traffic is heavy and others it is light.  Construction can cause backups, and occasionally a car fire will create a gaper's delay.  Accept variability of work and try to avoid forcing unreliable estimates into schedules not grounded in reality. 

If executives and business leaders can understand these principles estimates will no longer be an alibi used to forgive failure.

Until next time.

Each Scrum Master and Agile Coach Should Embrace the Weird.

Be Weird!

Being a scrum master in a large organization is filled with contradictions.  The scrum master is a servant leader for development teams with zero authority unless earned.  A scrum master removes impediments to progress and leads to continuous improvement.  It is a mission which often puts the scrum master in conflict with the organization they work.  People in the business see you as a misfit and weirdo.  I firmly believe this is a good thing and coaches and scrum masters should embrace their inner weirdo.

I kept thinking about how change is often promoted by the eccentric, weird, and outcast among us.  Allan Turning and Ludwig Wittgenstein are intellectual giants of the twentieth century.  One invents the concept of software development and computer science.  The other gave us the “Tractatus- Logico Philosophicus.” Our understanding of computing and language would never be the same thanks to these two people.

Both people were also profoundly weird.  Turning was a closeted gay man with a penchant for wearing a gas mask to ward off allergies.  He was also overly protective of his tea mug chaining it to a radiator.  Wittgenstein was weirder than Turning;  he quit university teaching to build a house for his sisters.  He claimed his book “Tractatus- Logico Philosophicus,” was the last book of philosophy anyone will ever need, and he also liked to pick fights with his contemporaries like Karl Popper. 

Today people like Turning and Wittgenstein would not make it out a Ph.D. program at a big ten college let alone be tenured faculty at a major university like Cambridge of the 1930’s.  The world of business has similar stories.  Bill Gates was a college dropout who could not complete his eagle scout when he was in high school.  By every definition he was a nerd, breaking into computer labs to get more time on mainframes.

I doubt a computer company or venture capitalist would give someone like Gates the time of day.  His elevator pitch would be too bland, his sweat-stained oxford shirts would not look professional, and what does a college dropout know about business.  The truth is Bill Gates is one of the countless oddballs, misfits, and weirdos who have moved business, technology, and society forward.

It is why when I saw this tweet from the Muppets I had a revelation.

Some people think it's okay to be weird, but they're wrong... It's AMAZING to be weird!!! There's absolutely nothing better!

— Gonzo (@GonzotheGreat) September 6, 2018

Being weird is amazing.  Not living in the box others live in is fantastic.  Being able to speak truth to power because they do not take you seriously is fantastic.  Making changes which are crazy enough to work is terrific.  Being weird is a lonely path, but the friends you do make are amazing.

As a scrum master or agile coach, you are in a weird role doing weird things which the rest of the organization consider weird.  The truth is what you are doing is amazing, and you are going to be remembered with more fondness than the boring CEO who speaks in accounting jargon.

Go forth, be weird and be amazing!

Until next time.

Time to call out bad agile before its too late.

Do you want this person coaching your agile efforts?

Agile is not a revolution in business.  You do not see technology professionals and agilists with pitchforks and torches wanting to burn down global capitalism.  It is a reformation where smart and conscientious people are attempting to reform business.   It creates a backlash against people who are happy with or benefit from the status quo.  Backlash is a natural reaction to change.  What I have discovered this week are developers I have known and respected for years heckling an introductory agile training course in their company.  Via social media, I had a front-row seat.  It was deeply troubling, and I wanted to blog about it.

Plenty of technology leaders have criticized Agile and Scrum.  I have written two blogs directly addressing these concerns. What struck me, recently, was the contempt I was experiencing from quality developers about the basics of agile.  I witnessed a series of vomit GIFS and videos of people attempting to self-harm while the presentation was in process.  One commenter said, “Reading these to my team (we all hate agile) and we are LOL” and the thread continued with someone else saying, “…I have a passion for hating agile so yeah I’m LMAO.”  Making matters worse the slides showing agile principles were mislabeled and out of sequence.  Combine this with an instructor who looked like they never had to deliver working software it was brutal and disappointing.

After some back and forth with the hecklers, someone I deeply respected got to the meat of the why there was so much contempt.  The agile manifesto and principles of agile were “insulting,” and further elaborated, “if your leadership is buying into agile, it works.  However, that is not a case at most companies.  This is much harder to install at something that isn’t a startup.”

The contempt is a product of poor leadership support of agile.  The ridicule comes from skilled and experienced developers who want to ship software without getting bogged down in process.  The laughter comes from poorly coached and led efforts to guide agile at the firm.  The cynicism is a product of “dark scrum” and the creation of a software sweatshop mentality.

It was upsetting to experience this kind of pushback.  I do not discount this experience.  People with PMP certification and limited exposure to agile feel threatened by the reformation of business.  Some of the unscrupulous put on the title of “Agile Coach” without the experience or the mindset of a coach.  These individuals peddle their services as consultants or thought leaders.  Often people like this are about a helpful as butchers in an emergency room and just as dangerous.

Poor agile leadership, coaching, and education deserve contempt.  Those of us who bring a sense of artisanship and care to agile need to point out bad actors and improve the field.  Often, we are brought in to clean up the wreckage created by these people. We should also extend help to the bad actors to improve their ability to do the job.

I firmly believe a terrible agile application to a company is worse than no use of agile at all.  Based on the contempt some of my developer friends heaped on the agile trainer; it is clear they feel the same way.  Coaches and scrum masters like myself will be around to help guide others.  It also looks like we are going to clean up this mess left by others.

Until next time.