Strongly Recommended Agile Learning Resources

One of the things that I think holds Scrum teams back from being successful is that they often learn about the Scrum process but don’t learn about Agile culture or infrastructure. Because Scrum is a system that relies on all of it’s parts, failure to master Agile culture and infrastructure means that companies will also fail to master Scrum. This failure is unbelievably costly for companies and teams: “average” teams deliver only a 35% improvement over Waterfall, while properly coached teams deliver 300-400% improvements. I’ve seen this myself in my time working with Scrum teams at Atomic Online: once a team got properly coached and running, we were at least 3-4x as fast as when we started. This is rare, too: I have not yet worked with a team that has outperformed the teams I worked with at Atomic Online.

I think we owe it to ourselves as members of Scrum team to learn about and embrace Agile principles. This is hard to do without a “sensei” (a well-experienced Agile leader) who can can conduct gemba walks with incumbent leadership to bring about organizational transformation. In lieu of that, though, here are some resources that I hope can help to at least illustrate the difference between a true Agile/Scrum/Kanban environment and a waterfall environment that has adopted a few Scrum processes.

(more…)

2016-02-01T15:26:43-08:00March 5th, 2014|0 Comments

Mary Poppendieck’s “The Tyranny of ‘The Plan'”

A couple of years ago, my former manager David Denton forwarded me a recorded presentation by Mary Poppendieck, a leading Agile software development expert and co-author of the popular book “Leading Lean Software Development: Results Are not the Point.

Watching the video on the InfoQ website is a bit kludgey and Mary has lots of wonderful details that are worth hearing. So, with Mary’s permission, I’ve had the video transcribed and included her slides in context. I hope that this will make this very useful knowledge easier to find and learn from. Mary, thanks again.

I’ve eschewed block-quote formatting as it made this transcript a little harder to read. I’ve also edited slightly for readability. Otherwise, everything beyond this point is Mary’s work.

(more…)

2014-03-11T21:07:03-08:00September 20th, 2012|8 Comments

I hate priorities

More specifically, I hate numbers or letter representations of priorities when it comes to product backlogs.

It’s a common strategy, even in Scrum. (Henrik Kniberg’s wonderful scrum book talks about a product backlog where higher priority items get higher priority numbers, preventing the “if this is critical and priority 0, what is ultra-critical? priority -1” issue.)

So why the hate? Simple – they do a lousy job of actually priortizing tasks. How many times have you encountered a product backlog where there were several items that were all of critical importance? How is this truly helpful?

Think of it in this way – what if half the items in your email inbox were of CRITICAL priority? At this point, what value does this tag add? At the end of the day, you’ll have to choose ONE thing to do next. What will it be?

I therefore argue that it’s exactly this hard decision that needs to be made earlier in the process, with the stakeholders who will wonder why this critical priority issue took precedence over that critical priority issue.

The real issue is that priority values attempt to apply a rigid metric of ABSOLUTE priority when the only thing that matters in the real world is RELATIVE priority – what do we do next? Even if you have the ability to complete work in parallel (e.g., more than one developer), you still need to figure out what those n people will do next.

Therefore, I propose that we kill the concept of priority values in the agile workplace.

Take your product backlog, remove the priority column, and sit down with the stakeholders. Don’t walk out of the meeting room until every item is sorted in order of relative priority.

The rest is easy: in your next sprint planning meeting, figure out how many story points you have available and work down from the top of the list. There are only two exceptions:

  • When the developers believe that two pieces of work are similar enough to realize greater efficiencies if completed together. If this happens often, you need greater developer involvement in the priority setting meeting. 
  • When the remaining story points don’t support the next priority item. For instance, suppose there are 3 remaining story points but the next item in the product backlog requires 5. It’s OK to scan down a little and take the next item at or below three points.

What do you think? What has worked well for you?

2008-03-09T10:06:04-08:00March 9th, 2008|3 Comments
Go to Top