Here’s an interview by InfoQ. I talked about my books, my travels, the agile manifesto translation project, coaching coaches, agile trends, and various other stuff. The interviewer (Craig Smith) had a great set of questions, and I’m pretty happy with my answers 🙂

I had recently a conversation with a business partner of mine, Erik Andrén at Macmann Berg. We were working on the material for the next workshop in a leadership program we have at a client. This time the workshop was about coaching, both in general terms but also from an agile perspective. Erik has a background as a therapist but is nowadays working as an organization and management consultant. At our meeting he described his view about coaching based on a therapy model he had used as a therapist, and we then had  a very interesting discussion about the model and the connection to continuous improvement of teams and organizations. This post discuss this connection since I believe we have a lot to learn from how therapists approaches patients when trying to help them create a better life for themselves.

Continue reading

On Oct 1-2 Alistair Cockburn is in Stockholm teaching Advanced Agile together with me. He has been here twice before and course reviews have been great! Alistair has a very pragmatic down-to-earth style, while maintaining the theoretical depth needed for an advanced course. He’s not only a Fun Guy, he’s the guy who (literally) wrote

A while ago I was asked to become one of the Swedish country ambassadors for the Agile Testing Days 2012 conference. I said yes, because I think it’s a great conference. As country ambassador, I help in promoting the conference. I chose to do it, because I think it’s a good conference and I already recommend it to my friends.
Continue reading

Here are the slides from my Ale2012 keynote: Everybody wants Change – but nobody likes to Be Changed.

Thanks for coming!

Continue reading

Here’s my default approach to problem solving and organizational change. Basically a light-weight version of the A3 problem solving approach and Toyota Kata.

(BTW my keynote at ALE2012 next week is on a similar topic: “Everybody wants Change, but nobody likes to Be Changed”)

Continue reading

För ett halvt decennium sedan när jag skulle börja som utvecklingschef på Polopoly kände jag att jag behövde ett verktyg som hjälpte mig att sammanfatta andemeningen och de praktiska konsekvenserna av Agile, Scrum, XP och Lean. Var och en av dessa innehåller en rad – i viss mån överlappande – begrep, som är tydliga och om man kan dem inte så svåra att förklara – om man har många timmar på sig. Men hur minns man hela denna komplexa väv? Hur kan man uttrycka den enkelt, snabbt och koncist?

Continue reading

Sunshine. Over 35 adults and 15 kids milling about, playing and socializing. Some down by the beach eating snacks and windsurfing. Work going on in the background: Pototoes being boiled, tables being set, drinks brought out, BBQ lit. Nobody is giving orders, things are just happening. Looks rather chaotic. But then at 16:30, precisely on

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

I was invited by Agilenetið to come to Iceland and do a talk. That didn’t fit my travel schedule, so we instead decided to do an experimental “remote seminar”. That is, with me on a video link instead of physically in Iceland. I’ve done webinars before, and usually miss the interactivity. I wanted it to “feel” like I was there, discussing and interacting with the participants.

Here’s what we learned:

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

Starting from scratch, this video demos how to quickly get to a fully agile project setup with continuous deployment. Everything is in the cloud – GIT repo, Jenkins, MongoDB, and the app server. The system deploys automatically with every successful commit. The app itself is minimal, but does have a simple web interface and a

Here are the slides from my metrics talk “Agila mätetal i praktiken” at Dataföreningen in Stockholm. Lots of very engaged and experienced participants, lots of interesting discussions, thanks for coming!

Here are annotated slides from my lighting talk Agile@Home at Agila Sverige 2012. Have you tried a BBQ board? Or a travel spike? Or a homework burnup chart? How about Limiting WIP in the kitchen, or the closet? How about agile party planning? There are plenty of ways that Agile and Lean practices and ideas

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

I am currently working as a Scrum Master for multiple teams at Projectplace in Stockholm, Sweden. One of those teams is the Mobile Team. They are developing Action Boards for both iOS (iPad) and Android platforms. These Action Boards are also available in the Customer Preview of the Projectplace web service. Both Web Team and Mobile Team share the same API’s. The iPad app is planned to be released in 2-3 Sprints from now.
This case study can be written from many perspectives, but in this article I am going to focus on how we are working with the challenges of having a distributed Scrum team.

Continue reading

I have been reading Gamestorming lately and found that I’ve practiced many of the games and followed most of the principles of game design already. However, there are a lot of new things in that book that I’d like to try. Today I tried drawing a Visual Agenda for the first time. I think it was well

Continuous improvement is a central part of both agile and lean; it’s the way to increase the productivity and ensure that the organization delivers an ever increasing level of value to the customers and the organization. Lean is derived from Toyota and the Toyota Way, which has inspired a lot of companies in the western world in their quest to increase their productivity as well. But we often focuse on the techniques and practices and do not see the more fundamental parts of the Toyota system that enable their very high level of improvement each year.

I worked at a company that tried to implement the Toyota Way and reach the same level of continuous improvment with what I believe to be the wrong focus. My company estblished a goal to reach seven improvements per employee in average per year. A goal that was inspired from a report that stated that Toyota implemented 1,000,000 improvements per year, which of course, is very high. This is one of many aspects that show why Toyota has managed to grow they way they have done during the last 50 years.

Continue reading

I’ve published another book! This one’s called “Lean from the Trenches“. It is about how we scaled a 60-person project by combing techniques from Kanban, Scrum, and XP. I chose this title because it really it illustrates how to put Lean principles into practice in a software project, especially the notion of an end-to-end Kanban

Most companies today uses differentiated salaries for their employees. This is something that is in general considered to be the way it must be; the companies needs the system in order to attract and keep talent employees to secure future profits for the business. This was also my belief until a few years ago; I thought that companies should pay more to the ones that produce more value to the business. Even if I saw cases where I thought people got too big salary increases and others too low at the annual salary review, I believed that in the long run the salaries would reflect the true values of each employee.

But during the last few years I have started to think differently. I do not believe in differentiated salaries any more, at least not for knowledge work like product development. There is too much evidence that the system you need to have in order to enable salary reviews each year, is impeding the progress of the business and lowers its result and profit. Knowledge work is based around motivated employees that have the support and environment they need to be creative during their daily work. Appraisals system, which is needed to implement differentiated salaries, is demotivating for the employees instead, and is therefore working against the high performance of the organization. Also, differentiated salaries is created under the belief that it is external motivations that drive people to be high performers, but as Pink describes in his book, Drive, it is autonomy, mastery and purpose that motivates people, i.e. intrinsic aspects instead.

This is also like Dr. Deming says in his book Out of the Crisis:

Evaluation of performance, merit rating, or annual review… The idea of a merit rating is alluring. the sound of the words captivates the imagination: pay for what you get; get what you pay for; motivate people to do their best, for their own good. The effect is exactly the opposite of what the words promise

My own experiencealign to this as well, both as an employee and as a manager, where I personally have witnessed the negative effect the system has had on its people and the company.

Continue reading

In Feb 2001 17 thought leaders from the software community met at a ski resort in Utah to discuss and compare notes on how to succeed with software development. These people had independently been creating new methods such as Scrum, XP, and Dynamic Systems Development Method (DSDM). During the meeting, they discovered a strong common ground: a shared vision of how to succeed with software development. This became known as the Agile Manifesto. After the meeting they agreed on twelve principles behind these values.

Continue reading

I am first and foremost an agile guy. I try to be as agile as possible at my assignments, and I coach and teach agile ways. But I know that there still are several companies that use RUP, and this is written for them.
As I argued in my previous blog post, you can do RUP and be agile. In this blog post, I will give you my top 3 RUP anti-patterns that I have experienced at various projects, and often enough the solution to them is to work in a more iterative way as the creators of RUP intended (more agile if you like). If you want to know what you can do about them, read on. If you can top them, please share your experiences with me 🙂

Doing the same thing every day for a long time can get boring. You might even forget why you started doing it in the first place; you just keep doing the same thing, and don’t reflect on what you are getting out of it. The scrum meeting at my current client had gotten into this rut, it had devolved into a status meeting. The participants routinely answered the three questions; what I did yesterday, what I’m going to do today and what impediments I have, but they didn’t really tell each other much about what they had actually done, or what they were planning to do today. They almost never reported any impediments either.

This team has been using Scrum for almost two years. It is a very well working team from a technical perspective; they produced an even amount of user stories each sprint with a high level of quality. But they had lost the energy in the scrum implementation. They felt that they could do more; that they could perform even better if they just could just somehow improve their scrum implementation.

We started working on the daily scrum meeting. Our goal was to use the meeting to give the team a good start to the day with energy and desire to start working on the tasks discussed during the meeting.  In order to do this we made a few changes, both large and small in how we perform the meeting.

• The structure of the scrum board
• The process of how we perform the scrum meeting
• The location of the scrum board and the meeting
• The metric that we uses to monitor how we are improving the meeting

Continue reading

In April Reza and I traveled to Teheran to teach the first CSM course in Iran. It was my first time in Iran, we had a great time! We had 30 participants in the class and they were absolutely amazing! They spent at least 30 minutes after class discussing, taking pictures, and joking around.

Continue reading

The past few days at my current coaching assignment have been great. We created a new backlog for all work they need to accomplish in the months ahead. The meetings where we laid the foundation for the future were marked by a high degree of collaboration between the participants and energy. It has been really fun to work with them so far.

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

I have just, as a guest blogger, posted a new post at the blog owned by the development team at TV4 Digital Media; “Några övningar vi gjort under retrospektiven”. It´s a post, in swedish, describing a few retrospective exercises we have done during the last sprints. I’m contracted by TV4 Digial Media as an Agile

Here are the slides for my Tokyo Scrum Gathering keynote “Everybody wants Change, but nobody likes to be changed“. Thanks for attending! Sample slides:

There’s a lot that could be said about metrics. I’m quite skeptical in general in the value metrics gives you in product development or running a department/organization. At the same time I feel that metrics could help you understand the health and status of your group/organization or project, and to know the effects the changes you implement have on the performance. During the years I have used a lot of different software metrics, both targeting the product development performance and the code and design quality. Most of them have been quite complex, and they have in reality given me little value or understanding of how things really are working.

But I have also used a few ones that I feel has helped me see things during product development, metrics that says something about the performance and also direct you to possible improvement areas. Below I briefly describe a few ones that I like.

• The happiness and stress indexes tells you about the health of the team
• The code duplication and test coverage tells you about the health of the code base
• The release burn down and lead time tells you about the health of the project goal

Continue reading

I had a conversation with some of my colleagues about what makes a good daily stand-up, here are some properties: Time-boxed (15 minutes) Everyone is engaged Synchronization is taking place Attention to problems People ask for help The conversation is about stuff that matters to most people, individual issues are postponed Anyone can lead the