Danube - Flattening the Cost of Change Curve: Theory vs. Practice - Comments

great observation

MichaelJames — Mon, 31 Mar 2008 19:03:27 -0500

Dan, I wish more people, including some "ScrumMasters" understood this the way you do.

--mj

softening the database schema

MichaelJames — Mon, 31 Mar 2008 19:01:28 -0500

A friend of mine in Seattle also wrote to me about this. There's things we can do to mitigate this -- it's not an unsolvable problem or even a particularly hard one. But no matter what, it's going to have a greater cost than a simple code refactoring that doesn't touch the persistence layer, and there may be times we wish we'd chosen "correctly" in the first place.

With databases, the cost of change is a little higher still if we've deployed or released a previous version with active data we've promised to preserve. We probably need to write some kind of migration (either explicit in one step, or implicit) which may itself have bugs or be misused by customers (ahem...).

Probably any promise we've made in the past increases the cost of change. In the case of user interface, people may get attached to our old UI. One way or another this will increase the cost of switching to a better UI. With an API, we may be obliged to support the deprecated one years after we come up with a better one; this constrains our options.

Database persistence can be seen as a special case of API that involves our past selves talking to our future selves.

Thanks for the kind words, Niels. Amsterdam was a great course with a positive group of participants.

--mj

Sometimes just a change in perspective is needed

dlefebvre — Mon, 31 Mar 2008 09:01:45 -0500

In your post you state:

The word ScrumMaster itself is another example. Many of us wish we'd chosen a term like Scrum coach or Scrum facilitator to more clearly convey the ScrumMaster isn't the team's boss. But changing the term now would only increase confusion.)

What I do with my teams is spend a few minutes relaying a post I once read from Bryan Stallings:

When I work with those new to Scrum I explain this subject as follows...

I ask them to tell me what a Master-of-Ceremonies does. They tell me about events such as the Oscars and explain that an individual with this role is responsible to ensure that the event progresses as planned, that they facilitate the transition from one phase of the event to another, and that they step in should anything unplanned occur.

I then ask that they describe to me the responsibilities of a Quartermaster in the military. They explain that a Quartermaster provides the troops with all that is required for their success and comfort, and sets-up suitable circumstances.

I of course agree with them and then I proceed to explain that like a Master-of-Ceremonies, a ScrumMaster is responsible to ensure that the Scrum process progresses effectively from event to event, that a ScrumMaster also steps in should an obstacle to success be encountered. Additionally, I explain that like a Quartermaster, a ScrumMaster shoulders the responsibility to provide the team with all that is necessary to ensure their success, comfort, and suitable circumstances.

So this change in perspective helps clear up the confusion and gives them a better understanding of the ScrumMasters responsibilities.

Regards,

Dan

things hard to change

Niels — Sun, 30 Mar 2008 15:44:56 -0500

I'm curious about the "hardness" of changing database schemas. Would the use of "public synonyms" help?

Another thing hard to change would be negative perceptions (eg about software development projects), positive perceptions however may be changed quite easily :-)

Anyway I like the philosophical viewpoint of this posting and I enjoyed the course you gave in Amsterdam last week.

Niels

Some common sense from XP

MichaelJames — Tue, 26 Feb 2008 08:27:23 -0600

Some common sense from XP luminary Kent Beck about cost of change.

--mj

Flattening the Cost of Change Curve: Theory vs. Practice

MichaelJames — Wed, 20 Feb 2008 00:16:11 -0600

Modern languages combined with the engineering practices derived from eXtreme Programming (Test Driven Development, constant refactoring, continuous integration...) make it possible to flatten out the pessimistic exponential "cost of change curve" we learned in the early days.

The ability to *do* this involves learning skills and habits your team may not have yet.