Wednesday, July 5, 2017

On Thomas Paine and the Dunning Kruger Effect (Part II)

A new team without any experience finds the adoption of the Scrum Framework seductive.  They observe that others have achieved success with agile, and so, why not us?

Sounds good!

They pick up boilerplate like The Scrum Guide, introduce electronic card walls, and start speaking jargon like "story points," "backlog grooming," "prioritization," "sprints," and "velocity."

When they reveal this to leadership, there is enthusiasm and buy-in. They are heralded as an agile example for others to follow.

Upon closer scrutiny, there are 30 cards in the "doing" column, assigned to various combinations of 5 or 6 people. 

But two of those people are out at a customer site, and another is on vacation.

Some cards in "doing" have not been updated in months.

To complete any one card takes many-many weeks. Whenever the board is occasionally inspected, people are assigned, un-assigned and re-assigned without notice. Due dates are pushed further out into the future.  

There is no indication on the card for whom the work is done, or who has a stake in the outcome.

There is a marriage of those who created the card wall with the wall itself. For everyone else, there is a lack of understanding of the cards on the wall and their purpose.

When good-faith changes are suggested to promote clarity, controversy erupts and change is dismissed out-of-hand. 

"Why do we call it backlog when what we mean is committed?"

"Because everyone else calls it backlog."

"We cannot possibly be working on all the cards in the 'doing' column."

"Yes we are."

I conclude this parable with a question:  what do you think will be the reaction of leadership when they see this card wall at the next quarterly meeting, and it's impossible to see that any of the cards moved, or that any work got done at all?

Saturday, July 1, 2017

On Thomas Paine and the Dunning Kruger Effect (Part I)

A couple of recent experiences have led to the following sequence of posts.  This one relates the first.

It was in my role as the engineering manager of a team of Extreme Programming [XP] bootcampers, none of whom had more than a year of practice.

Our first recruit for our tech lead role was an agilist I knew from a prior shop.  He came to the table with more than 20 years of practice, versed on all the current platforms (web and mobile), and more than 10-years of experience in XP.  He was a little rusty from a recent hiatus.

We governed by consensus, and when we convened at the end of the day to decide, the vote was not to offer him tech lead, but at the entry level, my vociferous opposition notwithstanding.

Of course, the candidate, knowing his salt, declined our offer and joined a well-known XP boutique.

Some months later, after my team had gained some practice, I heard from more than one of our members that they would have voted to hire that candidate had they known then what they came to know.

Why could my team not see at the time what was so evident to me?

Now, the experience with this team was rewarding in light of how much we learned.  When our team went our separate ways, everybody upped their game:
  • we sent our youngest member onto his current role at Google; 
  • the defacto team lead went from no experience in the functional style to practicing backend Haskell;
  • our HTML/CSS designer went on to practice node.js, mongoDB and Redis; and
  • I recently had the privilege to recommend our newest member for his new role after his stint practicing hard-core Ops on docker/kubernetes.

But the question remained to this day and recurred again to me recently:
  • what caused my team such clarity of hindsight about a decision with which they previously disagreed?