Archive for November, 2013

What kind of Scrum Master are you?

Tuesday, November 19th, 2013

I’ve noticed that there seem to be 2 types of Scrum Masters out there, change agent servant leaders and paper pushers with agile titles.

 

Some companies understand that the Scrum Master is a valuable useful position that make a difference.

Reviewing Michael James’s Scrum Master Checklist is a useful, (and humbling) bi-annual practice.

Scrum Master is a full time leadership position.

(By “leadership”, I use the military understanding of the word, meaning, “willing to do what needs to get done in order to fulfill the mission while keeping the big picture in mind.”

This is contrasted by what seems to be the standard civilian misunderstanding, “willing to give orders about this quarters work, while being incapable of providing direct value.”)

These types of Scrum Masters positions tend to be found in companies where the company mission statements are an accurate reflection of the company rules that are whispered in the halls.

Scrum Masters in these positions have the opportunity to make a difference by being change agent servant leaders.

 

 

Other companies understand that they need some magical fairy dust called “agile” or some vague bad thing will happen to the company in the future.

In order to get the magical agile fairy dust, these companies change their project manager’s titles to “Scrum Master,” because it is well known that Scrum Masters produce magical agile fairy dust.

These companies know that a Scrum Master is there to push their teams to show daily progress during the daily status meeting (weirdly called a “standup meeting”)

They also know that the Scrum Masters are there to turn those status meetings into magical burn down charts to be shared at executive briefings.

Lastly, Scrum Masters are there to schedule meetings for the team.

These types of Scrum Master positions tend to be found in companies where the company mission statement bear no resemblance to the company rules that are whispered in the halls.

Scrum Masters in these positions have little opportunity to make a difference because they have been reduced to the role of paper pushers with agile titles.

 

 

Are you allowed making a difference in your company?

 

 

Stay On Mission.

 

If you resonate with this agile slice, please add your voice to the conversation.

If this agile slice sounds silly, please take some actions to test a particular idea’s validity, and then share your results, good or bad, with the community.

If something strikes you as golden, then I’m glad we were able to provide value to your life, please let us know what difference it has made for you or your company.

Why empirical evidence doesn’t matter

Friday, November 15th, 2013

One of the most interesting phenomena I’ve discovered while doing agile coaching is the various knee jerk reactions when paired programming is brought up in the fortune 1000.

 

The reactions are interesting because studies show that paired programming makes a  huge difference.

We’re talking 50 – 85 percent reduction in new bugs, for a cost of 15% up front developer productivity.

Given the cost of finding and fixing bugs, the 15% up front cost is almost free.

 

Up until this week, the lack of interest in (or near violent reactions to) pair programming did not make sense.

 

Then, this week I came across the Semmelweis Reflex.

According to Wikipedia:

The Semmelweis reflex or “Semmelweis effect” is a metaphor for the reflex-like tendency to reject new evidence or new knowledge because it contradicts established norms, beliefs or paradigms.

The term originated from the story of Ignaz Semmelweis, who discovered that childbed fever mortality rates reduced ten-fold when doctors washed their hands with a chlorine solution between patients. His hand-washing suggestions were rejected by his contemporaries, often for non-medical reasons. For instance, some doctors refused to believe that a gentleman’s hands could transmit disease (see Contemporary reaction to Ignaz Semmelweis).

 

All of the sudden, the whole “Paired Programming Reflex” (if you will) started to make sense; empirical evidence doesn’t matter.

Just as a gentleman’s hands can’t transmit disease, having 2 developers working together must destroy half their productivity.

At this point, pairing is no longer just a funny idea.  Pairing is moved from adjective dangerous, it noun danger.

If you listen closely, the next sound to be heard is Fight or Flight reaction being engaged.

The idea, and the bearer of that idea, must be evaded, or destroyed.

 

Stay On Mission

 

If this sounds like a situation that a friend of yours has run into, please forward this to them.

If this explains a situation that you have run into personally, please leave a comment describing your experience.

Three 20 year-olds create a healthcare.gov miracle

Tuesday, November 12th, 2013

Up until the lurching non-roll out of Healthcare.gov, no one outside of the software community had ever heard of “Agile Development.”

The Wall Street JournalThe New Yorker, and Bloomberg have changed that.

Well, that and the miracle in San Francisco.

You see three 20 year-olds, in only 3 days, built a usable front-end to Healthcare.gov.

Miracle?

Yes, 3 people, in 3 days did what 55 independent contracting companies couldn’t do in 3 years with over 500 million lines of code.

There’s a miracle in there somewhere.

If nothing else, if you could get that kind of productivity out of your programmers, you would call it a miracle too.

Over the next couple of days and weeks, there’s going to be a lot of made of these 3, but how many smart business owners are stopping to ask, “How can I get that kind of productivity from my teams?”

In the coming days and weeks, I’ll be exploring that smart question.

Please pass this on to the smart business owners in your life.