Scrum, Kanban, Agile and Lean
Tomas Björkholm
Doing Scrum with Multiple Teams: Comparing Scaling Frameworks
2017-03-12 – 07:48 by Tomas Björkholm, Hans Brattberg and Jan Grape
Our article about Scaled Scrum has been published on InfoQ. In the article we describe the basics of LeSS, SAFe, and Scrum@Scale and show the similarities and differences between them
You find the article about Scaled Scrum at InfoQ.
Enjoy!
Scrum med flera team
2016-11-10 – 15:36 by Hans Brattberg, Tomas Björkholm and Jan Grape
Att organisera flera Scrum team görs på en hel del olika sätt. Här beskriver vi likheter och skillnader mellan några av de ramverk som vi har stött på hos våra kunder och utbildare, LeSS, SAFe och Scrum@Scale.
Gemensamt för LeSS, SAFe och Scrum@Scale
I alla tre ramverken utgår man från att man i botten har vanliga Scrum-team som är tvärfunktionella och självorganiserande.
Man utgår också från att vi alltid försöker bryta ner kraven vertikalt, så att varje inkrement blir så litet som möjligt men ändå kan driftsättas separat.
Underförstått är även att man kör kontinuerlig integration och automatiserad regressionstestning, och att man efter varje sprint har en produkt som går att driftsätta ifall man så väljer.
New book from Crisp – Kanban in 30 days
2015-07-17 – 07:33
Kanban in 30 days
Designed as a 30-day action plan, this book will help you understand and implement Kanban – and start seeing results – in a month.
Analyze your current situation and define your goals and wider strategic aims, and begin developing a plan to help you and your team confidently work towards achieving them. Involve your team into driving cultural change, learn how to prioritize, and organize tasks and projects to efficiently use your time and resources.
Create your own value stream map to better understand your processes and identify improvement areas, and adapt and use the features, tips, and examples to overcome challenges you may face when implementing Kanban. Pick up this book and experience the full results of this vital Agile methodology-fast.
Who this book is written for
If you want to simplify your processes, improve collaboration, and manage projects successfully, this guide to Kanban is an essential companion. read more
Lean Documentation
2015-04-09 – 21:15
My amateur research has given me the insight that the three most important things for greater effectiveness and good quality are knowledge, knowledge and knowledge. Knowledge is best acquired through a dialog but a dialog is only efficient if it includes someone with knowledge. Unfortunately, there are situations when such a person is not around.
This article will help you write effective and useful documentation for those situations where documentation is the only available source of knowledge.
Read the full article at InfoQ
The House of Agile – A visualisation of the core of Agile
2015-01-12 – 12:59
What is Agile, actually?
Have you ever asked yourself the question, ”what is Agile”? Ever been asked the question and found yourself looking for the easy answer? The true answer is of course that Agile is the Agile manifesto but do you know anybody who can recite the manifesto just out of his or her head? When asking what is Agle, it’s more likely you will get the answer that Agile is about being flexible or about high efficiency. Some will say Agile is about having a Scrum Master, daily stand-up meetings and notes on a white board. I think Agile is much more than that and in this post I will tell you the answer, the short answer, I have found after many years looking.
Is it important to know what Agile actually is? Yes, of course. If you don’t know, how can you know in which direction to change your way of working when you decide to go Agile. By the way, Agile is a direction how to improve your way of working, not a place or a fixed description of how to work.
To make Agile easy to understand I will borrow a symbol from Lean, the house
T-shaped people and U-shaped teams
2012-12-16 – 09:18
I guess you have heard about T-shaped people, that is, people with deep skills within one or a few areas combined with some knowledge in many areas.
Now it’s time to introduce U-shaped teams. That is, teams that are balanced and where teammates are helping each other. It’s a team where you might have a bad day and are allowed to fail without causing consequences. It’s where the teammates help you get back to normal and what’s more make you feel comfortably included in the team. Your team becomes your safety net and it’s the place where you can dare to be vulnerable. U-shaped teams are also good for productivity since safety means productivity. *
Shorter version of: Responsibility the Agile way
2012-11-25 – 21:12
A couple of months have passed since I wrote the post “Responsibility the Agile way” and I have refined it since then. Here is the new and more slim version:
1) I promise to look for improvements, both opportunities and problems.
2) I promise to participate in implementing the improvements. I will at least communicate the improvement possibilities I have found.
Responsibility the Agile way
2012-07-16 – 07:21
I am a teacher of Agile methodologies which means that I teach collective responsibility. I often get the response that ”everybody’s responsibility is no one’s responsibility”. To make everyone really take responsibility we need to define what we mean with responsibility the Agile way. Here is at least my version:
We are all responsible for contributing with our intelligence and senses for the best of the product and the process. We are also responsible doing what we have said we will do and being transparent with our progress.
If you think that is too fluffy, here comes more details about what I think Agile responsibility means:
Pomodoro meeting
2012-06-06 – 11:51
While reading a blog post by my Crisp colleague Anders Laestadius I remembered a meeting type I tried a few years ago. We called it “Pomodoro meeting” since it was timeboxed to 25 minutes, just as the time management technique Pomodoro.
This is how it was conducted:
Improve the improvement process
2012-03-27 – 08:14
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
2011-11-18 – 10:18
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/wp-content/uploads/2012/07/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
2011-04-21 – 08:26
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 https://blog.crisp.se/wp-content/uploads/2011/04/Kanban-kick-start.pdf
Enjoy reading and implementing
//Tomas Björkholm
Did you notice the big shift in software business
2011-02-18 – 09:36
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
2010-06-18 – 06:04
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 🙂
Jättarna blir agila
2010-03-30 – 01:08
I dagens Computer Sweden skriver Lars Danielsson om agila projekt på två stora företag och vad de har gemensamt. Företagen är IFS och Ericsson i Karlskrona.
Läs artiklarna på deras hemsida:
http://www.idg.se/2.1085/1.
http://www.idg.se/2.1085/1.
http://www.idg.se/2.1085/1.
Bland annat skriver Lars Danielsson att de har en sak gemensamt. De går utanför Scrum. Jag har haft förmånen att vara bollplank och lärare för båda projekten och kan därför avslöja fler saker som de har gemensamt och som jag tror är avgörande.
1) De har en ohierarkisk ledning som finns nära de anställda och som är lyhörda.
2) De anställda är nyfikna och väldigt trevliga. Det bidrar till ett öppet och förändringsvänligt klimat.
3) De har kunnig personal själva men tar också hjälp utifrån (i de här två fallen från mig 🙂 ). Let´s face it. Kultur äter processer till frukost. Det är därför svårt för "inhemska" att genomföra en förändring helt själva eftersom de är en del av den gamla kulturen. Ken Schwaber brukar säga att 75% av försöken att implementera Scrum misslyckas om företaget inte tar hjälp utifrån.
Jag hoppas fler svenska företag följer de här lyckade exemplen så vi får många framgångsrika agila företag.
/Tomas
http://www.crisp.se/tomas.bjorkholm
http://www.crisp.se/bok-lean-agile-scrum-xp
Agile Support with Kanban in French
2010-03-01 – 12:36
My paper about Agile Support has been translated to French. You can download the French version by clicking on this link.
Many thanks to Fabrice Aimetti for doing the translation.
Agile Support with Kanban
2010-02-17 – 11:56
A year ago I held an Open Space at Scrum Gathering in Stockholm about Agile Support. I have since received several requests to expand on the topic, so here it comes.
Download the article about Agile support with Kanban
Good Luck!
/Tomas
Why Scrum is better than Kanban
2009-02-17 – 02:53
I have for some time been thinking, what is best, Kanban or Scrum. I can’t make up my mind so I decided to write two blog entries, one where I have the "I love Kanban" hat on me and one where I’m wearing a "I love Scrum" T-shirt.
My conclusion is, not very suprisingly, that it depends on the situation.
In this entry I take the Scrum T-shirt on. Click here if you like to read the one where I love Kanban.
I concentrate on some area where Scrum and Kanban differs:
Iterations – In Scrum you work in iterations, Kanban sees development as a forever ongoing flow of things to do.
Commitment – In Scrum team commits to what they will do during a sprint
Estimations – In Scrum you must estimate. In Kanban it’s optional.
Crossfunctional teams – That’s one of the pillars of Scrum. For Kanban it’s optional.
Prioritized backlog, self-organizing team, transparency, inspect & adapt, pull scheduling and good communication/collaboration are things they have in common.
By asking team for a commitment they will get a positive stress knowing that people from outside will see if they can do what they committed to. It also gives an extra energy at the end of the sprint when team have the goal within reachable distance. After the sprint, the team can feel relaxed and gather some new energy for the next sprint. It’s psychologically nice to not feel you are in the middle of a never ending stream of things to do. Instead Scrum concentrates on one sprint at a time and give possibility to focus only on those things, decided to take in to the sprint. By working in fixed length iteration you get a nice rhythm the whole company can feel and adapt to.
Estimating is not waste since valuable information is transferred from product owner while the team ask what is needed to know what they are estimating. The same thing with commitment. To be able to commit they need to know what they are committing to. They simply have more interest of getting information from product owner.
Even though you can predict when a project is done just by counting stories left it is more precise if each story is estimated as well. Prediction is important when more departments, like marketing, is dependent on your work. It gives a more serious feeling.
If there are some time at the end of a sprint that’s valuable even if no new features are developed. This is time developers can use to improve code quality or development environment. Both will give better efficiency in the long run.
Working together in a cross functional team is a psychological thing. You are able to go the whole way from concept to released product together as a team without dependences. You are not just a cog in the machinery. It’s also fun and helps you grow as a person. By helping each other, knowledge is spread which gives less person dependency. It also helps prioritizations since features can be built without considering which knowledge is available. To coordinate between people with the same skills but sitting in different teams you can have virtual teams meeting as often as needed.
Please, help me Scrum-fans, what have I been missing?
Best regards,
Tomas
Why Kanban is better than Scrum
2009-02-17 – 02:51
I have for some time been thinking, what is best, Kanban or Scrum. I can’t make up my mind so I decided to write two blog entries, one where I have the "I love Kanban" hat on me and one where I’m wearing a "I love Scrum" T-shirt.
My conclusion is, not very surprisingly, that it depends on the situation.
In this entry I take the Kanban hat on. Click here if you like to read the one where I love Scrum.
I concentrate on some area where Scrum and Kanban differs:
Iterations – In Scrum you work in iterations, Kanban sees development as a forever ongoing flow of things to do.
Commitment – In Scrum team commits to what they will do during a sprint
Estimations – In Scrum you must estimate. In Kanban it’s optional.
Crossfunctional teams – That’s one of the pillars of Scrum. For Kanban it’s optional.
Prioritized backlog, self-organizing team, transparency, inspect & adapt, pull scheduling and good communication/collaboration are things they have in common.
Kanban is Lean and has been around for 50 years and has shown to be successful. Things are seen as a flow without iterations. Not many rules. It’s just a focus on reducing work in progress, strict prioritization and limiting demand after capacity. Besides that you have the normal Lean principles of quality, just-in-time (quickly from concept to cash), Kaizen (continuous improvement) and minimizing waste. No meetings if it’s not adding value to the customer. Most of those things are fine with Scrum but I can sometimes think Scrum has some waste. Here I will mention some areas were Scrum practices can be waste.
Estimations – If product owner knows what needs to be done and the only interest is to have it done a soon as possible, why spend time on estimating? In Scrum, estimations are needed for team to know how much to commit, to calculate velocity and for product owner to decide on prioritization. If none of this is needed, it’s waste and we shouldn’t do it. If you like to measure velocity you can instead count number of stories done per week or month. While talking about measurement why not look at something the customers are interested in, cycle time. That is, the time it takes for the customer to get what he or she ordered.
Last day in Sprint. If team is done with a story and there is not enough time left in the sprint to complete the next, it’s likely no one works hard the remaining time and that’s waste.
In Scrum, the team commits which does not work very well for a team with support issues. They get a lot of disturbance and commitment is not worth anything since the ones disturbing them doesn’t care about commitment. A commitment you can’t control gives either frustration and stress or demotivation.
In Scrum a team is crossfunctional and sits together with the people working with the same project and not with the ones with the same knowledge. Let’s say you work with sound effects for a computer game. Then it’s not much help to have a java-programmer beside you. It would be more valuable to sit with people doing the same things as you do who can help you with tools and practises.
Please, help me Kanban-fans, what have I been missing?
Best regards,
Tomas
Three reasons why story points are better than ideal man days for estimations
2008-12-05 – 10:46
I often hear from Scrum teams they don’t understand why estimating in story points are better than estimating in ideal man days. Here comes three reasons:
Reason 1. Estimation is a way of telling the size of a story, not how long it takes to implement it. If you give the size in a unit that sounds like a time people will likely mix things up. If you have persons in your organization who are control freaks it’s hard to explain why a story with size 5 ideal man days takes two weeks to develop. If one of the control freaks is your manager you will probably be asked to cut down on Scrum stuff like daily Scrum or retrospective or what ever you are doing the 50% of time you are not developing.
Reason 2. Scrum has a potential to make you four times more productive. Let’s say you are a development team of five people and have estimated a whole project in ideal man days and you start with a focus factor of 50%. That means you can include stories representing about 35 ideal man days in a three week sprint. Let’s say you actually become four times more productive which means you can handle stories with summarized size of 140 ideal man days in a timeframe of 5 persons * 14 days = 70 calendar man days which means you have a focus factor of 200%. Does that sound weird to anyone? Ideal man days is a size that varies over time depending on team performance. If you don’t understand the calculation the last paragraph might help you.
Reason 3. It’s proven that relative estimation is more correct than absolute and since ideal man days is a time measure it’s easy to make absolute estimations even though it could be used relatively as well. Story points has no meaning without something to relate to which means those estimates can only work for relative estimations.
My recommendation is to estimate in story points and use velocity to calculate the time just like you do for driving. The distance divided by your velocity gives the time it takes.
This is how you can get started. Take a well known task/story as your standardised benchmark. If this a rather small story, set it to two story points so you have room for smaller stories. Estimate the rest of the stories relative to this.
Before our first planning meeting we need to know our velocity so we know how much we can commit to. But we don’t have that since we don’t have a history.
To get an initial velocity for our first sprint, we estimate the selected standard story in ideal man days. Let’s say the story is 2 story points and 4 ideal man days, we then know the team can handle 1/2 story point per ideal man day. Use the focus factor to convert ideal man day to calendar days. The focus factor is typically between 50% and 70% depending on the amount of support and interruptions. If the focus factor is 50% we can handle 1/4 story point in a calendar day (1/2 * 50%). If the team consist of five people and the sprint is 14 days we have 70 calendar man days in the sprint. 70 * 1/4 gives that we should be able to bring 17 story points into the sprint. Finally we have our initial velocity.
Good luck!
/Tomas
No dish debt at home
2008-12-05 – 09:35
I’m half time on paternity leave so this blog entry will have a touch of my life at home with my 1-year-old son Oliver.
Even though they can’t speak, those young citizens have a lot of power since their screaming can make a father do anything they want and do it now. Similarities to eager product owners are not too far away 😉
But what has daily home life with Agile to do? A lot I would say but this time I will concentrate on the technical debt or debt in general and having releasable as part of definition of done.
Let’s say you choose the easy way out all the time. When your child wants food you cook and when your child likes to play you leave everything to go playing. What you leave behind is dishes and a messy home. The next time it’s time to cook it will take longer time since you first need to dish some pots and you have less free space left to use while cooking (because of the dirty pots). The longer you wait before dishing the slower you will be cooking and more frustrated will your child be. And when your baby goes to sleep and it’s time for you to catch up on emails and writing in your blog you can’t because you have to take care of your home first. And since your home is so messy your energy flies out of the window the very first moment you look at the mess so cleaning will take plenty of time because of the lower efficiency or should I say lower motivation. Oh yes, it also takes longer time to dish when the scraps of food in the pots are stuck which is not the case when you dish immediately.
Another way and what I will say a better way is to always dish when you have cooked and clean the table when you are done eating. Every step takes longer time but the total will be faster. There’s no debt that slows you down, you feel good and you can release whenever you want. So now I have time to write this :-).
Good luck dishing.
/Tomas Björkholm
How to build trust with a management team
2008-09-19 – 09:28
To get a self-organising team we need to get managements fingers out of the jam pot. The only way that can happen truly is if management have full trust for the team. If you face reality, trust is nothing you get for free it’s something you have to deserve. So how can we deserve trust?
Having a good standard format for reporting is a good way to earn trust since recognition gives control and control gives confidence, which lead to trust. So we have to find a way to repeatedly communicate to management so they feel they can truly trust the team and leave the team to self organise. The report must give feeling of full transparency but at the same time not being too much to chew and definitely not taking too much time to produce. We want to put most of our efforts on the product development and not writing documents, right?
A person from a former customer came up with an excellent idea, short, simple but showed to be very powerful. He suggested to, after each sprint, report the three p: progress, projection and problems. I know, the idea came from a project but it should work also for on going improvements since even they usually have some form of roadmap to follow, including mile stones and releases.
The three p of reporting
Progress – what has happened since the last time? Have we changed the team in any way? Have we reached any milestones? Have product owner added new stories or is the roadmap the same as the last report? What was the velocity and is it stable? The velocity is reported as the difference of how many story points there are left to the release this time compared to what was left before the last sprint. That is, how much closer to goal are we. I call it speed over land in difference to speed through water. If you are used to sailing you know that the difference is the current and in this case the current is bug fixing or fixing technical debt. Trying to tell management that you have a velocity of 30 but are only 10 story points closer to release will only confuse and confusion is a good way to ruin trust.
Projection – To build trust it’s a good idea to decide a road to reach the goal and give an estimation how long the road is. I know this does not sound very agile but if you like to build trust it’s great to have a plan but always communicate the plan might be changed and that management will be informed when it changes. The plan does not need, and even should not be, detailed but a rough idea of included and estimated features are needed. Projection is a way of saying how much is planned to be released and when. It’s a good idea to support your dates with a project burn down chart showing it’s realistic to hit the 0-story-points-left point that date. This implies that definition of done is releasable and no debt is pushed in front unless that is included in the plan and given estimates that are comparable to the other stories.
Problems – What is on the impediment list? What was said at the last retrospective? Especially things management can help you fix is important to include here but also include things the team will work on to become more effective, that helps building trust.
It might takes some hours to build a presentation based on Progress, Projection and Problems but when you have done it once you just need to update it for the next report and that is a quick fix that should only take a couple of minutes.
Good luck building trust and remember that your boss probably has someone to report to and squeezed people doesn’t act rational so make sure you give the information he or she needs to build trust to his or her boss.
Best wishes
/Tomas Björkholm
