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.
If you have a distributed team or can’t get a regular meeting space in your workplace, online video conferencing may be your next best alternative for a Scrum team’s daily standup. While I always advocate for co-located teams with a dedicated meeting place for standups, I realize that this isn’t always feasible.
You’re probably well aware that it often takes a few valuable minutes to corral everyone together using Skype, Google Hangouts, or other online video conference tools. This can really eat into the efficiencies of a 15-minute daily meeting. I really like Sqwiggle, but it is limited to four active video callers at any given time. Google Hangouts supports up to 10 users and works relatively well, but sometimes it’s a hassle to get everyone in the same chat at the same time. (Have more than 10 people in your Scrum team? Please consider splitting that team apart for optimal performance.) Never fear: simple instructions follow. This works as of Feburary 28th, 2014.
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.
Many of you will be familiar with Peter Skillman’s Marshmallow Challenge, an exercise frequently given to teams and business school students. Teams of four are given 20 pieces of spaghetti, 1 yard of tape, one yard of twine, and a marshmallow. They are then given 18 minutes to build a free-standing structure that places the marshmallow as high off of the table as possible. The team with the highest marshmallow wins.
If you haven’t seen it already, Tom Wujec’s TED talk is a good place to learn about the challenge. And if you haven’t introduced your team(s) to it, take 45 minutes out of one of your days to administer the challenge and see what revelations you get.
If you’re local to Los Angeles and interested in learning more about Scrum and Agile, come to a LA Agile & Scrum User Group meetup! Tony Wong and Vladimir Drndarski will be giving a program on communicating product requirements in a Scrum environment. It’s free and there’s only 13 spots left (as of now), so sign up now!
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:
What do you think? What has worked well for you?