Crisp's BlogPage 28

How would you present Scrum (agile) and Kanban (lean) as building from a common principle? What is the common core of these methods? These questions were the topic of recent discussions with colleagues agile coaches Joakim Sundén and Marcus Hammarberg. Based on our reflections, I would like to propose – yet another – definition of

Here’s a video recording of my 10 minute lightning talk "Kanban vs Scrum, a practical guide" at Agila Sverige June 8, 2009. It is basically a 10 minute summary of my book "Kanban and Scrum – making the most of both". NOTE – the recording is in Swedish.

My and Henrik’s book on is out. Get a downloadable version, or buy the full copy at InfoQ. The book includes: Foreword by Mary Poppendieck and David Anderson A comparison of Kanban and Scrum – their approaches as process tools in software In-the-trenches case study of introducing Kanban in operations Hope you enjoy the reading!

For further reading about the case study,  see my presentation at Devopsday’s 2009.

My new book "Kanban and Scrum – making the most of both" is done! The purpose of this book is to clear up the fog, so you can figure out how Kanban and Scrum might be useful in your environment. The book includes: Foreword by Mary Poppendieck Foreword by David Anderson Updated version of my

Here’s a Traditional Chinese translation of my book Scrum and XP from the Trenches (not same as Chinese translation). Thanks Ko Jen-Chieh! The other 8 translations are listed on the InfoQ page for the book. Feel free to email me (henrik.kniberg AT crisp.se) if you want to translate the book to your language.

Configuration Management (CM) is crucial to any software project as neglecting it will easily get you in big trouble. It may look like bad luck, but it is not.

A CM-plan will deal with several matters, from simple to decide things, such as naming of releases to more advanced subjects, such as branching strategy. I will talk about the latter today.

There are of course different ideas about what a good branching strategy should be. It is my firm belief that it must be aligned with the subject at hand, namely changes.

If you are near Atlanta and want to meet me and the rest of the Agile Alliance board feel free to come to our Agile Alliance Board Reception on wednesday evening! We’ll host a winter holiday networking reception for Agile Alliance members, partners and friends. We’ll provide refreshments, a preview demo of the new website,

Ever had this thrown at you?

"This production bug is unacceptable, it must never happen again!"

And that event, outside your systems control, formed a policy that affected all your every day life. Failure to distinguish between uncertainty under our control and uncertainty imposed by outside events is a bad management habit.

Instead;
"Manage the normal – treat exception as exceptional"

And have a happier life 🙂

Nu när det finns en första "Hello, World"-version av Eats-o-matic i drift, är det dags att fundera på allvar på den vidare utvecklingen.

För att det skall bli något så behövs det bland annat möjlighet att lagra data, samt ett ramverk för att skapa själva webbapplikationen med.

Jag har kollat igenom ett antal av de alternativ som finns för GAE och kommit fram till ett val som jag tror passar mig som utvecklare och Eats-o-matic som applikation.

Google har en Eclipse-plugin som automatiserar bygge, integrationstest & driftsättning av applikationer för Google App Engine.

Men hur gör man om man liksom jag tycker att det skall gå att bygga och driftsätta från kommandoraden?

Mitt svar är Maven. Tyvärr finns det inte (ännu) någon Mavenplugin, så det blir lite meckigt att få det att fungera.

Feeling busy? Not ready when the deadline approaches? Many things in action?

Maybe you should consider a personal kanban. Now,  I will admit the first to admit I heard about the concept I thought "but isn’t slight over administration? What about just saying no?" But not all events are under our own control and as this story will tell; I’m now convinced it actually works.

The personal kanban can help address three problems:

• "Constant reprioritization"
• "I need to be able to focus"
• "I want to feel the reward of completing work"

Det är mycket prat om Cloud Computing nuförtiden. Amazon EC2, Google App Engine, SpringSource CloudFoundry, och nu snart Windows Azure.

Detta är första delen i en serie som beskriver utvecklingen av Eats-o-matic, som kommer att köras på Google App Engine (GAE).

Häng med!

This coming spring we will host a course with Robert C Martin on advanced TDD. I would really appreciate the input from my experienced TDD readers on what they consider to be the largest obstacles when it comes to TDD. This is your chance to shape the event so that it is customized to meet your needs.

A few months ago we hosted a very popular course with Michael Feathers. He talked about refactoring legacy systems and of course, unit tests which are an essential part of that. But the crowd cried out for more.

I have been practicing TDD for two years. I program in Java and frequently use Mockito and Wicket. The latter has support for unit testing web interfaces and it is great although it has its quirks.

But what is everyone else doing?

Here the the slides from my presentation "Kanban and Scrum – a practical guide" from QCon in San Francisco today. The presentation is mostly pictures. If you are curious about what I was saying, check out the free online book “Kanban and Scrum – making the most of both”. Great feedback! 77 green notes, 7

Why do we level out? In many agile teams I have met the introduction of Agile methods have made the teams to take a big leap. But then, after a while, they level out. Why so?

I will present at the Lean Software & Systems Conference, April 21-13 in Atlanta.

 Looks like a promising event, with speakers like Don Reinertsen and David Anderson.

Ps: There are some new exciting events in Stockholm this spring coming up with David Anderson, stay tuned.

Here is a detailed example of a fairly typical 2-tier Kanban board, for teams that know the basics of Kanban and are taking their first steps towards implementing it in practice. It is sort of like a code example, or a condensed Kanban patterns repository. Print it out and use it as a source of

Doing kanban, there will come a point where you will be faced with holding or breaking the work in progress limit.  Here are fours ways of dealing with that situation:

• Case1: Urgency!
  The new story has higher priority than work on the board.  Accept a temporary violation of WIP, but don’t starting more work until WIP is balanced again

• Case2: Pleasant "no"
  Bring the stakeholder to the board and ask them if they would like you to throw away for  the benefit of their request.

• Case3: Can’t say now for Legal reasons
  Start an overflow section. Whenever WIP risk being broken, compare the priority to what is on the board and if it is less put the work in a overflow section. The policy  being: to put something on the overflow secion requires an email to the sent to the stakeholder saying you can’t do it right now but you may do it somewhere in the future (best solution is to find someone else to solve the problem)

• Case 4: Homework has been made
  Don’t violate WIP, instead ask the stakeholder to put it in the right priority in the backlog

Don’t forget, the "urgent" story brings information you can learn from. Is it a common or special cause? Is it an undiscovered demand type? Does the stakeholders upstream understand your approach?

So, you’re planning the future. There are is a lot of stuff you are eager to do. But stop and think – are you pushing forward in the right direction?

Make sure there’s a balance between:

• Product – what would makes up evolving in the eyes of our customers?
  We are not pushing features for ourselves right?

• People – what would make this a better place to work in?
  Are we leveraging the skills at our disposal?

• Process – are we limiting WIP, improving quality, surfacing problems early?
  Done right we should gain time to experiment and fulfilling creative ideas.

• Purpose – are we contributing to the society around us?

Doing kanban, there will come a point where you will be faced with holding or breaking the work in progress limit.  Here are fours ways of dealing with that situation:

• Case1: Urgency!
  The new story has higher priority than work on the board.  Accept a temporary violation of WIP, but don’t starting more work until WIP is balanced again

• Case2: Pleasant "no"
  Bring the stakeholder to the board and ask them if they would like you to throw away for  the benefit of their request.

• Case3: Can’t say now for Legal reasons
  Start an overflow section. Whenever WIP risk being broken, compare the priority to what is on the board and if it is less put the work in a overflow section. The policy  being: to put something on the overflow secion requires an email to the sent to the stakeholder saying you can’t do it right now but you may do it somewhere in the future (best solution is to find someone else to solve the problem)

• Case 4: Homework has been made
  Don’t violate WIP, instead ask the stakeholder to put it in the right priority in the backlog

Don’t forget, the "urgent" story brings information you can learn from. Is it a common or special cause? Is it an undiscovered demand type? Does the stakeholders upstream understand your approach?

So, you’re planning the future. There are is a lot of stuff you are eager to do. But stop and think – are you pushing forward in the right direction?

Make sure there’s a balance between:

• Product – what would makes up evolving in the eyes of our customers?
  We are not pushing features for ourselves right?

• People – what would make this a better place to work in?
  Are we leveraging the skills at our disposal?

• Process – are we limiting WIP, improving quality, surfacing problems early?
  Done right we should gain time to experiment and fulfilling creative ideas.

• Purpose – are we contributing to the society around us?

Here are the slides from my "What is Agile" keynote at Agile Tour 2009 in Grenoble. Sample slide: Take-away points: Agile is a set of values & principles that help you succeed with software development Agile is not binary Agile is not about specific methods or practices Agile is not a goal Agile is not

Last weeks have been busy!

• We ran the first Kanban training course i Stockholm with David Anderson. The training class got a 8.5 score average out of 10. I really enjoyed the skill and experience  of the participants as well as David’s many "off topic" discussions.

  

• The first Limited WIP Society meeting arranged in Stockholm brought 50 people(!). Besides sharing kanban stories (and a beer or two..:)  we managed to gather 20 people in playng the bottleneck game in the open space session. In the stories shared the simpleness of applying Kanban to an existing organisation was a common thread.

  

Talks I have held,

• NFI – Från krav till system, Var är mitt krav? Följ det med Kanban (slides in swedish)
• ScanAgile 2009 – Getting Agile in system administration and operations
  -> Great to meet some old finnish collegues!

Talks – upcoming

• Devopdays 2009, Belgium – Introducing Kanban in operations

Last September I attended the UK Lean Conference in London (September 27-29) with colleague coach Joakim Sundén. That was an exciting conference. Not the least because it was the first time for me that I met in person the Lean and Kanban thought leaders that you can follow on the leanagile and kanbandev mail lists

The fixed price contract has been discussed here at the Crisp blog by others. It is broken by design as it creates more problem than it fixes.

On the way from JAOO I talked to Udi Dahan and that made it fall into place in a different fashion. Not that this is what he said, this is what he sparked.

The fixed price contract is not necessarily fixed price, a contract or evil.

Continuous improvement ( "kaizen") is a core process within Kanban and/or Scrum.

But what does it mean?

Here is an A3 I use to explain the concept

Besides understanding the most important structures of a system, it is an architect’s responsibility to understand and influence the design principles.

One common and important set of principles are those of error handling. It is good to have the same principles throughout the system as it produces fewer surprises and mistakes.

In this post, I will discuss some principles that including checked exceptions and Null Object, which you may not fancy. But it is always good to think this subject through, so please come along.

At the Lean Software conference in London Portia Tung tipped me off about Christopher Avery’s responsibility model. I need to show it to you.

1. Denial – ‘Problem? What problem? There’s no problem.
2. Blame – ‘I don’t have a problem working with you. You seem to have a problem with me. That makes it your problem. ‘
3. Justify – ‘I guess it’s possible that I’ve become insensitive to other people’s feelings and needs. I can’t help it though. After all, I’ve been doing this job for a long time. It’s who I am.’
4. Shame – ‘What have I done? I’m going to look such an idiot in front of the people at work. How am I going to live it down? Why should they help me after the way I’ve behaved?’
5. Obligation – ‘Tell me what you think I should do. I have no choice but to do it (even though I don’t want to). I’ll do whatever you say. It’s only a job after all (no one can expect to do a job they love).’
6. Responsibility – ‘I can wait for them to change but that could take forever. No, it’s up to me. I want to fix the problem. So how am I going to be a better colleague? I know! I’ll listen more. And be more considerate towards others. It’s a start.’

Now test yourself –  just how professional are you?