Tomas Björkholm

This article is a follow-up to my post on lean documentation that I published some time ago. In summary, lean documentation is characterized by being easy to consume and simple to keep updated.  The purpose of lean documentation is to help you, as the reader, find answers to your questions, not to hold the detailed answers

To understand this article, first read Managing in Mayberry by Don Gray & Dan Starr: https://www.donaldegray.com/managing-in-mayberry-an-examination-of-three-distinct-leadership-styles/ In short, it is about three different styles of leadership, depending on their view of the problem. The situation is that, in heavy traffic, left-turners may cause a queue of cars that leads to a dangerous situation. Officer Barney’s micromanaging leadership

I guess you, like the most of us, have a problem breaking work down to small but still valuable pieces and that your MVP (minimal viable product) is more or less the same as the project scope. If you recognize yourself in this than keep reading.

Continue reading

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!

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.

Continue reading

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. Continue reading

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.

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

Continue reading

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. *

Continue reading

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.

Continue reading

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:

Continue reading

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:

Continue reading

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.

Continue reading

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

For everyone who asks the question, how do we get started with Kanban. Here comes one way of kick starting a Kanban team.

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.

Jeff Sutherland often talks about ready-ready. It sounded clear the first time I heard it. But I have recently got a deeper understanding of the concept. Here is my new understanding and why I think it’s important for successful development.

(Sorry to international readers. This is a comment to a notice in a Swedish magazine. That’s why I write his in Swedish)
I dagens Computer Sweden skriver Lars Danielsson om två stora Agila projekt och vad de har gemensamt. Som insider kan jag avslöja fler saker de har gemensamt.

My paper about Agile Support has been translated to French.

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

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.

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.

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 …

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 😉

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?