Value Stream Mapping a tool to help Systems Thinking

Hi guys, in this post I want to share with you a nice story that happened several months ago with one of my teams. At that time I had a team that was making the first steps towards Agile. They were a fantastic team, really eager 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 really 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 see 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 visualize 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 in terms of their separate “boxes”. After some discussions, the developers decided that in the folllowing 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?

I would love to get a star rating for this post:

Value Stream Mapping a tool to help Systems Thinking
3 (60%) 4 votes

Leave a Comment

  1. Reply

    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.

  2. Reply

    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.

    • Rlevine
    • February 18, 2013
    Reply

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

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

    • Matias Zaya Mendez
    • February 14, 2013
    Reply

    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?

    • Reply

      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

        • Matias Zaya Mendez
        • February 14, 2013
        Reply

        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” ;-)

    • Dov
    • February 14, 2013
    Reply

    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.

    • Bruno
    • February 13, 2013
    Reply

    Can you tell us what does it consist ofmin applying the tool? What kind of procedures and tasks involved?

    • Reply

      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 ;).

        • Bruno
        • February 15, 2013
        Reply

        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?

    • Marco
    • February 13, 2013
    Reply

    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?

    • Reply

      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?

More from our blog

See all posts

Stop being ignorant! Agile is not synonymous of crappy quality.

Hi, guys this week I want to bring up a topic that,…
Continue reading
sprint planning meeting

How To Have An Effective Sprint Planning Meeting

Hi guys, over the last weeks I have collected a lot of…
Continue reading
asked questions about retrospectives

The 5 most asked questions about retrospectives

The 5 most asked questions about retrospectives Guest blog by Marc Löffler.…
Continue reading