Dec 7 – Global Awareness looking through a narrow window? Nah!

December7

Continue reading

Advertisements

The Busy Bee Paradox

Here are my slides from my keynote at Agile Tour Lille

Don’t we all think that we get more done if we stay busy? We feel good and efficient. We may even get a pat on the back or even a promotion.

But is this good for the company? Is it good for our customers? Are we really optimizing for the whole or are we just keeping ourselves busy?

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

Standard work in software development–part 2

In part 1 of Standard work in software development I described what Standard work is and how it is the cornerstone of continuous improvement in Lean. In the post I will describe how a software development team I have been coaching have been using Standard work for a few months.

Context

This is a team that are doing a technology conversion from VB6 to .Net. They are in the process of converting a large number of batch programs with very different properties and implementations. Some are small, some are large, some are quite easy and some are very hard.

The process and visualization

To do the work we have identified some common process states that are used more or less for every batch. We use a Kanban board to visualize how work goes through the process. Below is our board with the process states we currently use.

MainBoard_thumb1

The process states are written on the stickies at the top of the board and are:

  1. Prio
  2. Business analysis
  3. Business analysis done
  4. Technical analysis/design, development and functional testing
  5. Ready for deployment to test
  6. Ready for System test
  7. System test
  8. Done

The Standard work cards

About one third from the bottom of the Kanban board above you can see some white A5 cards hanging from hocks. Below are is a detailed photo of two the A5 cards.

StandardWork_thumb

These cards are our Standard work cards and here is an example translated to English:

From Technical analysis/design, development and functional testing

  • Code checked in to source control
              Should follow defined coding standard and architecture
  • Code review done
  • Database project updated
              Changes documented
  • Test cases should have been executed
              All functional tests are green
              All automated tests are green
              For bugs
                   Run tests in DST together with the tester
  • Update requirements document with dependencies
  • Update Team Foundation Server
             Document all significant changes
             Set State/Reason to Awaiting deployment/Fixed
             Set Label
             Set tester as Assigned to
  • Notify CM and testers that work is now Ready for deployment to test

How we use the cards

When a team member is getting close to finishing the work in a process state they take one of the card for that process state off the board.

They go thru the checklist ticking the items off.

If there is something on the checklist that is not applicable, it will be stricken.

If there is something on the checklist that is not correct, it will be stricken and a correction will be written on the card.

If there is something missing on the checklist, it will be added by writing the new item on the card.

When the checklist cards are completed they will be collected by the team manager.

If changes are made on the cards the team manager has an opportunity to discuss the changes. If the checklist has to be updated the team manager will update the checklist and print the new version and replace the cards on the wall.

We are making changes to the checklists on a continuous basis. The changes are often initiated by turned in checklists, suggestions made by team members, discussions at the daily standup and at retrospectives.

The evolution

We evolved our Standard work cards from the more common Definition of Done used in Kanban and Scrum. Instead of printing the Definition of Done on the board it self we are printing our Standard work on paper and cut them up to the A5 size.

The benefit of doing this is that every team member can get a copy of the Standard work and have it on their desk as they do the work and checking off the items on the checklist. The other benefit is that we can collect all the changes and corrections made to the cards. These changes are triggers for potential process improvements.

Future improvements

Possible future improvements I’m considering for the Standard work cards are:

  • Adding start and stop time for tracking purposes.
  • Adding work item reference number for tracking purposes.
  • Adding the name of the person performing the Standard work
  • Adding Takt time for every process state. This would be the normal time interval that this process state should take. If the time spent in the process state is outside the specified time interval a root cause discussion will be triggered to discover possible process problems or improvements.

Conclusion

You can implement Standard work in something as variable as software development. It is all about how abstract or concrete you get in defining your Standard work. You start out abstract and make it more and more concrete as you learn how your process really works. The most important part is to change the Standard work as you change how you do the work.

Standard work should continuously change!

Standard work is the cornerstone of continuous process improvement, even in software development.

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