Jim Bo Rice, CSM, PSM I:

Much needed; great timing; thanks Ken!

Originally posted on Ken Schwaber's Blog: Telling It Like It Is:

Organizations usually don’t adopt Scrum because they like its name. Instead, they have heard that software development is better if they use Scrum – quicker, cheaper, higher quality, more satisfied customers and employees. Sometimes things are so bad in software development that they try Scrum just because it wasn’t what they were doing before.

However, adopting Scrum, becoming more agile and improving software development, costs money. It requires training, tooling, coaching. These are all investments. Scrum does not come with a set of tools for managing these investments, measuring the resultant benefits, and optimizing return on investment.

For the last several years, I’ve been developing a framework for managing this investment. It is called the Continuous Improvement Framework (CIF, yes, another acronym). CIF provides a set of management tools for continuously improving an organization and becoming more agile. Your agility is measured by metrics that reflect business value. The value…

View original 140 more words

Defend the Scrum Master role

Polling all Scrum apologists: Can you help me defend the value of the Scrum Master / Iteration Manager role?

Maybe it’s their [bad] experiences, or maybe it’s their culture, but I’ve been confronted on several occasions by developers who are convinced the Scrum Master doesn’t add value to the team. After all, they say, the SM doesn’t actually do anything. Really?? Where does this particular mindset come from? I just hope this doesn’t go viral, but I have been seeing this attitude in more and more places. Help!? Looking for a collaborative defense here, before I spout all my thoughts on the value the SM adds to solution development and delivery.

Is “overimprovement” possible?

I’ve been enjoying Tom DeMarco’s book, Slack.  It addresses the myth of total efficiency.  I’m gratified in that the picture that popped into my head, when I first contemplated reading the book and the idea of slack, was effectively the same used in his illustration of his point.  Remember playing with one of these?

sliding smile puzzle

Imagine for a moment that this represents a person, a knowledge worker specifically, and each tile represents a percentage of your utilization.  An efficiency expert comes along and, seeing people as fungible (which we are not), he notices there is a percentage of unutilized time – or slack (the missing tile). The efficiency expert then decides (quickly) that this person has some available capacity that could be utilized by someone, or for something, else.  So he fills in your utilization to 100% capacity.  Totally efficient, right?

Now imagine the sliding tile puzzle with no slack – no empty tile.  …Getting the picture?

Without any slack, there’s no room for change. No room for reinventing the picture.  No ability to respond.    So is total efficiency a good thing? If you think yes, cut me some slack!!  We absolutely can overimprove to the point that we are no longer effectively growing, evolving and remaining competitively successful in the market.

Myself, I need space just to turn around in. I need “some space to breathe in” (38 Special). And some slack to think in.  Come to think of it, why don’t we narrow the lanes in the roadways to the width of the average vehicle to utilize more pavement and get more vehicles on the freeways?  Crazy thought!! No thanks!

It’s a must read for leadership at any level. I hope my friends currenty emmersed in Matrixed Management will embrace this.

I don’t subscribe to Tom’s advocacy of the “Eve” persona, but ‘she’ makes his point. We want to grow and we want to learn (hence we need some slack in which to think and  discern, to imagine and to experiment, to fail and to learn.  But, sometimes it is good to comply to order, because sometimes “Don’t” means “Don’t hurt yourself”.

Any thoughts or insights on being “Overimproved”, as Tom describes it? Or on his book and idea of “Slack”?

I’m off to finish the book.

“While you were out…”

As I think more about addressing common User Story pitfalls, what keeps coming to mind is the idea of someone taking and noting a phone call for me while I was out.

I find the greatest challenge with user stories is indeed in writing them “right”.  Many Scrum teams struggle with this ‘staple diet’. Stories are not requirements on cards! (And Scrum is not waterfall on a board with daily status meetings!) As a visual aid to help form a better mindset on the best flavor and smell of user stories – expectations, writing, using, etc. – I offer the following image.

Think placeholder for a conversation...

Think placeholder for a conversation…

As Mike Cohn points out in his book User Stories Applied: For Agile Software Development, user stories are not requirements, they are prompts for a conversation with the customer and/or user. A story card, then, is only a placeholder for follow-up communication, to get confirmation. Paper cards used to note these stories may be useful in this format of a “while you were out” message pad. It contains just enough abstract content as to understand WHO to talk to about WHAT, and ideally WHY (but that can be added later once the reason is communicated and understood.)

So, think “While you were out” during story writing/workshops so there is a backlog of “calls to make” (or conversations to have) in grooming stories for release and/or sprint planning.


For [much] more on User Stories Applied, see the book of same name by Mike Cohn.

Scrum Master or Agile Coach, and other coaching categorizations.

This is such a poignant post I have to plug it on my blog. Kudos to you Sandy Mamoli @smamol

Excellent article on distinctions of Agile Coaching un die limited title of Scrum Master. An easy helpful read for all! See the article and supplemental comments here:  http://nomad8.com/types-of-agile-coaches/

Principles and/or Practices?

There are two basic and obvious approaches to looking for a new approach to software development: “Learn-by-doing” and “Understand before doing”.  Combining would be a third approach, and one that I leverage.

Thanks to @mpoppendieck, regarding #Principles and Practices of #Lean Software development, who offers, “We observe that the best results come from combining the two approaches. Copying practices without understanding the underlying principles has a long history of mediocre results. But when the underlying principles are understood, it is useful to copy practices that work for similar organizations and modify them to fit your environment. This can provide a jump-start to implementing the principles. This combination of understanding principles and adapting practices led to dramatic success.” – Mary Poppendiek

Agile “Best” practices: Really?

In practices that are true to Agile values and principles, are there any that are truly best?  If there are “best” practices I can simply plug in, then I have no further need for continuous improvement, right?  Or can I improve on what’s best?  Perhaps we should seek out “better practices”?

The 12th Agile principle from the manifesto states, ” At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior (practices) accordingly.”  Thus, if ever we think we’ve arrived, I suggest we’ve just failed to be agile.  If we feel we are doing what is “best”, we will tend to cease to be transparent, stop inspecting and adapting.

Any Agile development team, like any person, is only on a journey across a spectrum from lower performance to higher performance, from poor to great.  How great we become is limited only by how far we think we have left to go.  “Not that I’ve arrived, but I press on toward the mark…”.  So, through the lens of lean-agile values and principles, let’s look at “best” practices as, at best, better ways of doing things. And let’s press on to discovering even better ways, and “practice” them.

At the end of the day, I’m less concerned about how well we’re doing agile, and more concerned about how well agile is doing for us [the business].  After all, isn’t it business success that we care most about, not Agile per se?