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.

Resource: 7 Agile Myths

Monday, April 1st, 2013

Ade Shokoya has a great article called “7 Agile Myths That Could Cost You Your Job & Reputation” which is an excerpt out of his book “Waterfall to Agile: A Practical Guide to Agile Transition.”

 

This short article is a insiders look at 7 common misconceptions that can hinder an agile adoption.

 

I’ve only got a minor nit to pick with his article.  Ade’s first myth is “Agile is a Methodology.”  This is either a myth or a truth depending on how you define methodology.

Like I said, it’s a nit.  His point in here is that Agile is an approach, not a step-by-step method.

 

Ade’s article is worth reading simply for his opening about “What animal is the king of the jungle.”

 

This excerpt from the article is one of my pet peeves, because I’ve seen so many companies slap the agile label on their waterfall process, and then complain about their lack of results.

Myth 4 – Labelling It ‘Agile’ Makes It Agile

As Agile practices grow in popularity, more and more organisations are becoming aware of the benefits Agile has to offer.

But rather than making the necessary organisational, cultural, and environmental changes required to achieve those benefits, many organisations are simply slapping “Agile” related labels on what they’re already doing, thinking that makes them Agile.

And when things don’t turn out as expected, Agile gets the blame.

But just as calling a dog a cat doesn’t make it so, re-labelling traditional software development methods “Agile” does not make them Agile. It takes more than that.

The Entrepreneurial Developer

Friday, March 29th, 2013

Welcome to Agile Slices; a series of quick pragmatic articles of about 200 words, intended to help you, your team and your business, harness the power of agility.

 

The Entrepreneurial Developer

 

When I first started programming, more than 20 years ago, I was hired by a guy to teach him how to program. After 2 weeks he looked at me and said, “You know, I see what you do, and I know I could do what you do. I just don’t want to, how about I hire you to do the programming that I want done?”

 

Over the course of the next two years I became the effective CIO for Athena Software. Athena Software was an award winning shrink wrap company that produced handicapping software for American football and basketball. It’s ironic that I’ve never been a big sports fan.

 

During that time, I was the business analyst, the architect, the database administrator, the programmer, the tester, the release manager and the support team.

 

It was obvious that programming was just one piece of the puzzle. An important piece, but not the be all end all of making a profitable company.

 

Later, when I got out into “the real world” I was surprised to find out that my skill set was not “normal.” Normal turned out to be testers who could’t code, developers who couldn’t test, and database schemas that were … lets call it, sub-optimal.

 

Since that time, I’ve come to describe myself as an entrepreneurial developer and I’ve found many others who share that mindset.

 

Entrepreneurial team members are an asset to your company because they focus on the entire value stream and have a primary interest in making the company more money. Entrepreneurial team members can be difficult. They’re opinionated, they tend not to tow the party line, and tend to ask uncomfortable questions. Worse, not only can they be a pain in the neck, if you’re not careful, they will be the first ones hired away if you don’t pay them enough, or if the work environment becomes unfriendly.

 

For all that, you want to have them on your team because they are self driven, they get stuff done and they have ideas for bringing more money into your company.

 

Stay On Mission.

 

If you have already used this slice, please add your voice to the conversation. If it 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 I was able to provide value to your life, please let us know what difference it has made for you or your company.

“On Time and On Budget” Doesn’t Matter

Thursday, March 28th, 2013

Welcome to Agile Slices; a series of quick pragmatic articles of about 200 words, intended to help you, your team and your business, harness the power of agility.

 

“On Time and On Budget” Doesn’t Matter

 

In most cases, a software project’s success is based on how well that project meets it schedule and it’s budget.

 

All that does is tell you how good your guessing engine is at prediction.

 

It’s also easy to measure, and I’m guessing this is the reason it’s used.

 

 

So what is a better measure?

 

 

How about looking at your business case?

 

Let’s pretend you have a project that has a schedule of 12 months and a budget of 1.2 million dollars.

 

Now lets say that you get 2 months into this project and your team tells you that it’s going to be closer to 18 months and closer to 3 million dollars to accomplish.

 

 

 

What do you do? Is the project a failure?

 

Who cares?

 

Check your business case.

 

If the business case says the project is worth 2 million dollars, then cancel it. You just saved your company a million dollars.

 

If, on the other hand, the business case says that the project is going to bring in 5 million dollars a year for the next 10 years, keep spending.

 

Was the project on time and on budget?

 

Who cares.

 

Stay On Mission.

 

If you have already used this slice, please add your voice to the conversation. If it 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 I was able to provide value to your life, please let us know what difference it has made for you or your company.

Are you Being agile, or Doing agile?

Wednesday, March 27th, 2013

Welcome to Agile Slices; a series of quick pragmatic articles of about 200 words, intended to help you, your team and your business, harness the power of agility.

 

Are you Being agile, or Doing agile?

 

Agility is being able to cross a stream by jumping from rock to rock.

 

If I teach you the steps to cross a particular stream, it doesn’t make you agile. The steps probably won’t transfer to the next stream.

 

Agile coaches often have the following “Who’s on first” conversation.

 

 

Agile Coach: “I’m here to help you be more agile.”

Customer: “We’re glad to have you, we’re having difficulties doing this agile thing.”

Agile Coach: “That’s great, but I need to stress that I’m here to help you ‘be’ more agile.”

Customer: “Exactly, so tell us how to do it.”

 

 

There seems to be a belief that a methodology is a set of practices. This belief is so ingrained that the Scrum folks bristle when you call it the “Scrum Methodology.” They stamp their feet and saying, “It’s a framework, not a methodology.”

 

It makes sense, the Wikipedia entry on methodology has this charming nugget.

In recent years, some have argued the word methodology has become a “pretentious substitute for the word method”.

 

In agile coaching, we are often told, “Just tell us which steps to take to cross this stream, and then we’ll cross all streams with the same steps.”

 

Agility is a capability, not a method.

 

Stay On Mission.

 

If you have already used this slice, please add your voice to the conversation. If it 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 I was able to provide value to your life, please let us know what difference it has made for you or your company.

Without this one thing, plans are worthless

Tuesday, March 26th, 2013

Welcome to Agile Slices; a series of quick pragmatic articles of about 200 words, intended to help you, your team and your business, harness the power of agility.

 

Without this one thing, plans are worthless

 

Fanaticism is defined as redoubling your efforts after your aim has been lost.

 

You can see this in companies that worship their plans.  Plans that are worthless because of one missing element.

Their project’s mission.

The mission (usually called business case) is the why behind the what.

 

Too many times I’ve seen plans hand down from on high with no indication of the why behind the plans.

A few years ago, I asked a senior manager at a large company if I could see the business case for the project team I was working with. His response was telling. “Why would we let our developers see the business case?”

 

Sometimes this makes sense, like when Company A is trying to fake out Company B by announcing that they are starting work on a product or a service that Company A has no intention of taking to market.

If Company A can get Company B to waste resources by building a product or service that no one wants, Company B won’t be in position to respond to company A’s real product.

 

But lets say a company is not bluffing and are really planning to use the software or service they are having built.

The team implementing the product or service may know of a better way of of accomplishing the mission than the industry “experts” who made the plans.

Ask yourself, “What is the mission behind our current work?”

 

Stay On Mission.

 

If you have already used this slice, please add your voice to the conversation. If it 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 I was able to provide value to your life, please let us know what difference it has made for you or your company.

Are your requirements are too expensive?

Monday, March 25th, 2013

Welcome to Agile Slices; a series of quick pragmatic articles of about 200 words, intended to help you, your team and your business, harness the power of agility.

 

Are your requirements are too expensive?

 

If you are working in a software shop, or if your company is producing software, the odds are high that your company is spending too much money on requirements.

This is natural because we live in a plan driven culture. The expectation is that we figure out everything that needs to go into the product before we start. This will allow us to take our completed documentation and hand it over the wall to a development group that will produce what we requested.

Chances are, your company is wasting money, because when writing requirements, we are at the lowest point in our knowledge of our customer real needs.

Remember:

Our customers will not know what they want, until we show them what they asked for.

 

This is why reducing cycle time is so important.

The shorter the cycle time, the sooner you can build what your customers wants to pay for, as opposed to what they asked for.

This is not to say that planning isn’t important, it is, but it’s important to only do the right amount of planning.

 

Ask your developers (in private) these questions.

Have you ever gotten requirements that were too detailed in certain places, but not detailed enough in others?

Have you ever gotten requirements that you didn’t have any questions about?

Have you ever gotten requirements that you didn’t have a hand in making?

Have you ever been told what to do, without being given an explanation as to why you were doing it?

 

Stay On Mission.

 

If you have already used this slice, please add your voice to the conversation. If it 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 I was able to provide value to your life, please let us know what difference it has made for you or your company.

Is your Continuous Integration tool doing to much?

Friday, March 22nd, 2013

Welcome to Agile Slices; a series of quick pragmatic articles of about 200 words, intended to help you, your team and your business, harness the power of agility.

 

Is your Continuous Integration tool doing to much?

 

Yesterday I said that a CI tool should only do 3 things, Poll, Initiate and Update.

 

Period. No more, no less.

 

I can hear you saying, “But my CI tool will do my checkouts, my compiles, run my tests and a bunch of other stuff too.”

 

You’re right, it can, and you don’t want it doing that for one big reason. You only want your build done one way.

 

Your build server, your developers, and your testers should all use the same build process. Unless you want your team to have your CI server installed on all their machines (and there are some decent reasons for doing just that) then they all need to be able to run the same single one line of code to do their local build, and run their unit tests.

 

When the build machine does the build and runs the unit tests, you want it to use the very same single line of code.

 

If the build is being created in different ways by different people or processes, sooner or later you are going to get bit by the differences.

 

Ask yourself, are all my developers, and my automated build process using the exact same steps to create the build?

Or conversely, have you ever had to figure out why the build on the build box was different that the developer build?

 

Stay On Mission.

 

If you have already used this slice, please add your voice to the conversation. If it 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 I was able to provide value to your life, please let us know what difference it has made for you or your company.