Lean-Agile Roast: SAFe


I have been roasted (in a very friendly way) by Arne and Erik, two great friends that I have know for almost ten years now! Arne and I met at the first Kanban Leadership Retreat on Island 2011. Erik and I met at Ericsson 2012. I have learned a lot from both Arne and Erik. They are deeply knowledgeable and are also true practitioners with solid track records. Since Arne moved to Stockholm in 2017, we get to meet and talk more regularly. In several of these conversations we touched the pros and cons of the SAFe framework. We agreed that we would need a longer discussion to properly discuss the topic, so Arne invited Erik and me, and we recorded our conversation, which went on for over an hour.

Here is the third part of the conversation. Part one and Part two will be posted on Arne‘s and Erik‘s blogs. If you prefer to listen to the whole conversation, you can download the audio file here.

Arne: I find it interesting that you say there is a big focus on training managers up front. That actually sounds really tempting to me, because what I’ve seen a lot is that the managers say:

“Okay, we want to become Lean and Agile. So we hire a Lean person or an Agile person and then try to delegate this to this person and then try to weasel out of it.”
But in fact it is a really really big investment, especially for managers. And I assume that if you buy the SAFe package it is totally clear that before you can start with the implementation you need to sit down and learn the stuff. That that sounds really smart to me.

Håkan: The SAFe framework says that all the leaders need to be trained, before we start an Agile Release Train (ART). You want SAFe? This is how we do it. You are training the leaders so that they have an understanding of the SAFe framework, before you get started. And what we are trying to emphasize in our journey is that we want the leaders to be able to actually teach this to the teams further on. Supporting them of cause. Our focus as coaches on the enterprise level is to train and coach the leaders so the leaders can train and coach the teams.

Erik: But that would be an add on in line with Toyota leadership principles?

Håkan: That’s actually described in the implementation roadmap to some degree.

Erik: That it should be train the trainers?

Håkan: More or less, yes. Or it could be my Lean leadership glasses that tells me that that’s in there.

Arne: I would like to talk about the big picture thing, because I remember last time we had drinks you were really thrilled about it. Can you explain what exactly it is and what do you like about it?

Håkan: So I think the big picture is a great selling tool for people that don’t understand how SAFe could be connected. So by actually showing how things could be connected, you are reducing the fear of just walking into something that is unknown. Which, if you don’t have the experience, can be very comforting. Someone has thought about how it could work as a system. It helps to reduce the fear among the managers about this fluffy Agile thing and that we just gonna experiment and the future will tell if we get the business results. The SAFe big picture described how it could work as a system.


Arne: And what are the elements in the big picture?

Håkan: The big picture itself is divided in three or four levels. It depends on what version you want to implement.
On the basic level it’s describing how the teams would work together if you have multiple teams. This is kind of the basis for organizing an Agile Release Train. That is if you are at least 50 people. Otherwise you don’t need SAFe. It  describes how the teams would interact and the timeline for the basic events for team level.

And then you step one step up, there it shows how the interactions between teams would look like. It also describes the roles needed to make it work.

On the third level, it shows how multiple Agile Release Trains interact and who could be involved in doing that. How would it look like in terms of an iterative fashion? How would that look like? What do you need and what could be additional things that you need to think about?

And then on the top level, which could be third or the fourth level, depending on the implementation.  This level ties business strategies into execution for the different teams and Agile Release Trains. It is based on what SAFe call Lean Budgeting and a flow of Epics, related to your strategic initiatives or themes. If I would compare to Klaus‘ Leopolds different flight levels, you would have a team level, then you would have a multiple team level, then you will have a portfolio level.

Arne: And who creates this big picture and what do you do with it? Do you put it on the wall, or do you use it for trainings?

Håkan: Okay. So maybe you’re referring to the big picture that I created that was a compliment to the SAFe big picture?

Arne: Yes!


Håkan: I can describe what I created in addition to the SAFe big picture. There are a lot of the things on the SAFe big picture and it shows one, or a couple of iterations, but not necessarily how it would play out in calendar time. What I did was to try to illustrate for people how SAFe would play out during the year. So I took all the different events in our organization, including pilot Agile Release Train and other “Agile Release Train”-like organizations that interact. Then we tried to show the flow in between these different parts of the organization

Arne: So you tailored SAFe to the organization you are working?

Håkan: I took the concept and I kind of just played them out for a year. So instead of describing a couple PIs and kind of looks like it ends there. We played out what will be the the different program increments, PIs, over the year for Folksam. We mapped the events and how they connected to how we make decision on a strategic level – Budgeting, quarterly reports, and when we should do inspect and adapt and so on. All this to show how it all connects on the different levels.

Arne: Was that Håkan magic? That’s nothing that’s prescribed by SAFe?

Håkan: No, it was just playing it out in time and illustrating it. And I’m a big fan of visualizing stuff. So making a picture sometimes helps people to to think in new ways.

Erik: I agree. To have something like this big picture, however less or complex it is. It’s good to have it on on one sheet of paper. I’m used to the Larman and Vodde big picture. I don’t remember what it’s called even, but we had it in our journey at Ericsson. It shows a number of business requirement areas from the outside in. That was a very simple scaling mechanism. You take a combination of Scrum and Kanban, Kanban for the flight levels, and you can use Scrum or Kanban on the team level, and then you have an enterprise level Kanban board where you structure your lanes according to business needs to have that as a very simple scaling mechanism. So I think visualizing that and seeing that makes things really really simple.

Håkan: And that’s more or less what I tried to do. The big picture actually shows SAFe play out over a year, not just like a snapshot how it’s connected at one point in time. A lot of the stuff in SAFe is of course then very general so it’s kind of: here’s a snapshot in time how would it look and how would it interact? If you make a decision here on a strategic level, how is that then executed over the year? And maybe where you have synchronization between different trains, how the features would be planned in different parts of the organization? And illustrating that the more times you go through different trains and you have dependencies between different teams and trains the more lead time you typically generate. One of the goals of this implementation is to shorten the lead time. The Big picture kind of shows some of the problems.

Erik: Curious question: Do you currently have component teams, meaning teams that are working with a certain technology area?

Håkan: Yes. Is that our current context. And we are now trying to educate the organization on the downside of having that setup. One of the great tools to do this, which is I think something that they borrowed, is the dependency board. SAFe use it in the PI Planning (big room planning). This is a very powerful thing to most people, if they haven’t really understood it before, the dependency board will really help. They can take a look at all the strings that you will typically have in the organization and they will realize how many dependencies there are. That would affect lead time.

Erik: Do you see that as a gateway to move to a more cross-functional feature teams, which could go into all areas, because they have the competency from the beginning?

Håkan: Yes. It’s described in the SAFe framework that it prefers featured teams. But of course most organizations are not there in the beginning.

Arne: Erik, you mentioned earlier the Shu-Ha-Ri principle.I was curious about your take on how SAFe fits into those three steps. Maybe you can briefly explain what it means?

Erik: Sure. Let‘s go into eastern wisdom here. I tend to prefer that the Anglo-Saxon or American version of it: Learn the game (Shu), play the game (Ha), redefine the game (Ri). So first you need to learn the rules of the game, then you need to practice, and then you play the game a lot. And having done that, you can start redefining the game to take it to the next level. And as I said earlier, I think my fear would be that if there are so many rules to the game (like in SAFe), you might just get stuck in the first phase, which is learning the game. You might ultimately get to play the game and practice the game, but then there is potentially a new version of the framework coming out, and it’s getting more complex. So you never get to redefine the game yourself. You’re always playing by someone else’s rules. And that would be one one fear that I have, bearing in mind that I never practiced the SAFe framework myself. I tend to like Okham‘s razor: don’t make things more complex than they have to be. Or the Einstein dictum that you keep it as simple as possible but not simpler. So that’s my basic philosophy of life and probably that’s also where the dissonance between me and SAFe comes from .

Arne: Maybe you can Marie Kondo your SAFe. For every element you ask: Does this spark joy? And if the answer is not yes, then you thank it and throw it into the bin

Erik: Modern Eastern philosophy of life. Fantastic.

Håkan: Yeah. Why not. And I agree with Erik’s fear. If you just focus on implementing the framework, it’s probably not going to give you that much value. And that’s also why when we train we put a lot of emphasis of understanding the principles.

Erik: Curious question: How have you done a down selection? Have you picked parts already, a subset, where you start from?

Håkan: Some explicitly and some implicitly. So the explicit decision that we made so far is that we will not use what they call the large solution part of the SAFe framework. So we are using the portfolio implementation and that’s a way to not make it bigger than you need it to be. We are definitely not implementing at the moment things like the Lean UX part of it. The organization is not ready for that. We are moving in the direction of the lean business case on the portfolio level and on the financial and funding level.

Erik: So the Lean Business Canvas?

Håkan: It‘s a hypothesis based epic description, so you do it more based on the business value that you want. And you frame the hypothesis about how you think you would be able to achieve it. And then you need to test toward what you deliver. Are we actually achieving the results that we were expecting? We are moving in that direction. So, yes we select the things that we think could work in this organizational context.We also try to add things that we think are missing like the whole Hoshin part of how you actually work in your organization about goals and improvements. We will most likely add things like a Toyota Kata or a Four Disciplines of Execution type of framework to work on continuous improvements.

Erik: So always think for yourself.

Håkan: Of course!

Arne: I have one last topic I want to discuss and that’s tools. I vaguely remember when SAFe started it had a strong connection to one of the big tools. Was it VersionOne?

Håkan: It was Rally Software.

Arne: Is it still a thing? Does SAFe come with a tool?

Håkan: I’m not absolutely sure about the history here. I come from a Kanban background, so I’m leaning more towards tools should be visual boards with sticky notes and things like that. But I think Dean Leffingwell was a part owner of Rally Software so there’s a strong connection. And Rally Software also implemented SAFe in how they developed their tool. The SAFe Framework does not include any tools like that. However there are a lot of software tools that are supporting SAFe.

Arne: I’m learning a lot about right now about remote work and distributed team. Is there anything in SAFe about this? We know that it’s not perfect but I was wondering if Is there a section about how you handled the remote teams or you should not have remote teams or anything like it. Because it feels like it becomes more and more of a topic for four companies.

Håkan: I would say SAFe definitely prefers face to face communication.

Arne: Well that were all of my questions. Do you have anything you would like to add?

Erik: Well I think it’s always good to have the influences and the inspiration from several sources. And SAFe is definitely one of them. I would personally recommend people to go check out Larman and Vodde what they wrote ten years ago. I think the scaling thing is basically a solved problem by the brown book. Very pragmatic very much like try this avoid this try this we’ve seen it working in several contexts. It seems to be a pattern. Avoid this: We’ve never seen this work in any context. And it encourages you to think for yourself and try and experiment. So that would be one thing for me to investigate and be curious about what later turned out to be LeSS, the Large Scale Scrum framework, because they are in a sense trying to address the same kind of need similar needs but not exactly the same but in slightly different ways.

Håkan: That book is a great book. I really like it and the concept of trying things out is really valuable. And I think you need to also dive into things like what is your strategy for becoming better? So I really like the the book This is Lean by Niklas Modig and Pär Åhlström. And then of course the Don Reinertsen books are also really good. And then complement it with Toyota Kata or Four Disciplines of Execution.

Arne: Okay. Awesome. Thank you very much for your time.

Erik:  Thank you for having us.

Håkan: Thank you!


How to improve Flow Efficiency with Scrum – #Agile2014 Q&A


Thank you all of you who attended my #Agile2014 session: How to improve Flow Efficiency, Remove the Red bricks! In this, and upcoming posts (part 2) I will answer some of the questions I have received after the session.

Q1: I was hoping to better understand how to improve flow efficiency when the number of resources varies on our scrum process. For example, we have more developers than testers. We typically have a bottleneck in the test step. Not sure I got my answer.

This question is not necessarily a flow efficiency question. It may be more of a balance demand to capacity question. Nevertheless, let us explore the flow efficiency side first, as this was the main focus of the session. First, a short description of flow efficiency.

Continue reading

Agile2014 presentations

I had the great opportunity to present at two separate sessions at Agile2014 in Orlando.Here are the slides.

My first session was called “How to improve flow efficiency, remove the red bricks”

The video recording of this session is available on Agile Alliance Video Learning Center

In these posts I try to answer some questions I received as feedback for this session:

The second presentation that I co-presented with Erik Schön was called “The Mental Leaps at Ericsson 3G”.


Visual WIP Beta 2 is now out!

New and improved UI and better custom visualization support

Visual WIP the Kanban visualization tool for Team Foundation Server that makes your Work In Progress (WIP) visible!



This is the second Beta release of Visual WIP as the API is stabilizing. Changes may be made to what framework Visual WIP will be built on and further UI changes will probably be made as well.

What’s new

  • Pan and zoom is reset when loading settings
  • Added support for work item type and size specific design
  • The TfsWorkItemWorkProvider now adds support to open and edit work items.
  • Work items looks more like sticky notes
  • Auto loading of settings on the command line
  • Auto refresh interval is moved to settings file

Implementation details

  • WorkItemViewModel now inherits from DynamicObject to simplify work item field binding and error handling.
  • Simplified event bubbling implemented
  • Some out of memory problems has been addressed

Find out more and download at http://visualwip.codeplex.com

Some screen shots

A basic ToDo – Doing – Done board with no WIP limits.


A simple process with WIP limits. The Analysis and Development columns has to sub columns, Doing and Done, that share the WIP limit.


A three swim lane process with WIP limits


The settings window for a Team Foundation Server single query column. Team Foundation Server columns are populated based on Team Queries. Define your own or use existing ones.


Team Foundation Server work item editor. Double clicking on a sticky note on the board will bring up the work item editor for making changes and see more details.


Standard work in software development–part 2

In part 1 of Standard work in software development I described what Standard work is and how it is the cornerstone of continuous improvement in Lean. In the post I will describe how a software development team I have been coaching have been using Standard work for a few months.


This is a team that are doing a technology conversion from VB6 to .Net. They are in the process of converting a large number of batch programs with very different properties and implementations. Some are small, some are large, some are quite easy and some are very hard.

The process and visualization

To do the work we have identified some common process states that are used more or less for every batch. We use a Kanban board to visualize how work goes through the process. Below is our board with the process states we currently use.


The process states are written on the stickies at the top of the board and are:

  1. Prio
  2. Business analysis
  3. Business analysis done
  4. Technical analysis/design, development and functional testing
  5. Ready for deployment to test
  6. Ready for System test
  7. System test
  8. Done

The Standard work cards

About one third from the bottom of the Kanban board above you can see some white A5 cards hanging from hocks. Below are is a detailed photo of two the A5 cards.


These cards are our Standard work cards and here is an example translated to English:

From Technical analysis/design, development and functional testing

  • Code checked in to source control
              Should follow defined coding standard and architecture
  • Code review done
  • Database project updated
              Changes documented
  • Test cases should have been executed
              All functional tests are green
              All automated tests are green
              For bugs
                   Run tests in DST together with the tester
  • Update requirements document with dependencies
  • Update Team Foundation Server
             Document all significant changes
             Set State/Reason to Awaiting deployment/Fixed
             Set Label
             Set tester as Assigned to
  • Notify CM and testers that work is now Ready for deployment to test

How we use the cards

When a team member is getting close to finishing the work in a process state they take one of the card for that process state off the board.

They go thru the checklist ticking the items off.

If there is something on the checklist that is not applicable, it will be stricken.

If there is something on the checklist that is not correct, it will be stricken and a correction will be written on the card.

If there is something missing on the checklist, it will be added by writing the new item on the card.

When the checklist cards are completed they will be collected by the team manager.

If changes are made on the cards the team manager has an opportunity to discuss the changes. If the checklist has to be updated the team manager will update the checklist and print the new version and replace the cards on the wall.

We are making changes to the checklists on a continuous basis. The changes are often initiated by turned in checklists, suggestions made by team members, discussions at the daily standup and at retrospectives.

The evolution

We evolved our Standard work cards from the more common Definition of Done used in Kanban and Scrum. Instead of printing the Definition of Done on the board it self we are printing our Standard work on paper and cut them up to the A5 size.

The benefit of doing this is that every team member can get a copy of the Standard work and have it on their desk as they do the work and checking off the items on the checklist. The other benefit is that we can collect all the changes and corrections made to the cards. These changes are triggers for potential process improvements.

Future improvements

Possible future improvements I’m considering for the Standard work cards are:

  • Adding start and stop time for tracking purposes.
  • Adding work item reference number for tracking purposes.
  • Adding the name of the person performing the Standard work
  • Adding Takt time for every process state. This would be the normal time interval that this process state should take. If the time spent in the process state is outside the specified time interval a root cause discussion will be triggered to discover possible process problems or improvements.


You can implement Standard work in something as variable as software development. It is all about how abstract or concrete you get in defining your Standard work. You start out abstract and make it more and more concrete as you learn how your process really works. The most important part is to change the Standard work as you change how you do the work.

Standard work should continuously change!

Standard work is the cornerstone of continuous process improvement, even in software development.

How I visualize my weight loss progress


A friend and I have set out to lose 15% of our body weight between 15th of July to the 1st of December. If we reach this target condition we will go to Italy next spring for some vacation.

Because the feedback loop between food intake and changes to the body weight are quite hard to detect without measurement’s I have decided to keep track of two measurement’s:

  1. My body weight – On a regular basis I will measure my weight using Wii Fit
  2. Kcal spent during training – When ever I train and I have my Polar bike computer I will track Kcal burned.

Just tracking the last measurement’s don’t really give you the information if you are on track or the motivation. So I decided visualize the data.

You can the see a picture of the visualization above that I ‘m using. Here is a description what it shows.

  • The horizontal axis – the time in days
  • The left vertical axis – body weight in kg
  • The right vertical axis – exercise kcal burned
  • The upper dashed line – the upper control limit for my weight. I should never be above this line Smile
  • The lower dashed line – the lower control limit for my weight. I will probably not be below this line but it would not hurt Smile
  • The green solid line – this is the target weight for every day
  • The hand drawn ink dots and connecting lines – these are my weight measurement’s
  • The hand drawn ink bars – these are the number of kcal burned exercising per day

The idea is give me visible and visual feedback if I lose weight at the target rate or not. If I’m not losing weight is it because I don’t train enough or do I eat to much.

Wish me luck!