Monday, October 16, 2017

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.

Monday, October 9, 2017

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.

Monday, October 2, 2017

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.

Monday, September 25, 2017

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.

Monday, September 11, 2017

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.

Tuesday, September 5, 2017

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.

Monday, August 28, 2017

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.