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.