Scrum, Kanban, Agile and Lean
Tomas Björkholm
Improve the improvement process
March 27, 2012 – 8:14 am
Do you do Scrum? I would guess that 90% of Swedish programmers would answer yes.
Do you have retrospectives? Again most developers’ answer is, yes.
Will you empty the impediment backlog before the next retrospective? Silence.
This post is for those of you who remain silent after the last question.
2:nd version of Kanban Kick-start
November 18, 2011 – 10:18 am
Kanban kick-start has been updated. What’s new? Not much but I met David J Anderson and after that meeting I felt I wanted to make some changes to be more compliant with the content of his course “Kanban for Managers”.
Please enjoy. http://www.crisp.se/articles/kanban-kick-start-v2.pdf
If you like to have a version with the changes visualized, please let me know. tomas.bjorkholm(at)crisp.se /Tomas
Kanban Kick-start
April 21, 2011 – 8:26 am
For everyone who asks the question, how do we get started with Kanban. Here comes one way of kick starting a Kanban team.
Download the document from http://www.crisp.se/articles/kanban-kick-start.pdf
Enjoy reading and implementing
//Tomas Björkholm
Did you notice the big shift in software business
February 18, 2011 – 9:36 am
Maybe you didn’t notice it but there has just been a minor earthquake in the software business. The king has lost his crown; it’s a major shift in the hierarchy.
What happened was that Nokia announced collaboration with Microsoft. Normally, collaboration with Microsoft costs a lot and it’s worth it because your stock will go up like a rocket. What happened this time was that Nokia’s stock fell with about 10%. And what was even more surprising was that Microsoft paid for the deal. Rumours are saying billions of Euro. Google might give away things for free but Microsoft is now paying companies for including their software.
The fight between Apple and Google has got its looser, and it’s Microsoft.
The King is dead, long live the king
Go for success
June 18, 2010 – 6:04 am
When I first heard Jeff Sutherland talk about ready-ready I thought he meant that the product owner should know what he/she wants when turning up at the sprint planning meeting. That sounded obvious but anyway a good thing to make sure. At the JFocus conference in Stockholm early 2010 he talked about ready-ready-checklist and now it hit me that he meant something more than just that the product owner knows what he/she wants.
Here is my new understanding of the concept ready-ready. It’s simply that you should avoid things that might end up with a failure. So, what are the reasons for failure for you? Make a checklist of those possible failures and validate each story against it before you pull them into the sprint. The checklist becomes a recipe that gives your team the best possible start for a successful sprint. The checklist will of course vary from team to team but here are some examples.
Only pull stories into the sprint that fulfils the following:
- The product owner should know what he/she wants
… to minimize the risk he/she changes his/her mind - All major stakeholders must agree that this is what they want
… to minimize they get annoyed and want you to change it back - The team should fully understand what the product owner wants
… to minimize the risk he/she gets disappointed - The team should know how to develop it and have the persons needed
… to minimize the risk there will not be persons there to do the job - The team should have all needed knowledge or at least access to needed knowledge
… so we are not delayed waiting for answers - The team should have the environment that is needed
… so we can work in maximum speed - The story should be small enough to fit in a sprint
… so we can complete it during the sprint
If any bullets above are not checked then there is a possibility for some sort of failure and then it might be better to wait with the story to the next sprint and develop something else in this sprint instead.
Before the next sprint planning meeting we have time to fix what was missing.
Then there are two things that I think will help but is not mandatory:
- The team should understand the value of the story
- The team should understand how the new feature is about to be used
What if something needs to be done but some of the criteria above is not fulfilled? Maybe the best thing to do then is to timebox. Work with the story for a fixed amount of time and then either you are done or at least you have more knowledge to take a decision what to do.
Who’s going to do all this, you may ask. Well, who makes the goals in a football game? Usually it’s the centre forward but it could be anyone in the team.
So, only bring stories into the sprint that are truly ready-ready. Avoid failures and go for success.
By the way, leave the stories done-done after the sprint 
