Why Healthy Ownership

I have been deeply considering what we in the agile community need to do to make businesses more responsive to market demands.  Many relationships in the technology world can be abusive, which is why I want to talk about 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, the pressure to do more with less can be absurd, if you work in a shrinking industry.  With 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 stimate 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 except for 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 that 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 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 ensure 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 quickly; a developer needs to relearn their job every eighteen months.  It means that the code they are working on needs continuous refactoring.  What works 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 an, “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 breaks, it will to create a tremendous mess.  Paying attention to technical debt and refactoring is common sense like changing the batteries on your smoke detectors. 

These three 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.