Home > technical > One Step Forward, N-1 Steps Back

One Step Forward, N-1 Steps Back

For the purpose of entertainment, let’s assume that the following 3-component system has been deployed and is humming along providing value to its users:

Three Comps

Next, assume that a 4-sprint enhancement project that brought our enhanced system into being has been completed. During the multi-sprint effort, several features were added to the system:

Sprint Features

OK, now that the system has been enhanced, let’s say that we’re kicking back and doing our project post-mortem. Let’s look at two opposite cases: the Ideal Case (IC) and the Worst Case (WC).

First, the IC:

No Rework

During the IC:

  • we “embraced”  change during each work-sprint,
  • we made mistakes, acknowledged and fixed them in real-time (the intra-sprint feedback loops),
  • the work of Sprint X fed seamlessly into Sprint X+1.

Next, let’s look at what happened during the WC:

Rework

Like the IC, during each WC work-sprint:

  • we “embraced”  change during each work-sprint,
  • we made mistakes, acknowledged and fixed them in real-time (the intra and inter-sprint feedback loops),
  • the work of Sprint X fed seamlessly into Sprint X+1.

Comparing the IC and WC figures, we see that the latter was characterized by many inter-sprint feedback loops. For each step forward there were N-1 steps backward. Thus, TWC >> TIC and $WC >> $IC.

WTF? Why were there so many inter-sprint feedback loops? Was it because the feature set was ill-defined? Was it because the in-place architecture of the legacy system was too brittle? Was it because of scope creep? Was it because of team-incompetence and/or inexperience? Was it because of management pressure to keep increasing “velocity” – causing the team to cut corners and find out later that they needed to go back often and round those corners off?

So, WTF is the point of this discontinuous, rambling post? I dunno. As always, I like to make up shit as I go.

Einstein Make Shit Up

After-the-fact, I guess the point can be that the same successes or dysfunctions can happen during the execution of an agile project or during the execution of a project executed as a series of “mini-waterfalls“:

  • ill-defined requirements/features/user-stories/function-points/use-cases (whatever you want to call them)
  • working with a brittle, legacy,  BBOM
  • team incompetence/inexperience
  • scope creep
  • schedule pressure

Ultimately, the forces of dysfunction and success are universal. They’re independent of methodology.

The Diff

  1. June 16, 2013 at 2:39 am

    I really liked the Einstein picture 🙂

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: