Luis Goncalves
Last updated on | Agile General Knowledge

VSM (Value Stream Mapping) to help System Thinking

by Luís Gonçalves
value stream mapping, vsm

VSM (VALUE STREAM MAPPING) TO HELP SYSTEM THINKING

Hi guys, in this post I want to share with you an excellent story that happened several months ago with one of my teams, for that I will explain how to use VSM (Value Stream Mapping) as a tool to help System Thinking.

At that time I had a team that was making the first steps towards Agile. They were a fantastic team, keen to learn but still with the “old waterfall” mentality. They had a typical approach where the developers did development work and the testers – testing, not a truly Agile team.

I believe this is a common problem for teams that are switching to Agile: seeing only a small picture, they are not able to understand the entire system. I believe they lacked “System Thinking”. But what is “System Thinking”?

Shortly explained, “System Thinking” is the ability to see the “big picture” and not to be focused on just a small part of your job. For a better explanation, I will use as an example my former team to demonstrate my ideas.

In that particular team, the work was arranged so that the developers had a set of User stories to work on. A finished User story was passed over to the testers for testing. The problem was that although for the developers these stories were quite simple to implement, they were quite challenging for testing because of several compatibility issues that required full allocation of testing resources.

When developers ran out of User stories, they were asking the Product Owner for more stories to work on. However, the PO acted rationally and did not give them any new stories until the team delivered everything to the iteration backlog. It was obvious that the team needed some help to visualise everything that was happening. How to help the team?

Clearly, the developers had their best intentions in mind: they ran out of work. Therefore, they asked for more tasks. However, because of their lack of “System Thinking, ” they did not understand that more work for them would mean more pressure on the testing resources that were already fully allocated and, ultimately, an outcome of a poorer quality of the team effort.

Apparently, the developers needed to understand that it was not anymore a matter of “us and them” because their job is accomplished when a customer gets the product, and the product would be ready when the team would act as a single unit.

I have discussed this issue with some of my colleagues, and they gave me a good idea: in next iteration to use Value Stream Mapping (VSM) for observing how the system behaved. This tool is a great instrument to identify different aspects of a system. If you want to use it, you need to take some time to explain this tool to your team. From my experience, not many people apply this in software development.

VSM can be a fantastic tool to be used at retrospectives, but this could be explained in another post ;). Let´s see what happened at the iteration retrospective (an iteration where VSM was used).

By that time, the team was already familiar with the VSM, and they were quite impressed with the amount of information we collected using it. Having looked at different VSMs (we created one for each different User story), it was not long before the team could see that bringing more

User stories to the iteration would not translate into higher output because the testers were already fully loaded, therefore, producing more code would only mean that the testers would not be able to deliver everything on time.

The team started appreciating more “System Thinking” and not just think anymore regarding their separate “boxes”. After some discussions, the developers decided that in the following iteration they would help the testers with all the testing activities to deliver more User stories as a team.

In the following iteration, the developers and the testers worked more as a team, and the output of the joint effort of the team was indeed of a higher quality and volume.

Do you think this is something to consider when you work with your teams? What are your ideas on the topic? If you like to use VSM as a tool, you might consider reading this blog post: “How To Use Value Stream Mapping In Your Agile Retrospectives“.

Thanks,
Luis

Rate this post:
Luís Gonçalves

About Luís Gonçalves

http://luis-goncalves.com/

Luis is not simply a consultant, he helps people and businesses grow. He expects to deliver 10 times more value than what you’d actually pay for. As an Agile retrospective expert, customer happiness and client success are his biggest drivers!

Comments

Share your point of view

  1. Your post talks about developers and testers. did you had any similar experience with designers ? what should be their agile position on the hole. process?

    1. Actually we had some challenges with designers as well 🙂 You know better than me designers should be involved since the beginning :). Based on my experience having designers working together with the PO one iteration ahead is not bad. We tried this in couple of projects before and it works quite well. Would you be interested in writing a post here about your idea? You as a developer could give us some different insights. How about?

    1. You mean applying Value Stream Mapping? How can you apply it? If that is the case I will explain it on the next post. I got some feedback that people do not know what VSM is so I will create another post explaining it. Is it ok Bruno? If not we can always get a Skype call and I explain you ;).

    2. Yeap, i am just curious in what does it mean applying the tool. Is it just a verball communication about such problems so that everyones is aware of a systemic view in order tasks don’t overlap or you do you apply anything else other than the usual/common agile procedures on a big scale project where all tasks are pre-defined based in personas and use cases and stories?

  2. Hi Luis,
    My response may be provocative, but I am known for this, I hope you find it interesting as well..

    Seems to me you located a problem, explained it to the team, and introduced a tool to prevent it.

    I’d consider a totally different approach, which is to do nothing, and let the problem happen…

    I’ll explain…

    Supposing your assumption is right, the sprint would have finished poorly, perhaps even failed, which may waste some work (not a lot, I’d say a few days… since dev was done) but would produce a heated retrospective perhaps some conflicts between QA dev and PO
    And THIS IS GREAT! it will boost the team’s maturity and spirit enormously (if handled correctly, and remember – the retro is YOUR tool, this is where you can effect the team the most)

    But what if your assumption is wrong? what if the sprint would’t have failed?
    what if the QA is overbooked because they over-test? in which case there would be not so many bugs, which may lead to a change in the weight allocated to testing.

    When explaining what YOU see is wrong (and you said you had a hard time to do it), and putting a tool in place, you are (IMHO) blocking the growth of the team.

    And now for the hardest part for me, an apology:
    – It is so easy to interpret a story when it is given to you all wrapped up and you are not involved, I remember how I was so proud with some things I did with the team, and felt so stupid when re-thinking about it months later.

  3. Hi, just a small stupid question.. why wouldn’t the developers that finish the stories in that sprint help the testers get their job done?

    It amazes me how scrum is supposed to be about the “team” and then we talk about “developers” and “testers” and “analysts” and what not…

    The goal of _THE TEAM_ is to get stories done, if teh development work is done, then everybody should focus on the testing work.

    Why do we have to make things complex when they are super simple?

    1. Hi Matias, thanks for your input… I fully agree with you but at the same time I would invite you to try all those scrum ideas in a company that did waterfall for more than 20 years, where all the work was done in different departments 🙂 What scrum says (And I fully agree) some times cannot be implemented straight away. People need to understand by themselves. Changing ways of working and culture is something tht you dont achieve just because you start scrum 😉

      Cheers,
      Luis

    2. Agreed, I work in a company where we’re trying to implement scrum after thousands of years of waterfall in one of the most conservative minded countries in the world. I know that some of my colleagues will never change their minds, but I also believe is my role as scrum master to steer people into scrum, and not away from it. That’s why in your case I said that probably I would have gone more into strengthening the notion of what the team is. I’m not saying what you do is wrong, there is rarely wrong or right in our world, but I could see that in your case, the final output of the team will be depending on the testers capacity, whereas if you make them work as a team, the final output will depend on their capacity.

      Now, I might have also misread your article and the issue is that the testing people is outside your “scrum” team. In this case, I would either advise you to (and yes, I know it is not easy) to get testing within your team, and secondly, review your definition of done. Because If your “doneness” depends on an outside team, then, indeed, your team will be always get “bottlenecked” by this outside team.

      These are just my thoughts anyway, and it’s true, sometimes I’m too “idealistic” 😉

  4. Value Stream Mapping is a collaborative tool from Lean. Like any other tool, it can be used well or not so well. It’s a more layered and detailed version of “timelines” which is a common Agile/Scrum Retrospective technique.

    However, VSM is more forward looking so I would see it more suited to a Team Planning meeting or, better yet, a Product meeting. It’s basically intended to outline an end to end process, using colored post-its and swimlanes, with time lapses noted. The VSM sessions I’ve participated in have had neutral facilitators (with no domain knowledge) guiding cross functional teams in their determination of how to eliminate wasted effort and remove bottlenecks. A “kaizen” results, which is a type of Lean backlog.

    Technical Teams tend to do Whiteboard sessions to determine workflow and think aloud. I don’t know if I’d call a VSM a whiteboard session… but experience in using swimlanes or colored post its to facilitate collaborative problem solving is always a good thing. Plus, that’s what the techies are trying to do, anyway, in their whiteboard sessions…..

    Bottom Line: Value Stream Mapping, like Systems Thinking, requires a certain expertise to pull off well. I’ve participated and get it, but am not trained in VSM, although I’d like to be. And nobody on any team is going to be impressed by anyone else’s great discovery that we have to look at the interplay between all the moving pieces. Too obvious, whether you use terms like VSM or ST or not. The thing to do, IMHO, is get them used to devices such as post its and swimlanes, and asking questions about time lapse, efficiency and bottlenecks.

  5. I’m just curious. Does anyone know if having developers acting as testers, is in violation of SOX rules around Segregation Of Duties?

  6. Rlevine ~ Within a software development team, Development and Testing are roles to develop the product.

    What SOX SOD implies is to movement of products /work streams etc. Here the organization needs to identify potential risk areas (vendor / security) and implement proper controls to mitigate such risks (like fraud etc). Typically they hire auditors to help with identifying potential risk areas.

  7. Evolutionary weekly planning works like VSM. In preflection we spot the waste before we do the work and that way we can still decide not to produce the waste we otherwise would have produced.

X