Category Archives: Uncategorized

Blogging – Get Started Today

Hi all,

I’m not blogging for too long and still learning in how to do it in a good way.

Blogging can be a really great instrument to:

  • forming great ideas into something useable
  • condensing information from a book to share it and reference it later
  • writing a book like my friend Luis Goncalves recently did it 
  • showing what you’re passionate about
  • sharing your expertise with others
There are many more reasons for blogging. 
The one thing that many of my colleagues and other people with whom I spoke about blogging find as a big blocker is:

Starting with your first blog post – today

http://indulgy.net/a1/6F/nC/64598575875124329lXqu1zGbc.jpg

There are so many reasons why not to start a blog. I even had a discussion about that when I gave a crash course about blogging in my company.
You will only find out if blogging is for you by starting to write your first blog post.
Not tomorrow, not in two weeks. Today.
If you’re not willing to start today then don’t bother to read any further, you’ll just be wasting your time.

From the blogging crash course that I did I want to share some material with you.
Those ideas are from another blog.


  1. What is the reason to write this blog post? Think about why this could be interesting for others or how it will help you.
  2. Is there a special group of people that you want to address? What is it that moves these people?
  3. Write a headline that would also catch your interest when you would see it on any random page
  4. Write with someone as your target persona in mind. This can be you in case you want to share specific problem solving that you’ve found out with others.
  5. Structure the content in a way that is useful for you and for others. No one likes to read lengthy blog posts that only consist of text with no headlines and no pictures.
  6. Ask others for feedback or put a call to action there. There is a reason why you wrote the blog, you found it when thinking about point 1 – the goal.
  7. Write your first blog post today, then follow-up and continue. Be strict to yourself it will pay out soon. Once you’ve written a few posts it will get easier and feel more natural.

Checklist for your first blog post

Once you’ve written your first blog post you can use this checklist to see if you thought of everything.
From my own experience writing a blog post you’re looking at the following structure time-wise:
  • drafting 10%
  • writing + reviewing content 30%
  • finding a good headline 20%
  • putting appropriate pictures that transport your idea 40%
These numbers are just a rough guideline.
Looking for the right pictures I normally do at the very end before publishing the blog, because it’s the most time consuming part. I’d rather publish the blog post with just text than not publishing it at all because I start first looking for pictures, don’t find any and getting frustrated.
So now it’s the time. If you don’t have a blogger account create one and start blogging away. In case you have difficulties with it leave a comment and I’ll see how I could help you overcome the first and biggest hurdle.
Thx for reading,
MrSnow76

Value Flow final – lean on “Lean”

Hi all,

http://physics.ucsd.edu/do-the-math/wp-content/uploads/2012/02/matrix.jpg

in my first two blogs of this series about value flow I talked about Value Stream Mapping and waste in software development. If you read both blogs you’re beginning to scratch the surface of what lean is and that is a good thing. You are thinking beyond short time local improvements and focus on seeing the system as a whole. With this blog I want to conclude the series about value flow with a broader picture about lean.

Thinking about your company as a system that creates value and understanding how it does so and then continuously improving current standards, the way of work and how to learn is key to becoming lean.
Here are a few ideas how you could start on your journey to lean.

Systems Thinking

  • have long-term solutions and improvements in mind
  • use “pull” instead of push
  • level out workload
  • use visual controls to highlight problems
  • stop to fix problems
  • use reliable, thoroughly tested technology that serves your people and processes
  • grow leaders who deeply understand the work live the philosophy and teach it to others
  • develop exceptional people and teams who follow your company’s philosophy
  • make decisions slowly by consensus thoroughly considering all options; implement decisions rapidly
  • go see for yourself to fully understand the situation
  • become a learning organization through relentless reflection and continuous improvement

Now the key for most or anything in a company is management. A transformation to lean is nothing that you can do bottom up with the exception of startups where everyone might still be equal.

Role of Management

http://321pounds.files.wordpress.com/2013/04/drill-instructor.jpg

So you convinced the developers to use kanban boards with pull mechanisms to create a better flow of work. What next?
You find out that for real flow you would need true cross-functional teams, switch some workplaces maybe bring everyone together in a new office room.
Or you want to do a Kaizen-workshop to start working on long-lasting problems and show how those lean tools can help your company?
Can you do it on your own? With the teams help?

Almost always you’ll have to involve a manager from a certain level. This might be team leads, middle management or even C-level.









Motivate Management 

Management is keen on numbers, so give them numbers. Get them hooked up by providing them short term improvements that show the potential of what you want to do.
You could for example use a kaizen workshop to drive down the time for building, regression testing, deployment and uploading of the software that your company develops from 2 weeks to several hours.

What you want to do is to get their attention and then make them passionate leaders of your transition to a lean company. Don’t fall into the trap of just going for the low hanging fruits. Always follow up your quick wins with long-term strategies and continuous improvement programs that involve the leaders.
The goal here is to get the leaders involved and develop them instead of shining with quick wins.

From there your company should make it a goal to have leaders with the following skillset:

As you can see the most important skill by far is building a learning organization. In this role the leader should be the ones carrying and conveying the vision of the company and coaching and guiding how to get there.

As a group facilitator the leader empowers the  teams to take decisions for themselves and consult rather than command.

Additionally a lean leader also needs to be able to be a task master. This means he needs to know how the work is done and be able to show “how to get the hands dirty”.

Last but not least even in lean there is some bureaucracy needed. Processes are standardized with the help of the “Act” part Deming Cycle that you find in the second blog about value flow and those standards need to be followed. The leader also watches over these standards to ensure they are continuously reviewed and improved.

Without management support your quest will be over quite soon, but what else is needed?

Tips to get started with lean

These tips can help you get started:
  1. improve processes in the technical area; directly after that implement cultural change
  2. First doing, training comes after. Theories are nice, results are better.
  3. Use value stream maps to develop models that can be used as a “go and see” example
  4. With the help of these value stream maps create a future state vision that enables people to “learn to see”
  5. Kaizen-workshops can boost improvements on the way to the future state
  6. Re-organize around your value streams
  7. Make the transformation mandatory
  8. Use a crisis to switch to lean as a last resort
  9. Find “short-term” improvements with big financial impact to boost your movement
  10. Change your metrics to reflect your value streams perspective, e.g. throughput time
  11. Create your own lean company culture that can be seen as your DNA
  12. Hire or develop lean leaders and follow up with a succession system. If the top is not driving the transformation it will not happen.
  13. Use experts for teaching and getting quick results.

http://www.leansavvy.com/Images/Solution%20Way%20Sign.jpg

After that the only additional tip I want to give you is to get started. Apply pull systems, facilitate Kaizen workshops, create value stream maps.

If you found this blog interesting then I highly recommend to read the book The Toyota Way. Even though it’s not about software development almost all principles can be directly applied to a software environment. Another book that I highly recommend is Lean Software Development.

Thx for reading,
MrSnow76

Energize your sessions – Visual facilitation

Hi all,
recently we had a big company meeting where half of the day was spent listening to presentations.
source: http://tomfishburne.com/site/wp-content/uploads/2011/12/111205.powerpoint.jpg

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:

http://www.neuland.com/EU/markers-for-paper-use-9uek9p0tz9z/neuland-outliner-no-one-vk6ex9q4a5.html

For Texts and all other Shapes Outliner No One is recommended
Colored BigOne for Shadows and Highlighting:
    http://www.neuland.com/EU/markers/neuland-bigone-jmye29rxhxq.html

    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














    Stickmen
















    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,
    MrSnow76

    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!
    Cheers,
    MrSnow76

    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: http://www.freshtracks.co.uk/images/blog/outnumbered.jpg

    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 (http://firstrung.co.uk/dbimgs/knife%20thrower.jpg)

    • 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

    source: http://1degreebio.org/common/files/blogs/
    6158-1368542620-1degreebio_blog_work-conflict.jpg
    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.






    Methods:
    • 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

    source: http://4.bp.blogspot.com/-LZ2-ThJrFck/T2jbzyUrhII/
    AAAAAAAABCM/HSqJaWslzgE/s400/Musketeer-Sword.jpg
    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

    Accountability

    http://cardinalconnection.org/wp-content/uploads/2013/03/peer-pressure-image-jpg.jpg
    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

    Delivery

    http://i195.photobucket.com/albums/z225/bullseyedrivingschool/180darts.jpg
    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,
    MrSnow76

    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 šŸ™‚
    MrSnow76

      Value Flow – get insights with Value Stream Mapping

      Customers like to have a constant flow of value, the faster they get their products and the lower their costs are the happier they will be. 

      Faster Value Flow with lower defects

      With the rise of agile methodologies and techniques like XP (Extreme Programming), Scrum, Lean, Kanban many companies seek to improve their capability to deliver value in short time spans and with lower defects.
      Automated Testing, Continuous Integration and Continuous Delivery are some of the buzzwords that you might have heard. I won’t go into detail about these but will show you a practical example how to get deeper insights into any part of your value chain.
      But before talking too much about the background why you do it and raw and boring theory I’ll just go ahead and show you a practical guide.
      If that get’s you interested you maybe want to read the follow-up blogpost.

      Step 1 – Post-Its and a pen

      All you need to start is a pack of post-its and a pen.
      With that you create something similar like you see in the picture below.

      What you’ll do is to literally “walk” the value stream and create a post-it for every action taken where you also take a note of how long the action itself takes.
      While you do that the most important step is to also take a note about the time it takes between the actions. This you can see in the arrows in the picture above. 
      For the example above you would note the time that it takes (in average) from the moment a bug is found until it is submitted into the bug-tracking system. And also the time that it takes until it is analysed and prioritized. From there on walk your way through the complete bug tracking chain and take notes of all actions and the time it takes until the next actions starts.
      With this information you can now create the… 

      Value Stream Map of the bug fixing chain

      1. To create the Value Stream Map first find an appropriate scale (in this example the whole time was 50 days), but don’t be scientific about it all you need to create is something with the right proportions
      2. Draw a horizontal line for the action with it’s duration
      3. Draw a vertical line when the action is done and goes into waiting mode
      4. Draw a horizontal line for the duration of the waiting time
      5. Repeat step 2-4 until you are at the end

      Analysing the Value Stream Map

      Now you have the information that you wanted in a very nice visual way.
      All the work done with it’s duration is above the baseline, and all the wait time with it’s duration is below the baseline.
      You can also add the numbers on the value stream map, but you don’t necessarily need the numbers. What you want to find out is the relations between work done and wait time.
      If you take the example above one thing jumps to attention when you look at the time between having fixed a bug and when it is assigned to a release until it is finally deployed and tested.
      The waiting time is huge.
      So if you don’t have limitations from outside your company on how often you can release one obvious step to improve the time for fixing bugs would be to release more often.

      Next – Improve

      So why did you do all this paperwork?
      If you care about your customers you want to provide them with constant value flow.
      And if you do it right and your customers are happy this will in return give a constant flow of new work and projects which will make you successful.
      So pick out the one thing of the value stream map that you can and want to work on and improve it.
      In my next blog post I’ll speak more about ways (like the deming cycle – PDCA below) to identify possible improvements and also how you can step by step work on improving those flaws in your value flow.
      If you liked this blog post I’d be happy to receive feedback on how you created your first value stream map, what insights it gave you and I would also be happy if you then read the follow-up post.
      Cheers,
      MrSnow76

      Fixed Price = Death March?

      So there you are being asked to lead that agile fixed price project. Is it a death march project?

      What will you do to find out if it’s worth doing the project or if you should avoid it?

      Maybe it’s one of the following:

      • Scope – find out what exactly should be built and how much uncertainty and assumptions are in it
      • Risk – create a list of major risks, how they will affect the project and what you can do to mitigate the risks and if the estimated buffer is big enough for your list
      • Team – does the team that should deliver the project have enough domain knowledge, more important was the team involved in the estimation process and is the team the right one to do the job?
      • Customer – Do you have a dedicated customer representative that is there for your questions and who will do the demos with you ensuring that what you build during your sprint/iterations is what the customer wants? Will he also be there to continuously re-prioritize the backlog if needed?
      • Environment – Are all the technical (software/hardware/systems) and physical (desks, access) prerequisites met?
      • Definition of Done – Has a concrete list of deliverables and constraints been defined together with the customer to define what the product increments should include in the demo?
      • Dependencies –  are there any dependencies that you cannot influence and is your customer taking care of those?
      • Velocity – Do you already have empirical data of the team that should work on the project so you can validate scope vs estimation? 
      • Change – Is a change process defined together with the customer to avoid scope creep?
      • Ceremonies – is there a buffer for clarification of unclear specification? For additional meetings beyond your Pre-Planning, Planning, Demo and Retrospective? Are those even included?
      After you checked these and everything is to your satisfaction, there are still some indicators that can help you on your way.
      Project Burndown

      If you have a burndown like that, you should act already in sprint 3-4 and talk with the customer about the budget vs. story point delivered trend. Whatever the reasons are when the money is out it’s too late to act.
      Don’t allow Change Requests
      • The scope is as negotiated, if the customer wants one extra feature he has to remove another from the backlog, and he has to take into account that you have some extra work estimating the new feature and managing backlog etc. so he’ll probably loose some additional scope 
      • Always have a dotted line in your backlog that marks the “end of the line”, all items that are below that line won’t make it in the final package and should go in a follow-up project (if they are still needed)
      • Together with your customer focus on MVP don’t let that fancy additional functionality tempt you

      Focus on long-term partnership with your customer
      • With a deadline ahead it’s easy to drop quality to get the feature done in time. This might help in the short-term but will damage your customer relationship in the long-term if problems arise
      • Don’t overburden your team. If you keep them running on 120-150% to finish that project what happens if you customer is so excited that he immediately wants to start the next project with you? Keep a steady pace in what you do, that helps motivation and quality
      • By being completely transparent and in constant interaction with your customer you’ll gain their trust and this will always pay out in the end
      What are your experiences with fixed price projects?
      Do you have ideas to add to that list?
      What would be a total no-go for you?
      I’m happy to hear your thoughts and learn more on this…
      Cheers,
      MrSnow76 

      Practical improvements for distributed agile teams

      Hi there,

      recently I participated in a Planning meeting of a distributed team where one member of the team was connected over Skype (voice only) from India the rest of the team was collocated in Germany.

      Once it came to the estimation with Planning Poker most of the collocated team put a 2 or 3 up while the single guy in India put a 8 on that story.
      There was one short question about the “why” of 8 points but after waiting 5 seconds in silence one of the team members suggested “lets use the 2” and everyone in the room nodded. The one guy on the other remained silent.
      What was the reason?

      There might be several:

      • he couldn’t follow the conversations about the stories because the hardware used was not the best so he didn’t share the same insight all the others team members shared
      • as an “outsider” he didn’t want to speak up
      • the rest of the team already was used to not paying attention because understanding each other was very difficult

      Distributed teams are quite common nowadays since it’s not so easy anymore to hire professionals in your area.

      You’ll might experience one of the following challenges when working with distributed teams:

      • Lack of team spirit
      • Technical Communication issues
      • Cultural Communication issues
      • Time-Zone differences
      • Integration pain
      • Delays in Delivery of the remote team
      Now the above might seem quite obvious. But the question is what can you do – starting right now – to help the teams with those challenges?

      Lack of Team spirit

      • have the remote team members visit the rest of the team on a regular basis
      • schedule some out of work activities for the time the remote team members are visiting (beer garden, bowling, barbecue together, you name it)
      • take care in the different team meetings that everyone is heard, even if maybe the skype connection today is not the best
      • Use Video Conference instead of telephone / Audio only, seeing a face will help to ease conversations 

      Technical Communication Issues

      • Until everyone is happy with the setup, have one member of the collocated team sit in a separate room and dial in just like the remote attendees to get good feedback
      • Get proper hardware that is able to support the room(s) that you are meeting in
        • built in laptop microphones work for one or two persons sitting directly in front of the device, for a full room you’ll need external microphones
        • Check this Overview about different microphones for a list of external speakers, while rooms that fit more than 4-5 people should take a mic from the “Room Speakerphones” category
        • If you heavily work with distributed teams your company might want to look into a long-term investment to boost collaboration world wide, Tandberg Video Conferencing Systems might help
      • Sit close together around the microphone
      • Have everyone face the microphone and speak loud and clear 

      Cultural Communication Issues

      • Try to find out the differences between your cultures:
        • if possible in a retrospective by talking about it directly
        • in case that doesn’t work find someone you can truest to talk 1:1 openly about the issues and work out steps to improve
      • If you have difficulties exchanging the needs of the different cultures NVC could be of help – Non Violent Communication
      • Cultural Barriers to Effective Communication in depths analysis with suggestions about the problem

      Time Zone differences

      • Plan meetings in the overlapping time that you have with the remote team members
      • If you don’t have overlapping times work out compromises which work for all locations
      • Consider having two standups one early during the day for collocated people and one together with the remote attendees – or the other way around – keep both of them short and preferably use video not just audio

      Integration pain

      • do not just integrate only at the end of the iteration/sprint, have a CI or continuous delivery system that allows you to integrate daily or even several times per day
      • integration only at the end of your sprint leads to problems and bugs found after integration which will hinder you in your next sprint

      Delays in Delivery

      • make sure that your remote team members don’t have colliding agendas, it is so much easier to work on that one local thing to help the well-known colleagues around you instead for that  remote team that you see once a year
      • one project for all team members or a fixed ratio (eg. 3 days project A and 2 days project B) of time if you have to have more than one projects
      • Have everyone speak up in the daily, especially about impediments or blockers to avoid a delay in delivery
      • Don’t check in Friday 17:00 when you have a demo Monday morning, especially not when you need some person in the remote location to help you fixing problems that might come up
      I’d be happy to amend some of your own findings to the list, so please feel free to share them in a comment.
      Cheers,
      MrSnow76

      Lean Change Canvas combined with Impact Mapping

      “Agile Transformation” is something that you might have heard about or even experienced in your own work environment.
      Most often this is a quite lengthy process that takes years. And change agents like Agile Coaches or Agile Consultants at the beginning often have the same problem.
      Find out what needs to be done and visualize it in a way that the management – which is more than often knowing little or nothing about agile – understands it.

      Lean Change Canvas

      The lean change canvas helps you visualising the “pains”. It’s structure leads you quite naturally to a result that even non-agile people can understand.
      It is devided in 9 separate areas. Those can deviate in their nomenclature depending on the context but they share the underlying meaning.
      1. Urgency/Drivers
      2. Change Recipients
      3. Vision
      4. Target State/Foundation
      5. Actions/Tactics
      6. Required Investments
      7. Benefits/Wins
      8. Success Criteria/Measurable Outcomes
      9. Communication
      Steps for change gives you a quite comprehensive explanation of all these points.
      The Picture is an example fromt his blogpost: Lean startup for change is dead.
      If you capture your Agile Transformation with a lean change canvas the targets that you will find might be very high level. So high level that you will not be able to act on it right away.
      This is where the next step can help you.

      Impact Mapping

      With the Lean Change Canvas you have identified high level goals.
      Let’s use a simple example: “Introduce TDD to development”.
      With the impact mapping technique you could now start to clarify what exactly that means for your organisation.
      The basic technique is:
      1. Why
        • This needs to be a SMART goal, so that you can track it. If this is too vague you will hit a wall sooner or later when you try to define the “hows” and “whats”, so better take your time to break the abstract goal down into something achievable.
      2. Who
        • This is the person/group that can help you or block your endeavour. It is a person/group that is impacted by what you want to do 
      3. How
        • Here you list what the individual(s) listed under “who” can do to help you. How they should change to produce the desired outcome. Or for example what they should not do
      4. What
        • This is the things that you as a team that is creating the impact map can do to support the impacts that you want to achieve
      So let’s use the example “introduce TDD to development”.
      First of all we need to have a SMART goal, so elaborate that a bit further.
      āž “Deliver basic TDD training to all development teams until end of next Quarter”.

      This is just a quick example that I created. It is by far not complete but maybe gives you a few ideas to get started on your own.

      The combination

      Combining The lean Change Canvas and Impact Mapping helps you in several ways:

      • Quickly get an overview over the giant task at hand
      • Identify the most important changes that you want to start with
      • Get the big picture about the involved individuals/groups
      • Get a tangible picture on the wall – you can use post-its to create that
      • Rough view for management and High resolution view for all others who are impacted
      Did anyone of you combine these two?
      What are your experiences? I’m curious to see your comments.
      Cheers,
      MrSnow76