Say No to Ugly Metrics

One of the perks of my job it that I get to interact with plenty of talented and smart people.  One of them is Andrew Keener and I had the opportunity to spend a few hours with him over beer to discuss game theory, the philosophy of social contract theory and metrics to improve scrum teams.  It was heady stuff and I enjoyed every moment of it and wanted to share a little of the experience with you.

Keener has a very in depth discussion of scrum in metrics on his blog on linkedin.  I will let you read that on your own.  This week I wanted to discuss his notion of ugly metrics.  According to Keener, an ugly metric is one that reinforces the dysfunction of the organization rather than provide a means to improve performance.  Business people want to measure productivity and provide objective measures for how the people under them are doing.  The trouble is that for a creative endeavor like software development it is hard to come up with meaningful ways to do the measurement.

I try to track things which are concrete like bugs in production, how many story points successfully completed by the team, and number of stories flagged as technical debt by the team.  This way we have a means to see where we are and how we can improve. If I started using these metrics as a means of performance then my developers would begin to game the system to drive up their numbers. This inspired the famous 1995 comic strip from Scott Adams below.

So as a scrum master it is our duty to measure things which are relevant to our teams.  It is also important to use those measurements to inspire positive behavior and performance rather than encourage dysfunction in the team.  Otherwise, you are no different than the pointy haired boss Scott Adams loves to mock in his comic strip.

Until next time.

Fighting the F.U.D. as a Scrum Master

Fight the F.U.D.

The world of technology is awash in acronyms.  These acronyms rise and fall with much of fashion in the technology world.  A few of them have lingered over the years and represent a common knowledge among technology people.  This week I want to talk about F.U.D. and how you can fight it.

According to the urban dictionary, the term F.U.D. is an acronym for fear, uncertainty and doubt. The term was born during the start of the open source movement as companies like Microsoft and Cisco used disinformation to try and undermine the credibility of open source advocates.  The idea was that if they could create fear of the new movement, uncertainty of their goals and doubt about if they could actually solve business problems then they could maintain dominant market share.

Since these early open source days, Microsoft has dropped the F.U.D. campaign and has eagerly embraced open source and cloud computing with its Microsoft Azure tools.  It is positive development and has been a money making strategy for the company.

As a scrum master you are going to deal with F.U.D. every day.  Organizations, are riddled with fear of changing how they do business.  Any uncertainty is intolerable to executives and business leaders.  Finally, doubt is going to be used at every turn to try an undermine efforts for change.  To address fear, start small with an individual or team and show how the process works.  A person scared of heights will jump on a zip line if you can prove that they will not fall off the line or injure themselves.  Uncertainty is easily dispelled with hard data and evidence that the new ideas are working and improving performance.  Doubt, is eliminated by your personal conviction as a scrum master and by more real world evidence.

I am not saying there is a magic bullet to deal with F.U.D. but as a scrum master you need to be aware of it.  Otherwise, any effort you make to try and improve the organization is going to be fruitless.

Until next time.

Devotion matters

Devotion is harder than it looks

I work as a scrum master and technology professional.  It is not an easy job.  I am expected to run meetings at all hours of the day.  I communicate with developers half a world away.  I spend weekends and evenings retraining myself to stay on top all of the latest trends and topics.  I am compensated for my work but it really isn’t enough for the sacrifices which are expected of me on a daily basis.  So what drives a scrum master to do what they do?  It is devotion.

This week I wanted to talk about devotion and how it helps a scrum master get through the difficult periods of work and life.  When I was growing up, my aunt was a nun.  It did not seem like a big deal to my mother or the rest of the family.  It was her job.  She was a teacher and administrator and to have those opportunities in the early 1960’s she became a nun.  It didn’t seem to me like a religious calling but just something that came with the job.  As I grew older, it became obvious that my aunt sacrificed much to become a teacher and administrator.

She was not allowed to have a telephone in her room.  When my mother wanted to speak with her she had to get permission from the Mother Superior to speak with my aunt.  My aunt couldn’t keep a pet to keep herself company.  She had to live a life of celibacy so she was forbidden to have a boyfriend or husband.  She was even forbidden to rent an apartment and she did not have any say on where she worked.  She went to where the arch-diocese sent her.  She made these sacrifices because she loved teaching children and giving them an opportunity to succeed.  It was her devotion.

I talk about it as devotion rather than dedication because, to me, the different between the two traits is one of desire.  Dedication is something you do because you have a sense of duty or obligation to do it.  This is why many employees are dedicated.  They feel they have no choice to engaged in this type of commitment because they will be judged wanting.  Devotion is something you do out of love and commitment to the cause you are working.  Thus, my aunt was devoted to helping children and the sacrifices she made to make that happen were things she made gladly in order to help her cause.

This is how I think about being a scrum master.  You go into it as a devotion.  You have to like people.  You have to like developers.  You have to want to make a difference in your organization.  You are going to give up weekends and holidays.  You will have lonely moments and you will be giddy with success.  That is what devotion is all about giving up something of yourself for a cause you believe.  I am devoted and more scrum masters should be too.

Until next time.

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.