Archive for the ‘Agile Adoption’ Category

Can you fill in this line? “If … you might be doing #redneck-agile.”

Wednesday, August 6th, 2014

I just ran across this gem in an agile open group on LinkedIn ‘Discover how to develop “bug free” software projects using Agile based project management tool’ followed by a link to a sales page.

I couldn’t help myself, I started laughing.   I could just imagine it, somewhere, some poor PMP is excited, because finally, they can “buy agile.”

I could also imagine the Jeff Foxworthy of geeks, drawling ‘If your senior managers, keep equating “the right tools” to “agile” … you might be doing redneck agile’ (Except the JFoG in my head was much funnier)


Heinlein once said “I’ve found out why people laugh. They laugh because it hurts so much . . . because it’s the only thing that’ll make it stop hurting.”

He also made reference to the coercive effects of humor.  You can influence people’s behavior more by making their behavior a punchline, than you can by all out education.

Just maybe there is some concise wisdom out there that can be used to help people lighten up and understand that making mistakes on the road to agile is a part of being on the road to agile.

So I’m asking for help from the agile community.  There’s a bunch of y’all out there that are funnier than I am.  Can you craft your painful, yet funny experiences into the form of a #redneckagile joke?







3 Secrets To An Agile Mindset

Wednesday, April 23rd, 2014

Recently I was asked how to position oneself from being a project manager to being a product owner and I came up with the following list


* Read the agile manifesto and underlying principles once a day for 30 days and then monthly until you leave the industry (it’s 267 words, it won’t take that long – 3 – 5 minutes each time.) and

* Watch Fred Kofman’s talk ” Doing Your Job May Be Hazardous To Your Career” (13:55)

* Take Steve Blank’s “How to build a startup” course (it’s free) (That’s about an hour a week for about 8 weeks)at


In the process though I realized that this list applies to anyone who is doing anything with agile software development, and possibly anything to do with starting their own business.


If this post has been useful to you, please comment below and forward it to your friends.

If this was forwarded to you, the original can be found at or at

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 miracle

Tuesday, November 12th, 2013

Up until the lurching non-roll out of, 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


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.