What I Learned at AgileIndy 2023

As a business professional, it helps to spend time with others who you do not work with. It helps provide fresh perspectives and moral support when times are tough. It is also good to hear from others that they share similar struggles in their business situations. It is like cleaning the emotional pallet from the sour aftertaste of daily dysfunction. I took the opportunity to attend the AgileIndy 2023 conference to perform that cleanse. I was a presenter, and I learned a few things. Today, I wanted to share my trip report with everyone. 

I traveled to Indianapolis to present a talk on servant leadership and how to use language to build credibility with team members, stakeholders, and leaders. I had a packed room, and the presentation went well. I look forward to making many connections and seeing if my tips are helpful to people in the field. This journey's best part is meeting old friends and making new ones. The agile community is one big tribe of like-minded people who bicker like family but often unite to make work more sustainable. 

Along with giving a presentation, I got to sit in on some great presentations and discussions about how to make businesses more successful with agile techniques. If there were any big themes at this conference, they were twofold. The first theme was the role of managers in an organization going through an agile change. Teams that self-organize and deliver in rapid iterations create unique challenges for managers who now have to do something else beyond traditional management. The other theme is establishing trust in organizations. I want to discuss each of those themes. 

For many of us in the agile community, implementing agile techniques works well at the team level, and executives occasionally achieve buy-in. Most managers threaten agile methods because they fear the organizational changes that agile demands. Thus, self-organization, empowerment, and transparency often make managers feel redundant and threatened. Many change management efforts fail because middle management strangles it if considered a threat. Fortunately, Diana Williams and Liz Rettig had a great conversation about this forgotten cohort of people who can make or break your agile adoption. I know plenty of folks at Project Brilliant, and I was not disappointed by the advice and suggestions they provided. I am going to devote a future blog post to their advice. 

Mike Cottmeyer from Leading Agile gave the keynote speech about the enormous challenge facing the agile community in 2023: building trust between business leaders and agile teams. We in the agile community demand empowerment for groups doing the work. Still, empowerment does not happen if that team does not create working solutions for the business to sell. It means that for a team to be empowered, the company must trust the team to do the work. Cottmeyer points out there are steps to business agility, and approaches like SAFe and Scrum at scale are about helping the business manage technical debt and dependencies. Dependencies are agile killers in organizations, so it is up to everyone to find ways to mitigate them. The truth will always win between reality and purity, so Agile professionals need to be reality-based. 

I had some great conversations in the green room at the conference. Coaches love to talk shop, and sharing experiences with others is always instructive because our experiences overlap. Finally, I met Dimple Shah and attended her presentation, which covered diversity in organizations and how the drive for diversity is often the same as the desire for organizations to become more agile. In a relaxing manner, she reviewed that people need to both talk the talk of change and walk the walk. By following this simple approach, people create credibility in the organization.

I am fortunate to spend time around so many great people. It is also a blessing to share my knowledge and experience with others and help them. Best of all, I learned a few new things to return to my practice. I hope to present to AgileIndy next year, and I look forward to visiting plenty of old friends and making new ones. 

Until next time. 

The Paradox of Certainty

The biggest paradox in business is that business people and shareholders demand certainty. Profits must be steady or growing. The business meets expectations with little struggle, and the organization behaves like a perpetual motion money machine, creating gains and dividends. The reality is that business is a deeply uncertain activity filled with plenty of chaos. Consumer tastes change, regulations tighten, and the human beings who run corporations are frail and prone to mistakes, so while everyone demands certainty, there is never any guarantee that the expectation will happen. This paradox is central to most business challenges, and I want to discuss it this week. 

When you speak with business leaders, particularly executives, you hear them say, "I expect." It provides a veneer of certainty and cloaks the person in a coating of faux confidence and confidence. Often, you hear conversations like, "I expect the realse to go well," or "I expect that report on my desk at the end of the day." Meryl Streep portrays this language of callous efficiency with awful accuracy in the film, "The Devil Wears Prada."

Often, these expectations come into conflict with reality and the chaos that often surrounds technology projects. Developers sprinting toward a deadline and working long hours make mistakes, introducing software defects. Last-minute changes and defects extend timelines. Finally, power imbalances in organizations create situations where decisions create conflicting priorities that seize up progress. 

The empiricism and transparency that come with agile are supposed to address these problems but bump into the paradox of certainty. Decision-makers with expectations often do not want to know about the defects and dysfunctions that riddle their organizations. Instead, they demand results, and if they hear the word no or that the organization is creating a constraint hurting delivery, they will treat the messenger as insubordinate. It creates an atmosphere of fear where people know things are wrong, but no one takes action because their risk does not offer any reward other than unemployment. It is a scary place to be, and the effect resembles gaslighting behavior. 

I do not have a solution to this paradox. Still, as an agile coach and software professional, I know that we can reduce uncertainty by ruthlessly inspecting and adapting each time we finish a sprint. It also requires the swallowing of pride by decision-makers and developers to address each project's good, bad, and ugly. It is complex and requires discipline, which many business people lack, but those who are successful will make the effort and grow in the process. To break out of the paradox of uncertainty, try having observations and opportunities for growth instead of having expectations. 

Until next time. 

I get knocked down!

When you become a blogger or post on social media, you offer your wisdom and opinion to others. Giving advice also comes with a particular burden because you must practice what you preach to others. Finally, your guidance has to have a positive practical effect.   If you are not helping others, you are no different than a mentally ill person ranting about lizard people on a soapbox at the corner park. The business world makes me feel crazy occasionally, but this last week was insane. Each blogger, coach, scrum master, and social media poster will face a test and must rely on their advice to struggle through.  

As a coach and blogger, I have repeatedly said that failure is more important than success to determine your ability to grow professionally. Failure is educational, tests your mental toughness, and motivates you to transcend those failures. I have failed plenty of times, and the experiences have made me more intelligent and wiser as a professional. 

The most vital test of a person is how they respond to setbacks and failure. My partner coaches a soccer team on weekends. It means I spend my Saturday morning watching five-year-old girls kick a soccer ball around a small field. It is also a chance to watch personal growth happen in real-time. A young girl over-kicked a ball, tripped, and fell. She was stunned for a moment but realized there was a fight for possession, so she huffed at the indignity of falling, got back up, and got back into the game. Later, she would score a goal. It made me proud of her because she rose above a setback. 

The business world is like those five-year-olds learning to kick a soccer ball. People fail and make mistakes. The ball does not bounce your way, or a teammate will disappoint. Unfortunately, global business is not youth soccer because you often don’t receive a juice box and encouragement from your coach after a game. Many times, you feel alone and empty. Business is ruthless when it comes to failure. 

As a culture, we often trumpet success but greet failure with awkward silence. No one knows what to say when you are on your stomach with turf stains on your face. For me, the obvious answer is to say, “Get back up!” How we respond to adversity is the best measure of success. 

If you excuse me, I have to clean some grass off my jersey and get back into the game.

Until next time. 

Southwest and Lessons of Technical Debt

Kicking over an ant hill resembles an Irwin Allen disaster movie. It is a frantic and desperate scene. Insects scurry in all directions attempting to make sense of the catastrophe and repair the damage. Some ants try to bite or sting the offender who upset their home. It constantly happens in nature, and the scene is repeated in business as unforeseen events conspire with neglect to create desperate situations for professionals. The latest example is the recent trouble at Southwest Airlines as it attempts to recover from bad weather and worse software. Today, we kick over a metaphorical ant hill and look at how to avoid this catastrophe. 

News stories circulated over the holidays about Southwest Airlines and countless passengers stranded in the middle of holiday travel. The press was so bad that Southwest offered 25,000 free air miles to its passengers as a sign of goodwill. How on Earth did this happen, and why? 

While working on my MBA, Southwest Airlines was a thorough case study on how to run a business properly. Flight attendants worked with management to understand scheduling. The organization and its labor union have a collaborative relationship. A reality TV show featured Southwest gate managers highlighting customer service challenges. Seeing headlines featuring incompetence and dissent within the Southwest organization was discouraging. 

How did such a great business fall so quickly? The answer became clear when Business Insider shared an open letter from the head of the pilots union, which pointed out that the former CEO, Gary Kelly, did not invest in updated software for pilot scheduling. Kelly also packed the organization with cronies with a common background from the accounting program at the University of Texas. Discussion about how to run the business moved from the pilots and other employees to the executives' leadership surrounding Kelly. It was great for the organization's profitability, which made money when other airlines faltered, but it was a situation where the qualities that make Southwest unique atrophied. Most damming was the deliberate neglect of technical debt in the company's software scheduling of pilots. 

I talk about technical debt as an agile coach and consultant. I have written about the subject on several occasions. Software and data are as vital to customer service as adequately trained people and well-maintained aircraft. As software continues to eat the world, it is incumbent that business leaders pay attention to the operation of their software systems because if they do not, they will experience expensive and embarrassing episodes of business interruption. It appears that Kelly, who is still the chair of the board of Southwest, is being exposed to that costly lesson.

Technical debt in a business organization point to deep organization failures. If a business fails to update its systems, it shows it does not care about the proper operation of the company. Somewhere, someone calculates that updating systems does not have an immediate financial benefit, so they neglect it. Over a series of years, the systems become more brittle and unable to deal with changing conditions. The result is ill will from customers, lawsuits for poor service, and a large financial hit to the organization. All of which could have been avoided if leadership had paid attention to the technical debt sooner. The east coast snowstorm around Buffalo was the final straw, and it took Southwest longer to recover. 

I am not surprised by this story. Many organizations have this problem, and it takes an event like this to make it relevant to business leaders. In truth, having your organization experience something like this is an excellent way to avoid inertia and complacency. By having your metaphysical ant hill kicked over, you pay attention to the operational issues that matter. Southwest will pay for this; I hope they have learned their lesson.

Until next time. 

Software is NOT transcription!

One of the most challenging things about working in technology is explaining what I do to others outside the business. A chemical engineer at a food company can explain they help create flavors or ensure the potato chips we eat are consistently crispy. A petroleum engineer transforms crude oil into gasoline and other valuable petrochemicals, making modern life worth living. An agile coach, scrum master, or software developer has difficulty explaining what they do. Sometimes it looks like magic, and other times, it resembles tedious bouts of frustration. There are plenty of ways to describe my profession, but today on the blog, I want to explain what it is not. 

Nothing is more frustrating for me professionally than interacting with executives who earn their leadership in their organization by mere survival. These people look like leaders but do not exhibit leadership characteristics because survival in a dysfunctional organization is the only accomplishment they can proclaim. They were mediocre people who were unremarkable employees. Eventually, these people are promoted by someone because they do not threaten the status quo and the leaders above them. These executives are allergic to risk and innovation because it would threaten their position.  

Countless times I have been in the office of these individuals and their faux leadership. One ordered me not to speak to other departments because he did not want the different departments to learn about our challenges with software releases. Another explained that we were not a technology company, so to expect us to behave like a technology company was foolish. I even had a vice president pat me on the head and call me ‘son’ before explaining how I did not understand modern branding. Naturally, when layoffs came, these paragons of leadership remained, and I was made disposable. 

These leaders are toxic and insulting to the professionals who keep the global economy spinning. By far the worst was a salesperson who said, “Software is easy; you just transcribe our order forms into the inventory system.” At that moment of emasculation, I knew it was a matter of time before I would quit the organization to do something else. Software development is not transcription! It is a complex process of taking business artifacts like forms and turning them into strategies that deliver value for the firm. It is not a transcription but countless creative decisions that developers make that have numerous implications for the business and the software development process.

The dismissive notion that software is just transcription is self-defeating. For example, how does an order form behave once a customer fills it out? Developers will ask about the impact of the order on the inventory and accounts receivable system. Software engineers worry about what happens if an item is missing from the warehouse. Can a data team use the inventory to track trends and determine how to serve customers better? Finally, what else should the ordering system do to deliver value to the business? It is a game with thousands of questions, and developers need to answer them to make the software work.

The technology world overflows with intelligent and talented people. Despite layoffs, the technology world has an over-abundance of work and needs more people to do it. Business leaders want to throw as much work at employees as possible because their labor is expensive. It is this crazy ratio of supply and demand which drives much of the dysfunction in the technology business. Instead of creating a cycle of productivity, there are episodes of burnout and failure to deliver. 

Over the years, I have been profoundly disappointed by business leaders who do not understand technology or how to lead others. I joined the agile reformation because I know that there are better ways to lead others and deliver working software. The business world needs reform, and it is up to people like me and you to speed that process along, so now, when a toxic leader says software development is easy, I know what to say to convince them otherwise.

Until next time. 

Southwest Airlines and the Gremlins of Technical Debt

It is Halloween season, so I indulge in a few monster movies when I have downtime.  I am partial to the old Universal monster movies with Bela Legosi and Boris Karloff.  I also enjoy anything with Vincent Price, and I consider his film “The Abominable Dr. Phibes” one of the most frightening things I have ever seen.  There is something about monsters lurking in the shadows which always gives me a great scare.  One of my favorite monster movies comes from director Joe Dante entitled “Gremlins,” which is a fantastic popcorn movie and a parody of entertainment culture at the same time.  Today, on the blog, I want to discuss a different kind of gremlin lurking in the shadows and how it has been fouling up air travel.   

The term gremlin was invented by the British.  In the early days of aviation, airplanes were not mechanically reliable; engines would jam, flight controls would snap, and canvas would tear without explanation.  Mechanics and pilots often blamed these mishaps on “gremlins,” nasty elf-like creatures who liked to cause mischief on an aircraft in flight.  By the Second World War, pilots from the United States and Royal Air Force had stories about gremlins.  If anyone has stories about these creatures from the German, Russian or Japanese Air Forces, please share them in the comments.  Suffice to say, gremlins were an excellent alibi for poor maintenance, bad design, or dumb luck.  The gremlin became a part of aviation culture. 

I keep thinking about these critters the more I work in technology.  I wish I could invoke them during a debrief of a poorly executed project or use them to explain a server outage.  Unfortunately, gremlins are mythical creatures, and if I use them to present a technical problem, the CIO of my client would laugh at me and then ask me to pack my desk and leave the building.  

Gremlins are comforting, compared to the problems technical professionals face with increasingly complex systems.  Earlier this month, Southwest Airlines could have invoked the little monsters during a three-day weekend when it faced a severe shortage of flights.  Some pundits on the internet spread the false rumor that the slowdown was a strike created by pilots who refused to receive the COVID-19 vaccine.  The reality is less about the civil disobedience of pilots than the negligence of Southwest Airlines and its Information Technology systems.

According to the Southwest Airline Pilots Association spokesperson, “I point to how they (Southwest) manage the network and how I.T. supports that network.”  It seems the union has been complaining about the reliability of I.T. systems for over four years.  Company officials have not commented on the claims but based on the events of the long holiday weekend, it is easy to see how an outage can ground an entire fleet of planes.  

I understand why something like this could happen at a large organization.  The internal system which schedules flights is buggy or unreliable.  Debate within the organization happens, and a decision is made not to fix the system because the cost and inconvenience are greater than dealing with the flawed system.  The conscious choice to do this is called technical debt in the agile community.  It sits in the organization like a time bomb waiting to explode the business at the least convenient time.  I suspect that is what happened to Southwest Airlines. 

Having technical debt in your organization is like having a box of gremlins and tossing them into a swimming pool.  Bad things are going to happen.  It is why everyone in an organization needs to regularly look at technical debt and give it a serious evaluation. Otherwise, your organization will get grounded.  To avoid a horror movie corral the gremlins of technical debt, you will be glad you did.  

Until next time. 

Don't Go Fishing in Jira

I am currently working on a gigantic project with over twenty software development teams.  It isn't straightforward and contains numerous surprises for everyone involved. Projects like this are emotionally exhausting and require focus and attention to detail which can humble the best professionals.  Along the way, I have learned a few things about myself and the SAFe scaling framework.  Additionally, I have discovered an anti-pattern which I need to expose to my fellow coaches and scrum masters.  

One of the base requirements of any project is to have a source control system to manage code and a kanban board to track user stories and defects.  The board can be as simple as post-it notes on a whiteboard or as complicated as an elaborate software package.  Like many organizations, our project uses Jira.  The company uses the tool to keep track of the numerous teams and the thousands of product backlog items completed each iteration.  I will not waste my readers' time critiquing the merits of Atlantasan's project management software.  You can find better discussions about the subject elsewhere on the web. 

What I have noticed is an ugly anti-pattern that is taking place on this large project.  One of the technical leads called it "Jira-fishing," and if you want to deliver value quicker to customers, it needs to stop.  Jira can help an organization or transform it into a bureaucratic cesspool of evil like any software development tool. If software developers or product owners engage in Jira-fishing, you are fighting corruption.  

Jira has a powerful feature known as linking product backlog items.  It allows a developer or product owner to connect other product backlog items to the original story.  So if you are building out a web service and the front-end developer will use it, you can link your story to the front-end developer's story and say they are either dependant on each other or related.  The feature makes it easy to track dependencies and establish relationships between different pieces of work.  Things become evil when multiple teams in the same repository create defects and "analysis" tickets that block other work.  A product owner or developer is "fishing" around multiple tickets to understand dependencies and stopping a work item. 

For example, we have a team building APIs, but another team is working on the database, and a third-team is constructing the UX/UI for the customer.  The front-end developer on the UX/UI team has a story to edit a record, and they rely on an API to work correctly.  For the API to work, the developer on the API team needs to have someone on the data team properly update the database.  During testing, the front-end developer discovers the data is not updating correctly.  Naturally, the developer or the quality person on the team creates a defect, links it to the front-end development team, and then assigns it.  The Product Owner on the development team is then aware of the fault and assigns a developer to fix it.  During debugging, the API developer discovered a database problem and raised a defect to the database team, and the process repeats.  For the Product Owner of the UX/UI team to understand what is happening, they have to go fishing through a minimum of three Jira tickets.  Each defect can have a different priority for each group, and the original story for the UX/UI team will not get completed during the sprint because of those dependant defects.  Timelines slip, and the customer does not see any business value.   

The previous example is a simple illustration of the problem.  I see stories that have taken sixty days to resolve because of numerous dependencies between teams. Deadlines are out of the team's control, and work is held hostage by another team that does not have the same priorities. To anyone who works in the agile or SAFe world, it is a prescription for anxiety.  

The easy answer to this problem is organizing the development team, so a front-end developer, API author, and database person work on the same team to address the original ticket.  Dependencies vanish, and work moves through the system in a smoother fashion.  The practical reality is that splitting up teams and reorganizing them in the middle of a massive project guarantees the project will go over budget and be late.  The team's reorganization won't work because it violates Brook's law which says, "adding staffing to a late software project makes it later.  If adding a new person to a late project makes it later, I will expand that postulate and say reorganizing a software development team on a late project will obliterate any reasonable deadline.  I call it "Wisniowski's First Theorem of Project Management." 

What is a coach to do when confronted with Jira fishing and dependencies which resemble a series of Russian nested dolls?  I always return to the notions of empiricism and transparency, which are central to agile.  The Product Owner must explain each link or dependency in the story along with the acceptance criteria.  It should look something like this below.  

This story is dependant on story 123 from the database team >> which depends on story 345 from the API team >> which requires a change request 678 from the claims team.  

The point is that the Product Owner and the team can clearly see the dependencies and mitigate them.  

Each day I have a standing meeting with product owners who have dependencies with my team. Next, it will become apparent where the dependencies are happening.  It is then up to the Product Owners or scrum masters to create a steering committee or scrum of scrums to address these situations.  Finally, when all else fails, get executives and stakeholders involved.  Often these individuals get in the way of progress with micro-management, but when priorities do not align and work is stalled, they can step in to clear out a blockage.  In most organizations, the Executive Vice President of Development has more authority than a product owner, so when the Executive Vice President asks why something is lingering for sixty days, it becomes a priority for the organization.  

Jira fishing is an ugly by-product of a large project with numerous dependencies.  It is also a symptom of agile teams which are not cross-functional.  To mitigate these challenges, make sure all dependencies are linked to stories and are explicit.  Next, create a scrum of scrums or steering committee to deal with those dependencies.  Finally, have executives and stakeholders get involved to break down obstructions to work.  I enjoy going fishing.  I don't want to do it in Jira. 

How to Help Your Team Overcome Failure.

Software development is a tricky business.  The nature of the work is changing so rapidly that what worked eighteen months ago could fail today.  The mercurial world of software development is the reason why the agile reformation got started.  We do an outstanding job teaching the basics of agile to others.  Unfortunately, we take these essential skills and rub up against the reality of working in a contemporary business environment.  It is a recipe for disillusion and frustration.  As coaches and scrum masters, we need to do a better job helping people who join the agile reformation navigate the hills and valleys of the business's fallen world.  

I say failure is the ultimate teaching tool.  Each day, a business person confronts failure.  It humbles a person.  It pushes them forward to do better.  Finally, it educates in a way no success can.  We need a way to look at our failures dispassionately to create future success.  When the team fails, the best place to address it is the retrospective.  Create a safe and secure environment for people to discuss the challenge.  It also helps to remind everyone about the retrospective prime directive created by Norm Kerth,

"Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources, available and the situation at hand."

Talk frankly about what happened and how the team could have done things differently.  It is crucial to develop an action plan to address the things that the team can control. 

The next thing a team should do is ask if they are facing a constraint with the organ
ization.  For instance, if network services must schedule a time to promote code to production servers.  It is a classic constraint according to Eliyahu M. Goldratt's book, "The Goal." Understanding the condition of the network services team, the developers can devise ways to exploit the constraint and find ways to mitigate it later.  The process of exposing and mitigating constraints will empower the team and give them a sense of control.  

Finally, please write down your experiences and review them.  A coach or scrum master should keep a daily log of what they do.  It should feature the high points of each day and the low points.  Look it over each week.  It also serves as a contemporaneous memo you can provide your leadership to remain updated on your progress.  Over time, looking over these reports provides an oral history of the project, and you can apply the theory of constraints to help challenges you see recurring.  

Business is a fallen world.  As a person, you face failure and disappointment regularly.  Your team is going to disappoint you.  We do not say this enough in the agile world.  What defines a team that succeeds over one which suffers, in the long run, is the ability to recognize and overcome previous adversity. To deal with these disappointments, use the power of the retrospective.  Have the team apply the theory of constraints.  Finally, keep a journal of contemporary events to track progress and learning.  

Frustration and disillusionment are natural by-products of leading change.  Do not let that stop you.  The fallen world of business can get better, but only if coaches and scrum masters learn to face challenges with an approach that helps them improve. 

Until next time.

 

The first attempt at learning is the hardest.

Failure happens.

Failure is one of those seminal experiences we have as professionals.  People will often forget their victories, but failure stings forever.  What makes failure more painful is the way we are shunned by our fellows when we fall short.  It is as if our failure is a kind of contagion which might contaminate others.  It explains why we are so afraid of failure the personal, professional, and social costs seem too high.  I disagree that failure is shameful or contamination.  It is a test and how you respond to disappointment is just as important as your approach to success.  

Failure is quite common in the technology business. A missing curly bracket will prevent code from compiling, and hidden memory leaks can hinder the general operation.  Finally, bugs show themselves during demonstrations with investors and stakeholders.  The time pressures and details developers must sort through create a perfect recipe for humility.  

As a coach or scrum master, what do you do when confronted with failure.  First, a coach should acknowledge each failure as a learning opportunity.  Mistakes and failures are necessary when learning new skills.  Software development changes so radically that a developer needs to relearn their profession every eighteen months.  It makes failure the first attempt at learning.  I remember crashing an e-commerce website because I arrogantly thought the upgrade would go smoothly.  I was mistaken.  The cloud service was also not willing to restore a backup.  The site was down for four days, and I had to find a new job when the site came back up.  I new always backup software before doing an upgrade because I never want to fail like that again.  

Next, failure exposes problems within processes and systems.  The book “The Goal” introduced the theory of constraints, which states systems are only as good as their least efficient part.  Failure is a constraint that the remainder of the system must accommodate if it is going to improve.  Failure is necessary if we are going to understand how to improve the process.  The exposure of failure can point out things that can be corrected or accommodated.  

Finally, failure can create a positive feedback loop.  Angela Duckworth pioneered something called “grit theory.” People and teams that are successful have a passion for what they do, the ability to persevere, and a willingness to overcome failure.  Often teams with ‘grit’ respond to loss with a deep desire to show others they can prove people who doubted them wrong.  It is the ambition to say, “Just you wait!” to those who witnessed that failure.  A good coach channels that energy into process improvement, personal growth, and attention to detail.  

Failure is not an end but a beginning.  First, you have an opportunity to learn.  Next, failure exposes ways to improve processes and procedures using the theory of constraints.  Finally, overcoming failure makes teams develop ‘grit,’ allowing them to channel their energies into success.  Each time I have failed, I feel awful, but I have learned something new and overcome it in the aftermath.  My professional and personal life continues to test me, but I am better prepared for those tests thanks to my experiences.  

Until next time. 

Two Leadership Themes

My leadership will keep on sailing.

I spend plenty of time with other professional people.  We often discuss many subjects, and we often talk about our family lives, careers, and what motivates us.  Occasionally, we talk about deeper topics, but the main topic of our conversations is leadership.  How does a person lead a group of people?  What does a leader do when faced with incompetence or insubordination?  Today, I want to discuss my feelings on leadership.  

The main focus of my career is helping others avoid the mistakes I have made in my career.  I want people to avoid the hardship and disappointment I have encountered during my adventures working as a software developer and project manager.  Failure is the best educator someone can experience in a career.  I want to share the hard-earned wisdom of failure with others so they can avoid the roadblocks and setbacks I have encountered.

Along the way, I have discovered two main themes which have guided my leadership.  The first is servant leadership.  I was exposed to this as a teenager with the help of Marine Corps JROTC.  I discovered leadership is lonely.  It required being a servant for the people you lead.  It also forced me to put my needs on hold while things got done.  I gravitated to leaders who practiced this ethos, and it further shaped me as a person and leader.  

The other is the discovery of Kim Scott and her book Radical Candor.  Her writing and efforts' central thesis is that leadership requires a combination of honesty and empathy to be successful.  Truth without compassion is obnoxious aggression.  Empathy to hide the truth is ruinous.  Kim Scott brings plenty of experience to her writing, and it is bracing to hear her talk honestly about her mistakes.  

I combine Radical Candor and servant leadership to guide how I work with others.  It is not a straightforward approach, but it has given me tremendous satisfaction over my career length.

Until next time.

Admit Weakness and Become Agile

Good teams help compensate
 for the weakness of its individual members.

Continuous improvement and changing organizations are difficult and time-consuming work.  I talk about it all the time because it is the vocation, I find myself.  I worked for years for bad bosses and exploitative people.  I swore to myself if I earned a position of authority, I was going to be different.  Your values and your principles are exposed when you are a servant leader.  You are vulnerable, and learning to forgive others, and yourself becomes critical. I want to talk about something which illustrated that point.

Being a software developer is hard.  It is a lucrative and satisfying career, but it is not easy.  You have to relearn your job every eighteen months.  Developers are surrounded by smart, capable people and expected to be intelligent and capable.  The time spent writing software is filled with false starts and dead ends.  It also contains unrealistic deadlines and pressure to excel.  I was an intermediate level software developer.  It explains why I am so protective of the developers under my leadership; I was one of them.

Since being a developer requires a tremendous amount of problem-solving skills, focus, and intelligence, it creates a culture where to admit misunderstanding or lack of knowledge is to admit weakness.  It is why stand-up meetings degenerate into a perfunctory status report or silent staring matches between the scrum master and the team.  No one wants to look weak, and in many technology companies, this weakness leads to unemployment.

A software demo went poorly this week.  The client was unhappy, and the CEO was frustrated.  What happened next changed the culture of the company and the career of the developer.  Instead of asking why the demo went poorly, the scrum master asked how the demo went badly.  It became apparent the developer was using an untested technology and was struggling for two weeks to meet a deadline.  Instead of speaking up, they suffered in silence.  No one knew there was a problem or that someone needed help.  It was apparent when the software demonstration failed, but by then, it was too late.

Instead of shaming the developer for not knowing the untested technology, the scrum master asked him what he would do differently.  In a heartbeat, the developer said next time they would ask for help.  By showing vulnerability and learning painful lessons, the developer grew as a professional.  The development team learned that they were only as successful as their weakest member.  The team discovered they would have to support each other.  Finally, they accepted failure was necessary if the team is going to succeed.  The scrum master used non-violent language and powerful questions to fix a problem and grow the organization.  I do not doubt that the team will have a successful demonstration in two weeks.  Together, they learned what it takes to be successful.

Admitting vulnerability and asking for help is essential for individuals to come together as a team.  Admitting weakness is a powerful professional strength.  Finally, understand those weaknesses and helping others overcome them is the key to good leadership.  I am glad I got a chance to witness it among my team.

Until next time.

Good Habits, Teamwork, and Grace Create Agility

Forgiveness is Agile

Being a business person is the ultimate endurance sport.  Each day we awaken and try to earn a living for ourselves and the people we love.  It is a grind.  It goes on for years, and if we are lucky, we will get a chance at the end of our lives to reflect and relax.  It is a precarious existence of striving and survival.  The business person confronts this reality each day.  We compete for the quick win and the big score but understand the long term nature of being a business person.  We need to take a look at the long term nature of the life of a business person and how agile can make the experience more sustainable. 

Building a business is a harrowing process.  For every entrepreneur who succeeds, there are more who fail.  Some of the best ideas fail because they can not find a market, while some of the most trivial can generate oceans of wealth.  The random nature of the success breeds arrogance, and these captains of an industry often ignore problems within their organizations until it is too late.  Only when threatened with extinction do organizations feel the need to change.  The scrum master steps into the world of organizational change when the stakes are highest.  It is the realm of failing fast and making corrections.  For some, it is like building the business from scratch all over again. 

The first step is building successful habits among the people doing the work.  It means meeting standards of quality, showing up to meetings prepared, and communicating correctly to make sure everyone understands what needs to happen.  The process of setting up the fundamental expectation of excellence is outlined by philosopher Will Durant who said, “We are what we repeatedly do.  Excellence, then, is not an act; it is a habit.”  Asking people to develop good habits and practice them is the first step to improvement.  Do not ask people to work extra hours and do not expect them to treat their work as a heroic struggle.  Work should be at a sustainable pace; heroic action is unnecessary. 

It is after this process that you enter the second step.  Everyone should understand the business succeeds or fails together as a team.  It takes a team working together and complimenting each other’s strengths to be successful.  The success is constructed on positive habits and relying on others to do their part.  It is the salesperson respecting the administrative assistant for getting the presentation organized, and it is the developer understanding the quality assurance tester wants to ship quality code.  Everyone has a role to play, and it only happens when we work together. 

Habits of excellence and creating a team mentality in the organization are entry-level steps in creating agility.  It also requires what religious people call “grace.”  A pastor once told me the Christian definition of grace is, “…getting absolutely, positively something you do not deserve.”  It is having school canceled when you did not study for an important test.  It is the client rescheduling a meeting when you are stuck in traffic.  I also think grace is when you forgive yourself and someone else for a bad day.  It is the extra cup of coffee or bag of chips as you muddle through the day.  It is letting some go home early to look after a sick child or deal with the side effects of chemotherapy.  Grace means that you can trust others on the team to step up when you are not performing at your best. 

It is only by combining the habits of excellence, creating teams, and practicing grace do we create a more sustainable business environment.  It is a place where the day in day out grind becomes a day of learning, innovation, and forgiveness.  The victories are more regular, and the defeats are more educational.  It is a new way to look at work and one which I hope to pioneer. 

Until next time. 

A Hard Lesson in Agile Leadership from the U.S.S. Roosevelt

Agile leadership comes in all shapes and sizes.

The current pandemic and stay at home order continues to linger.  For those of us with careers which give us the privilege to work at home it has been a strange experience. I confess I feel like a grounded teenager stuck at home.  The reality is that many of us are stuck at home.  Plenty of others are less fortunate because they lack adequate shelter, or they are performing essential jobs risking increase exposure from the disease.  I have made a point of keeping informed but not wallowing in the 24-hour news cycle.  One news story did catch my attention, and that was the tale of the U.S.S Theodore Roosevelt.

Theodore Roosevelt is a Nimitz class aircraft carrier.  It is a floating airbase and city which can travel around the world.  It served in Desert Storm and provided continuous support for America’s ongoing efforts to fight the war on terror in the aftermath of the September 11th attacks.  It is a symbol of American power.  It also became an example of how that power is vulnerable.  The ship and its sailors had an outbreak of the COVID-19 virus.

Navy and Marine officers have two significant responsibilities; they accomplish their missions, and they look after the safety of the people under their command.  Everything else is a distraction to sailors and marines.  The commander of the ship Capt. Brett Crozier sent pleas for help and supplies via e-mail up the chain of command.  The navy did not answer those requests but they leaked to the press.  One hundred sailors contracted the disease, and the ship’s commander was asking for the evacuation of the sick to prevent more people from getting ill.

The chain of command exposed for its slow action began a medical evacuation of the ship.  It then relieved Captain Crozier of his command, effectively firing him.  The acting secretary of the navy said he had lost confidence in Crozier’s leadership.  As he left the ship, his sailors cheered and supported him.  We can gather plenty of lessons from this experience.  As an agile coach and scrum master, you should apply them to your practice.

First, look after the wellbeing of the people you lead and serve.  An aircraft carrier is a floating city powered by two nuclear reactors and has a fully functioning airport.  Over six-thousand people live in close quarters on the ship, and it operates night and day.  An outbreak of one-hundred sick people can quickly become a thousand in a matter of weeks.  If the carrier was going to remain combat effective, the sick had to relocate to a naval hospital.  The commander was acting in the best interest of his crew, the United States Navy, and America.  The thought of six thousand sailors sick and dying in the middle of the ocean is the stuff of nightmares—a plague ship that runs on nukes.

In the next lesson, do the right thing even if it is not popular.  Captain Crozier knew he would cause trouble if his messages became public.  He sent the messages anyway because the lives of his sailors and combat effectiveness of his ship were more important than his career.  When senior leadership relieved him of his command, Crozier accepted the decision and stepped aside rather than protest the injustice of his treatment.  He even took the time to make sure his second in command was ready to take over.

Finally, leadership means being with the people doing the work and making you successful.  Captain Crozier has COVID-19, so he had contact with the sailors and marines under his command.  Instead of sequestering himself on the bridge and giving orders, he met with the sick crew members and learned first hand from his ship’s doctor what was happening.  He put the health of his crew above his own.

I think the navy has made a grave mistake in relieving Captain Crozier of his command.  Acting Secretary of the Navy is showing poor leadership in his actions because it is more about keeping appearances to the commander and chief than looking after the safety of sailors and marines.  Being a leader means dealing with bad news, and it means accepting responsibility.  Thomas B. Modly, the current acting secretary of the navy, could have acknowledged the situation on the U.S.S. Roosevelt and admitted the navy was slow to act.  Instead, he fired Crozier sending a clear signal to other officers not to make the navy and the Commander-in-Chief look terrible.  It is a self-interested policy that will cost the lives of sailors and marines.

Being relieved of command effectively ends the career of an officer.  Crozier, if he survives his COVID-19 infection, will be passed over for a promotion and then asked to retire.  If you are a corporation, having someone like Captain Crozier on your leadership team will make your organization better because he will practice servant leadership and look after the people he serves.  He will do the right thing when circumstances require it.  Finally, he will get involved and get his hands dirty in times of crisis.  He may not be commanding an aircraft carrier, but to this agile coach and scrum master, he has shown exceptional leadership.  We need more leaders like Captain Crozier in our organizations.

Until next time.

Use Agile to Fight Failure

Failure hurts, but not learning from failure hurts worse.

The purpose of agile is to create working software and solutions.  I have stated this goal repeatedly.  The iterations, meetings, and emotional labor are all designed to get work completed promptly.  The rapid feedback delivers value in the least amount of time without waste exposing failure.  The real test of an agile team is how it copes with failure.

The world of politics, media, and business loves to celebrate winning and success.  John F. Kennedy remarked that success had many fathers, but failure was considered an orphan.  People with careers on the line will do anything to avoid failure.  In a world of achievement, the stigma of failure is very real.  I suspect it is this stigma that makes it hard for business leaders to experiment and try different approaches to problems.  To do so is to risk failure.

Failure is a clarifying experience. We quickly discover what does not work.  We also understand the conditions we are working to overcome.  Failure also creates an emotional connection to the work.  It is the chip on the shoulder that drives you forward which says to the world, “I may have failed now but it will make my future success more powerful.”  I extol the virtues of failure because it makes people and teams better at overcoming adversity.  I have failed a lot in my career and that wisdom follows me around.  It helps me train others to avoid the mistakes I have made in the past.

A team has three reactions to failure.  The first reaction is apathy.  If failure does not have any repercussions, a group of people will continue their bad habits and personal agendas.  The next response is fear, where we have people behaving in self-preservation mode.  Team members withdraw from each other and look to do just enough work to avoid blame or blame someone else.  Leaders micro-manage because they feel helpless and see the people they lead unable or unwilling to do the job.  Fear is a palatable emotion, and everyone experiences it on the team.  The final sentiment is determination.  Where the fear once existed, the emotional survivors of the group become determined to overcome their adversity.  Good leaders and coaches get teams to the point of determination quickly.  Those with less skill will have to slog through the earlier steps.

Agile and scrum help along this process, exposing failure and forcing the team to inspect and adapt.  Each retrospective allows the team to find the points of failure and address them.  The team reflects on what they need to do and what they need to change.  A woman I respect who teaches children says failure is an acronym for the first attempt at learning.  Based on this premise failure is a stepping stone to more substantial success.

I have failed more times than I can recall during my career.  Each setback, mistake, and screw up has made me a better developer, scrum master, and coach.  I like to point out the mistakes I have made in the past so that other people can learn from them.  It is also this display of vulnerability that helps me build credibility with the team.  I strive to be a leader instead of a boss or manager.  So, when you are creating working solutions for customers, you are going to confront failure.  The critical part of the failure experience is how you learn from it and the emotional strength of the team who should develop the ability to overcome.

Until next time.

Failure is the Foundation for Continuous Improvement

Failure hurts but it is the start of learning.

Summer is slowly winding down and children are heading back to school.  I find this time of year wistful.  I remember being driven down to college for my first semester away from home.  We were listening to an oldies station, and Arlo Guthrie was crooning, “The City of New Orleans.”   I still get emotional when I hear that song.  Being a university student changed me in ways big and small.  The most significant way was how; it pushed me beyond my comfort zones.  Being in college taught me about failure and learning.  The business community enjoys talking about winning and success.  I feel we need to take a more in-depth look at failure and how it is essential to continuous improvement and learning. 

The current political and social environment is depressing for too many reasons to mention.  One of the primary reason for this is the fetishization of achievement among business professionals.  We have to win at work, at life and our children have to be examples of our winning nature.  If you are labeled a “loser,” you are confronted with public shame or possible ostracism. People wanting to avoid this fate play it safe, doing just enough to get by and avoid making waves. It creates a feedback loop of mediocrity in organizations.

The fear of failure is a significant obstacle for continuous improvement.  The shame and stigma associated with failure often cause people to hide it so they can avoid blame.  As a coach, it is your responsibility to create an environment where people feel safe and admit mistakes.  Once it is possible to admit failure, then the team can examine what happened.  Reflections make it possible for the team to learn from failure and overcome their disadvantages.  The process is humbling, but if done correctly, it is going to create levels of competence and confidence, which will be the envy of other development teams.

I suggest to start with small improvements and then work your way up to more significant corrections.  Start with insisting that meetings begin on time.  Ask about what kinds of things are holding back the teams.  Take time out to listen to how people do work and how they want to improve.  Talking and listening is the best way to beat the feedback loop of mediocrity in organizations.  Give it a try, and you will see that failure is an organic matter where success will grow. 

Until next time.

Avoiding the Dumpster Fire

I have seen this ugliness before.

Technology is evolving and improving.  What is not improving is how we lead technology projects.  I have been in the business for twenty years, and it is clear how we lead technology projects needs significant improvement.  Last week news broke Hertz rental car was suing Accenture for 32 million dollars because it could not deliver improvements to its website.  I am surprised this kind of thing does not happen more often because plenty of large projects burn through obscene amounts of cash.  On the blog this week I want to talk about project failure and how it should provide businesses with a model on how not to do large projects.

Nathan Allen writes an excellent blog on all the things which went wrong during the Hertz affair.  It would be amusing if it did not involve the squandering of millions of dollars.  It contains all the usual culprits in a massive software delivery death march.  Salespeople made promises to executive and then forced technology professional to keep them.  Poor infrastructure at the client exacerbated poor development from the consulting company.  The deadlines were unrealistic, and the client abdicated all responsibility for the success of the project.  Add in a pinch of arrogance from a top tier consulting firm, and you have a perfect example of what scrum masters and project managers alike call a dumpster fire. 

Nothing is more dispiriting than working on a dumpster fire project.  It stinks, and it is fraught with getting your career burned.  Often, developers put their heads down and hope no one blames them for the catastrophe.  The main reason for this state of affairs is large projects are so big that any small setback will grind the project to a halt.  The state of affairs undermines the psychological safety of the people doing the work, and everyone is afraid to step forward and be honest with project leaders.  I suspect this was the primary factor why the project failed.

Deadlines were missed and missed multiple times.  When it was over, 32 million dollars disappeared.  What makes the entire episode more galling is Accenture refused to do more work unless Hertz paid more money to fix a broken project.  Failure crashed into failure setting more money on fire, and the only solution was to throw more money into the flames.

I have worked with several people from Accenture.  They are very good at selling products and getting paid, but they are not good at delivering results.  In the world where they work, it was more important to get paid than it was to provide value.  According to the agile manifesto, this is a refutation of the value of customer collaboration over contract negotiation.  It is clear Accenture is more interested in contracts than helping customers.

I entered the agile reformation because I wanted to build things rather than toil in obscurity.  I have worked on projects where we extracted money and value from the customer rather than deliver it.  Working on a project like this does pay the bills, but it does not move the practice of software development forward or improve the reputation of the development profession. It is up to experienced agile and project management professionals to pour cold water on these dumpster fires.  The business needs to set a standard which is more than watching piles of money burn.  Otherwise, we will have more trash fires like Hertz and Accenture.

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.

Dealing with Scary Stuff

I am scared but I am going to be OK.

I have a sign on my wall which says, “If your dreams don’t scare you they are not big enough.” It has been a frightening period for me.  I am interviewing for new opportunities, sending out applications, all the while the holiday season approaches.  It is a lonely period despite the support I have received from family, friends, and colleagues.  Periods like this test a person and this week I would like to discuss it.

Since high school, I have been one of those students who could be labeled as “striver.” I wanted to advance myself and do better for myself and my family.  Pushing myself academically and participating in extra circular activities, so I would get noticed by a college.  It happened with a twist. I was offered a scholarship to a university and then it fell through.  I went to a community college for the first two years of my college career.  In hindsight, it was a perfect move as I was able to deal with the pressures of college with the support of my family.  When I transferred to a four-year university, I learned the discipline it takes to succeed academically.  It was not easy, but the early lesson was that success required sacrifice and discipline.

Sadly, those two qualities are not helpful when jobs were scarce as was the case in the recession of 1990.  Keeping the lights on and the rent paid required the swallowing of personal pride.  It meant working retail working for commission.  It was dealing cards at a casino.  I discovered I was good at computers and learning how to program them.  I was lucky when I left the casino industry, it was the giddy and stupid times of the dot-com boom.  I transitioned from dead-end jobs to a career.  It only took seven years out of school to make this basic professional milestone.

In the intervening period, I have been fired and laid off more times than I can mention.  I struggled to keep the lights on and the mortgage paid.  People have treated me in a grossly unfair fashion and I have received numerous second chances throughout my career.  The adversity which has dominated my career makes me contemptuous of others who have not had similar experiences.  It is also why I roll my eyes when I hear certain public figures discuss their “life of struggle.”

The ups and downs of my career took a heavy toll on my marriage and family life.  It has changed me more than I would like to admit.  In spite of it all, I have remained committed to the business of building working software and attempting to make work more satisfying, sustainable, and sane.  I am committed to large businesses treating people with basic decency.

I am going to give that vision a hard test.  The experience is going to challenge me in ways I am not comfortable.  I might fail.  I still have to try because I owe it to the people grinding out code.  I owe it to my family and I owe it to myself.  My dreams are very big and they scare me witless.   I look forward to defeating the fear and sharing those dreams with you.

Until next time.

When you lose a bet on your career.

Boy, did I fail.

It has been a crazy week.  I made the transition from working on a gigantic waterfall project to unemployment in the span of an afternoon.  I was feeling a flurry of emotions.  At first, I was ashamed and disappointed.  My feelings then migrated to anger and bitterness at how cheaply was thrown aside.  Currently, I am feeling determination and resolve to get back to work.  Through all this process, I have been overwhelmed by well wishes and support from the agile community.  It is this support which is keeping me going during this difficult time.

I joked glibly; I was betting my career that the project I was on could benefit from my agile knowledge and approach.  In less than seven business days, I was rolled off the project and laid off.  I did not receive any feedback from peers; I was just marched into the HR office and let go.  I should be angry and bitter, but that is not going to help me get back to work.  Fortunately, my colleagues on social media and #Slack came forward.  I received comfort, coaching, and support.  I also took some time to think.

It is not comfortable looking at failure.  It is necessary if I am going to grow and develop as a person.  It is one of the main postulates of agile is, “…to fail early and often.” In that respect, I was successful.  I failed, and now I have to take that failure and learn from it.  I am going to do a better job vetting employers to make sure they want the agilest working on their staff.  I am going to change the notifications on my mobile phone, so I am not distracted during the workday, and I can concentrate better.  Finally, I am going to focus more intensely on Radical Candor and Non-Violent Communication.

I have plenty of free time, and so I am going to use this opportunity to decompress and spend with family and friends.  I will live through this and would not be this brave without the help and support of everyone around me.

Until next time.

Product Owners deserve Healthy Ownership.

Spending quality time with Alex Sloley

I have been working as a scrum master for the last five years.  What I have discovered over that period of my practice as a coach and scrum master is that product ownership is the weak leg of the triad of Scrum roles.  We spend plenty of time making scrum masters and developers better, but we still struggle with the purpose of the product owner.  I suspect this is because as a former technical professionals scrum masters and developers speak a similar language.  Product ownership is different in experience and expectations.  It is why it is the weak leg because it is so radically different to slinging code.  It is why I want to talk about “healthy ownership” on my blog this week. 

The notion of “Healthy Ownership,” was constructed when I attended the Agile Coaches Retreat in London this summer.  I had just finished a contentious sprint planning session before getting on a plane to England where a product owner questioned the estimates of the development team.  It was a gross breach of the social compact of agile.  The product owner protested, “They did something similar last sprint, I thought they would be faster this sprint.” Typically, I do not want to drink bourbon at the office, but at that moment I was sorely tested. 

I brought this and other examples of bad behavior to the other coaches.  I pleaded with them for help. Others had similar challenges and solutions.  The truth was they did, but no one had come up with coaching techniques that would help them rectify the situation.  Like any other self-organizing group of individuals, we came up with a team to address this situation.  We had numerous people with different perspectives from former developers to project management professionals who were attempting to instill professional practices in their organizations. 

We had three goals: 1) open dialog between team members, 2) increased empathy between team members, and 3) collective ownership of outcomes.  It was not going to be easy.  We did discover that we could combine coaching techniques to gather information and come up with scenarios for common pain points.  From there we could collect data and try to inform and persuade others on how to approach situations.  It is not a script or prescriptive but more like a way to practice common coaching techniques with common problems on agile teams.  It is not perfect, and we are still forming approaches, but for the rookie coach or scrum master, it acts as a safety net.

Flash forward to the Agile 2018 conference, and I heard other people discuss their challenges in getting buy-in from product owners and developers.  It is why I am grateful for Alex Sloley and his discussion about transplanting the brains of product owners and scrum masters.  By shifting the roles of a scrum master and product owner, we get to “walk a mile in someone else’s moccasins.”  The product owner understands the challenges of the scrum master and developers while at the same time the developers and scrum master understand the challenges of the product owner.  It was a nice juxtaposition, and I will use the term “backlog coaching” in my practice for the rest of my career. 

So to me, “healthy ownership,” means putting yourself in another person’s situation and understanding the unique challenges they face.  It means that it may be necessary to do a “brain transplant” or less drastic measures for people to understand what is going on in the development process.  Product ownership is the weak leg of a scrum team, but it is because coaches and scrum masters do not pay enough attention to the role and how to make it better.  It is why I am going to be spending more time with my product owners and walking a few miles in their moccasins.  With a little luck, I will reduce the stress on my development teams and improve the performance of my product owners.

Until next time.