Earlier tonight Chris and I presented our talk on Test Driven Development.  I have to say I was rather impressed at the turn out since its only a week away from Christmas and we still managed around 40 people.  As promised here are the slides from the presentation and all of the code/files that were used during the talk. 

Test_Infected_Presentation.ppt (544.50 kb) 

SkillsMatter.TestInfected.rar (6.15 mb) 

Running Fitnesse

1. Uncompress the SkillsMatter.TestInfected.rar file into C:\SkillsMatter\TDDTalk
2. Run C:\SkillsMatter\TDDTalk\TDD\fitnesse\run.bat - This will start the Fitnesse web server on port 8080
3. load http://localhost:8080/MidlandsFoodsFirstCut
4. Press the Suite link and the tests should execute and all fail - This demonstrates the deliverable from a Business Analyst
   
5. Load http://localhost:8080/MidlandsFoods 
6. Press the Suite link and the tests should execute and most will pass

1. Uncompress the SkillsMatter.TestInfected.rar file into C:\SkillsMatter\TDDTalk
2. Run C:\SkillsMatter\TDDTalk\TDD\fitnesse\run.bat - This will start the Fitnesse web server on port 8080
3. Load C:\SkillsMatter\TDDTalk\TDD\JackPlaysSnap\JackPlaysSnap.sln
4. Set the Fitnesse project as the StartUp Project
5. Under project propertie
   1. Set Start external program to C:\SkillsMatter\TDDTalk\TDD\fitnesse\dotnet\TestRunner.exe
   2. Set the Commandline arguements to localhost 8080 MidlandsFoods.GiantWinsJackNeverSnaps
   3. Set the Working directory to C:\SkillsMatter\TDDTalk\TDD\fitnesse\
6. Set a breakpoint in JackPlaysSnapFitness.cs
7. Run the project under debug mode

A common theme within my posts is how Iteration and Feedback is the life blood of an agile project.  A project consists of a repeating series of sprints.  Sprints consist of goals/user stories to be implemented.  Within each sprint there are planning sessions, retrospectives and milestones/tasks.  Tasks in turn can be designed/implemented using a Test Driven Development or Acceptance Driven Development approach which are often described using the Red, Green, Green analogy.

• Red - Create a test to flesh out the public interface/the expected output of the component
• Green - Develop code that implements the public interface and fixes the test
• Green - Refactor the code so that it is simpler or more maintainable

Its clear that there are iterations within iterations within iterations.  In this regard Agile projects are fractal like in nature with the entire SDLC consisting of self similar behaviour across the time axis.  Recently I have found it useful to generalise each of the iterations (no matter what level of abstraction we are dealing with) to the following:

• Envisage
• Innovate
• Stabilise

Envisage (Analysis hat)

verb: This is similar to imagine; it means to form a mental picture of something which may one day exist.

The Envisage phase is primarily concerned with asking the following questions:

• What is the project/sprint/goal/milestone/user story/component trying to achieve?
• How will be different post iteration?
• What is the success criteria for completing the iteration?
• Are there any edge cases that need to be investigated?

Phase is being performed incorrectly when:

• More time is spent discussing the solution's implementation as opposed to problem definition
• Only the Happy Path is analysed
• Tests are written that make assumptions about the implementation

Innovate (Creative hat)

verb: to introduce something new; make changes in anything established. (www.Dictionary.com)

I have purposely chosen the word innovate over implement or build to describe this phase.  Being innovative implies that we can experiment, prototype, flesh out and most importantly make mistakes.  Its concerned with:

• Solving the indentified problem
• Plumbing and Infrastructure

Phase is being performed incorrectly when: 

• More time is spent getting to Green than finding new edge conditions
• More time is spent Refactoring than writing new code
• More time is spent working on plumbing than solving the identfied issue

Once the problem has been solved its time to switch focus to strengthening the quality of the solution.  This entails:

• Writing more tests
• Refactoring
• Ensuring that all edge conditions are accounted for 
• Change/Risk reduction

  Phase is being performed incorrectly when: 

• New tasks are continually being found (implies team is still in Innovate stage)
• Changes are introducing bugs
• Features are being added
  

Conclusion

By generalising all Iterations to Envisage -> Innovate -> Stabilise its becomes very easy to determine what type of activity should be performed.  For example I only allow infrastructure or plumbing changes to occur early in a sprint so that there is ample time for stabilisation.

One of Scrum's great strengths is that it promotes transparency. 

The daily stand-up ensures that team members understand what their peers are working on.  It also helps to quickly identify cards (tasks) that were underestimated or when a particular team member or pair have become stuck and aren't making progress.  Unfortunately while SCRUM is great at managing the project it can be more difficult to present the progress to senior management.

For example which of the following metrics should be used as the public face of the SCRUM.

• Sprint burn chart

• Completed stories

• Card life cycle (planned, in progress completed)

Originally my team was only using a burn down chart for reporting but in the last couple of sprints we have added the concept of Sprint Milestones.  A Milestone is

• Scheduled

• Dependent on a set of cards

• Completed

Once all of the cards in the Milestone have been complete we move the Milestone card from Scheduled to Complete.  When reporting a Milestones progress we list the number of cards completed over the total number of cards (i.e. 2/6).

 The following is an example of the type of information that is placed in the fortnightly progress report that is presented to my projects steering committee.

Sprint: 1

Sprint Goal:  Integration between Eagle and Bloomberg

Sprint duration: (3/11 - 22/11)

Milestones:

Bloomberg market data transformed into Internal schema (3/8) - GREEN

Market data loaded into Eagle (2/5) - GREEN

Bloomberg data exported to down stream systems (0/5) - YELLOW

Sprint complete (5/18) - YELLOW

 Burn down chart:

<image here...>

Issue List:

<table of outstanding issues/external factors that are blocking the team>

In many ways you can think of Milestones being an aggregated view of the user stories and tasks within a sprint.  The most important criteria for determining if an item should be wrapped within an Milestone is whether it needs to be publicly reported on or whether it contains integration points with other teams and so needs to be carefully managed.

Scaffolding definition within the building industry

Scaffolding is a temporary framework used to support people and material in the construction or repair of buildings and other large structures. (Wikipedia, 2008)

Scaffolding definition in software project management

Scaffolding are the semi-rigid processes and tools that surround a project that are used to support people in the construction of complex systems such as software.

Each project management methodology is optimised against a particular pain point. When the software industry was young the hardest part of software development was coding. Assembly coding errors was common so reams of upfront documentation was necessary to ensure that coding errors were minimised. Today the pain points are very different. Internet time has shortened product schedules to months instead of years. Customers are far more savvy and their expectations are far greater.

Without delving deeply into the definition of Agile I think that most people would agree that Agile methodologies are optimised to provide constant project monitoring. Unit tests quickly inform developers that code changes have broken working code. Daily stand ups, sprint retrospectives and project post-mortems all ensure that throughout the project, the team is tracking progress and that the progress is visible to external parties such as the client and management teams.

However project monitoring is only part of the Agile way and often it's more important partner feedback is forgotten. In control theory feedback is defined by a system that monitors its output and uses that information to maintain a desired state. For many years I worked for a company that built Autopilots for fishing boats. The ship's captain would dial in a set of way points into the Autopilot and the device would use GPS and other sensors to steer the boat in the correct direction. If the boat was going left or right of the desired target the Autopilot would move the rudder to minimise the error. To a far away observer the boat would appear to be moving in a straight line. However this was not the case.  The rudder would often be moving violently back and forth countering the effects of the wind and current.

Agile projects are at their best when:

• Process is borderline regimental

  • Daily stand ups (happen even when the team lead is away)

  • Defined sprint durations and outcomes

  • Change tightly managed through the sprint/product backlog

• Waste is minimised

  • Code that is developed gets into production

  • Development time is spent solving business problems and not creating YABF (Yet Another Bloody Framework)

  • Meetings make decisions

• Feedback

  • Bugs, Defects, Misunderstandings are caught fast

  • Are fixed faster

  • No surprises for management and the client

  • Project can turn on a dime – features added/removed at will

Unfortunately, over the last couple of years I have seen Agile projects that have failed over and over again in the wild. The projects were humming along nicely and BANG suddenly out of the blue they were 3 months behind schedule and the reporting module which was the project's main deliverable as far as upper management were concerned had yet to be started. I've witnessed highly skilled consultants from companies that are synonymous with Agile being walked out of client sites after project after project had failed. I used to strongly argue that these teams weren't doing real Agile. Like any zealot I nodded my head and sagely predicted that if only they had done some random XP task better they wouldn't have failed or that it was due to poor staff on the project. So it wasn't really Agile's fault. If only they had done more peer programming...

In hindsight, the common problem between all of the failed projects was pretty simple. The project's had lots of alerting and monitoring systems in place such as unit tests, continuous build servers and stand ups but there was no real feedback loop. The projects were in trouble but at no time was the rudder pointed in a new direction.

So, are you on an Agile project; or is the project very good at writing unit tests?