Friday, December 11, 2009

OO Day 2009 presentation: Scrum Is Not Enough

Here are the slides for a presentation I gave with Ari on 9th of December at OO Day 2009 in Tampere, Finland.

Since the presentation was in Finnish so are the slides. I and Ari might write more on the subject later on.

Thursday, October 22, 2009

The Huitale Way - Is it Scrum or is it Kanban?

Last week I was sitting together with Jim Coplien and Karl Scotland in Scan-Agile 2009 "speaker dinner" and talking about various things. One of the topics was the way we do product development in Huitale. Jim thought that our way is "red pill Scrum" but another CST (Petri Heiramo) thought it is not any form of Scrum as it does not have timeboxing. Later on I talked with Karl (both over some beers and in the open space session) and got impression that he would consider this to be Kanban.

I noticed that there was a question in Karl's blog about what was the implementation discussed with Jim hence I thought to share our way.

I would like to know which is it in order to be able to discuss with the community about it. I do not favor Scrum over Kanban nor Kanban over Scrum but I feel both are useful and even complementary tools.

Evolution of our Scrum implementation

We started with "pretty close textbook Scrum" and after 26 sprints we had molded our implementation quite a bit based on the results from internal Kaizen events.

Version 1.0: Release story by story
* Note: Blue box is our Scrum wall. It has columns Not Started, In Progress, Done (todo, IP, Done in the picture). Green arrow is daily standup, red arrow is sprint.

At this stage we did sprint plannings and planned work for two weeks sprints. We had continuous integration and deployment capability so we thought that we would like to release story by story instead wait for the end of the sprint. Demos took place on demand, but plannings and retrospectives were taking place every 2 weeks. Progress was shown with burndowns.

Version 1.1: Introduce explicit Work-in-Progress limit

We dropped sprint backlog and burndowns. We were working one to two backlog items at any given time (this was probably true previously as well, but this time it was explicit), measured cycle time and used that as feedback for planning. We still did sprint plannings and retros every two weeks.

Version 1.2: Planning on demand

We introduced WIP limit also for "Not Started (todo) column". Product owner would prepare planning at any given time when there was less than 7 items in that column. It seems we got "pull system" in place as planning, demos, releases and retrospectives took place on demand and features were pulled from "Not Started to In Progress". Some sizing was put also in place and cycle time for each size was measured. As you can see we did not have any timeboxes any more.

Version 1.3: Ready column and Cadence for retrospectives

We noticed that sometimes the items on In Progress did not progress and they jammed the system. In retrospectives we came up that we need some intermediate stage with rules so that unprepared items would not stop the flow. Ready column was defined with limit of 2 and now that became the "pull signal" for Product owner to start preparing some items from "Not Started" to meet the "Ready" criteria. Interesting that Jeff Sutherland is mentioning that 1% of Scrum teams are having similar "Ready" in his blog (EDIT: link fixed, thanks Anu for noticing that :) ). We also noticed that "on demand" retrospectives could be neglected and decided to set cadence for them.

This is our current implementation of Scrum/Kanban that was discussed in the dinner. Do you think it is Scrum? Do you think it is Kanban? .. or do you think it is both?

Why do I care? I would like to discuss the implementation with the community in order to learn from others and it would help me tremendously if we'd have common terminology :o)

Wednesday, October 14, 2009

TETRAsim Agile Transformation @ Scan-Agile 2009

I would like to highlight one of our customer cases that is going to be presented in Scandinavian Agile Conference 2009. Go and see Olli explaining how it was done in TETRAsim.

There are still some seats left so you can still register.

Monday, August 31, 2009

Managing "shared resources" in Agile way

I hate the term "shared resources", but sometimes my customers tend to have them and they are wondering how that fits into agile. Mumbling about cross-functionality and "whole team" just usually irritates them; they want to get their stuff done, even it is suboptimal.

I demonstrate what we did in one of my customers about year ago to solve this issue before they got cross-functional.

Two scrum teams, one shared resource (Database developer).

In the beginning they had one database developer for a department having multiple scrum teams. It was really common that since the database developer commited to Team 1 sprint, he could not serve the others (he was PART of the team 1). Product Owners (PO) got pissed off about not getting their stuff done and always waiting for the "shared resource" to be assigned to help their team.

We figured that we need get the database developer to help the team 2 in middle of the sprint in case the team 1 database related stories would take a day or two to complete. So we moved the guy in between.

Of course we had to ask ourselves how would he know which team to help at any given time, how to prioritize, how to get visibility what he is up to and so on. It was obvious that the "shared resource" would need some kind of "to do" list. I had previously seen kanban used to manage work done in technical operations, so I thought maybe we could use kanban here aswell.

Product owners would still have their backlogs so it would be natural for them to feed the kanban with those.

How to get that done in synchronized manner with everything else? We decided to setup a shared resources meeting before the sprint planning meeting so that the PO1 and PO2 could take the shared resource into consideration while sorting out their individual backlogs. The meeting takes place between POs and the shared resource(s). In following picture the meeting is visualized by dashed circle.

So how does the kanban look alike? Here is a simple example kanban for database developer:

The red counters are Work-In-Process limits. As there was one database developer, we decided to have limit of one item for the "In Progress" column. As you see, each item on the kanban board describes also which team is involved. As this PHYSICAL board is placed on the corridor of the development department, anybody can tell where the database developer is working (he sits together with the team that is visible in "In Progress" column.

It turned out that the solution really worked. POs were really happy to have visibility to their shared resources and they also were amazed how big of a constraint (being visual now) it was for their organization. Another improvement was the increased motivation for the "shared resource" - he got visibility for his future assingments by having them on the kanban board and also he ws in control of his tasks as they were not "hidden" as part of something else.


I would not recommend to have shared resources even with help of what is presented here. Cross-functional teams are more optimal, but if you are on your way to get there, maybe you found this useful.

Please do not hesitate to give me feedback by commenting or sending me an email to marko dot taipale (at) huitale dot com. I am also interested to hear if yu have found some other ways to manage your shared resources :o)

UPDATE - some comments

I got some feedback from various people so here are their comments:

Jonas Lindström
problem comes when not all sees the benefit and it isnt followed up upon, for it to have any value at all we need to be able to trust the kanban at all time... but that's a completely different issue :)

My response to Jonas
Yeah, if the kanban is not up to date then it is basically lying -> no information maybe better than misinformation

Jani Vesterinen
This is quite good note, not that I've seen this kind of problem.. ;)

One important thing, which in my mind is forgotten nowadays easily with all these different work practices and tools, is people coaching. E.g. with shared resource, you should use most of the time for coaching and teaching the people in organization what does it mean if there ... Read moreare shared resources AND that screwing around has to end AND this is the way we try to solve it - Using Kanban board.

p.s. I would even recommend that these shared resources would need dedicated person (Scrum Master or just some bad ass mfucker) who says no if needed as long as everyone understands and is used to work with this kind of concept.

Jonas Lindström (response to Jani)
well, if the work is pulled from a prioritized task list and the only way you get work done is if its on the list you shouldn't have to use a 'no' person... and if you see that you often have too much work that cannot wait a day or 2 for it to be prioritized you might have other issues you should be looking at :)

btw, what is there really to teach and coach here, seems pretty straight forward?

Jani Vesterinen
Hmm.. Shouldn't this be a topic in Scan-Agile - the power of coaching?

Ari Tanninen
Liked the blog! Good basic stuff, a great example and clearly put. :)

Ari Tanninen (response to Jani and Jonas)
Are you guys talking about coaching or tools or processes or what? A Kanban board is just a tool, and no tool will serve is used wrongly. Nor will it compensate bad management nor coaching. Duh? :)

Monday, April 27, 2009

Toyota QC Circle Example

Imagine having this on A3.

I like it and I do not see too many companies doing this even with their fancy "improvement processes".

Tuesday, April 7, 2009

Huitale Kanban

First I want to thank Henrik for publishing ScrumVsKanban as it helps me to describe our way of writing software and getting stuff done. Hopefully we can co-operate at some point to make this all a bit clearer to the community as there obviously is some interest.

I need to stress that I am no way saying that Scrum is bad or you should not do it; I have seen Scrum working in various teams already but found Kanban more appropriate for Huitale internal development :)

We stopped sprinting and doing Scrum after 26 sprints in Huitale. Here is some of the "whys":
  • We felt that splitting stories is artificial
  • Estimating sucks, even though it is 20% correct
  • What we need iterations for?
  • We can release every day, the process needs to serve us, not vice a versa
  • What if we have subcontractors and things take just more than 2 weeks?*
  • Stories are a bit weak, all the teams that I have worked with have trouble with stories (sure you can do something else in Scrum aswell..)
  • Splitting is about focusing but it is also about loosing some information (see pitfall)
  • YES, we need them for reflective improvement (do we need to wait?)
  • NO, we do not need them for demo (why wait?)
  • NO, we do not need them to split stories (leads to problems)
So we do Kanban instead. By Henrik's description we are "Kanban team #3".

“We trigger a planning meeting whenever we start running out of stuff to do. We trigger a release whenever there is a MMF (minimum marketable feature set) ready for release. We trigger a spontaneous quality circle whenever we bump into the same problem the second time. We also do a more in-depth retrospective every fourth week.”

In practice it means that

  • No sprints nor iterations
  • No sprint planning
  • No complexity estimation (no story points)
  • Flow is more important than iterations
We value more getting a Minimum Marketable Feature out than having multiple stories that have no meaning (as they are parts of something more meaningful) for the business out

Huitale Way

Here is a picture demonstrating our way.

Some acronyms explained
PBL = Product backlog
NS = Not Started
IP = In Progress

As you see, we take 7 items from the backlog to our Kanban board. Why 7? Because that is the amount of items we can keep in our heads at any given time.

Here is a picture of our actual Kanban board

Red numbers are our queue size limits and as you see we allow two items to be In Progress. We have also defined a way how we cope with bugs, how we track waste etc. but I have left them out for simplicity.

Here is (imaginary) example of a Minimum Marketable Feature (yellow card on the previous Kanban board).

We add data to the MMF as it moves in the board. In addition to the board and the item itself we have so called Engineering Board where we keep all the relevant data per In Progress item.

How do we demo?

We have applied scrum-like demos, but we do demonstration per story. If the story is accepted by the Product Owner it will be deployed to production next day thanks to our capability to release every day.

What metrics we follow?

We gather the following metrics
  • Kanban board cycle time (from Not Started to Done per MMF)
  • Overall cycle time (From Idea to Done)
  • Number of defects
  • Waste

How do we plan or even roadmap?

Based on our cycle times we get average wait times per MMF (we call it Disneyland Wait Time as it won't be precise) . From there we can tell how long it takes to get stuff done. In order to get something done faster our Product Owner simply repriotizes. All data is naturally empirical and currently our wait time is 3 weeks. So 7 items in Not Started means that 7th item will be done after 21 weeks (7 x 3) if In Progress is empty.

Previously we have also tried some sizing based on t-shirt sizes (S, M, L, XL). Each size has been tracked (cycle time for each size adjusted based on empirical data) and they have been relative (3xS = M, 3xM = L, 3xL = XL). I would recommend new teams to start with sizing and then seeing if it works for them.

How do we retrospect?

I think cadence is good for reflective improvement so we have kept the "iterations" for retrospectives. Naturally the team members are actively improving "on the spot" any practice as there is no reason to wait for the retrospective to take place in order to reflect. However, I feel that we need the pulse for retropectives - it reminds us in case we may forget to do it.

Do not hesitate to contact me (marko.taipale at in case this raised some questions or you have similar experiences to share. You can also drop by our office to see it yourself - we have already had some ;)

Monday, March 30, 2009

Saturday, March 28, 2009

Sunday, March 22, 2009

Is business value model overrated?

I often get asked how do we calculate business value for our backlog items. We have a (relative based) way to do it, but more importantly I have been wondering how much estimation is actually needed.

James blogged about "Maximizing Value with Agile.." and came out the following:
  1. Work on One Project at a Time
  2. Release Early and Often
  3. Adapt Your Plans
  4. Keep Your Options Open
  5. Plan at the Last Responsible Moment
If your company has clear vision where it wants to go ("we want to have more users for our website"), then your prioritization should be pretty easy.

Is your company just missing the focus and hiding it with a complex business value model?

Tuesday, March 17, 2009

Exposing Huitale Way - take 2

Again we are getting visitors from companies to see how we do agile. This time the guests are from Accenture and Leonidas.

Wednesday, March 11, 2009

Exposing Huitale Way

Today we're having a group of visitors from Houston Inc. to see how we do agile.

So cool to share some findings with other agilists :)

Monday, March 9, 2009

Manifesto for Software Craftsmanship

I just signed the Manifesto for Software Craftsmanship. Take a look at it at

Of course the manifesto does not matter if we do not act like we have signed it.

Sunday, March 8, 2009

Interact with your customer - this is how Mousehunt does it

"I think the main reason MouseHunt has become such a deeply engaging game is because we've included our users in the development of the game. We've done everything possible, used every method to get them to interact directly with us. The users have access to the development team (and each other) through the forums, videos, and a built-in chat system. We've decided to share a large slice of our office lives with them."

How could you do the same with your product?

See more at

Thanks for the link Rob.

Friday, March 6, 2009

Broken Build?

There is no way to be too serious about broken build..

Thanks to Ari for the link :)

Tuesday, March 3, 2009

Testing (teasing) your Product Owner

It so much fun (ok, it is about being a bit of nasty..) :)

Anyway, here's a story about what I did just recently when I was invited to join a "scrum" team that had some difficulties to deliver.

I was told that the team has been developing fancy system for 2+ years. The development was not too much guided (= missing leadership) so the team just did what was "wished" by "stakeholders" and now they were on their way to "put it out".

I tried to understand the system with help of some of the developers that had been part of the team. We went trough some of the functionalities together and after a while I got the impression that the system was way too complicated for any "non-techie" to use (yes, it was meant to be used by non-techies). I wondered who had requested such a features and yet approved the features in the demos.

I took few screenshots and went to the Product Owner (PO) to have a chat. I asked him to describe what the screens are about and in few seconds he admitted that he had no idea. Encouraged by that I requested if any of the stakeholders would know if I would visit them with the screenshots. Not surprising the answer was "I don't think so". I wondered what would be the cost of building such complex features.

When a "scrum" team delivers something that nobody has requested nor approved the demos must suck. I went off back to the team and asked how have they conducted their demos.

The team told that their demos were "practiced" beforehand (good? maybe..) so that the tester who will go trough the implemented stories knows all the "traps" that should not be touched. In another words demos were about looking good (~lying that it is done) and not letting the customer to trial. No wonder that they were not ready to put it out when the time had come.

Unit testing is overrated

When I present our case (400 acceptance tests, 30 unit tests) I often get asked
"How you can refactor without unit tests?". Well, it's easy, if the refactoring did not break my acceptance tests then I am safe. It seems that there is common misbelief that you need unit tests in order to refactor.

Lets look at the some view points:

1) Unit testing supports design (building the knowledge)
True, though you could as well use any other "tool" like CRC cards and you would not increase the mass of your "manufacturing equipment" than can be seen as waste. Acceptance testing also supports design by giving the focus and telling you when you have "done" with the story from functionality perspective.

2) Unit testing does not ensure that the totality works
... so you need the acceptance testing anyway.

3) Acceptance testing is slow, so therefore it is better to do unit testing
If something is slow you should not do it? That's just weak. You should look into tools like Selenium Grid.

4) Fixing acceptance tests takes so much time, refactoring unit tests is faster
So maybe your acceptance tests are not very good? Changes in implementation (not behavior) should not break your acceptance tests.

5) Unit testing is not really that much about testing
... but it may be a good tool for learning. Still unit test coverage does not mean anything really (neither does acceptance test coverage).

Of course you may have as much unit tests as you ever like - just give it a thought before jumping into it. :)

Update: Some people have taken this post as "Unit testing is something that should not be done at all". That is NOT my message - I think we need delicate balance and I would pursue that by "outside in"-approach where you take the user's view and start approaching the system from there, working from Acceptance test towards Unit tests. If you approach automation by implementing "inside out" unit tests you may get lost with the unit testing adventure.

Monday, February 2, 2009

What works?

Sometimes I get tired of people asking details regarding implementing scrum. Of course I am happy to give insights based on my experience but often I feel that the right answer to their questions is "So does it work for you? Oh.. it does not, well what could you do to fix it?".

So it is about what works... which is about "inspect and adapt" and PDCA-cycles (Plan-Do-Check-Act). Here is a list of things that have worked for me from top of my head:

  • Team sitting in the same room, almost face-to-face all the time
  • Test-First development and refactoring (both in large & small)
  • Incremental development
  • Frequent, preferably continuous integration
  • Frequent deliveries, small batch size (great if you can deliver story-by-story)
  • Time-boxing
  • Single guy thinking about the product, prioritizing the work (scrum PO)
  • Doers estimating the effort (scrum team members)
  • Failing fast to learn fast, improving yourself by reflection
  • Easy access to domain experts / users
  • Automated tests
That's probably missing some, but you get the idea. The more I work with implementation of agile methods the more I ask the team to look into the values of agile ... into "what works?".

Thursday, January 29, 2009

Do Not Sell Anything That You Do Not Believe In

Lately I have been part of various kick-off meetings and negotiations about delivering software for various companies. Too often the talk gets to the track of "getting it right by planning it carefully.. this time" and suddenly the team is asked to commit to the plan with fixed scope and time. It is amazing how we should believe the prediction that we come up with on day 0 even though the industry has so huge project failure rate.

This week I had to turn down a request about training project managers to waterfall approach to software development. The request mentioned "international industry standard approach (so it must be good?)", "ensuring the quality by following the waterfall process" and so on. It took me few days to come up with appropriate response that essentially said: "We are not selling anything we do neither believe nor have experienced working ourselves".

I was proud for a moment though I would really love to go such a training myself to learn what do others believe in or even better: is working for them.