Sunday, March 26, 2017

Taking a sick week

The hardest part of being a leader is the emotional self-control.  How do you maintain your emotional even keel when you have people lying?  How are you supposed to trust people when they let you down on a regular basis?  How do you inspire others when they are more interested in the office pool and watching the clock at the end of the day?  Usually, in this blog, I try to provide answers which I have discovered over the years.  This week I am out of answers.

I am pretty worn out at the office and I have been struggling with sleeplessness.  I also am feeling whipsawed by professional and personal setbacks.  I am not much good to myself or anyone else right now.  I am kind of messy and in a corporate environment that is a forbidden state.

I will be back next week with more wit and wisdom but for the moment I am going to take a rest.

Thank-you.

Until Next time.


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.



Monday, February 27, 2017

Harassment is NOT Agile

Harassment is unacceptable always
Writing software is one of the few human activities we have not been able to automate.  This is why people like Angela Dugan and I say that software development is a messy process.  In spite of the education and training necessary to be a good software developer the technology business still struggles with misogyny.  If software development is going to become agiler, we will need to address these issues.

I have been adamant on this blog that the technology world needs to be more accommodating to women.  I have openly criticized the misogyny of others in the technology business.  This week Susan J. Fowler described her experiences working as an engineer for Uber.  I will let the blog post speak for itself.  As a developer, you should not have to put up with unwelcome sexual advances from management.  Also, when you make a credible accusation of harassment, it should be treated seriously by human resources.

I think this is part of what Slate magazine calls, "..the open hostility many technology firms have for women." I have noticed this throughout my career and have repeatedly called it out.  Women are just as good as men as software developers. Gender is not an obstacle to success in this field.

I suspect that misogynistic men join the software business for three principle reasons; 1) they like building things, 2) they like showing off their intelligence for ego gratification purposes, and 3) people in the technology business like creative destruction especially if you can flout social norms.

Building things is a natural human endeavor.  Building things are traditionally masculine in many cultures.  Thus, women involved with technology could be regarded with suspicion because they took part in a traditionally male activity.  Since the rise of second-wave feminism, men have been pushing back in the indiscrete ways to women who want to participate in manly activities.  I firmly believe that this is insecurity on the part of some men who feel threatened by women competing with them for success.

Since the early days of Western civilization, men have enjoyed bragging.  They would brag about athletic prowess and business success. Scientists and philosophers would opine about their intelligence to anyone who would listen.  Over the last four thousand years, men continue to do these things and being the smartest, best, and most successful engineer is a gateway to more success.  Thus, the engineering culture of software includes plenty of people who are willing to tell you how smart they are.  A select few can back up that claim.  Throwing women into this completive and egotistical environment is a recipe for harassment.

Finally, the notion of creative destruction appeals to many.  For the smart but emotionally unintelligent, an algorithm is a tool for vengeance for every playground bully, spurned romance or humiliation suffered.  Success is the best revenge and what better revenge than to ruin someone who metaphorically kicked sand in your face financially.  For the people who are not technically gifted but are more emotionally intelligent and competitive, the world of technology gives them a place to move fast, take names, and amass lots of money and power.  Naturally, these folks gravitate to sales and management.

Combine the need to build things with egotistical preening and the ability to engage in creative destruction; you have a toxic stew of masculinity which is particularly hostile to female engineers.  If the technology business wants to become more agile and fruitful, this kind of behavior needs to stop before a sexual harassment suit with punitive damages in the hundreds of millions of dollars shuts down a promising technology company.

Quid Pro Quo sexual harassment or hostile workplaces are antithetical to Agile.  It undermines trust on software teams.  It halts the exchange of ideas at the firm.  Finally, it creates an environment of fear which acts as cancer on any organization.  As Agile Coaches or Scrum Masters, we need to be on the front lines and help manage this behavior out of any organization.  What happened to Susan Fowler should not happen to anyone at any company.  That fact it happened at a technology company makes me doubly determined to make sure it does not occur at any technology company I am associated.

Until next time.

Monday, February 20, 2017

Disagreement means learning

Listen and Disagree
It is invigorating to have back and forth between fellow agile professionals.  It represents the give and take of knowledge between people.  People inevitability disagree about subjects, and the practice of Agile is no different this week I would like to talk about disagreement.

One of the more interesting books about leadership is “Team of Rivals,” by Doris Kearns Goodwin.  The central thesis of this book was that President Lincoln had a unique leadership style where he relied on the opinions of political rivals in this cabinet to help him better manage the events of the American Civil War.  Having a room full of devil’s advocates made Lincoln a better leader.  Numerous other articles and books have also surfaced which emphasized that diversity of opinion and perspective is necessary for success and innovation.

Lately, my blog posts and discussion on the Google plus agile community are being challenged by coach from Europe.  Some people would recoil from this kind of push back; I do not.  This individual has credentials and plenty of experience in the field so while I may disagree with his opinion; I respect his perspective.  I am a firm believer in disagreeing with people without being disagreeable.

My approach to Agile and Scrum centers around the Agile Manifesto and Agile Principles.  The Scrum Alliance gave me formal training as a Scrum Master.  Finally, I have spent nearly four years in the role of a scrum master shipping software with domestic and offshore development teams.  I have seen some things and done some stuff.  My experience colors my agile knowledge and opinions.

The product owner has the hardest job in the scrum.  The Scrum Master is a Coach, Therapist, and often the bad cop which keeps things moving forward.  Finally, the development team generate shippable code each day and are the unsung heroes of the process.  I live this experience every day and hope each of you who read this blog gain from my knowledge.

Disagreement is healthy, and if you are not willing to consider other opinions and activities, you are not going to grow as Scrum Master.   Listen to others who you disagree with; you never know what you might learn.

Until next time.

Monday, February 13, 2017

When to Unleash the Kracken

Make sure you mean it!
I have called being a Scrum Master many things.  It is a coaching role.  Being a scrum master can resemble being a therapist.  I have even compared being a scrum master to a parish priest.  The job is not easy.  A scrum master has plenty of late nights and early mornings.  One of the things they discuss in training for Scrum Masters is an important responsibility.  A scrum master can terminate a sprint.  Trainers don’t often consider this awesome responsibility but this week I will.

When things go badly in spaceflight mission control can terminate the mission.  When that happens, the astronauts turn the ship around and head back to earth via the shortest route.  When things go wrong on a scrum team, we have what is called an abnormal termination.  The sprint ends immediately, the team does a retrospective and plans a new one.

There is a contentious debate in the Agile community about who has the right to terminate a sprint.  I belong to the ideological camp that a scrum master should have this terrible duty.  I feel this way because the scrum master is the protector of process and improvement of the team.  When the Product Owner or the development team is in a hopeless situation, it is up to the Scrum Master to recognize it and take draconian measures.

Terminating a sprint is a huge deal.  Do not do this lightly.  It should be the plan “C” or “D” for any sprint.  Terminating a sprint creates all sorts of attention in an organization and is profoundly disruptive.  When a Scrum Master kills a sprint, it is the equivalent of Zuse saying, “Release the Kracken!”  Do not do it unless you are certain.  Otherwise, it is like pulling a fire alarm because you do not want to go to class.

The following are the rare reasons why a scrum master ought to terminate a sprint.

Project funding has changed drastically-

In an uncertain global economy, projects get canceled, and new ones are spun up.  These events impact your plans.  If this happens, the scrum master may want to terminate the sprint.  The termination will give the Product Owner, development team, and Scrum Master a chance to take stock and decide what the next steps to pursue.

The Product Owner is fiddling with a sprint while it is in progress-

I working with a product owner who was under so much pressure they could not prioritize work.  Sprints would begin, and stories would be swapped out with others.  Things which were a priority during sprint planning would be dropped days before the end of the sprint and replaced with stories of equal size.  The development team was forced to try and do the same amount of work in half the time.  Confronted with this bad faith behavior, I hit the self-destruct button and brought it to the attention of my Vice President. Leadership replaced the Product Owner in the aftermath.  The development team resumed sprinting.

The team grossly underestimated the work they could do in the sprint-

We have all had the “ten-minute change,” conversation. A product owner or someone from the business asks for a change to the system.  The developer listens to the request absentmindedly and says the change takes approximately ten minutes to perform.  A week later the developer admits the change affected other systems and it would take longer than expected.  Soon the rest of the development team is sucked into correcting the situation.

As my mentor, Angela Duggan would say, “developers are afraid of looking incompetent or unskilled.” This fear pushes software developers to underestimate work.  The team commits to something and then realizes it is more complicated than first expected.  If your development team has with six weeks of work in a three-week sprint, it is acceptable to hit the reset button.

These are three of the rare situations where you might terminate a sprint.  If you have other suggestions, I would love to hear them.

Until next time.