E-mail - the Enemy of a Scrum Master

E-mail can be the enemy

One of the biggest challenges for a scrum master is communications.  The scrum master is sending e-mails, attending conference calls, and walking around attempting to understand how the sprint is going and what people are saying about it.  It is not an easy job.  It requires great listening skills and the ability to communicate vital information in just about every format a modern business can throw at you.  This week I wanted to discuss e-mail because this old standby of the office is the least effective of all the tools at your disposal.

Many argue that the modern internet was born when the first e-mail was sent in 1972.  In the forty plus years since, I have seen how the technology has evolved from something helpful to the bane of a business person’s existence.  Since e-mails had a recipient and the ability to carbon copy people, the e-mail quickly became a way to disseminate information in a large organization.  Sadly, many e-mails resembled the memos which were distributed before the advent of e-mail.

E-mail as we know it today really didn’t begin until the release of two programs which changed business irrevocably.  Lotus Notes and Microsoft Outlook became the do dominant players in the e-mail game.  Notes not only featured e-mail but primitive forms which could be routed through the organization like paper forms.  Workflow as we know it was born.  Outlook was different, it was a stand-alone tool to send e-mail.  You could attach files to it and forward messages in order to keep people informed.  It was supposed to save paper and speed up collaboration.  What it did was create a vortex of time sucking busy work.  

E-mail communications quickly mirrored the dysfunctions of their parent organizations.  Organizations which were hierarchical demanded reports be forwarded up the chain of command.  This meant that the higher up in the organization you went the more e-mail you received from subordinates.  Soon upper and middle managers were swamped with e-mail.  Decisions were not faster, they took more time as decision makers waded through increasing volumes of e-mail.  E-mail also echoed the lack of trust in organizations as people sent out e-mails to inform others if something was going to go wrong and then use the mail not being read in a timely manner as an alibi.

Soon managers were having conversations similar to this in their offices,

“That sale should not have gone through.  The margin is not high enough and I have to do a major revamp of the vendor portal to make that happen,”

“I sent you an e-mail about it.  I did not hear from you so I decided to go ahead.”

…and so on.

Sometimes as a scrum master I have sent e-mail messages to senior leadership and I have gotten one word responses or the content of the mail has been misunderstood so badly that I have had to print them out hang them on the white board in my bosses office and ask what part of my writing was unclear.

E-mail does have a written record of what was said but if there is too much of it, the record is lost in the constant noise of information modern business people receive.  So e-mail is a poor tool in conveying information to others.  This is why one of the principles behind the agile manifesto is “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”  Instead of sending an e-mail get up from your desk and talk to the people who make decisions.  Instead of sending an e-mail, pick up the phone and make a call.  Instead of sending an e-mail, start a video chat with the person.

I understand that executives have gotten very good at learning how to be unavailable to the “peasant masses” that work for them but as a scrum master we have to be the ones to convey information both positive and negative.  Otherwise, team success will continue to get lost in a flood of e-mail.

Until next time.

Dungeons and Dragons Made Me a Better Scrum Master

A teen-aged past time helped
shape my career as a scrum master

As a teen-ager, I stumbled into the world of gaming.  Board games, toy soldiers, and Dungeons and Dragons became a central feature of my young life.  My initial fascination became a lifelong hobby.  Today my house contains thirty years of scale model soldiers, tanks, ballistae and medieval fortifications.  It also occurs to me that my hobby helped shape my career as a scrum master.

Dungeons and Dragons was one of the first commercial role playing games.  It came out in 1974.  I would discover it in the early 1980’s as the hobby caught on nationally.  The game featured all the tropes of swords and sorcery.  To a nerdy kid who was picked last for most games on the playground, it was a chance to be a powerful wizard or hulking warrior.  Dragons, Orcs and goblins would quake in fear at the mention of my name.

Through the hobby, I met plenty of older kids who would become my friends and mentor me through high school.  Saturday nights would be spent over a pizza and brave heroics around White Plume Mountain.  I was exposed to mythology, H.P. Lovecraft, and differences between a gully dwarf and a mountain dwarf.  It was a great way to grow up.

It occurred to me the skills I learned over pizza have been invaluable to me in my later life.  In Dungeons and Dragons, I was a dungeon master and the key to success was organization. I had countless folders of non-player characters, maps and tables covering any possible circumstance.    This organization would help me as a scrum master as I chased down requirements for user stories and test cases.

The improvisational theater aspects of role-playing games make me comfortable leading discussions and retrospectives.  Because of role-playing games, I write better than many of my peers.  This has made me stand out from the other developers and scrum masters as my firm.  Taken together, the ability to be organized, improvise when necessary, and facilitate communications in a group means that a good dungeon master can easily become a good scrum master.

I still spend time painting soldiers and playing board games. I have even written some material for Steve Jackson games.   If I could find the time, I would love to run another game.  Until then, I take comfort my hobby has given me some of the tools to succeed in my career.  

Until next time.

The Overworked Product Owner

Overwork and stress brings out the worst in everyone.

It has been my experience that most technology problems are not technology problems but problems with people obscured by technology.  Many of my professional headaches in business are caused not by technology behaving unexpectedly rather, they are a product of people behaving in an unexpected manner.  It does not help that modern business puts so much pressure on people that they do not have time to sort through crisis situations in a rational manner.  This week on the blog I wanted to discuss the overworked product owner who you are going to run across in your career.

It amazes me how knowledge and power concentrate in different places at the firm.  Executives who seem to be very good at kissing up and kicking down know nothing about the inner workings of their business.  They understand the accounting but not the actual operation of the business.  The people who understand how the business actually operates are busy making sure the invoicing is done and that the organization is operating.  These people make perfect product owners but they are also a rare commodity so executives often ask these people to do double duty managing multiple projects.  The thinking that they are so good with one project the other projects will go just as smoothly.

This is penny wise and pound foolish.  With attention divided between multiple projects the product owner will not be able to focus on any project and all of them will suffer.  This will create situations where the user stories will not get written in a timely manner or their will not be enough user stories to keep the team working efficiently.  This is going to lead to conflict because the scrum master will accuse the product owner of not doing the necessary work and the product owner will get upset with the scrum master for not delivering his vision soon enough.

My suggestion is that you bring this to the attention of upper management right away because they should know a project is failing long before a deadline passes.  Otherwise it will be your fault that a project fails.

Until next time.

Say I told you so.

Taxes should be more efficent

It is tax time in the United States.  It is an annual ritual where you spend a few hours filling out paperwork either to determine if you are going receive a refund or owe the federal government money.  This week the IRS reported that they had hardware failures to their systems which has been holding up tax returns.  This week I wanted to talk about this and what it means for the good people in the Agile community.

When you work for large bureaucratic organizations, an agile professional is living in a constant state of paranoia.  This is because you lack control over many of the systems you are responsible.  For instance, pushing code to production is not the development team pushing the code but an implementation team located in another country taking a deployment package and then moving it to production.  When a customer has a problem they are not communicating with the development team but with call center located in a different time zone.  You may not be in control but when something goes wrong an executive is going to ask you what went wrong.

It cannot think of a more bureaucratic organization than the American National Government.  Civil service labor rules, political politicization, and the institutional inertia and you have a recipe for poor service.  I suspect that is what happened with the IRS this week.  I am sure a few people in the IRS asked to stress test the tax servers in November to make sure they could handle the traffic.   Unfortunately, those concerns were vetoed by manager appointed by the President or congress and the work was put off.

Flash forward to tax season and the servers for the IRS are swamped with the traffic from people looking to get refunds.  The hard ware could not handle the traffic and it crashed.  Then for the remainder of week the server teams at the IRS have been trying to fix the situation.  In the meantime, people are waiting for their taxes to be processed.

As an agile professional, you need to say “I told you so,” and remind others when they are about to make the same mistake again.  That said, I don’t think the IRS is going to have these problems next year.

Until next time.

Laquan McDonald can teach us something about scrum.

They look cute until they undermine your efforts

One of the hardest things for a scrum master to do is lead organizational change.  For example, showing developers how to do SOLID development and test driven development is not enough.  The developers should see the utility of what they are doing and be compelled to practice it.  If your development team refuses to follow your lead you are stuck.  This week I wanted to discuss what happens when institutional needs meets resistance from the front line employees.

There has been plenty of news in the press about the killing of Laquan McDonald.  The young man was carrying a knife and walking away from a police officer when he was shot 16 times by a Chicago Police officer.  Video footage of the police officer using lethal force on McDonald was caught on a dash board camera in a police car.  The audio for the event was lost because the microphones were either disabled or broken.  McDonald’s death has sparked protests and calls for the mayor of the city to resign and has made the election of the attorney general a wide open race.

What is not being said in all this protest is that police officers have been wearing body cameras and using dash board cameras for roughly five years.  The shooting of McDonald also included a three year effort by the city to prevent the video footage from reaching the public until a judge gave the order during the December of 2015.  So on the one hand you have efforts to make the police department more accountable and on the other the information is suppressed by self-interest by police, politicians and prosecutors.

Currently, news has surfaced that eighty percent of the dashboard cameras and body cameras have the audio feature disabled on them.   There is a great deal of doubt as to whether this is because of tampering among police officers or poor maintenance; either way the optics look very bad.

So you have a government which wants to make the police force more transparent and cut back on the use of deadly force in communities and you have a the members of the police force with equipment which does not make that happen.  There is a lesson here for the scrum master.  If you are going to institute change then that change needs to be embraced from the bottom up rather from the top down.  Otherwise, you will be confronted with sabotage, monkey-wrench efforts, and stonewalling.

It is a shame that it takes a dead kid and embarrassing headlines to make that point.

Until next time.