Merry Christmas

It is Christmas day.  This year has been a whipsaw of emotions.  In that time, I have shared the wisdom I have gathered.  Thank you for reading along and joining in the conversation.  I am going to take some time off away from the office and spend it with family.  The New Year is going to be filled with excitement and I look forward to sharing it with you. 

Have a happy Christmas and until next time. 

Some Thoughts About the Holiday Rush

A little holiday rush

It is the final rush of 2017.  The business is pushing to squeeze as much profit out of the holiday season while the technical professionals are scrambling to bring on-line systems promised by the executive team.  It is a busy time and filled with pressures both personal and professional.  I find it hard to cope with this strain.  You spend time keeping the commitments of others and struggle to use the difference supporting family and friends.  This week I want to make sense of the holiday rush. 

For as long as I have been a business professional, the one motivation I have seen in business is fear; visceral, cold, unforgiving terror.  It is the anxiety that you are not hitting your sales figures.  It is the panic of the payroll system not interfacing with the accounting software.  It is a shame that comes with a sixty hour work week not being enough to deliver what your manager promised. 

The reason I became so enamored with agile and scrum is I wanted to work without fear.  I have been fired the week before Christmas.  My spouse left me because I finished up a consulting contract early.  Each meeting with quality assurance or my manager triggered spasms of fear.  There had to be a better way.  Agile and scrum provided a means to do things differently and escape that fear.

I have been in the agile practice for eight years.  I have had tremendous successes and bitter failures.  I have lost countless hours of sleep and overeaten junk food.  I have struggled against organizational inertia and corporate indifference.  I would not change a thing because the changes I have made mean that one less developer is living in fear.  That makes it a worthy goal. 

So as I fight crowds to get my shopping done and stay up late to ship software on time; I understand the sacrifice and frustration I put in for 2017 is worth it.  There is a little less fear in the office.

Until next time.

Food Trucks and the Theory of Constraints.

The food truck can teach us about theory of constraints

In the global economy, events are moving at the speed of light.  An order placed in Singapore triggers a cascade of events in Tokyo and then at the corporate headquarters in Chicago.  Technology makes this kind of speed and accuracy possible.  To many people who use this technology, it is like magic.  To people who build and maintain these systems, it is hard work.  So the biggest challenge of our time is how to balance the desires of people who think technology is magic with the reality of innovation being hard work.  This week an introduction to the theory of constraints and what it means to a scrum master.

I have been reading a book entitled, “The Goal: A Process of Ongoing Improvement,” by Eliyahu M. Goldratt.  It puts the reader in the shoes of a plant manager of a failing company.  His wife is unhappy with all the responsibilities he has which keep him away from his family.  His boss threatens to shut down his plant in 90 days.  He is also dealing with his children and his aging parents.  It is a trifecta of stress which would grind down any person. 

The main character has to juggle these competing demands on his time and energy while confronted with the collapse of his marriage and loss of his job.  He decides to concentrate on saving his job to provide for his wife and family.  Over the course of the book, the protagonist learns about the theory of constraints and how to use it to save his plant.  I will let you find out for yourselves if his marriage survives. 

I am personally surprised that I did not get exposed to this idea sooner in my career.  In layman’s terms, the theory of constraints posits that a system can only operate at the speed of its slowest sub-unit.  For instance, if you have a food truck, you have someone taking orders, someone doing food preparation, and someone plating finished products and delivering them to customers.  I realize that this example features a crowded food truck but stay with me.  The cashier can take an order every two minutes.  The owner can prep food for about 10 minutes per items on the menu.  Plating and delivering food takes five minutes. 

In this simple example, it is clear the slowest part of the process is preparing the food.  If there are ten items on the menu, it takes 100 minutes or almost two hours.  If done in a just in time fashion, then it takes 10 minutes.  So, a busy developer visiting the food truck outside of the office has to wait almost 20 minutes to get a meal.  This kind of service would put the food truck out of business.  The bottleneck is food prep.  Most food trucks avoid this issue by doing food prep in advance.  It reduces meal time from 20 minutes to seven. It is a major improvement, and it might keep the food truck in business. 

As a scrum master, it is important you recognize the bottlenecks which slow down the flow of value through the organization.  Are product owners not writing stories?  Are developers not doing test-driven development?  Maybe the release process is taking too long.  A good scrum master will figure this out and try to smooth worth through the system. 

The theory of constraints contains plenty of mathematics and ways to measure flow through the system, but the general idea is to find the slowest part of the system and maximize it to find the slowest part of the system and maximize its output while preventing work from stacking up before the bottleneck and slack gathering behind it.  Like many discoveries in science, engineering, and project management it is pretty simple once we understand it. 

Until next time. 

That awkward talk about scaling

Portrait of a Scrum
Master as a young man.

When the signatories of the agile manifesto got together sixteen years ago, they had no idea what they created would be the basis for a reformation in the business community. I have been part of the agile movement since 2009.  I am a short timer.  During my brief agile practice, I have noticed a trend.  Software projects are getting bigger, and it is becoming increasingly difficult to lead these projects.  This week I want to talk about scaling agile as software eats the world.

When I first learned about agile and scrum, I felt like the apostle Paul on the road back from Damascus.  It was like being struck by lighting and seeing the world for the first time.  The team did work in sustainable chunks.  Stakeholders would receive rapid feedback about how the project was going.  If something was wrong, it could be escalated quickly up the chain of command.  The ability to create software would become more sane and human.

I was deeply deluded.  I did not count on the ingenuity of my fellow software developers to avoid work.  I was blind to the inertia which exists in the modern corporation which rejects new approaches to solving problems.  Finally, executives and financial professionals see agile as a threat because it undermines their need for command and control.  Confronted with these realities, agile and scrum became a means to help small teams ship software promptly.  As individual groups became successful, management began paying attention.  Soon entire Agile consulting teams sprang up offering Scrum Masters and developers who could rapidly bring software to life.  For three years, everything was going well, until enterprise software application attempted to be agile.  It was 2012 and agile hit awkward puberty.

Software teams would be sprinting at different cadences.  Some teams would be sprinting every three weeks while others would be on a two-week cycle.  Network teams were not even sprinting and would treat requests on a first in first out basis.  Finally, the marketing team would be making promises which others would have to keep.  I and others would ask, how do you scale Agile across multiple groups and projects with hundreds or thousands of developers?

The answer has fractured the agile world into three camps; scaling with scrum, SAFe, and LeSS.  I have received formal training in scaling with Scrum and SAFe.  I am looking forward to attending LeSS training in the new year.  Each camp is involved in a friendly rivalry with each other.  Each approach seems to be dealing with project scaling differently.

My first exposure to scaling agile was called, “scaling with scrum.”  The approach was very organic.  As an organization grew, the backlog of work would splinter into smaller backlogs.  These backlogs would then be delegated to teams and completed. In the end, these smaller backlogs would bubble up into a “master backlog,” so that leadership could track what was happening.  I liked it, but it did require plenty of administrative work.  It also assumed that everyone was in perfect communication with everyone else in the organization.

My next exposure to scaling came from the world of SAFe.  This framework has caught on with more prominent organizations because it has a command and control structure which is very familiar with executives.  Scrum Teams bubble up into release trains, and those trains have particular departure dates.  Networking, Software, and Hardware all obey scrum or a Kanban approach to work.  Leadership over three or four sprints then witness a “product increment” and inform what direction to take next.

I like SAFe.  It feels like a good marriage of agile and corporate structure.  I see three principle drawbacks.  First, executives can maintain a top-down approach to innovation and control of the software process.  Next, SAFe depends on quality Product Ownership, and this is the weakest area of the agile movement.  Finally, working in a SAFe development environment feels like being a cog in a giant wheel.  If we can figure out how to mitigate these issues, then SAFe might be the future of agile.

As an agile coach and scrum master, I have borrowed liberally from the scaling frameworks.  One of the tenants of the Agile Manifesto is, “…responding to change over following a plan.” So I found it necessary to incorporate elements of SAFe which work with those which can wait.  I use scaling scrum with scrum all the time in my agile practice.  I also rely on the suggestions and directions of my peers and management to get software shipped out promptly.

In my opinion, we are still in the awkward years of the Agile Reformation.  We are very good at shipping software from small teams, but when we try to scale to large multi-national corporations, we still have plenty of work to do.  Software is eating the world, and if we are not careful, it will consume agile and scrum.

Until next time.

Experience Matters in a Scrum Coach

Leadership experience is not pretty but necessary

Plenty of issues crop up in the day to day life of a scrum master.  Impediments need to be resolved and each day you are a living example of how Scrum is supposed to work.  As a fellow coach, Ryan Ripley remarked on how some individuals with little experience with agile are marketing themselves as coaches.  Ryan feels pretty strongly about the subject, and so do I.

There are two lines of thought about leadership.  The first school is called the “great man theory.”  This school firmly believes that great leaders are not made but are born.  This notion has been used for generations to support monarchs and other forms of tyranny.  For each leader born into greatness, there are numerous counterexamples of individuals who fall woefully short.  There is also an elitism and snobbishness associated with this school of leadership which says that only specific groups can aspire to leadership.  I also find this type of thinking has plenty of sexist and racist baggage associated with it.

The second school of thought is the notion that leadership can be taught just like any other skill.  I am a firm supporter of this idea.  When I was a teenager, I benefited from leadership training from Boy Scouts of America and Marine Corps Junior Reserve Officer Training Corps.  I had the Boy Scout Law ingrained into my personality at an early age.  The outdoor activities forced me to learn to help younger scouts cope with being alone and away from home for the first time.  Being caught in a rainstorm surrounded by wet and tired twelve-year-olds is a good measure of your leadership skills.

Marine Corps JROTC taught me self-discipline, my left form my right and that leadership is more about credibility than shouting at people.  I met some remarkable people.  David Ogle was a survivor of combat around the Chosin reservoir and a USMC boxing champion.  He served in Vietnam and became a Sergeant Major.  Richard Weidner was a company commander in Vietnam and taught me about the less than glamorous things leaders have to do.

Together, Boy Scouts and Marine JROTC gave me a good foundation from which to build.  I took that knowledge with me into the sales profession, the casino business, radio, and finally into technology.  I am entering the fifth year of being a scrum master.  The experience of shipping software at the end of each sprint changes a person and their style of leadership.  Working with offshore teams changes how you relate to others.  Those experiences make you a better scrum master and coach.

We can teach leadership, in my opinion.  I also feel experience acts as a multiplier of leadership skill.  A good leader does not ask someone to do something which they would not do themselves.  That means if you ask a developer to write a unit test you better be willing to write a few of your own.  An agile coach who has not led a retrospective or shipped code is not a coach because they lack the practical skills to make agile successful.  They are faux coaches, and you should steer clear of them.  An agile transformation is like performing a heart transplant on a person running a marathon; you would not trust that job to a first-year medical student.  Anyone can call themselves a coach, it takes time and experience to be a valuable coach

Until next time.

A Little Gratitude this Thanksgiving.

Mmmm Pie!

If you are working as an agile coach or scrum master you spend plenty of time working in negative situations.  Continuous improvement means finding things which are not working and helping others fix them.  It is an often a thankless process filled with personal and professional frustration.  This week I want to take a step back from my day to day struggles and reflect on the things which make me grateful.

I am grateful for the people who work with me.  I have developers spread over two continents, and they are smart and hardworking individuals who make my day easy.  The team accepts my faux cheerfulness in the early morning during stand-up calls.  The team also put up with my grumpy admonitions to follow good code practices.  The development teams I work with are a pleasure to work with, and any scrum master would be honored to work with them.

Next, I am deeply grateful to LSC Communications for allowing me to lead agile initiatives.  It has to be strange having an entrepreneurial person in your cubicles asking awkward questions and shaming individuals to do better work.  You embrace my enthusiasm and flakey nature to help make the organization better.  The world of business moves at the speed of the internet, and I am glad you allow me the opportunity to guide the firm in that direction.

I have an understanding group of friends.  I do not spend as much time with them as I should.  We play cards, board games and plenty of military simulations.  They keep me grounded.  They keep me clean and sober.  They have supported my professional decisions, and they have been there for me throughout the inevitable ups and downs of my career.

My family generates a fountain of gratitude.  As my parents have grown older, I have become close to them.  They show me the kindness and support that is sorely lacking in the other areas of my life.  In the aftermath of my divorce, they have prevented me from wallowing in loneliness and made sure I bought groceries.  I wish I were half as good as my parents.

In spite of all the difficulty of my career, I have a lot to be grateful; my colleagues, my company, my friends, and family make life worth living.

Happy Thanksgiving until next time.

The tribalism hurting your agile practice

My Agile Practice has changed over the years.

It has been a strange year.  Last year, I was talking about comfort food and sleeplessness.  Three hundred and sixty-five days later, I want to share a little wisdom I have gained along the way.  This week how disappointment can make you a better scrum master. 

I have deliberately not discussed politics on this blog.  The internet is filled with plenty of places on the political right and political left to discuss current events.  I have plenty of strong opinions myself but do not share them here because they are not germane to the discussion of Agile, Lean, and Scrum.  The world of business transformation is hard enough; injecting partisan political views seems counterproductive to me.

I come from the world of college debate and forensics.  It is a community centered in the “reality-based,” zones of academia, science, media, and government.  It is a skeptical community which relies on empiricism and rhetoric to persuade others. These same institutions are referred to by political conservatives as pillars of deceit.  A year ago, my smug self-assurance in my expertise took a severe beating. 

Over the last year, I have gotten much wiser.  I have rededicated myself to my profession.  I shut down my internet startup.  I even made an effort to listen to Nickelback to see if there was any merit to their music.  Suffice to say; it was the audio equivalent of eating chocolate frosting out of a tub with a spoon; including the stomach ache. 

The most significant notion revealing itself to me was the concept of epistemic-tribalism.  I felt that if you are “reality-based,” and gave people the facts of the situation, they would eventually come around to your point of view.  If this formulation was good enough for Socrates, then it was good enough for my agile practice.  I now realize this was naive.  People have deep emotional and political biases.  Stating the facts is not good enough.  When confronted with facts that contradict their worldview or place in the world, some people will reject those facts.  It is similar to the ideas of Wittgenstein who explained language was a construct and subject to games.  Furthermore, two people can look at the same object and see two different things.  The neat and tidy world based on objective reality and evidence fell away replaced by an effete world of conjecture resembling a postmodern literary theory class.  It was disorienting. 

If epistemic tribalism can happen in the realm of national politics, it is not too far of a stretch to see it manifest itself the cubical of an office.  Personal relationships are more important than sales.  Countless Quid Pro Quo agreements bind the office together and harm customer service.  Tenure with the organization is more important than accomplishment.  Finally, being likable is more important than getting work done.  It became clear to me that these things were happening.  I counted on the better angles of others instead of understanding the tangled webs of motivations.  To be a successful scrum master or agile coach, I had to accept office professionals could be nasty and brutish. 

So this last year for me, the political became professional.  Reason and empiricism are less useful tools for change compared with understanding the motivations and prejudices of my colleagues.  Epistemic-tribalism is a real thing, and you need to understand it in your organization.  Finally, it takes disappointment for you to set aside your prejudices and view your surrounding differently.

Until next time.

Agile is about Deadlines

I have nothing on Martin Luther
but I know a little about software development.

Five hundred years ago a German monk named Martin Luther hammered 95 theses to a church door.  He was calling attention to corruption inside the Catholic Church and started the events which created the protestant reformation.  The agile manifesto is only sixteen years old, but it has produced a transformation in the business world.  I consider myself one of the evangelists spreading the word.  With every reformation, there is a counter-reformation, and today I would like to discuss one of the principle objections used by opponents of agile.

There is an excellent blog post written by the Wall Street Journal called “9 Myths About Agile.”  I strongly recommend it.  One of the most durable myths about Agile is the preconception that deadlines do not matter. Work gets completed, and deadlines are not necessary.  I wish to argue that deadlines are an essential part of the agile process and provide an example of how it works.

The most central feature of Agile and Scrum is the time box of the sprint.  For two to four weeks, the development team completes goals.  If they do not finish the stories in that period, then the sprint is considered a failure.  Failure is not a bad thing it is a learning opportunity for the team can to do better next time. Scrum relies on deadlines to focus effort and drive improvement.

Skeptics would then argue that sprints are well and good, but there are not firm due dates to communicate to upper management or the people paying for the work.  My reply is that with a sprint backlog following Roman Pichler’s DEEP model, it is easy to forecast when work will get completed.  The backlog is detailed to show the volume of work.   The backlog is estimated because it allows the product owner and the business to predict when work will get done.  The backlog is emergent so it can adjust to changing conditions as a project moves forward.  Finally, prioritization allows the firm to say what matters and what does not.

I am now going to provide a simple example.  The marketing department needs to incorporate social media into its website.   The works need to be accomplished by November 1st. The product owner gets to work, and come up with a list of features.  It should look like this:

• Milestone: Social media on corporate website (Due Nov 1st)
  • Feature: Facebook
  • Feature: Google+
  • Feature: Twitter
  • Feature: Pinterest

Now it is up to the Product Owner and development team to write stories.  After a week or two of effort the backlog looks like the following:

• Milestone: Social media on corporate website (Due Nov 1st)
  • Feature: Facebook
    • Set up a Facebook account.
    • Create Hooks into Facebook API.
    • UI for Social media on the page.
    • Create log internally when pages are shared.
  • Feature: Google+
    • Set up Google+ corporate account.
    • User Google tools to allow sharing of stories from the website.
    • UI for Social media on the Page.
    • Create log internally when pages and shared.
  • Feature: Twitter
    • Set up a corporate Twitter account.
    • Use Twitter API to post content.
    • UI for Social media.
    • Create log internally when pages are shared.
  • Feature: Pinterest
    • Set up corporate Pinterest account.
    • UI for Social media.
    • [Spike] prototype how to use Pinterest API.
    • Create a log when pages are shared.

The backlog looks typical to a scrum master or anyone on a development team.  The Vice President might understand what the group plans to do. The group estimates with story points because business people treat hours estimates as quotations of work.

• Milestone: Social media on corporate website (Due Nov 1st)
  • Feature: Facebook
    • Set up a Facebook account. - 2
    • Create Hooks into Facebook API. - 3
    • UI for Social media on the page. - 3
    • Create log internally when pages are shared. - 13
  • Feature: Google+
    • Set up Google+ corporate account. - 2
    • User Google tools to allow sharing of stories from the website.- 3
    • UI for Social media on the Page. - 3
    • Create log internally when pages and shared. - 13
  • Feature: Twitter
    • Set up a corporate Twitter account. - 2
    • Use Twitter API to post content. - 3
    • UI for Social media. - 3
    • Create log internally when pages are shared. - 13
  • Feature: Pinterest
    • Set up the corporate Pinterest account. - 3
    • UI for Social media. - 3
    • [Spike] prototype how to use Pinterest API. - 8
    • Create a log when pages are shared. - 13

The estimates from the team point out severe risk and ambiguity.  Also, the team has not worked with Pinterest, so they are going to do some experiments to understand how it works.  The sponsor of the product might get frustrated at this point and ask, “When will it be done? Can I have it by November 1st?”

The scrum master should be able to answer that question.  According to the backlog, there are roughly 91 story points of work.  The team can do 21 story points a sprint and each sprint is three weeks long.  It will take roughly twelve weeks to do the job. It is good news if it is June but bad news if it is September.

So a process of negotiation begins where stories get prioritized, and others ignored.  If the company sells food products, Pinterest may be more critical than Google+.  A media company which relies on breaking news might ignore Pinterest and focus on Twitter.  The product owner might notice that each social media site has its analytics suite and that an internal log is not necessary.  Fifty-two story points fall off the board.  We have 39 story points of work which we can get done in two sprints or six weeks.  If we begin in August, we will hit our due date.  The final board looks like this:

• Milestone: Social media on corporate website (Due Nov 1st)
  • Feature: Facebook
    • Set up a Facebook account. - 2
    • Create Hooks into Facebook API. - 3
    • UI for Social media on the page. - 3
  • Feature: Google+
    • Set up Google+ corporate account. - 2
    • User Google tools to allow sharing of stories from the website.- 3
    • UI for Social media on the Page. - 3
  • Feature: Twitter
    • Set up a corporate Twitter account. - 2
    • Use Twitter API to post content. - 3
    • UI for Social media. - 3
  • Feature: Pinterest
    • Set up the corporate Pinterest account. - 3
    • UI for Social media. - 3
    • [Spike] prototype how to use Pinterest API. - 8

So in this brief and simple example, I have shown there is a quantitative and drama free fashion to discuss projects where deliverables get negotiated, and deadlines get met.   Agile and Scrum can help people make educated decisions about what work can get done and when it will get done.  All that is required is a conscientious product owner, a dedicated development team, and a scrum master who will speak the truth to decision makers.

Agile is about deadlines, and I am willing to put my career at risk to prove it; just like that German Monk from five centuries ago.

Until next time.

It is time Agile crushes magical thinking in business.

Working in Technology is like taming a dragon.

In the contemporary business world, one of the things which surprised me the most is how divorced people are from the technology which their careers depend upon.  Arthur C. Clark, the author of “2001: A Space Odyssey,” said, “…and sufficiently advanced technology is indistinguishable from magic.”  Today, in a world moving at the speed of the internet, tens of millions of people are wandering the world behaving like magicians.  I want to talk about what this means for you the scrum master or agile coach. 

At the click of a smartphone, a human being can summon a ride, book restaurant reservations, order clothing, and find potential romantic partners.  News and gossip travel around the globe.  We can even live in virtual spaces reshaping our bodies ignoring concepts or gender and aging.  Thanks to the world of technology and algorithms we can live in a curated rich world where there are no opposing opinions and everything is quick and convenient.  It is a seductive world. 

The world I describe is the product of millions of hours of labor and the application of fifty years of merciless engineering to make systems better, faster and cheaper.  It is the application of silicon wafer technology, advanced mathematics, and smart people doing smart things.  It is the unwritten story of our time.

Now imagine people who live in the magical age who want to implement a new payroll system or create a better way to get products to customers.  Since they are accustomed to systems which are quick and compliant, they think it is possible to spin up systems which behave the same way with the speed of downloading a phone application.  These magicians take it for granted that the data will always be correct and they do not need to proofread the work. 

This is not the reality of technology.  Developers need to get involved, and they need to be managed, so the code is clean and scalable.  Data needs to be placed on Oracle or Microsoft SQL servers.  Network accounts need to be created, and all of this costs time and money.  It is not magic.  It is hard work.

As a former web developer, it always troubled me when people told me how they expected a website to look and behave without understanding a lick of HTML code.  It is my experience these individuals rise in organizations and get budget authority.  So you have the ignorant paying the bills while someone more ignorant is giving orders to the development team.  It falls to a technology lead or scrum master to transform ignorance and magical thinking into code.   It is just as disheartening as it sounds. 

It is also why so many technology projects fail because the people involved do not conceptually understand the labor it takes to get the job done.  A construction project is easy to understand compared to a software project because the people paying the bills realize what is happening.  A typical business person does not understand the difference between Java-script and JAVA; so how are they going to know what it takes to successfully construct a web application.

As a scrum master, it is your responsibility to crush magical thinking.  Tell the truth about how long it is going to take to get something done.  Show people work in progress and ship code periodically so if adjustments need to be made they can happen in a timelier manner.  You will have to say no, and you will have to create trust between the development team and business.  This means enforcing one of the central tenants of Agile; their business sets the project priorities, and the development team says how long it is going to take.  If this social compact is not upheld, then any agile implementation will collapse into dust. 

So in this magical world, it is up to the scrum master to create a much-needed dose of reality.  Otherwise, you are confronted with an evil magic act which does nothing but disappoint. 

Until next time.

Product Owners Need to do the Damn Job.

A product owner and scrum master
should be equal professionals committed to the same goal.

I have spent the last two weeks talking about technical debt.  It is an important topic to me and has been a significant issue during my career.  My agile journey has had three themes; mitigation of technical debt, organizational change, and teaching product owners to be more successful.  This week I want to talk about product ownership. 

The most significant frustration of my career as a scrum master and agile coach is how I have been unable to work with a real product owner.  I am spending most of my time training former business analysists on how to do the job or working with someone who is doing the job in a “part-time” fashion.  I even had a product owner say they were not responsible for software delivery just requirements.  This kind of experience causes me to consume alcohol and have an unhealthy relationship with food.

I learned that this was not just my grievance.  At the Agile Coaches Symposium in Chicago, a common point of discussion was the state of product ownership.  On the last day of the conference, I hosted an open space where I asked other coaches what I could do to improve the performance of my product owners.  It was a good discussion, but we centered on theory rather than practical approaches. 

I hit my emotional wall when I asked product owners to prepare a list of stories for the developers, so they do not go into sprint planning unprepared; the product owners greeted me with blank stares and then complaints I was creating “busy work.”  It was at that moment when I realized agile, and scrum could not change lazy or ambivalent business partners.  I wanted to scream. Since that moment I reviewed my blog post about the difficulty of being a product owner.  I also took time out to reread Roland Pilcher’s book on product ownership.  Being a product owner is the most challenging job in Agile, but it is still a job.  As a professional, you should aspire to do it well.

An agile team with a lousy product owner is like an airplane with a weak pilot.  You might reach your destination, but there is no guarantee you will arrive safely and in comfort.  An inferior product owner is not going to deliver business value, and they are going to miss numerous deadlines.  It makes it the interest of your organization to make product owners competent and capable.  If the people tasked with the responsibility are not interested then someone else needs to fulfill the role.  If not, your organization deserves a spectacular crash. 

Until next time.

The fatberg in your organization

This is grotesque monster is lurking in your organization

Last week I shared some thoughts about technical debt.  It is a pretty important topic because plenty of organizations are dealing with the repercussions.  As a scrum master and coach, you will have to navigate this treacherous territory because in the world of enterprise technology you are often attempting to update systems while trying to keep the business running.  I liken it to performing heart by-pass surgery on someone running a marathon. 

To illustrate the damage of technical debt, I point to the city of London.  It is suffering from a particular problem which is grotesque and illustrative of legacy systems.  A “fatberg,” is clogging the sewers of the city.  Over the length of the tower bridge spanning the Thames River, it weighs several thousands of metric tons.  Composed of fat, condoms, towelettes, and sewage, it is a drain clog of biblical proportions.  City officials concede that if the object is not broken up, it will cause the sewers on the cities east end to back up.  Combine a sewer system first constructed in the 1750’s with twenty-first-century human waste you create a “fatberg.”  It is a perfect metaphor for technical debt. 

The sewer system was not designed to scale to accommodate a population of over 8.5 million people.  Making matters worse non-biodegradable towelettes and latex condoms did not exist in the 18th century.  Finally, human behavior changed with people dumping their cooking fat into the drain instead of recycling it for soap and further cooking.  The result is one of the most repulsive examples of human waste created by humankind. 

There is no easy fix for this disaster.  Workers are spending time breaking up the “fatberg,” and civil engineers are attempting to find ways to prevent this environmental abomination from happening again.   Some of the problems can be mitigated by banning moist towelettes which are not bio-degradable.  That is still not going to prevent people from dumping cooking fat down the drain unless the government can come up with a program to recycle it.  Such a recycling program would rival what happened in the United States during the Second World War.  We have also not come up with a decent substitute for latex condoms. 

The depressing reality of this situation is similar to what happens every day in a fortune 500 company.  Bad data pollutes systems, and that data requires teams of professionals to organize and understand it.  People exchange excel spreadsheets via e-mail with no change management or concern for security inside an organization.  Finally, countless human hands are used to bill, invoice, and collect money from customers.  It has all the making are a “fatberg.” 

I am a lonely voice in the wilderness about this issue, but continuous improvement depends on the removal and mitigation of technical debt.  Otherwise, your organization is going to confront its own “fatberg,” and it will not be pretty.

Until next time.

Fix Technical Debt NOW!

Technical debt is a lot like leaky pipes

I am very fortunate to spend time with smart people.  The day goes by faster when you spend it with intelligent and capable people.  One of those talented people is a former colleague of mine, Larry Gassik.  He was asking me a few questions about technical debt, and it occurred to me that I have not shared many of my thoughts about it on the blog.  Technical debt is becoming a growing concern in the agile community as more teams expand into enterprise systems and confront legacy code.  This week a brief conversation on technical debt.

When I think about technical debt, I use the metaphor of plumbing.  Indoor plumbing has existed since Roman times, but its innovations only became global in the 20th century.  Thanks to plumbing, the spread of cholera have ended.  Indoor plumbing has given millions of people clean drinking water and helped reduce pollution.  Plumbing is so ubiquitous that the only time we notice it is when it is not working.  When a toilet backs up or a pipe bursts, we become very aware of the effects of plumbing on our lives.

The “if it isn’t broke don’t fix it,” attitude we have about plumbing is prevalent in the business world.  Many business professionals in the corporate world are focused on shareholder value and profitability.  When business professionals think about technology, it is either an expense or inconvenience.  It is why many organizations have not made the switch to cloud-based systems and use old versions of Microsoft office.  To them, the investment of money is not worth the rate of return.  The reality is that not paying attention to older technology systems is just as negligent as ignoring the maintenance of your home; you risk broken pipes and greater expenses caused by water damage.

The technology of pipes and plumbing has changed over the centuries to be safer and less expensive.  In Roman times, pipes were lead.  The contaminated drinking water caused outbreaks of “Saturnism” which was a polite term for lead poisoning.  Terracotta pipes followed, but those broke down over time thanks to tree roots and natural decay.  Iron pipes came along, but they were brittle and caused water to be rusty.  Copper pipes came along and have been a good solution, but they are expensive and require welding which creates maintenance a problem.  Today, most new construction relies on PVC pipes because they do not corrode, are inexpensive, and easy to maintain.  If the materials of plumbing can change so radically, image what is happening with technology moving at the speed of the internet.

Forty years ago, while the Sex Pistols were singing “Anarchy in the U.K.” there was no personal computer market in the United States.  Microsoft and cellular phones did not exist, and a modem was fast if its speeds were 300 bits per second.  Mainframes dominated computing, and most business transactions were done over the phone or in person.  Compare that business environment to smartphones, personal computers, and Gigabit speed internet we have today.  There is no credible way the technology of 1977 could support the needs of business today.  The difference between the needs of the firm and the ability of the technology to support the business is something agile professionals call technical debt.

Technical debt is cancer threatening to metastasize and kill the business.  Here is how it happens.  Slow or ineffective systems undermine customer confidence.  Weak confidence means less use and less use guarantees less money for the company to maintain the system.  Less money translates into slower time to market for new features and updating the system.  It means employees and IT professionals will take shortcuts to bypass the pokey system.  With the system jury-rigged to address business problems, it becomes more expensive to maintain, and improvements take longer to roll out.  Finally, you create a situation where the system fails, and it does not provide benefit to the business.  If you pay attention to the technical debt, you can avoid this kind of failure.

A business with significant technical debt will have trouble attracting talent.  Computer professionals being smart, know what technologies the market supports, and they are terrified of having skills which are obsolete.  It means they will gravitate to businesses and projects which have a smaller portion of the technical debt.  It also means that college graduates will avoid working for companies with old technologies.

Technical debt is the difference between what the business needs and what they technology systems support.  If you do not address technical debt, it is a threat to the success of the firm.  Finally, the mitigation of technical debt is no different than routine household maintenance.  Do the right thing and focus on technical debt before the pipes burst in your business.

Until next time.

Sharpening the Saw at the Agile Coaches Symposium

Billie Schuttpelz and I at the Agile Coaches Symposium

One of the seven habits of highly successful people is called “Sharpening the Saw.”  It is taking time off for self-care and personal development.  I took time off from the blog and spent some time at the Uptake offices for the Agile Coaches Symposium in Chicago.  It was a great time and a valuable learning experience.

Working as a scrum master and agile coach is often a lonely duty.  You are spreading the word and sharing information with a skeptical audience.  Business and cultural forces often impede the agile maturity of the organization.  As a coach, you are spending your time serving as an example to others.  It is why it was nice to spend time with others in this profession and exchange information.

A few themes cropped up during the conference.  First, over 80% of the people at the conference said that had suffered from Impostor Syndrome.  It surprised me because when I have moments of doubt and disappointment, I chalked it up to something else. It is clear that those moments of darkness are Imposter Syndrome rearing its ugly head.  We did not have any easy answers to these issues, but it was still helpful to discuss them out in the open with others.

Next, there is a trend in the business world for Project Managers and other waterfall types of people to falsely brand themselves as agile coaches.  These falsely branded coaches create plenty of situations where people without experience or the personal qualities of coach try to bring agile to organizations.  The aftermath is typically a poorly applied implementation, and the agile movement undermined.  Collectively, we felt that some level of exposure and experience with agile was necessary to help coach others.  The consensus of the group was that a good coach, “Wares the shoes and can talk about the walk.”  So be on the lookout for agile coaches who cannot find comfortable shoes to wander around the office.

There were plenty of other discussions.  I even had a chance to talk about how my notion of story points have changed during my career.  The best part is spending time with other agile professionals and learning from them. If that is not sharpening the saw, I do not know what is.

Until next time.

Planning is Everything

This scrum master
wants to be more like Ike.

It takes plenty of emotional energy to be a scrum master or agile coach.  Developers need guidance, product owners need constant coaching, and upper management is always asking for status updates.  It is psychologically exhausting.  Along with day-to-day chores, you are planning and setting strategy.  This week I want to discuss how planning and responding to change are not mutually exclusive.

According to the Agile Manifesto, responding to change is more important than following a plan.  Situations in technology are changing at a rapid clip and an idea that seemed plausible an hour ago can be hopelessly out of date.  Agility depends so much on responding to change.  The unintended consequence of this is business leaders abandoning planning altogether because “We are doing agile we don’t need plans.” Let me try to add a little sanity to this discussion.

The manifesto states, “…while there is value in the items on the right, we value items on the left more.”  Planning has some value and should not be abandoned because we are responding to change.  It seems like a contradiction.

Planning is an integral part of agile.  A scrum team does sprint planning before the start of a sprint to decide what they are going to do.  The product owner does release planning to prioritize stories in the backlog.  A plan makes it possible for an agile team to understand the nature of the problems they are trying to solve.  It also allows them to learn how to respond to change when the inevitable happens.  It explains why Dwight David Eisenhower said, “Plans are worthless, but planning is everything.”  When a team plans they are going over possible scenarios which might happen during a sprint.  The team is also doing much of the analysis necessary to start writing unit tests and code.

To use a metaphor from music, Jazz and Blues musicians still rehearse even though much of their music is improvisational.  The players outline key progressions and cords they are going to play.  It is the plan they use for their performance.  Once the concert begins, situations may dictate a deviance from the scheme.  Thanks to the outlines figured out during the rehearsal, these musicians can respond to change.  The same thing happens to a development team during a sprint.

So responding to change is important but you cannot respond to change unless you have spent some time planning to understand what changes might happen.

Until next time.

When a team fails.

Failure Stinks!

I continue to assert that software development is one of the most misunderstood professions in the business world.  Numerous executives think what we do is magic or do not understand the creative nature of the activity.  It is not like working on an assembly line or collecting accounts payable.  There is plenty of uncertainty and opportunities for failure.  As a scrum master and coach, you have to deal with the failure of your agile team along with the personal failures that inevitably crop up in your career.

The saying in the agile community is that you should “fail early and fail often,” because failure is a brutal and efficient means of learning.  The notion of failure conflicts with the “cult of success” preached by motivational speakers.  It also contradicts notions of winning promoted in sports journalism.  I believe the failures in my life and career have made me a better person.  I also feel these failures were necessary milestones on the road to the success I have had in my life.  Failure is painful, but it does put into perspective the ups and downs each of us have in this life.  

Part of the educational process is owning up to and taking responsibility for those failures.  When your team fails to deliver software on time, you have failed.  It is incumbent on you understand what you did wrong and how to avoid the same mistake in the future.  There are situations where you do not have much control, and you still are confronted with failure.  It is unfair and unjust, but accepting that position and learning how to deal with it next time may lead to success in the future.

The acceptance of failure also does something else; it wins the respect of others who have been through the same experience you have.  You have endured the same hardship as others and have accepted responsibility for your shortfalls.  If you blame others or do not assume liability for failure, it will undermine your credibility as a leader and destroy teamwork.  I witnessed this first hand and could see collective eyes rolling as this individual began to speak.

So as a scrum master and agile coach, accept failure and take responsibility for it.

Until next time.

Admitting personal failure

I failed.  I will get over myself.

There is a saying in the medical profession, “When God puts his hand on the left shoulder of a patient, take yours off the right.”  The meaning being that patients die and even the best doctor will have to accept that they cannot heal everyone.  This week I am leaving the University of St. Francis business incubator, and I am shuttering much of my start-up.  I want to discuss this on the blog this week.

Seven years ago, in the aftermath of my failed second marriage, I founded E3 systems. The goal was to create an online inventory management system which other small and medium sized businesses could use to manage their organizations better.  I wrote software non-stop for weeks.  I would sequester myself to focus on setting up business structures which would scale.  I had numerous arguments with my product owner who also happened to be my father.

I would run into various business situations like people expecting me to give them my product for free.  One potential client loved my work until they realized they would have to pay me.  I even did a classic Silicon Valley “pivot” writing software which handled fleet and equipment maintenance.  I flooded social media with youtube videos, tweets, and Facebook posts and information on my product.  I did everything with scalable technologies and paid for everything out of my pocket.  Sadly, I could not do business development and close sales.  As my advisor told me, I was a dilettante.  The business world rejected me with harsh Darwinian indifference.

I toughed it out for seven years.  I kept my day job and hoped someday I would pack up my cubical and go full John Galt.  The last two years have been a denial of reality.  I did not have a market for my products, or a means to sell those products.  I failed.

I am disappointed, but I have learned some valuable lessons.  I understand that I am pretty good at operations and project management.  My software development skills have dramatically improved including my use of SOLID and test-driven development.  I have been jumping on the chest of a dead business.  Everyone knew this but me.  Now that I have a moment of clarity, I see that now is the time step aside and accept its demise.

I will still be open for consulting and will be happy to continue Agile coaching but my days of selling software as a service are over.  I have a relationship with the Will County Project Acclaim which I will continue to support.  I am shuttering my cloud based software on September 1st.  I will keep this blog open because I still have plenty to share about agile and software development.

In the agile movement, we say, fail early and fail often. Failure is the ultimate learning experience.  As a failed entrepreneur of a startup, I consider this something which makes me a better leader, agilest, and software developer.  Once the disappointment wears off, I will be ready for my next act.  I suspect it will be a command performance.

Until next time.

I would have fired him too!

Freedom of expression is not a license to be an asshole.

Plenty of pixels have been expended on the diversity memo from a Google engineer who argues that efforts to improve diversity were a waste of time.  I have been following the arguments and spoken with friends about the dust up.  It dawned on me that this is not a question about diversity versus political correctness.  The entire affair is really about teamwork and being a jerk to you colleagues.  The author of the memo is not free thinking but using pseudoscience to justify biased views.  As an agilest and leader, there is no room for these individuals in your organization.

Over the years, I have been critical of the “brogrammer” culture.  I have also been critical of engineers who think gender is a disqualifying factor to work in technology.  Last week, I further bemoaned the lack of women in the development profession.  I placed much of the blame on a feedback loop of men pursuing computer science careers and providing a leg up to other men in the industry.  It is also apparent to me that working in technology gives certain individuals the license to be an asshole to others.

One of my favorite business books is “The No Asshole Rule,” by Robert I. Sutton, Ph.D.  Sutton does a fantastic job providing a scholarly definition of what an asshole is and reasons why you do not want them in your business.  I think it should be required reading for any business person along with the “The Five Dysfunctions of a Team,” by Partick Lencioni.  

According to Sutton, an Asshole has two traits:

• Test One: After talking to the alleged asshole, does the “target” feel oppressed, humiliated, de-energized, or belittled by the person?  In particular, does the target feel worse about him- or herself?
• Test Two: Does the alleged asshole aim his or her venom at people who are less powerful rather those individuals who are more powerful.

Based on the above criteria, it is evident to me that the author of the Google memo is an asshole.  The author considers himself and those like him intellectually and morally superior.  Since they are superior, they should not have to debase themselves by having to educate, mentor, or collaborate with those people.  This"other" could be women, ethnic minorities, and people living different lives.

A modern office is not an environment for this kind of thinking.  Women make up a large percentage of the work force and are filling senior leadership positions.  There are also countless people of color working as professionals.  Finally, individuals who are gay, lesbian, bisexual or transgender are collaborating with those who are not.  Anyone who considers themselves superior to others not like them is going to create tension and undermine collaboration in the office.  Eventually, behavior like this is going to trickle down to the bottom line.  From an agile perspective, individuals who feel this sense of superiority are going to be resistant to continuous improvement.  It is not a surprise the author of the diversity memo wrote this after attending a workshop on the bias.

As a manager and agilest I would have fired the author of the Google memo.  He was a distraction to the firm and advocating for a direction that the company had openly rejected.  Finally, his attitude to co-workers different than him would undermine any project he was assigned.  Better to remove a polyp than deal with cancer which could kill your organization.

Until next time.

I am taking next week off to attend the Gen-Con game fair. 

Software Development needs Women

We need more women in Technology.

I take a great deal of pride in what I do.  Being a scrum master is difficult but it has plenty of intrinsic rewards.   As I have muddled through my career, I have noticed the technology business is diverse.  I have worked with Indian, Pakistani, Russian, and Latino developers.  I have worked with every possible religious group from atheists and pagans to evangelical fundamentalist Christians.  The only criteria in the technology business I have encountered is could a person write good code.  Race, creed or color never disqualified a person from being a software engineer.  Unfortunately, gender is not diverse in the technology business.  We need to do a better job having women represented in the ranks of coders and agile practitioners.   This week, I want to formally provide my support for efforts to get more young girls to join the profession I love.

In the early days of software development, women and men were equally involved in the trade.  These pioneering software developers were business people first who learned how to write software without a formal collegiate curriculum.  One of the best depictions of this period is the film “Hidden Figures” which shows women of color working for NASA.  The 1950’s and 1960’s were not a golden age of diversity in American Business, but in the early days of software development, there was less gender disparity.

I believe that this changed as colleges began accepting undergraduates for computer science course.  Men began to dominate in this academic major, and it created a feedback loop of men helping other men get into the profession.  As women retired from the occupation, men replaced them.  These individuals knew how to code but did not understand the businesses they were working. As the business of software development became more lucrative and prestigious, companies pushed more women out the activity.  With fewer women in the occupation, the “brogrammer” culture began to grow, and software development teams became hostile work environments.  With the rise of Silicon Valley software shops, this trend became more pronounced, and it has been severely parodied in popular culture thanks to the HBO series. 

I am glad to report that over the years, I have run into plenty of exceptional women who walk a lonely road and work in this profession.  It is also good to see the rise of organizations like Girl Scouts and Code Like a girl encourage young people to get into the profession.  There is plenty of toxic masculinity in this business, and only with the addition of more women, a means to discourage it.  Finally, it is important that men support women in this craft.

Software development is a diverse profession, but it could do better with gender equity.  It is up to all of us in the business to recognize that girls can code and they are welcome in the profession.

Until next time.

Learning to Manage time

Time should never be wasted

A software developer is a unique brand of employee.  The profession requires mental toughness and creativity.  The ability to create software also requires strong time management skills.  As a scrum master, you need to help your colleagues learn to manage time better.

If you work in technology, you confront a stark reality.  To keep the global economy moving there is a too much work chasing too few people.  Less than .05% of the world's population can build software and maintain the networks which run it.  Software engineers are under constant pressure to grind out code.  For those who do not understand, it feels like cramming for an exam every day of your working life.  This kind of pressure takes a mental and physical toll on the people doing the work.  Developer’s abuse alcohol, binge eat, take numerous prescription medications and engage in unhealthy behaviors to mitigate the stress.  It is an abusive cycle which leads to burnout and bad quality.

As a scrum master, we need to help others learn to manage time better.  First, create a routine for the development team and business owners.  The daily stand up should never state late, and everyone should attend.  Next developers need “quite time” to concentrate and do work.  People who are looking for favors, football pools, and making lunch plans are forbidden if they interrupt the developers.  Finally, headphones and other techniques to create a state of flow should be encouraged.
Business people divide their day in hour long chunks.  Software engineers think in thirds.  There are morning, afternoon and evening and each period is an opportunity to work and write software.  Another reason I have no meetings scheduled in the afternoon for the development team; I want the afternoons to be interruption free for the developers.

I also use it as a time management tool for product owners.  After lunch, I have a one-hour sprint refinement meeting.  We discuss stories for an hour and then adjourn for the day.  The time after sprint refinement is a perfect opportunity to write user stories.  Developers get into the routine of meetings in the morning and open afternoons of coding.  Product owners understand that the time after the sprint refinement meeting is for writing stories.

So a helpful way to help others better manage their time is to give them clear routines so they can set aside time to do the work.  It is not perfect, but it beats flailing around the office in a panic.

Until next time.

Life Lessons influence Your Agile Coaching

Twenty Seven years later this cover of Time
 magazine still bugs me.  They got it wrong.

Little things remind me of my mortality.  This week I received an invitation to my high school homecoming and a fiftieth birthday party for the class of 1986 afterward.  This reminder of my demise made me do some reflection.  There is nothing like the specter of death to force you to take stock of your life.  This week I wanted to share my revelations.

Demographically, I belong to the Generation X cohort of American history.  Born in the late 1960’s and early 1970’s we were raised in the Reagan 1980’s.  We witnessed the birth of Apple and the fall of the Berlin Wall.  We experienced “Morning in America” and two ugly recessions.  The revolution was televised on MTV, and the counter-revolution came from the White House.  The anxiety of terrorism was nothing compared to the possibility of human extinction caused by mistake in the Cold War.  Plenty of cultural forces mixed to create emulsion which is still relevant today.

As a nerdy Dungeons & Dragons playing child, there was no place to find solace during this period.  I was a striver and wanted to succeed.  There was no internet culture to speak of so I relied on my small circle of friends in theater, JROTC, and scouts to muddle through.  It was a lonely way to grow up.  It was also preparing for my future career because nothing is more solitary that leading change.

Like many people in the early 1990’s, I was adrift.  The job market was lousy, and the prospects for a college graduate were not good.  I worked odd jobs and spent most of my time attempting to be self-sufficient. After working in a casino for a few years, I decided to make a change and become a technology professional.  It was 1998, I was thirty years old, and I began my first entry level job as a Visual Basic developer.  I had found a career.

My career would have numerous ups and downs.  I would confront long term unemployment in the aftermath of the Dot.com bubble.  I would be a consultant, and I would work full time for plenty of companies.  It would take me ten years to learn how to become a competent web developer.  During this period I was exposed to Agile and Scrum.  Since that moment in 2009, I feel like I have gone through a second educational period in my life.  I completed a master’s degree in management.  I became a certified scrum master and then later a certified scrum professional.  I began spreading my experience and knowledge around.  It has been rewarding and fun.

Lately, I have noticed how much cultural opposition within the business community there is to Agile.  It is hard to break old habits and upset personal relationships when you are trying to improve business.  Personal loyalty often takes precedence over doing the right thing for the firm.  There is a lot of understandable fear in the cubicles of America about change and what that means.

Using quantitative measure to judge performance holding people accountable for delivering a quality product, and expecting everyone contributes is controversial among white collar workers.

“It is unfair to measure me to everyone else,” someone I was coaching said.

The reality is it is unfair for someone in the office not to do their job to the best of the ability and cause customer service to suffer.  It is also unfair that you are not improving as your career progresses.  Technology professionals understand this, and it is about time other people in the business community do as well.

So as 2017 drifts lazily into its third, quarter, I am looking forward to the class of 1986 reunion.  My life struggles are a legacy for others to gain experience.  It explains why I enjoy training new developers and helping others avoid the mistakes I made in my career.  Growing old is not as terrible as I suspected.  My life experience has given me the tools to help others, and it just means I have a lot of wisdom to share.  My life prepared me to be the scrum master and the agile coach I am today.  Not a sad thought when you are confronting your mortality.

Until next time.

Work should not make you crazy

Being an office worker feels this wrong and it
needs to change or the global economy is in trouble.

I have been a business professional for over twenty years.  I have witnessed the good, the bad and the ugly of what it means to be a professional.  I am well compensated for my work, but like many people today I live paycheck to paycheck.  I have endured three recessions in my lifetime each time suffering a personal of a financial setback.  I am pretty stoic about these experiences, but they continue having a lingering effect on the kind of leadership I practice.  This week I want to talk about an issue which is an unspoken problem in the business community – mental health.

I began thinking about this topic when news came out on Mashable about Madalyn Parker.  She sent an e-mail where she told her staff that she was taking two days off for mental health reasons.  Her letter was then followed up by a letter from the CEO thanking her for taking the time to focus on her health and wished her a swift recovery.  What followed was a flurry of articles and think pieces about mental illness in the work place.  I want to add my two cents to the conversation.

The world of the white collar professional is unforgiving, highly competitive, impersonal and unfair.  The global economy does not care about the individuals who keep it going.  The factory worker manufacturing smart phones in China, the developer working late nights building applications and the young person cultivating social media likes are all part of this ecosystem.  This environment is an ideal breeding ground for mental illness.  With 1 in 5 Americans who have a mental illness, and I consider addiction part of this statistic, there needs to be a discussion about mental health in the work place.

The reason I became an agile practitioner is as a software developer I labored in plenty of situations which were dysfunctional.  I swore there must be a better way if given a chance I would help lead the necessary changes.  My career is guided by that mission.  In that respect, I am similar to the muckrakers and union organizers of the late 19th century.  These people lobbied and organized to end child labor, reduce injuries in the workplace, and enforced fire safety in all factories.  Eventually, the government became involved, and O.S.H.A. was created to ensure the abuses of the past never happen again.

Just like we do not want to work in factories where the likelihood of amputation or death is high we should also demand offices which discourage mental illness.  Here are some of the long term trends I see which are promoting mental illness.

The use of alcohol and recreational drugs as a social lubricant in business. – 

As long as there has been an America, there has been alcohol.  The nation’s drinking problem became so bad that elected officials, wrongly, passed a constitutional amendment to ban the sale of alcohol entirely. When prohibition proved to be a failure, American returned to its drinking ways.  The real spike in alcohol abuse in this nation took place in the 1950’s and 1960’s.  “The Man in the Gray Flannel Suit” and the television show “Mad Men” chronical these boozy times.

Fifty years later, alcohol is the drug of choice in the media profession.  Client in all industries is being “entertained” with fine wine and cocktails.  Account executives and vendors are exchanging and consuming alcohol, and it is a regular business practice.   Professionals see this as early as college and discover the consumption of alcohol is a way to deal with stress.  Some of these professionals develop addictions problems, and these addiction problems spill over into the business.

Also, the use of cannabis among engineers has increased over the last fifty years as well as abuse of cocaine among executive ranks.  The reliance of both legal and illegal means to alter consciousness exacerbates existing mental health issues and hurts productivity.  The office should not be a gateway to addiction.

Sleep deprivation. –

Tight deadlines, outsourcing and the around the clock nature of the economy means that a professional to conduct their job has an irregular sleep schedule.  I have written about the importance of sleep in the past, and so has my friend Lawrence Gasik.  Research has shown that people who do not get enough sleep exhibit the traits of PTSD or alcohol intoxication.  There are international conference calls to take and offshore teams to consult.  Business leaders still expect meetings in the office take place during daylight hours, so those people working on these bifurcated sleep schedules suffer in silence.  It explains why sleep aids, melatonin, coffee and Five Hour Energy drinks sell so well in the United States.  We are attempting to whipsaw our bodies into sleep and wakefulness to accommodate the demands of the global economy. This type of sleep deprivation also undermines the mental health of employees.

The focus on shareholder values instead of customer value in large companies. –

Richard Eastman of the Kodak Company paid his employees above average rates, provided numerous perks for his employees and provided outstanding service.  He resisted unionization of his office and factory workers but always made sure his pay and benefit packages were always better than the current market.  With rising unionization of the work force, capital balanced the needs of customers, labor, and shareholders.

This trend began to change as future CEO Jack Welch gave a speech about “Shareholder Value,” to The Pierre in New York.  Combined with the Chicago school of Economics, led by Nobel laureate Milton Freedman business leaders began to worry more about share price than other aspects of the firm.  The effects have been remarkable.  Stock prices have increased for many companies, a particular segment of the investment class has gotten obscenely wealthy, and many mergers and acquisitions have happened to create massive economies of scale.  Shareholder value also lead to the Financial Crisis of 2008 popularized in “The Big Short,” the rise and fall of Enron, the skullduggery of RJR Nabisco and finally the destruction numerous corporate towns in middle America and popularized by the book “Glass House.”

There is plenty of pushback in the academic community against the shareholder value movement, but the business sector has not embraced it and still do not see employees as partners in success.

The inability for business to pay people their real labor value. –

Since the Presidency of George W. Bush and the bursting of the dot.com bubble, companies have gotten very good at creating what my friend Bob Karzeniowski calls the musical chairs economy.  Using slow growth as an excuses firms are demanding more experience from applicants and cutting back training opportunities.  People cannot get on the career ladder, and those that do often have limited chances for advancement.  I also should point out that recruiters and hiring managers openly discriminate against the unemployed people and those who are laid off.

The Great Recession of 2008 – 2009, created a glut of workers.  It has taken nine years, but now that the job market has tightened, business people have lost the “muscle memory,” to increase labor participation to meet the market demand.  We now have created perverse incentives such as airlines having to cancel flights because there are not enough pilots.  Low wages, the musical chairs job market, and the mental scars of the great recession create insecurity.  This instability leads to the undermining of self-esteem and mental illness issues.

The promotions of people with psychopathic tendencies into executive leadership roles.  –

Over the last 40 years, we have been promoting the wrong people into business leadership roles.  Many of these people support the short sided notion of increasing shareholder value.  Making matters worse is some of them are psychopathic who find emotional fulfillment by playing people off each other.  Instead of nurturing others and guiding the business, these leaders create a toxic stew of dysfunction.

It is even more pernicious because these leaders become celebrities in the corporate world and media.  Finally, psychopaths are emotional chameleons kissing up and kicking down to advance their careers.  These emotional vampires undermine morale, and the mind games threaten mental health.

Finally, social stigma against people with mental illness means people who should get help do not. –

Numerous studies have shown the stigma of mental illness is the principle reason people do not get treatment.  This stigma is amplified in the business world where mental toughness and grit are highly prized; to admit weakness is to accept failure.  Venture capitalists are reluctant to give money to people who might be risky.  Someone with bipolar disorder or narcissistic rage is risky to lead a project.  The stigma of mental illness is equal to risk, so business people shun it.

I find it ironic business people does not treat individuals with diabetes or high blood pressure in a similar fashion.  Mental illness if managed correctly, resembles those chronic diseases.  So the stigma of mental illness and its effects on a career prevent people from getting help when they need it.

Taken together, I think these six factors in the modern workplace make it fertile soil to nature mental illness.  Most business people pay lip service to their employee’s mental health because they are trying to keep the business running, meet payroll, and keep investors happy.  It is an ugly spiral; if we want productivity and GDP numbers to improve the business community will have to make some significant reforms.

Just as a factory with fewer fatal accidents is more productive one with deadly accidents; then the contemporary office with fewer mental health problems is more competitive than an office filled with dysfunctional people.  What we currently have is not sustainable, it is better to reform now than wait and see what happens next.

Until next time.