In Theory and In Practice

We recently completed a small but interesting project at work. The team consisted of Tim Weeks, Lee Walton and I played a supporting role. We shared the lessons learned in an experience report at the Agile Practitioners group. The talk was filmed and can be seen below.

On this project, the developers tried a number of Agile and XP practices. BDD and Pair Programming were tried for the first time, in the video they explain what this was like.

In addition to the Agile aspects, the talk shows what Lean (kanban) principles we followed e.g. making decisions at the last responsible moment.

There is a large section on using code reviews and code metrics to help improve code quality.

I got off to a shaky start, but things seemed to improve as the video goes on.

Part 1:

  • Overview of the project
  • Developers discuss how they felt on the project
  • Discussion on pair programming for the first time
  • The importance of putting people first
  • NUMMI case study (GM and Toyota)
  • Start of project – beginning with the end in mind
  • Re-writing stories, to remove implementation details
  • Simplicity – the art of not doing work
  • Cost of defects
  • Concurrent development
  • Making decisions at the last responsible moment

Part 2:

  • Burn down charts
  • Cumulative flow diagram
  • Walking skeleton or tracer bullet
  • Lean thinking – limiting work in process
  • Pull System
  • Dealing with blocked stories
  • Code Reviews (brief discussion)
  • Relationship with PO – developers having access to users
  • Task switching – cost of task switching on projects

Continue reading

Advertisements

The Buffering Law observed in Software Engineering

Railway buffer at the top of Pikes Peak, Colorado Springs CO

There is an informative slide deck on the FactoryPhysics website entitled A Fast Cycle Time Story. This slide deck was created by two Intel Products employees namely Tim Skowronski and Joan Tafoya.

The slides cover many aspects of lean manufacturing, one of the topics covered is The Buffering Law

Systems with variability must be buffered by some combination of:

  • Inventory
  • Capacity
  • Time

Tafoya and Skowronski explain the implication of this law

If you cannot pay to reduce variability, you will pay in terms of high WIP, under-utilized capacity, or reduced customer service i.e. lost sales, long lead times, and/or late deliveries.

The following variability buffering examples are provided:

  • Ballpoint Pens:
  • can’t buffer with time (who will backorder a cheap pen?)
  • can’t buffer with capacity (too expensive, and slow)
  • must buffer with inventory
  • Ambulance Service:
    • can’t buffer with inventory (an inventory of trips to hospitals?)
    • can’t buffer with time (response time is the key measure)
    • must buffer with capacity
  • Organ Transplants:
    • can’t buffer with WIP (perishable – very short usable life)
    • can’t buffer with capacity (we cannot ethically increase capacity)
    • must buffer with time

    Continue reading

    The X Penny Game

    The X Penny Game is a simulation game exploring the effects of WIP limits. It is a combination of Karen Greaves modified Scrum Penny game with Karl Scotland’s version of the Ball Flow Game.

    This game is geared to show the importance of limiting the work in progress and to explore the following formula (implied by Little’s Law)

    Flow Time = WIP/Throughput

    • Flow Time (Cycle Time, Lead Time) – average amount of time it takes to fully complete a unit of work
    • WIP (Work In Process) – is the average amount of units in the system
    • Throughput – average number of units being completed within a given time frame

    The game is designed to work with 6 to 12 people – we had 8 players and 1 facilitator

    The team divides into the following roles:

    • 1 – Customer
    • 5 – Workers
    • The rest are efficiency experts

    We had a total of 8 players (6 workers, 2 efficiency experts).

    The team organises themselves around a table. The image below shows how our team arranged themselves. Each worker has an empty area on the table directly in from of them referred to as a workspace.

    Continue reading

    Agile Practitioners

    It is important to mingle with other members from our industry. This keeps us up to date and stops us getting too caught up in a closed off world. If you would like to have face to face discussions with other professionals you may wish to join us at one of the  Agile Practitioners events. This London based group will be meeting at least once a month. We will be discussing a variety of topics. While we don’t plan to replace any of the existing Agile groups, we do intend to be intriguingly different.

    Avatars and not acting like a manager

    Recently we started using avatars on our Kanban board. We are certainly not the first to do this, however I was surprised by how excited and rejuvenated the team became. If you have never tried this I recommend you suggest it to your team and see if they go for it.

    Not only is it fun, but it is also practical. With one look at our board we can see exactly who is working on what and who they are working with. Each person has one avatar on the board, therefore they can only work on one task at a time. Occasionally someone will start work without updating the board, but this is very seldom.

    We went for the classic South Park characters, each team member got to draw themselves, here is the result:

    You may have noticed that my character (Daryn) is a bit stressed out. This is a reminder to myself, that as the ScrumMaster I should not get overly concerned about everything. I need to trust in the team and leave them alone to get the job done. I need to remember that a ScrumMaster is a facilitator and not a manager. For me, not acting like a manager is the most difficult part about being a ScrumMaster.