14 Roundup: Agile 2011

We couldn’t attend Agile 2011, but we’ve been keeping an eye on proceedings and conversations since. Here’s a brief 14 Roundup:

  1. Most popular sessions from Agile 2011
  2. Abby Fichtner (@HackerChick) 10 Years Later, What’s Next for Agile
  3. Brief Synopsis of Linda Rising’s keynote
  4. Culture Matters by @jasonlittle
  5. Keynote from Kevlin Henny. We’ve got a lot of time for Kevlin for after hearing good things from his DevWeek sessions. Slides here.
  6. Good round up by @llangit: A technical conference filled with women
  7. Interesting visual realtime feedback mechanism for speakers using index cards
  8. Good slides from @josephwilk: Acceptance Testing in The Land of The Startup”
  9. Good intro to DevOps from Eric Minick
  10. A bunch of video shorts from Agile2011
  11. @ChristopherAver‘s talk on Getting People to Take Responsibility & Demonstrate Ownership was one of the most popular
  12. Added 28/08: @YvesHanoulle has an Agile 2011 book list. Yves put together an Agile 2010 book list, but couldn’t be at Agile2011. This year’s list was done remotely in the spirit of last years.

If we’ve missed anything we should really have included, let us know. We’re after 2 more!

Posted in Roundups | Tagged , | 1 Comment

Scrum Guide 2011

In mid July, Ken Schwaber and Jeff Sutherland updated the Scrum Guide. The Scrum Guide is the “definitive rule book of Scrum and the documentation of Scrum itself” and the changes are intriguing to say the least.

A summary of the changes in Scrum Guide 2011 were made by Schwaber and Sutherland themselves on July 21st. Here they are summarised along with our thoughts.

Change #1: Development Team

“The team of people performing the work of creating an Increment is the Development Team. Regardless of the work performed by individual team members, they are known as Developers.”

We’re averse to siloing.

We worry this statement further pigeonholes very capable and intelligent people into a big “developer” bucket. We’ve been encouraging our development teams to read, watch and deeply understand everything from Eric Reis, Steve Blank, Ash Maurya, Dan North, Edward Tufte, Ryan Singer, David Anderson (the list goes on, and on).

Learning is everything.

We encourage our development teams to think outside of their development mind set. To be passionate, capable developers. But also be aware of and be able to contribute to the bigger picture.

Sure, some developers don’t want to.

The developers that do grow exponentially.

Change #2: Commitment

“Development Teams do not commit to completing the work planned during a Sprint Planning Meeting. The Development Team creates a forecast of work it believes will be done, but that will change as more becomes known throughout the Sprint.”

Commitment is dead? Hooray!

It’s been dead to us for a long time (although in times of need, we have swung back to it on occasion).

This change is the biggest nod towards the Kanban and the Limited Work In Progress movement. And we fully agree. In fact, we’d go further, and argue that the ‘Development Team’ should spend as little time as possible putting together this “forecast”. If you use evidence, flow, and roughly-equal sized work items, you’ll end up with an exceptional measure of past progress for virtually no effort.

Change #3: Burndowns

“Scrum does not mandate a burndown chart to monitor progress. Scrum requires only that a) Remaining work for a Sprint is summed and known on a daily basis. b) Trending toward completing the work of the Sprint is maintained throughout the Sprint.”

Finally. I hope CSM’s around the globe don’t cry into their soup. If you use effective Visual Management you have never needed a “burn down” to see if you’re on target!

You (and all interested parties for that matter) can see progress with your own eyes by looking at where cards are on the board.

Measuring progress towards the end of an iteration is substantially less useful than  empirically measuring your performance over time: lead time, cycle time, & cumulative flow.

Grand, less busy work.

Change #4: Release Planning

“Release Planning is a valuable thing to do when using Scrum, but isn’t required by Scrum itself.”

This seems like another nod to the rising up of Kanban. Depending on your execution of Release Planning, we either fully support or have issue with this change.

Someone (product owner, product manager, whatever you call it) must be looking at regular, coarse grained goals – ideally through the eyes of Customer Development. That role has to and will continue.

If you’re of the “sit everyone in a room for 2 days and release plan every single item in a 300 item backlog” then yes, we fully approve. That approach should be put into a potato sack and eradicated.

Change #5: Single Backlog

“The Sprint Backlog is the Product Backlog items selected for the Sprint, plus a plan for delivering them. There is no longer a required concept of “Sprint Backlog items” although that technique can make a great plan. A self organizing Development Team always has a plan.”

This is a positive move towards “flow”. The dual concept of “Sprint Backlog” and “Product Backlog” has always been confusing for people first coming to Scrum. It is something we rejected long ago – a single “Backlog”, and you work through the top backlog items as quickly, smoothly and sustainably as possible.

Change #6: Ordered not prioritised

“The Product Backlog is “ordered,” instead of “prioritised,” providing flexibility to the Product Owner to optimize value in his or her unique circumstances.”

“Priority” is such an abstract term – you can prioritise by any set of rules or constraints you choose. Anyone who has performed the product owner role will know that the set of rules or constraints for “prioritising their backlog” is not as simple as just ROI, or just “business value”.

For us, an “ordered” backlog and a “prioritised” backlog have been synonymous for a very long time. In fact, since the dawn of anyone using Scrum. Think about it for a minute: anyone who’s ever had to manage development priorities will know they can’t prioritised by ROI solely. As soon as you do this your development team will say “we can’t build C before A, so we need to do A first”. A good development team will push back for business reasons also: “We could develop B in 1/2 the time of A, and we believe B will have more of an impact on monetization. Why wouldn’t we do B first”. This change in the Scrum Guide is very subtle.

The explanation given by Schwaber and Sutherland does little to clarify. This may just be a result of many practitioners understanding the concept of “ordering” backlogs for a long while.

One change in the comments from Schwaber and Sutherland is valuable. No two items can have the same “priority”: the backlog must be fully ordered. This is really first-baby-step stuff though.

Overall, it’s good to see the Scrum movement adopting and changing to the times.

What are your thoughts on the changes in the latest revision to the guide? Let us know: @14principles

Posted in Agile | Tagged | 4 Comments

Visual Management – Part 4 – Colours

Specialisation in Generalism

When working in cross-functional teams, try to reduce the dependency on “specialists”. Whatever your definition of specialists: tend towards generalists. In other words: everyone being able to chip in. Nobody owns a castle.

This doesn’t mean that talented people lose their specialisation.

It’s not black or white.

Someone who’s strong in one area will remain that way. However, expect specialists to learn other skills, and pass their skills on to others too. Specialism can result in `hit by bus syndrome`: If said specialist got hit by a bus, will your team/business function in the aftermath?

Do you have a specialist who’s unwilling to mentor, coach and pass on their specialism? Are they really a healthy part of your organisation?


We work in the games industry. Being a heavily creative industry, we certainly end up with our share of characters, and specialists. In games, hard discipline boundaries exist: that’s the whole point of being on a cross-functional team: using your different skills; working together to deliver something people really want.

Games development has historically broken down into the following skills: artists, programmers, designers, audio, quality assurance, and production. Whilst there is room for some cross-over, some disciplines have hard boundaries. Some engineers are actually very good artists (in their own way). But you don’t want engineers creating artwork. In this instance, separation of skills is not just desirable, it’s required.

This is also very true in other industries.

Different skills pull differently

To complete a `user facing feature` we pull on each of the required skills; some user facing features have different demands on these skillsets:

· Some features will be code-heavy.

· Some features require little to no code but heavy art work.

· Sometimes bugs spike up.

We try to identify work items that have an equal pull on the different skillsets. But that’s not always possible.

In teams with hard skillset boundaries, the contention for the different skillsets has always been a sore at one point or another. As we mentioned in the last in our visual management series, one visual solution is to stop fine-grained estimation and visually estimate coarsely. Another visual solution is to colour code work by skillset.

Colourise Skill

To let everyone see what’s happening, we visualise these different skill-dependant tasks using coloured stickies on our team boards. One of our very valued colleagues (@CJIsaacs) suggested we give it a try. We’ve found it extremely valuable:


This simple, colourful board is exceptionally powerful. Take a look at the following boards:




At a glance you can see:

· The green board is art heavy. Everyone else needs to do everything in their power to help the artists get their already overloaded. Certainly don’t start creating more green work…

· The orange heavy board clearly indicates something very wrong. A large spike in defects; Why?

· The evenly coloured board is showing a pretty good mix.

· If I’m an artist, and I’m looking for my next bit of work: I can go to the board and find green stickies.

This approach really unlocks the power in the principle: “use visual controls so no problems are hidden”.

Posted in Tactics, Visual Management | Tagged , | Leave a comment

14 Roundup – 7th August 2011

This week:

  1. Why Lean Startups are hard by @kevindewalt
  2. We covered Lean from the Trenches by @henrikkniberg a couple of weeks ago. It’ll be published by Pragmatic Bookshelf, but the draft will remain free. If you haven’t already, check out Scrum and XP from the Trenches, and Scrum and Kanban: Making the most of both.
  3. @YvesHanoulle has a moving and personal piece on taking a positive look on the worst situations
  4. 12 Tips for Customer Development interviews by @giffconstable
  5. Agile 2011 is getting underway in Salt Lake City, see @agile2011 and #agile2011
  6. @mhsutton can’t make agile2011 so is using XTC in London on the 9th for notgile2011, see #notAgile2011, #xtc
  7. Lean Startup Machine bootcamp in London, 16th Sept.
  8. Scott Adams on Boredom is a brilliant take on lack of downtime, or the need to prioritise downtime…?
  9. Step by Step Lean UX by @digitalwoman
  10. End with the beginning in mind, an excellent take on ending relationships (personal and business) from @ChristopherAver
  11. Exceptionally good non-vanity metric post on techcrunch about social/casual gaming company OMGPOP
  12. The rise of the (shitty) landing page is an excellent take on how people misunderstand and incorrectly execute on the initial steps of Customer Discovery. By @vngh0st
  13. @sgblank on Bonfire of the Vanities
  14. @kjscotland on Crystallising Kanban with Properties, Strategies and Techniques

Couldn’t leave out a funny picture linked from @lisacrispin showing the current state of browser wars.

Whilst we can’t make #agile2011 we’ll be keeping an eye on proceedings. Expecting some good finds next week.

Posted in Roundups | Tagged , , | Leave a comment

Visual Management – Part 3 – Estimation Matrix

Relative Estimation at near zero-cost

We’ve been through the full spectrum of estimation, as I’m sure a few of you have. From Gantt charts demanded from above to zero-estimation derived from below.

We’ve come to a conclusion*: Fine-grained estimation is ultimately wasteful. Tend towards zero-estimation.

Meet the The Estimation Matrix.

You need:

  • A cross-functional team
  • A week
  • A prioritised set of work, of roughly equal size (i.e. 2-3 days per `work item`)
  • A limited work in progress (of say, 3 work items at once)

Here’s how:

  • Draw up a Matrix on a small, portable whiteboard (say 5ft x 4ft).
    • X Axis: Monday, Tuesday, Wednesday, Thursday, Friday
    • Y Axis: Number of `lanes` that your Work In Progress limit(s) allow
  • Get the team to `best-guess` by sticking cards on this Matrix. For cards that take longer than 1 day, draw a line to when the team think they’ll finish.
  • Take a photo of this board, and email it around: It’s your set of work and importantly when the team thinks they’ll have it done by.
  • Put the board up in the work area for all of the team to see.


The Effect

This is another simple but highly effective tactic. As with all estimation exercises, it helps the team understand the work at hand.

The team can visually score off cards and see the week progress. This is substantially less abstract than a burn-up, burn-down or cumulative flow graph. It’s simple, the team just get it.

Leave the matrix up on a 5ft x 4ft whiteboard. This lets the team see how they are progressing. The same benefit as a burn up/down chart but for 5% of the overhead.

The Cons

A major benefit of planning poker is everyone has to contribute. Everyone has to pluck out a card. People can’t just sit back and follow the alpha-types. You need to balance this against the time it takes: we’ve sat through multi-hour planning poker sessions that add no value.

Substantially less empirical: This is certainly true. But as we’ll show you in a later article, you can actually get substantially more empirical by measuring more effectively.

The Power

The power of this approach comes when combining with cumulative flow and empirical evidence. With near-evenly sized work items and measuring cumulative flow – you’ll be able to predict based on evidence for near-zero estimation cost. But more on that later….

Proof is in the pudding

We’ve been using estimation matrices as a handy 5minute `best guess` for a good while now. Although we Limit Work in Progress and we believe commitment is dead we’ve found estimation matrices a good proportional investment to the estimation problem. They really help visualise the old prioritisation problem of: “OK, we can’t fit this in but you’re asking for more? What’s going to give?”

Here’s a few of our estimation matrices over the last couple of months.


*no conclusions are permanent. Given the same set of inputs, we’d arrive at the same result. If our inputs change, we might well end up at a different result.

Posted in Tactics, Visual Management | Tagged , | 1 Comment

14 Roundup – 1st August 2011

It’s time for the shiny that’s caught our eye this week:

  1. Interesting to see another publishing/lean startup post. @LeanBlog writes about applying Lean Startup to book publishing.
  2. Interesting take on finding the right champion in an organisation from @flinchbaugheven if that means it’s not the CEO
  3. Don’t Be Fooled By Vanity Metrics on @TechCrunch
  4. “You Are Solving The Wrong Problem” – Another Boyd’s Law one by @dumontis
  5. Interesting take on hiring based on interest rather than credentials.
  6. Answering the loaded question via @ProjectRecovery
  7. Funny quote: “If you ain’t making waves, you ain’t kickin’ hard enough.” – Anonymous #startup #business #marketing via @TriKro
  8. Requirements driven development must die via @TriKro
  9. @kjscotland on InfoQ: Kanban System Design
  10. Bank of Australia using methods from software development for product development via @agilescout
  11. Interesting Pivot snippet. Agree with the overuse and misuse of pivot, and also agree with the ubiquitous language: @tobins: Look, @ericries I love #leanstartup but the overuse of the word #Pivot is getting nuts! Can we @pivot from the word @pivot? @tobins @ericries it’s true that pivot is often misused, but any word you use in it’s place will have the same fate. I will keep using pivot
  12. Via @clintonkeithPMP in Games
  13. If it’s not a hit, switch
  14. Go Only As Fast As You Can Learn by @ashmaurya
Posted in Roundups | Leave a comment