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:
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?