More difficult than crayons

Crayons are easier to create than software.

When you spend your career helping people deliver software, it quickly becomes apparent that the biggest challenges you face are not technology problems.  The biggest challenge is working with messy people.  Machines can make pencils and crayons by the thousands each hour, but before that happens, someone has to design the product for manufacturing.  The people who do this are engineers and product designers.  Software relies on Scrum Masters, Product Owners, and software developers.  The creative process is the same, but it is much easier to manufacture crayons than software.  Today, I will try to answer why it is so hard to write software.

Software has only existed since the aftermath of World War Two.  The first documented “bug” was a moth which died among the vacuum tubes of the first computer.  In spite of technological advances, the way we write software is still primitive.  Developers continue test code on local machines and then push that code to remote servers to see if they work.  Testing is manual, and the ability to automatically push code through the web or large enterprises is limited.  The software craft movement is making progress in this area along with the DevOps movement are helping with this antiquated process, but it is still a long, tedious trudge to get software written.

The key adverb here is “written.” The writing of software is a creative process.  People take the vague directions of others and translate it into web pages or client-server applications.  Unlike traditional prose, software contains code, markup, and data.  The disciplines working with each is different and filled with plenty of nuances.  Business people compensate software professionals generously because it is such a rare skill to cultivate.  Developers are also under tremendous pressure to ship code and work long hours to do it.  Imagine, Earnest Hemingway, attempting to write “A Farewell to Arms,” with management standing over him demanding updates each day. Furthermore, imagine the Nobel laureate is required to write one character’s dialog in English, another in Spanish and finally hexadecimal code for each letter on the page for a different character.

If the above was not challenging enough, the people paying for the creation of software are not actively involved in its production.  Software projects often begin with a problem which does not have an answer.  A marketing executive blurts out, “I need a client website!” or a Human Resources professional asks if it is possible to manage timecards online.  The business set aside money hired consultants to do the work, and begin writing software with no idea how it should work.  Agile fixes this problem by requiring rapid time boxes.  Often, lack of participation and vision from business partners thwarts the benefits of agile.

Combined with the difficulty of writing software and the apathy of the people how to pay for the software, the final challenge is the hypercritical nature of everyone who cannot write software have for the people who can write software.  It is similar to the Austrian Emperor mocked in the movie Amadeus whose only criticism of Mozart’s opera is, “There are too many notes in it.”  Many people have opinions about software and provide critiques, which is either nitpicking or unhelpful.  As a developer, a color pallet I used for an application caused controversy, and we spent countless meetings reviewing color chips.  It extended the life of the project by three months and made it over budget.  In a different episode, punctuation on a page sparked hundreds of revisions and emails.

The reality is like a committee of proofreaders, executives, and people not involved in the creative process demanding edits to Hemingway’s work.  The final straw might be the demand that “A Farewell to Arms,” not have one of the main characters die at the end of the book.  The entire narrative arc of the book changes because of the “suggestion,” but if Hemingway does not make the changes, he does not get paid or published.  Considering this type of feedback, Hemingway would have consumed more alcohol than he did.

So this is why writing software is so complicated.  It is a creative process.  Next, the people who want and pay for the software are not actively involved.  Finally, if customer partners are in the project, they provide feedback and guidance, which is often removing value from the software rather than adding it.  I have been in this career for a long time, and I know how to write and deliver software.  It is much more complicated than creating crayons.

Until next time.

Goodhart's Law is Going to Get You.

Goodheart's law strikes!

Information technology is hard work.  I have written about it before on this blog.  I have plenty of empathy for others who work in this profession.  I do not have much understanding of poor service or lazy behavior.  I am even less forgiving when large organizations brag about their success in public and struggle to do the basics in private.

I am at a client, and I have the following interaction with someone from the help desk; they said, “Can we close this ticket? If it ages any longer, it effects out SLA.”  My first reaction was surprise.  My second emotion was anger.  The help desk person was asking permission to close the ticket and open a new one because if they did not fix the ticket at a particular time, it would reflect poorly on him and his consulting company.  He was going to lie to make his response time look better than it was. 

It is human nature to please others.  British economist Charles Goodhart coined the maxim, “When a measure becomes a standard, it ceases to become a good measure.”  When you judge or pay people based on a measure, they will game the system in any fashion to make themselves look better.  You see this in economics.  It happens in video games and depressingly at work.  My help desk technician was living proof of Goodhart’s law.

Martin Fowler wrote a great article on the subject, and it outlines how to avoid this trap in agile practice.  Metrics are abused regularly in business.  In a large organization, the only way leadership can track progress is by reviewing these metrics.  Thus, the people doing the work are more focused on the outputs of hitting the metric numbers instead of the outcomes satisfying the customer.

I see service level agreements or SLAs as a necessary evil in business.  You have to hold vendors and third-party partners accountable.  Such a contract controls my current situation.  In a perfect world, my help ticket would age, and someone who could help me would respond to my issue.  The technician was afraid that if the ticket aged, they would receive a poor performance review or get fired.  It is an ugly situation, and if a company is going to succeed, they with have to address it. 

Large organizations need to focus on execution.  To focus on this goal, metrics and SLA’s need to be used judiciously; outcomes are superior to outputs.  It is a message which did not reach the help desk or his boss. 

Until next time.

Keeping the Corporate Superorganism Alive

The business world is as
complicated as this turmeric rhizome

I spend plenty of time working with technology.  It is a career filled with wonder and long stretches of drudgery.  One day you are building a mobile phone application; the next you are spending months attempting to grind millions of records out of a database in microseconds.  It is not a glamorous world. It is a world filled with tedium and self-doubt.  Lewis Carroll said, “…between the idea and the reality lies the shadow.”  Technology people live in the shadow world of continuous improvement and innovation.  Today, I want to discuss what it is like living in the shadow realm.

The world of global business is so complicated people struggle to find good ways to describe it.  Often, others use metaphors to describe the way the business world behaves.  Some describe the business world in military terms and others attempt to use athletics as their reference point.  I think these approaches are too simple.  I prefer to use biology as a way to describe a business.

Owners, Employees, Managers, and customers are all working together in an intricate dance to generate value.  People exchange trust and money as the enterprise becomes more extensive; the system becomes more complex until it starts behaving like a giant organism.  A friend of mine, Andrew T. Keener refers to the modern corporation as a “superorganism.”  Watch hundreds and thousands of people commute into our major cities to work, and you can understand what Andrew is attempting to say.

A technology professional is an essential part of any large business.  Network engineers are maintaining the corporate nervous system so information can flow.  Software professionals create new ways of interacting with customers and keeping the like giving blood of money flowing through the organization.  Scrum Masters and Project professionals act as pacemakers keeping everything running on time.  It is a complicated dance to keep the superorganism of the modern corporation alive.

Technology people live in a shadow realm because no one pays attention to the systems they create and maintain until they do not work.  Unfortunately, the relationship between business professionals and technology professionals have been dysfunctional since the beginning of business computing.  The dysfunction was beginning to undermine companies and hurt their ability to respond to change with the competitive environment.

The agile reformation was born when people who understood the problem outlined four values and twelve principles to make working in the shadows more sane, sustainable, and satisfying.  Business people and technology people had to work together for the greater good of the business.  Technology people began to understand business challenges.  Business people started to understand things like technical debt and data security.  The collaboration of these two tribes in the parent super organism makes it stronger.

As s scrum master or agile coach, it is up to you to work in the shadows to improve the organization.  If not, the superorganism you work for will succumb to darkness.

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.