Why Healthy Ownership

"Healthy Ownership" created to fight abuse

I have been in deep thought about what we in the agile community need to do to make businesses more responsive to market demands.  The reality is that many relationships in the technology world can be abusive; this why I want to talk about the reasons why I have been working on “Healthy Ownership.”

It is not a secret that software developers can be jerks.  It is also not a secret that there are plenty of raging asshats in the technology business.  Finally, if you work in a shrinking industry, the pressure to do more with less can be absurd.  With all of these realities, there is no reason to be involved in the following behaviors.

Questioning the estimates of a development team.  

I have written several times about the underlying social contract of agile.  Product Owners set priorities and development teams to estimate how long it is going to fulfill those priorities.  I had a product owner question those priorities saying, “You did something similar last sprint so I thought you could do it faster this sprint.”  All user stories should be negotiable but for things like scope and acceptance criteria.  When product owners start questioning how long it takes to complete that scope you break the social contract of agile.  It is this kind of conduct which demotivates the development team and gives them license to question the judgment of priorities of the product owner. 

Not writing a unit test or chipping in with QA work.

I have known developers who have looked down on quality assurance people.  Experience tells me that these individuals are not very good developers.  Software development is complicated, and the process of authoring it creates intellectual blinders.  Quality assurance people guarantee that those blinders are less convincing.  They ask uncomfortable questions, probe weaknesses in logic and are willing to take a sledgehammer to a sink to make sure that everything works as promised.

Quality assurance people help developers improve, and developers help QA people understand what they are testing.  A recent blog post mentions a professional golfer is not finished with a hole until they put the ball into the cup.  For weekend beer league golfers, it is good enough to get it close to the hole and “pick it up.”  Writing unit tests and doing QA work separates professionals from beer league developers.  Refusing to do this means you are rejecting the professionalism of your craft. 

Ignoring refactoring and technical debt

Technology is a brutal business.  It is unforgiving and humbles the best of us.  It changes so quickly; a developer needs to relearn their job every eighteen months.  It means that code they are working on needs continuous refactoring.  What is working in the short term may be hard to maintain or adapt to changing business needs.  It is why technical debt and refactoring matter.

Many people in leadership roles have a, “if it is not broken do not fix it,” attitude.  Neglecting technology is like ignoring your household plumbing.  It may work now but when it does break it is going to create a tremendous mess.  Paying attention to technical debt and refactoring is common sense like changing the batteries on your smoke detectors. 

All three of these pathologies brought me and others together to create “healthy ownership.”   These behaviors are abusive and counter-productive to any team.  Only be addressing these dysfunctions will the practice of software development improve.

Until next time.