Wednesday, September 29

Endless Iterations

S ome time ago I sat in on two iteration meetings for an adjacent team. There was a possibility that I would join the team on a part time basis, a possibility that never eventuated.

The project they were working on was fairly far along. They claimed they were using extreme programming, they claimed that they were agile, they claimed that they were using two week iterations. However
  • The team were not asked to commit to completing the tasks scheduled the iteration planning meeting.
  • The instead of scheduling based on the historical progress of the team in previous iterations the capacity of the iteration is simply assumed to be 80 hours times the number of developers.
  • Deflects arising from tasks failing acceptance tests were saved for the end of the release, leading to a final test and fix phase.
  • Instead of using rolling wave planning and progressive elaboration all stories were assigned to an iteration during the release planning phase.
  • There was no ceremony or activity to close the iteration (no demonstration of completed functionality, no interim retrospective), the uncompleted tasks were just moved to the next iteration and the new iteration planning meeting commenced.
There was no learning in this process. Any mistakes made during one iteration were repeated during the next. Any lessons learned forgotten in the mad dash to grind out tasks.

The point of time boxing is to
  •  provide risk management 
  •  limit the amount of time consumed by a task.
  •  habituate the team to meet deadlines.
  •  prevent endless chasing of sunk costs.
None of these objectives were being met. 
They were continually starting but never finishing

Monday, September 27

Sticky Code

I
was working with though some legacy code when I discovered that the original coder had
  • avoided magic numbers by using Macros which was good
  • defined the Macros in multiple places which was bad
The Root Cause

I started asking myself "why" questions in order to discover the reasons behind this failure.

Question: Why has this duplication occurred?
Answer: The original location of the definition was poorly chosen and subsequent coders where reluctant to move the definition.

Question: Why were coders reluctant to move the definition?
Answer: Because to move code you need to delete it from its original location.

Question: Why are coders reluctant to delete code?
Answer: Either :-
  • they do not have source control
  • their source control software does not clean up after itself (files deleted in the repository are not delete in the workspace)
  • or they do not have decent code coverage.
The importance of moving definitions and implementation between different modules and libraries.
If code sticks to its original location and is not moved then over time you will find that you will get duplications or circular dependencies. Usually both.