Marcus Hammarberg

+ Follow
since Aug 07, 2013
Marcus likes ...
Mac OS X Windows
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Marcus Hammarberg

Congrats all winners!

Thanks for some truly great questions and keeping me (and my mind) on my toes!

Nice meeting y'all!
Grasshopper [grinning]

I'm struggling with that from time to time. I think our industry as a whole often seek solutions rather than ideas.
Solutions can be implemented straight off. Ideas needs to be thought over and adjusted to our context. That's harder. But more rewarding.

You're doing great Burk! Keep it up and you'll inspire others too.
you know the answer to this one... Search within...

It's up to you :P

But common things are:
- swimlanes
- different colored stickies
- turning stickies on their side

The important thing here is the policy that you associcate to the class of service and how you, as a team, remembers what to do around them.
It is in reality just policies around how you should treat work of certain type.

For example: urgent items should always be prioritized over all other work, only one urgent item is ongoing at the same time and we always do a retrospective after each to ensure that we learned from it.

We haven't seen a lot of teams being so advanced that they are using classes of service extensively but it's a very powerful concept that could assist the team into becoming more self-organized.
It would sure be a lot of change either way, but at the time (and always?) it felt that it was a lot of things to keep in our heads at the same time
The coin flip (we call it Pass the pennies) is awesome.

We haven't included any Lego games, but there are some of them too. Often too big to setup.

My favorite is called The Dot Game and is described in great detail in the book. It both is a great simulation but also makes the transition into "reality" easier when you discuss the game afterwards.
Yes, keeping them all "in progress" meant that we had a lot of stuff moving around at the same time

(the book will probably be around 350 pages actually ).

You're bang on target! There's just three very simple principles, but following them with lead you towards improving and changing your process. That in turn might require you to use a lot of other practices and techniques that you might find helpful and motivating. The book teaches you a lot of those, but the underlying theme is that there isn't anything that we can say works for every situation.

The best you can do is the fill your toolbelt with a lot of practices and a solid know-how of the principles and ideas that is underlying the thinking behind kanban (and Lean).
Our book teaches you both - from a very practical viewpoint.

chapter 9 is really just a collection of practices and concepts that teams that are using flow-based approaches (that kanban often leads too) can benefit from using.

It also shows on the problems with some of the practices that we take for granted (such as story points) and what you can use instead.

Finally we talk about the need for planning and estimating and that many teams, that use kanban and other agile practices for awhile, see goo away. The need for big plans for long periods of time is not that valueable for teams that can change fast and be agile in what they can do and deliver.

there's a number of Lean simulation that shows on the benefits of lowering WIP and how that can help you find and expose problems.

Then there's a couple of kanban simulation games that actually help you dry-run using kanban. They are a very good introduction to kanban.

I have had great use of these exercises and games to teach concepts and show situation that can happen in real life, in a more controlled environment.
Well, that was not hard to understand given my description.

But we introduced a story in the first chapter and wanted all the other chapters to point back to the story from time to time. That meant, in reality, that we had to rewrite them.
Well... there's the one where we realized the problems with lot of things going on at the same time. Lots of WIP in other words.

We had about 6 chapters going on at the same time. When the first of those was completed we realized that we wanted another introduction. And in the process had to rewrite the 6 chapters.

If we only have had one or two chapter the damage for such a change would have been considerable smaller.

were hoping that the book will be live in November. But you can get the complete book as a MEAP (Manning Early Access Program) from the end of this month

We have used a variety of kanban techniques in our work with the book. We've written about some of our failures to do so in the book.

Junilu Lacar wrote: If kanban is about improving process, does it have a narrow focus or does it help you take a more "systems thinking" view? One problem with immature teams is that they often don't know where to start making improvements. They can identify a multitude of things that they need to improve but have a hard time deciding where best to start so that they can see results quicker and get the most out of their efforts. Is this something that the book touches on? That is, does kanban help develop systems thinking, looking at things more holistically (e.g. at the team or group level) vs local optimizations (e.g. individual performance)?

Hi Junilu,

thanks for your questions. The thing with kanban is that it doesn't really care or is limited to the personal or team level. It will reveal your "improvement opportunities" to the level where you apply it. If you apply it on the team level you will start find ways to flow work faster through the team pretty soon. What often happens though, is that after awhile you'll reach the limits for you team, and will have to start interact with and improve outside your team, with other functions or people

For example, let's say that you have a separate department doing deployments. If you start flowing work through your team fast, you will still end up waiting for the deployment department. The focus on lead time (the complete time from idea to production) will be slowed down by waiting for the deployment department. This is now your next problem (oh sorry improvement opportunity) to solve to gain even faster flow.

Kanban sadly don't have any patented one-size-fits-all solution (nor should you trust any method that claim to have so). Kanban simply showed you the problem, by focusing on shorting lead-times. What you do about the problem is what decides if you will improve or not.
For awhile i called kanban for "problem finders" because that's all they really is. They show you problems. Problems that, if you fix them, will help you improve.