The Non-Repetitive Work Fallacy

The Non-Repetitive Work Fallacy

It is not uncommon to hear people say that software development is non-repetitive work where the work always unique and rarely repeat.  It is not uncommon to hear people say that software development is a craft, an act of design and even divine inspiration and that we therefore can learn from other industries that is described as repetitive.

I think this is a fallacy, a fallacy I call the Non-Repetitive Work Fallacy.

Continue reading

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

HowToImproveFlowEfficiencyRemoveTheRedBricksQA

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

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

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

Continue reading

Different forces in Scrum and Kanban for the common goal

Scrum and the Kanban method use different forces to achieve this same goal of creating the most possible value over time for the organization by continuously inspecting and adapting the processes and tools.

In Scrum the main forces are the time boxed Sprints and the cross-functional team. In the Kanban method the main forces are visualizing work and limit the work-in-process (WIP).

Scrum

In Scrum the main forces for improvements are achieved by the time boxed Sprints and the cross-functional team.

It is in the time boxed Sprint the team are supposed to build a potential releasable increment of your product. By setting a fixed time box in which a product increment shall completed including all steps like analysis, design, development and testing will force the increments to be small enough to fit the time box. This will most often reduce risk by the smaller steps with validation of the increment at the end of the time box in the Sprint Review.

The members of the cross-functional Scrum team are the only ones that should work on the product increment. This will force the organization to have all the necessary competence in the team so it can deliver the intended product increment.

The Kanban method

In the Kanban method the main forces for improvements are achieved by visualizing work and limit the work-in-process.

Visualizing and making the work visible is used to make people in the process aware of how work is done and the amount of work that is in the process. Humans are very good at processing visual information and making meaning of it as a very large part of the human brain is dedicated to it. The saying that a picture says more than thousand words is a very good description how the brain works. By visualizing and making the work visible the Kanban method the created understanding and understanding can force the organization to make improvements of how work is done.

The goal of limiting work-in-process is to create an even and continuous flow of work. This is done by reducing the work-in-process in small steps over time. This will force process problems to the surface and together with the visualization it will be visible. Limiting the amount of work in the process will often reduce risk as less work is done in parallel and the focus on getting work done before new work is started.

Different forces for different contexts

Scrum and the Kanban method use different forces to achieve this same goal. Depending on the context the forces will have different catalytic effects on your organization. Based on your current context choose one or the other or combine them to achieve the goal of your organization.

Scattershot Improvement Lists or Behaviors for Continuous Improvement

It is the end of the sprint and time has come for the retrospective. Scrum Master Jane starts by explaining the objective of the meeting.

The retrospective meeting is our time as a team to reflect back on how the sprint went. We will map out what went well and what can be improved. We as a team will then vote on what improvements we will work on during the next sprint

Jane then starts the meeting by setting the stage with a simple exercise.

Jane then moves on to a formalized discovery exercise where the team members writes post-it notes with things that went well and what can be improved. After 10 minutes of everyone writing notes Jane starts going through the post-its and the author describe what they mean. Jane then starts grouping the post-its into groups of similar things. The team adds some more post-it notes as they get more ideas based on the wall.

Jane now asks the team to dot vote for the improvement they want to commit to in the next sprint. People vote and there are two improvements that get 80% of the votes.

Jane asks the team if they are willing to commit to these two improvements for the next sprint. The team says yes.

Jane now close the retrospective by asking everyone to give appreciation to each other for a work well done.


This may be something you recognize from a scrum team you have been part of. This is at least a typical retrospective from most team I have worked in. Is this really cultivating a culture of continuous improvements?

No.

The common improvement list of most retrospectives is a ineffective and scattershot approach to process improvements.

Setting a target condition and purposely using PDCA(Plan-Do-Check-Act) cycles to get to that target condition in small focused steps every day is a much better approach.

In the book “Toyota Kata” Mike Rother writes the following about Action-Item Lists like the list the team produced in the above retrospective.

1. It doesn’t work very well. The underlying thinking with the list approach appears to be that the more action items we have, the more the process will be improved. … the list approach is an unscientific and ineffective method for process improvement. It is actually a scattershot approach: multiple action items are initiated in the hope of hitting something.

2. We are in the dark. Defining and introducing several action items simultaneously, and sometimes even voting to prioritize them, indicates that we don’t know what we need to do to improve. It would be better to simply stop and say we don’t yet know what exactly to do. “I don’t know” is a completely acceptable answer and much preferable to pretending we do know, but this seems to be one of the hardest things to say.

3. We are asking our self the wrong question. When we hunt for wasted opportunities to improve and make list of action items, we are focusing on the question, “What can we do to improve?” The question is actually too easy, and it automatically leads us to lists and a scattershot approach. The more focused question is, “What do we need to do to improve this process?” Admittedly, this is a more difficult question …

4. We are jumping to countermeasures too soon. A weakness in the list approach is a tendency to jump to countermeasures before we understand a situation. … People are rewarding people for fixing a problem, for firefighting, not for analyzing, even though the problem may recur later because it was not yet sufficiently understood.

5. We are not developing our people’s capabilities. The list approach does not harness or grow our problem solving and improvement capability in a very effective manner.

What he suggests in stead is to purposely go through a behavior pattern he calls an “improvement kata”.

In short an “improvement kata” is a behavior pattern where you move from your current condition through a number of intermediate goals towards a future vision using focused PDCA cycles.

With continuous improvement it is most important to know where you want to go. To have your “True North”. Without something to move towards how else do you know if you improve?

It is also very important to truly understand where you currently stand.

Now you can form a direction by setting the next intermediate goal – target condition – towards the vision.

You then ask your self what obstacles prevents you from reaching that target condition today. You choose one and only one of the obstacles. Now start go through PDCA cycles until you have eliminated that one and only one obstacle.

Then you go and see what you have learned.

Is your new current condition the same as your target condition? If not, choose the next obstacle and try to eliminate that one. If you are close to, or at the target condition, then it is time to set a new target condition on the direction towards the vision.

How could Jane do the “improvement kata” in her team? Let’s look at an example.


It is Tuesday morning at 09:00 and Jane the team leader opens todays Daily Standup Meeting.

Good morning everyone. Great job yesterday everyone! Lets go through the board and see how we stand today.

Jane goes through the kanban board starting at the end of the value stream. She focus on blocked work and work that are, or that potentially will not meet the target delivery dates. Jane then asks the team if the board shows all the work that they are working on. Everyone nods.

Jane now moves on too the second part of to the daily meeting.

What is your target condition here?

Mike, one of the business analysts, speaks up

At the Operations Review last week we agreed to set a target condition of a continuous flow of 4 stories ready for production every week.

Jane then asks:

What is the actual condition now? How does your throughput data look like?

Mike shows Jane the throughput measurement diagram posted on the board. The diagram shows that the throughput has been steadily been climbing for the last few months but are now starting to flat line just below 3.5 stories per week.

What obstacles are now preventing you from reaching the target condition of 4 stories every week?

Jane asks the team. Bob a tester in the team answers:

We think it is the how we deploy and how we set up our test environment.

Jane wants Bob to explain why he think that this is the case. It is not that Jane doesn’t trust Bob and the rest of the teams analysis but she wants them or explain how they formulated that hypothesis.

Bob and Mike points to the board and the “Ready for Test” queue. It contains six work items, two over the work in progress limit set by the team. They also show the Cumulative Flow Diagram that shows that the “Ready for Test” queue has slowly been growing over time. Bob also says that he and the other tester has to wait for hours when they want to start testing the next story. Bob explains that they have done a root cause analysis and have found two major root causes that they think would move them closer to the target condition. The root causes are:

  1. The deployment to the test environment is done manually
  2. The time to set up the reference database takes way too long

Which one are you addressing now?

Jane asks. Bob answers

We are looking at starting on both this week

Jane responds

Lets us take it one step at the time and see if the change we will make has the result we are expecting. If we do more than one thing at the time we can’t be sure of the cause and effect relationships. What root cause would you start with? The manual deployment?

The team agrees that that can be a good start. Jane now asks the team to start a new PDCA cycle testing the hypothesis. And ends the meeting by asking:

When can we go and see what we have learned from taking that step?

Give us a week and we will see where we stand

Bob answers. Jane is satisfied for today and ends the meeting.


Jane would one week later, or earlier, go through the five “improvement kata” questions again with the team:

  1. What is your target condition here?
  2. What is the actual condition now?
  3. What obstacles are now preventing you from reaching the target condition?
    Which one are you addressing now?
  4. What is your next step?
    (start of the next PDCA cycle)
  5. When can we go and see what we have learned from taking that step?
      When the target condition is reached, then a new target condition will be set that moves a small step towards the vision and

“True North”

    .

Repeating this behavior pattern over and over and you can create an environment of continuous improvements. I will practice the “improvement kata” and learn for my self how this is done in practice. It will probably be a struggle but to quote Aristotle:

Excellence is an art won by training and habituation. We do not act rightly because we have virtue or excellence, but we rather have those because we have acted rightly. We are what we repeatedly do. Excellence, then, is not an act but a habit.

Will you join me in this learning journey? Read more about Toyota Kata here on my blog

Visual WIP–work is progressing

Work on Visual WIP is progressing. Lots of refactoring has been done for the last few weeks. I’m trying to move as much as possible of the visuals to xaml files that will be loaded in run time making it possible for you to customize the visuals to suit your needs. Below is a screenshot based on the current pre-release that you can find here

MainWindow1

In the Analysis column you can see the new hierarchical work item support. In the example above user story work item [15 – New UI design] has one issue work item as a child [19 – Problems] that in turn has issue work item [20 – More trouble] as a child.

The Analysis column has also exceeded its work-in-progress limit and the column background has been changed to strengthen the visual signals.

In the Testing column you see the medium size work item design.

In the Production Ready column you see the small size work item design.

What’s next

In the coming week I will continue working on the save and load settings support.

If you are interested in contributing to the project please let me know. I’m especially looking for help with UX work and help with building an SharePoint provider.

Update: See progress by following the Visual WIP tag or go to the project at VisualWIP.codeplex.com

Byggstatus med Lavalampor

Vi håller på att migrera från Visual Studio 2005, Visual Source Safe och CruiseControl.NET till Visual Studio 2008, Team Foundation Server och Team Build. Som en del i detta så ville vi få igång en tydlig visualisering av hur våra byggen går. Vi valde att använda de traditionella lavalamporna! Såhär fick vi det att fungera.

lavalamporna

Vi hade sedan tidigare ett CK13 Activehome Kit för att styra 220V från datorn.

Lampmodule och appliance module CM11a

För att styra de två X10 modulerna från kod så använde vi oss av Brian Vallelungas Home Automation (X10) Library

Vi utgick sedan från Martin Woodward TFS Build Wallboard API Example 

Vi uppdaterade koden i WallboardForm.cs för att tända och släcka lavalamporna till:

public voidUpdateStatus(IBuildDetaildetail) { // We used the build server later to convert the enums into the localized display values.
  
IBuildServerbuildServer = detail.BuildServer;

    lblBuildNumber.Text = detail.BuildNumber;

    //  The TFS API’s always return DOMAINusername, however the convention is that we only
    //  display the domain portion if it is different from our current users domain.
  
lblRequestedFor.Text = UserNameFormatter.GetFriendlyName(detail.RequestedFor, null);

    // If the build has finished then display the finish time.
  
lblFinishTime.Text = detail.FinishTime.Equals(DateTime.MinValue) ?
      “”: detail.FinishTime.ToString();

    // Convert the build status into a localized display text.
  
StringstatusText = buildServer.GetDisplayText(detail.Status);

    using(CM11AlavaLamps = CM11A.Instance(“COM1”))
    {
        // Now we want to show the fancy images.
      
switch(detail.Status)
        {
            caseBuildStatus.Failed:
                statusPictureBox.Image = global::BuildWallboard.StatusImages.status_bad;
                lavaLamps.SendCommand(X10HouseCode.B, 2, X10Command.TurnOn);
                lavaLamps.SendCommand(X10HouseCode.C, 2, X10Command.TurnOff);
                break;
            caseBuildStatus.InProgress:
                lavaLamps.SendCommand(X10HouseCode.B, 2, X10Command.TurnOn);
                lavaLamps.SendCommand(X10HouseCode.C, 2, X10Command.TurnOn);
                break;
            caseBuildStatus.NotStarted:
                statusPictureBox.Image = global::BuildWallboard.StatusImages.status_queue;
                statusText = buildServer.GetDisplayText(BuildStatus.InProgress);
                break;
            caseBuildStatus.PartiallySucceeded:
                statusPictureBox.Image = global::BuildWallboard.StatusImages.status_partial;
                break;
            caseBuildStatus.Stopped:
                statusPictureBox.Image = global::BuildWallboard.StatusImages.status_stop;
                break;
            caseBuildStatus.Succeeded:
                statusPictureBox.Image = global::BuildWallboard.StatusImages.status_good;
                lavaLamps.SendCommand(X10HouseCode.B, 2, X10Command.TurnOff);
                lavaLamps.SendCommand(X10HouseCode.C, 2, X10Command.TurnOn);
                break;
            default:
                break;
        }
    }
    // And finally set the text.
  
lblStatus.Text = statusText;

}

För att sedan få allt att fungara så var vi tvunga att trixa lite med X10 delarna (jag tror att Brian Vallelungas bibliotek inte är 100% kompatibelt med den Europeiska varianten av CM11 modulen).

Till att börja med så kunde man inte ha båda X10 modulerna på samma huskod. Jag valde att köra gröna lampan på huskod C och den röda på huskod B.

Sen var man tvungen att tända och släcka båda modulerna med en X10 kontroller (som jag lånade från min X10 anläggning hemma).

När detta var gjort så var det bara att köra igång! Alla i rummet ser nu snabbt och enkelt byggstatus liksom alla som går förbi i hallen!

Byggstatus Grön Röd
Bygger X X
Success X  
Fail   X