scrum - Matt Kimber

Matt Kimber

scrum

A collection of 8 posts

Methodology? What Methodology?

Methodology? What Methodology?

I think I'm getting kind of post-methodology in my thinking. I don't really care what it is or what it's called, but I do care that it facilitates three critical things

Too much in flight

In a Scrum context, multitasking is bad. Teams who follow Kanban will be familiar with this concept, as that process invites you to explicitly set your lane limits up front - only 3 things in progress, only 2 things awaiting product owner review, only 7 tickets waiting for release, and

The Backlog

I had one of those "changing the way we work" discussions today, about the product backlog. I'll spare you the details, but it came down to answering two questions: 1. How many of the stories we know about should we have on the product backlog? 2. How many of the

Working with both physical and electronic progress boards

Yesterday in a retrospective one of my teams asked a question which is all too familiar: "Updating both a physical board and an electronic board to track our progress is a bit annoying - can we get rid of one of them?" So we had a bit of a discussion,

Kaizen and Scrum

Kaizen, the process of "improvement" in the Toyota Production System, is a valuable complement to Scrum, based on many of the same principles. It means teams can get effective results both from their retrospectives and daily attempts to resolve waste. At the core is a variant of the PDCA loop

Waste

What's the difference between a merely good Scrum organisation and a great one? The answer is waste. Waste in a Scrum context is loosely defined as any activity which does not result in something the customer uses. At its most obvious we're talking things like TPS reports and bikeshedding, but

Be careful with "Modern Agile".

organisations Featured

Be careful with "Modern Agile".

I have a problem with a lot of the recent advice suggesting firms looking to adopt agile practices should eschew the stand-ups, estimations and fixed iterations of Scrum. Which is strange as a lot of that advice is coming from respected, experienced Scrum practitioners. However, I think what's happening is

Painting by numbers

I'm a real fan of estimating things by doing relative sizing with planning poker cards. The cards mean everyone gets a say, the Fibonacci-like number sequence of the deck avoids getting bogged down in differentiating between tiny graduations in task complexity, and the relative nature of the sizing… ...well, that