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.

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.

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.

Scrum should not be a cargo cult.

Scrum should not be a cargo cult.

Blogging about business and scrum opens you up to feedback and criticism.  Confronted by people who challenge your ideas allow you to reflect on your knowledge and beliefs.  A college of mine took offense to me referring to the meetings of a scrum as “rituals” last week.  I would like to address his concerns.

The primary criticism of my article was that I was encouraging a “cargo cult” kind of scrum.  The term comes from a Scientific American article from 1959 which documented primitive tribes in Melanesia coming in contact with missionaries and soldiers.  The connection prompted these indigenous people to create cults to encourage cargo to be delivered to them.  Primitive air strips, airplanes, and shipping terminals cropped up in the hope that actual cargo planes and people would show up.

The pre-modern culture felt if they mimicked the trappings of technology without understanding the principles behind that technology they would receive the prosperity which comes with modernity.  This assumption is wrong.  The tribes created many faux landing strips and cargo depots in the South Pacific.

People in the agile community, use the story of the cargo cult to illustrate the difference between going through the motions of agile and being agile.  In a perfect world, a business would reconfigure itself to follow the word and spirit of the Agile manifesto.  We do not live in a perfect world, so it is up to scrum masters and agile coaches to provide structure for the transition from traditional business to agility.

The events of scrum provide a means to help speed that transition.  Business people and developers are forced to inspect, act and adapt to changing situations.  That is the heart of an agile business.
When I refer to the meetings and events of the scrum as rituals, I mean the meetings should have purpose and significance.  I am not attempting to create a “cargo cult” in an organization.

I am glad someone challenged me on my assertions, and I look forward to more give and take in the future.

Until next time.