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. 

Let Your Employees Work from Home

From time to time, I like to call out bad behavior in the business community.  I don't particularly appreciate doing it, but when people behave poorly or say things that need challenging, it is the responsibility of people like me to call attention to it.  This week, billionaire hedge fund manager Ken Griffin gave a speech at the Economic Club of Chicago and said young people are hurting their careers by not returning to the office.  I respectfully disagree and want to point out that a net worth of 21 Billion dollars does not equal wisdom. 

Mr. Griffin is hugely successful, and he has offices in Chicago, New York, and across the globe.  He has one of the most significant hedge funds in the United States, so when you have that level of wealth and power, people like the Chicago Economic Club are going to give you a forum to speak.  According to Bloomberg News, he said, "So for our youngest members of our workforce, I'm gravely concerned that the loss of early career development opportunities is going to cost us dearly over the decades to come." I disagree; if we work in the global economy, we need to think differently about asking people to work at a corporate office.  

Workers are going to time-shift working with teams in India and Asia.  Thanks to tools like Zoom, Microsoft Teams, and Slack, they do not need to come into the office to have those meetings.  In addition, people who work at home can avoid commuting expenses, and the savings in both time and money tends to increase productivity from the workforce.  Finally, the last 18-moths of work have proven that professional workers can do what they do from anywhere in the world.  

I suspect that Mr. Grifin is more interested in exercising control over his workforce than the personal development of younger people in his organization.  Why?  Because he runs a multi-billion dollar hedge fund and thinks it gives him absolute power over the people who are delivering value to his organization.  It is a common form of arrogance that the wealthy have regarding the people who work for them.  

Griffin can run his business, however, he chooses, but it is clear that it is a conformist place that stifles innovation and creativity.  I am confident he enforces a dress code in the office and likes to keep up appearances for his clients or competitors.  The offices he is eager to populate with his workforce are a stage to show off his wealth and power to future investors.  

Mr. Griffin then chides other CEOs for being soft because they are not mandating their workers to return to the office.  The reality is companies are struggling to retain workers because they want to work from home. The great resignation is a reaction to businesses that will not allow them to work from home.  Workers are voting with their feet, and CEOs are not being scared; they are smart.  The global talent competition is such that if you do not offer a hybrid model for working, your competition will poach talent from you.  

I have repeatedly said that workers are not resources, and treating people like machine tools who can be used up and thrown away is a recipe for failure in the 21st century.  Mr. Griffin's wealth insulates him from that reality, but that does not mean people like myself cannot call out his lack of vision.  It will only be a matter of time before that reality catches up with him or his descendants.  

Until next time. 

Dealing with the Darkness of Dependencies

As agile professionals, we learned early in our careers that agile is easy to explain but difficult to practice.  For instance, agile talks about individuals and interactions in the manifesto but does not discuss how to help a development team member going through a contentious divorce.  The manifesto also does not talk about deadline pressure or the weirdness of the project budget process.  Lewis Carroll, who wrote "Alice in Wonderland," said, "Between the idea and the reality lies the shadow." As a coach or scrum master, you spend plenty of time in the shadow.  Today, I want to discuss a particularity dark subject in agile: dependencies.  

The scrum guide is clear about the organization of work.  With the help of a product owner, self-managing teams should work with the business to deliver value in rapid increments.  Backlog items are created, prioritized, and worked on during a sprint.  If everything goes well, then the team should have working code to go into production at the end of the sprint.  It is a fantastic concept, but the organization of most corporate systems plunges teams into shadow.  

People outside the purview of the scrum team often control the web or database servers, and the group becomes dependant on others who have a different set of priorities.  These priorities do not align with sprint goals.  A developer or scrum master then wades through the politics of getting servers provisioned with the correct configuration and security permissions.  The experience is a hassle and often throws off the team's timeline, undermining the rapid delivery of value to the customer.  

I hate dependencies like this with a passion that borders on pathological, and it was a hatred that blinded me to mitigate these situations for five years of my career.  Once the rage and frustration wore off, I discovered that a dependency is a story in the backlog; if it is incomplete, the team can escalate to leadership.    

I worked on a project where the server team did not configure the webserver to allow Azure DevOps to deploy code from a pipeline.  It is a mighty cool feature from Microsoft and saves loads of time deploying code to different servers.  One day a sprint ended for my team, and the server team did not configure the webserver.  Instead of showing code in a development environment, we demonstrated the software on the test environment, which returned an HTTP 404 error.  The leadership was scandalized and asked why nothing got done during the sprint.  I produced a work ticket with the need for the configuration of the server. The team shared e-mail messages, text messages, and corporate paperwork to get the server online.  We also showed that the server team did not respond to our inquiries for three weeks.  Based on this information, leadership made a few phone calls and addressed the problem.  The server team configured our server correctly the next day.  

The moral to this story is document dependencies in the product or sprint backlog.  The approach creates a quantitative technique to measure how long it takes people outside the team to complete work.  Transparency and openness are tools to help the team and its leadership better address organizational impediments. It works for small projects of one group or giant enterprise solutions with hundreds of developers.  

Dependencies are a shadowy subject, but if you document them in the backlog and are transparent about their impact on the project, you will have a way to overcome these organizational hurdles.

Until next time.