Monthly Archives: September 2013

Energize your sessions – Visual facilitation

Hi all,
recently we had a big company meeting where half of the day was spent listening to presentations.

Powerpoint presentations are boring because:

  • there is often too much text too read
  • it’s extremely difficult to visualize with powerpoint
  • it’s very tiring to listen to a speaker and to read text for 45 mins – 1 hour
  • there is little to no interaction with the audience

But is there an alternative and how does it work?

The Cure – Visual Facilitation

Creating interactive, easy understandable and appealing material for workshops and meetings is actually quite easy and even doable by the not so creative folks among us.
And the best thing: it’s ways faster to create flip charts than to create awesome powerpoint slides. 

Here is an example of an Agenda created with Visual Facilitation skills:

But before you start you need some pre-requisites:

Marker for Text and Shapes:

For Texts and all other Shapes Outliner No One is recommended
Colored BigOne for Shadows and Highlighting:

    For Shadows I’d recommend a BigOne No. 101

    Why these and not “any” other flipchart marker?

    1. They are refillable which saves you money
    2. The ink that is used doesn’t smear when you draw e.g. with orange over black which is the case with other brands that immediately will ruin your colored marker after a few uses

    Getting started – learning the basics

    So what do you need to learn to be able to create appealing flip-charts?

    First you learn the basic rules:
    • Always hold your marker the same don’t change your grip
    • Write text in big letters and close together, size it big enough so it is readable from far away (if you have graph flipchart paper use two boxes height for headings) 
    • The sun is top left, so all shadow goes to the bottom right
    • Shadow for square elements is outside
    • Shadow for round elements is inside
    • Create a corner around each flipchart with a shadow to pimp it before taking a photo of it
    • Don’t draw through other elements but leave out some space in the line to emphasize the 3D effects
    • Don’t make flip-charts beautiful in front of an audience, do that after the session is over before taking photos

    Then you typically draw some basic shapes like in this picture:

    From there you immediately go over to draw people and interactions:

    People and groups can be drawn in two ways:

    Round people


    People and animations are the hardest part of visual facilitation. But after some practice you’ll be able to visualize even the most complex interactions between individuals and groups.

    The creative people will get this part immediately. For the not so creative ones some guidance is extremely helpful.

    This is why I suggest to do either:
    • internal workshop with someone who already knows how to do it
    • external course with a professional to learn it thoroughly
    • self-study with the books
    It’s also easier to first acquire some “vocabulary” before creating more complicated material. You can do this by creating your own Pictionary like this:
    To be able to do this I strongly recommend to get one of the following:

    With these books you always have a reference to find new shapes and animations and even complete templates for different workshops.

    Last thing I want to share with you is the output of someone who never heard about visual facilitation before  and after a two hour workshop was able to create this:

    When do you start to take your marker instead of opening power point?
    While doing the workshop and drawing pictures of their work the attendees got a lot of new insights because they looked at it from a completely new angle.

    Start using this great tool to generate valuable outcomes of your meetings that people will remember.

    Thx for reading,

    Are we “done” yet? Getting to a Definition of Done

    Hi all,

    I’ve seen many teams struggle with their Scrum or Kanban boards.
    Many of the teams had an “in review” column where the stories would pile up during the sprint.
    A lot of stories were worked on in parallel but the burndown looked something like this (if they were lucky):

    Why can’t we get stories done continuously?

    • Too many stories started in parallel due to specialisation or lack of focus
    • no visibility on the progress (missing burndown)
    • no real team commitment but loosely coupled bunch of individuals
    • doing mini waterfalls due to dependencies on work from outside (testing, deployment)
    • no clear definition what done means
    There might be many more reasons, but two of the things that every team can start working on are the following:
    1. Agree to focus on getting stories done before starting new stories, helping each other on the tasks that need to be done, always checking on what team mates are working on before picking tasks of a new story
    2. Set up a Definition of Done for the team that can be used as a working agreement inside the team and also in negotiation with the PO to let him or her know what to expect as outcome of a sprint

    Step 1: Gather input

    First of all everyone needs to understand what a Definition of Done is for and that it is a contract between the team members on how they want to work.
    And much more important:
    The Definition of Done can only be created by the team itself and has to be agreed upon by all members. The input to it should come from the team members themselves and should not be pushed from outside (e.g. the scrum-master, manager). This is especially important if the team should accept the DoD.
    So your first step could look like this:
    Once you have a rough idea and clustered the redundant points you’re done with step 1.

    Step 2: Now, Next Sprint, in the Future

    With a big list of things to do you could start and use this whole list immediately. But stop!
    Doing the step from manual testing to full blown automation testing with unit test, integration test and automated deployment might take a while.
    So what can you do to not overwhelm the team with impossible tasks and still get some stuff done to not get haunted by the PO?
    Structure the List of points that you found in step 1 and create something like this:
    Must: Everything that is in immediate effect right after the meeting
    Should: Points to be worked on and cover in the next 1-2 sprints
    Want: Long-term plans for the team (4-8 sprints)
    Nice to have: Once all the other basic points have been implemented this would be the gold-plating

    You can use this tool to agree upon each point. Agreement doesn’t have to be full support from each team members for each point. As long as you don’t have anyone blocking, you’ll be fine.
    Just have everyone make a mark or use the avatars from your Scrum/Kanban board if you have some.

    Step 3: Work in progress, follow-up

    A Definition of Done should be a living Document and it should be constantly visible for all team members. Since it’s a living document the team should regularly check the validity of the definition of done and where they stand in improving. 
    Ideally more and more post-its from the initial session would make their way from the “should” and “want” section to the first section “must”. 
    As the team learns and grows in technical skills like automation testing, pair programming BDD/ATDD they can add new points to the “should” and “want” or try to achieve all of the initial points. That depends on the environment and improvement speed of the team.
    Follow-up sessions, be it in a retrospective or dedicated meetings about the DoD are imperative to success. If you plan to create a DoD in a “fire and forget” manner then stop right there and don’t do it at all.
    If you don’t have a Definition of Done in your team already maybe this post inspired you to create one? Let me know the outcomes. In case you have a DoD this might be a good time to review it and see where you might need to change it or enhance it?
    You are the most important part of continuous improvement, so go and continue to improve!

    Teams – Using conflicts as potential for great success

    Hi all,

    recently I did a retrospective with a team and one of the points that we found out to improve is teamwork.

    image source:

    This reminded me of a book that I read about teams: “The Five dysfunctions of a Team”.
    And since it is an awesome book that gave me a lot of insights about team dynamics I wanted to share some of it with you.

    In many companies a Team is the smallest working unit and therefore the foundation for success. If you have teams that work together really well, take over responsibility for what they do and show commitment you’ll normally also have the outcomes that you want see.

    So what is a good Team and how does solving conflicts help in being successful as a team?

    Team Values  

    1. Trust – this is the basis for a good team. Members need to be able to trust and rely on each other. “All for one and one for all”. This includes being open to suggestions for improvement from fellow team mates and also the ability to give this feedback in case others lack skills in certain areas.
    2. Culture of Conflict – Teams that are not open and honest with each other will hide their conflicts. The subliminal conflict will always be there in discussions and members will talk behind the backs of the others. Teams that trust each other will openly talk about conflicts and solve them.
    3. Commitment – Teams will only commit as a unit to their goals if they have Trust and a Culture of Conflict. That is needed to get the buy in of all team members. There will always be decisions to take that not all team members will have the same opinion to begin with. Then they have to openly discuss and solve disagreements to be able to commit as a whole.
    4. Accountability – Teams that commit to targets know what needs to be done to achieve these targets. All team members work together to achieve what all the single members of the team could not achieve alone. This also includes reminding team members of what they committed to do. Everyone has a bad day sometimes, and team members will be there to motivate each other.
    5. Delivering results –  Great results are the result of great teamwork, and great teamwork is only possible with all the value that you read before. “Stars” inside a team who value their own ego or career development higher are the biggest threat to delivering team results. They will undermine all the values because they have their own secret agenda.

    How to improve your team?

    Building Trust

    Trust me. I know what Iā€™m doing. Honest.
    Image source (

    • First step of trust is to get to know each other better. This works best for newly assembled teams and can be achieved with a speed-dating exercise where all the team members talk to each other for a few minutes to find out about family status, hobbies, interests and so on. This will result in a deeper understanding of team members.

    • Finding out the team effectiveness – Team members identify the most important contributions of their peers to the team as well as the most important area to improve. This will give the team a lot insights about their strengths and where to improve most
    • 360-Degree Feedback – Team members make specific judgements and give constructive criticism. This requires a basis of trust to use and also this feedback needs to be detached of performance evaluations or compensations
    • Team Leaders – in order for team members to show vulnerability and take risks the leader has to be a role model and do the same. If the leader has an image of invulnerability and no flaws it will make it difficult for team members to be open about their weaknesses.
      Even more important for the team leader is to create an environment in which it is ok to show weaknesses and make errors. If you get punished for making an error what you will do is to simply hide all the problems.

    Solving Conflicts

    This is the most difficult at least for me, since it may include hurting the feelings of other even though that’s not intended.
    Before you start to work on conflicts try to create an environment where everyone agrees that it is good to work on conflicts and to solve them.

    • Mining for conflicts – someone in the team can take over the role of a “miner” and uncover buried disagreements in the team and work on them until they are solved. Important here is the commitment to stay on the conflict until it is solved
    • Encouraging each other – while working on conflicts team members should remind each other that it is important to continue working on disagreements even if the tension is so high that some team members want to withdraw themselves of the discussion because they feel too uncomfortable. This is when their peers can help them by coaching them.
    • Leaders role – a leader should support conflict instead of suppressing it, they need to demonstrate restraint to allow a natural resolution of the disagreements. This is often counterintuitive for a leader since they often need to protect the team from harm. The inability of a leader to allow healthy conflicts inside the team will in the long run harm the commitment, accountability and ability to deliver results of a team.

    Achieving Commitment

    To achieve commitment from a team you need to have clarity and buy-in.
    Great teams achieve this buy-in from every team member even if initially not all agree on the decision. 
    This requires the team members ability to accept a team decision once they’ve been heard and formulated their doubts. It’s also necessary to let everyone’s ideas be heard. In case of an impasse the leader should be allowed to make the call. Coming to a decision should not be hindered by consensus.
    In case of uncertainty the team should be aware taking a decision is better than no decision. Not taking a decision often is a direct result of a fear of failure. Good teams make decisions and learn from it if it was the wrong decision. 
    Improving commitment:
    • Cascading Messaging – after a meeting review the key decisions that have been made and agree what needs to be communicated about those decisions. By doing that a team reassures that everyone understood the decisions the same way and that it is clear who to inform and what information should be communicated
    • Deadlines – setting deadlines to take decisions and following them even if they are only milestones to the real important decisions, forcing misalignment between teams to be addressed
    • Worst-Case Scenario Analysis – a team that struggles to take a decision often can be helped by painting the picture of the worst outcome that could happen, often resulting in reduced fear and thus helping the team to understand that making a wrong decision is not tragic at all
    • Leader – a leader must be willing and comfortable to make wrong decisions and he or she must push the group to adhere to schedules (deadlines) that the team has set

    Reminding peers on performance and behavior that hurts the team is one of the hardest parts of teamwork. This is also called “peer pressure”. 
    Team members show respect to each other by holding one another accountable and showing their high expectation on performance.

    Reaching Accountability 

    • Publication of goals and Standards – for an agile team this would mean the creation of a Definition of Done that is agreed upon by all the team.
      It can also mean to write down “Team agreements” about the ways of working and interacting with each other. In an agile Team a clear goal would be a user story that has a clear description together with acceptance criteria, so that no one could talk him or herself out of not reaching the committed target
    • Giving feedback about performance – in an agile team if you have a backlog you normally also have a burndown. A team can use the burndown to constantly reflect on their progress towards their committed goals thus reminding each other of what everyone needs to do to achieve the agreed team goals
    • Team rewards – a team is more likely to succeed if the team as a whole is rewarded in case of success. Team members won’t stand by quietly if one of the peers is not pulling his or her weight
    • Role of the leader – a leader should create a culture of accountability in the team meaning he or she is not the only source of discipline. In the case the team fails to hold each other accountable it has to be clear that the team lead will step in when it’s necessary

    There are two factors that work against team delivery team status and individual status.
    For some teams it’s enough for their members to be be part of the team to be satisfied. One could take an architecture group or management group as an example.
    Personal career and egoistic goals that are set higher than the teams success is another danger that can hinder delivery.

    Boosting Delivery

    • Make results clear and only reward actions and behavior that benefit these results
    • Public Declaration of Results – once a team has committed to achieve a specific goal it should also be comfortable with declaring these goals publicly. The whole company should have a culture to not throw stones at those that don’t achieve results but collaboratively support teams through continuous improvement cycles
    • Team leaders are the most important factors in achieving results. They need to be selfless and objective and reward those that contribute to the achievement of group goals. If team members sense that a team leader doesn’t value results but for example his own career most then no one will be motivated to deliver
    After this short summary if you liked the ideas and structure of the team analysis I highly recommend to read the book The Five Dysfunctions of a Team. It is written in a novel style and can be read in 1-2 days.
    I’d be happy to get some feedback if you found something interesting in this blog or in case you have a suggestion for improvement. Then please leave a comment.
    Thx for reading,

    Value flow – what is Value and is there something like Waste in software development?

    Hi all,

    this is the second article about Value flow – last time I gave a short introduction in Value Stream Mapping.
    With Value stream mapping you can find obstructions to your value flow and then work on them one by one until the value flow improves.

    But one question that you might have had when reading the last blog is still open.

    What is value in software development?

    For some companies value is easily defined by their total turnover per year. The higher the better.
    So everything that generates revenue is value.

    Then there are different companies. I’m reading the book “The Toyota Way” right now.
    Kiichiro Toyoda the founder of Toyota Motors Company once said to his son:
    “Everyone should tackle some great project at least once in their life. I devoted most of my life to inventing new kinds of looms. Now it is your turn. You should make an effort to complete something that will benefit society”.  
    That is one of the value principles in Toyota. Everything that they do is not oriented at total profit but should also benefit the society that we live in.
    Certainly there are different philosophies depending on the company but one thing is common to all of them. 
    Value is defined by the customers that pay for products. Only when customers like a product they will pay for it. So this defines value as:
    The properties or factors of a product that a customer is willing to pay for.
    For the further discussion let’s call the customers that in the end pay for a product: end customers 
    As software development especially in enterprise environments is normally no simple task but requires some advanced engineering skills you more then often have several steps that you need to undertake to create the “final product”.
    This is why it’s also normal to have “internal customers” inside a product development chain.
    If you have a “test at the end” strategy for example your Quality Assurance department would be a customer of your development department or maybe of your build & deployment department.
    So for the following discussion about waste in software development we distinguish between internal customers and the end customer

    Wastes in Software development

    The following wastes are also taken out of The Toyota Way, but I try to translate it to the world of software since making a car is not exactly the same as software development.
    1. Overproduction – parts of your product that haven’t been ordered by your customer. In software development often generic classes or “building for the future to be flexible”. Most often it means to make things more complicated than they really need to be. “Gold Plating” would also be considered overproduction
    2. Waiting – The tester waiting for the developer to end the implementation part so that he or she can finally start the (manual) testing. The developer that waits for the build pipeline to finally give feedback if the automated tests were broken or not. The team that waits for the PO to decide that important decision so they can start using the new tool.
    3. Unnecessary transport or conveyance – Having to move the needed material long distances. In software development this is needed information. And the fastest way of getting to this information is if the team is collocated and sits together with their respective PO. Any form of “EMail, telephone, walking over to the next building” can be considered as unnecessary transport.
    4. Overprocessing or incorrect processing – Doing extra work or processes due to usage of bad tools or poor product design (architecture) often causing unnecessary motion and producing defects. Waste is when your product is higher quality than it actually needs to be.
    5. Excess inventory – too high WIP (work in progress) which causes delays and in the end leads to a hiding of the problems because problems often only surface after they reach the end customer. In software development the most typical form of excess inventory is working on too many projects in parallel.
    6. Unnecessary movement – all extra movements that a worker has to to at the production line such as walking and longing for tools. In software development I’d consider every extra step during the normal work e.g. filling out form xy before checking in to source control or clicking 4 times with your mouse in the UI instead of just using keyboard shortcut “cmd + alt + p” as unecessary movement.
    7. Defects – Finding bugs, rework and fixing of the bugs, extra releases or patches that need to be shipped together with all accompanied extra work
    8. Unused employee creativity – By far the worst waste in my eyes. Most often ingenious middle managers which are 10 years out of development decide on environment and tools for their development teams instead of delegating these important decisions to them.
      Not listening to the improvement ideas of the employees and not providing an environment of learning and continuous improvement. In many companies employees even have to beg to get books paid for self studies.

    Now what does this all have to do with Value Stream Mapping?

    You know how to create a Value Stream Map. You learned it in how to create a Value Stream Map.
    But what do you do with it?

    How can you read a Value Stream Map?

    Do you remember the Value Stream Map from last example?
    What you would start with in your analysis of the Value Stream Map (VSM) is the biggest waiting phase. Then you can use the list of the different wastes from the previous chapter to categorize where the problem is coming from.
    When doing this always consider the internal customer as the next step that is following.
    For example a developer would be an internal customer of Analysis and Prio and the value he or she needs to have is the priority of what to do first. Just the information not a fancy System, it could even be post-its.
    In the example above you’re kind of building piles of “excess inventory” (fixed bugs) that has to wait for a release to be scheduled and deployed. Also this long time of waiting will hide if a bug really has been fixed, since the customer could have a similar problem but not exactly the same thus creating some defects in itself.
    You can start your root cause analysis with asking “Why” 5 times:
    1. Why do we only release every 3 months?
      Because it takes us 2 weeks to do a full regression test
    2. Why does it take us 2 full weeks to do a full regression?
      Most of the tests that are done in a regression are done manually and we only have limited resources to do the tests
    3. Why do we have so many manual tests?
      Our skills in writing automated tests are lacking and we couldn’t create automated tests for our legacy code base
    4. Why couldn’t we create enough automated tests for our legacy code base?
      We’re asking for the time to do it for several months now but we’re always under pressure to deliver the next release
    5. Why are you under constant pressure to deliver the next release?
      Between releases we would need some time to “wrap up” and refactor some of the things we had to do for the previous release, but since we’re not given that time we’re working extra hours to get things done in time
    From there choose one of the things that you want to work on.
    Then you go into the Deming Cycle that you might remember from last post.
    Plan – Hypothesis: “With one sprint after a release to wrap up and refactor we would be able to take care of tests for our legacy code base to shorten the time for regression tests by automating manual tests.”
    Do – run one sprint after a release with the measures that you deem necessary
    Check – compare how much time you saved by automating regression tests compared to doing them manually
    Act – if you achieved the anticipated results then consider adding a sprint for working on refactoring and dealing with legacy code to your release planning (standardizing it)
    From here on it’s on you.
    What are the WASTES that hinder you the most? Identify them using Value Stream Mapping.
    How would you start working on them by doing a root cause analysis and then use the Deming Cycle to improve and standardize your findings?
    If you used this method please share some of your findings with us so we can all learn from it.
    Thank you for reading this lengthy post šŸ™‚