Monday, March 20, 2017

Rage is when I am most vulnerable

Don Quixote got nothing on me.
Being a scrum master is a hard job.  It includes plenty of early meetings and late nights.  It is a life filled with stress.  Sometimes, there is a payoff when the customer is happy, and the software is in production.  Software development is a messy job.  Inevitably that dirt rubs off on people especially the scrum master.  Cleaning off this grunge has an emotional toll and this week I would like to talk about it.

As a scrum master and agile coach, I am a big believer in the idea of servant leadership.  The Marine Corps saying, “Ductus Exemplo,” is starting to become slang among business executives.  It is a fantastic concept, and I strongly support it.  The hardest part of being a servant leader is the everyday realities of being in charge of complicated software projects and managing people who are equally messy.  The mask of command and professionalism falls away, and you become vulnerable which for a leader is dangerous.

This danger of vulnerability means your raw nerves are exposed, and your emotions are controlling you rather than you controlling your emotions.  Losing emotional control means you will say things you should not and do things impulsively without thinking them through.  It is a dangerous place to be and one which can undermine your leadership credibility.

I have to confess that the above situation happens to me more than it should.  I become a fountain of rage at times.  In particular, when confronted with an individual who refuses to be accountable for their conduct I become a character from a Robert Louis Stevenson novel.  I get angrier when I spend time coaching someone, and they ignore my direction.  It makes a person feel like Don Quixote jousting with windmills.  The reward for your trouble is getting knocked off your horse and the laughter of by-standards.  Getting up and dusting yourself off to do it again looks stupid and futile when you have to do it with weekly regularity.

So here I am at my most vulnerable, filled with rage, feeling like a failure and believing the effort is futile.  These feelings can be fleeting, or they linger.  It is the worst when you are alone in bed trying to sleep, and the vulnerability is thicker than the darkness in the bedroom.

Like any leaders, I have to deal with these emotions and the emotions of my team.  It is not easy.  The rewards are fleeting. I promised myself that when I became a business leader, I would try to be firm, fair, and inspire others.  I fall short from time to time, but I still aspire to that ideal.  I have no choice; it is a promise I kept to myself and to the people I serve.  People depend on me.

Until Next time.

Monday, March 13, 2017

"Never Events" in Software Development

Without "Never Events"
a doctor is nothing more than a glorified butcher
There is a phrase in the medical profession known as a “never event.”  It is something that should never happen in a hospital or another medical setting.  People have been practicing medicine since Neolithic times.  We have only been writing software for about seventy years.  I think we can learn a few things from the field of medicine and I would like to discuss it on this week’s blog.

The term “never event” came from a medical paper from the National Quality Forum.  These are mistakes which should never happen in any medical setting.  Some examples of these never events are, people receiving the wrong type of blood during a transfusion, surgeons amputating the wrong limb, and discharging an infant to the wrong set of parents.  If something like this happens, the doctor is subject to profound liability, and a patient could die.  It is why they are called “never events.”

I thought about this, and I felt that those of us in the software business should have a series of “never events” for our profession.  If we are going to improve in the agile community, we need to have a set of standards and those standards should include things which should never happen.

Here is my list of never events for software development –
  • Code which exists in production should never reside on individual’s computer; it should all reside in source control.
  • The database administrator should never ignore system backups of data; data should be backed up regularly and before scripts are applied to the system.
  • All code which performs business logic should have unit tests; this way you will understand where the system has changed and what the possible changes are.
  • Network servers should receive regular patches and security upgrades; this will discourage hackers and avoid technical debt.
  • A developer should never work longer than 10 hours; fatigue causes mistakes.
  • Before checking in the code, it should be code reviewed by another developer; an extra set of eyes on the code prevents errors and helps to learn.
Those are my starting points for “never events” in software.  Look forward to what each of you thinks should be included on this list.

Until next time.

Monday, March 6, 2017

Why good developers put up with bad workplaces.

Working in technology should
 not feel like being in a sweatshop.
I touched a nerve with my blog last week and it kicked off plenty of debate.  What struck me was the insight from Steve Seather who asked, “…why would anyone work in such a wrong place?”  This week why good people put up with bad workplaces.  I have been a contractor and full-time employee in the technology business for almost twenty years.  I have a lot of experience in bad workplaces.  I will also cop to the fact that I was a poor software developer for the first ten years of that career.

According to the United States Census website, approximately 7.3 Billion people live on the earth.  According to the Verge website of that roughly 18.5 million people know how to write and maintain software.  If you do the math, only .05% of individuals on the planet know how to keep the modern global economy moving.  In short, there is too much work chasing too few people able to do the job.

Since software can be written quickly in a cafĂ© in Nigeria or a pub in Northern Ireland, the laws of supply and demand get twisted into a pretzel.  Domestic developers are pitted against offshore teams to keep wages low but because the skills are still rare wares are relatively high compared to other professionals.  Something has to give, so IT professionals become swamped with work.

IT professionals commonly work long hours and fight unrealistic deadlines because of this labor shortage. Software professionals become contingent workers because much of their work is project based.  They are hired and fired at will and often treated with contempt because they are often “the geeks” they have to pay.  So many people in the profession do receive excellent compensation, but they have zero security or respect.  Like rock musicians, they are only getting paid when they are working.  Unlike rock musicians, we rarely have adoring fans.

Making matters worse is the H1-B visa.  The United States immigration service provides this service.  In short, if you are a foreign national and work in the United States you need an H1-B visa.  If you lose your job you have 30 days to find a new one; otherwise, you are deported. Over my career, I attended many staff meetings where everyone was afraid to talk because if they offended the Vice President, they would be rolled off the project and deported back to the country of origin and this is why I compare the H1-B visa to indentured servitude.

Finally, many managers who lead IT teams have no understanding of the messy nature of building software and treat it like the manufacturing of machine tools.  They use project management and manufacturing techniques to lead IT professions which create numerous situations of labor alienation and crushes productivity.  IT professionals like any other employee have to put food on the table.  IT professionals put up with the lack of respect, overwork, poor security, and incompetent leadership for one reason – the paycheck.

It should not have to be this way.  The Agile reformation started because many smart people felt there was a better way.  People could do work more productively and more sustainably.  It is why I am and agilest.  It is also why I will not put up with ever working in a lousy environment again.  I am getting to old for that kind of grief.

Until next time.