3 Legs to Running an Agile Transition

A while back, I wrote 3 Legs to Standing Up an Agile Project from the perspective of an Agile team just getting started. Lately, I’ve been thinking about the same sort of thing, but from the perspective of a coach or an executive that wants to transform the organization. At first glance, this seems no different. Further reflection, however, reveals that this is less about “how to work in an Agile fashion” and more about “how to introduce change in the way people work.” The earlier post was a description what an Agile project needs. This one is a recipe for creating what an Agile project needs. Read More

Building sand castles on a rising tide

Grabbing a handful of wet, saturated sand, I let it dribble through my finger tips.  I watch each drop pile on top of the previous, draining away the water and leaving a new building block of solid sand.  Too much water and the previous drip will be washed away.  Too little and the sand cracks and refuses to hold together.  I watch the sand grow, getting into a rhythm that ensures just the right amount of water, without thought.

My thoughts are not on the mechanics of building a drip castle with sand.  Instead, I’m thinking of the spire that I’m building.  Can I build these two spires toward each other and form an arch?  Can I make this slender spire taller?

Frequently I fail and a part of the castle slides down, becoming part of the landscape again.  Or becoming a foundation for a new part of the castle.  No matter.  It’s the building of the castle that brings me joy–not the owning of it.  For I will never own it.  The sea soon comes and takes it away.

Last weekend, I drove six hours down to Floyd, Virginia for a Code Retreat organized by Gustin Prudner and led by Corey Haines.  There, I joined thirty-some people working in pairs and threes on Conway’s Game of Life for forty-five minutes at a time.  Then, Corey would call time, and we would wash away all traces of what we’d built.

Does that sound like a waste of time?

Read More

Projecting into the Future

In my recent posting on estimation precision, I briefly mentioned how you can estimate when certain features will be done, or estimate what features will be done by a given date, using a burn-up chart.  Some people don’t find this an obvious and easy thing to do.  Let me explain in more detail.

I’ll start with the assumption that you have a list of features you want to add to an application.  Some of the things you want to add may not be properly called features–they might be bug fixes, for example.  And the application might be brand-new, with zero functionality so far.  That’s OK, we can handle cases like that.  Let’s walk through how I do this… Read More

The Importance of Precise Estimates

We’ve got a rather old bathroom scale.Borg-Ericson scale, circa 1950 I’ve found advertisements for this model ranging from 1949 to 1954.  My wife inherited it from her mother.  When we first got it, we set the “zero” weight to three pounds to give the “correct” weight.  Now it’s set closer to five pounds when nothing is on it.

The readings it gives are a little inconsistent.  When you bounce lightly up and down, you may get a different reading.  (I tend to take the smallest number I can get.) Read More

20 Comments

Categories: Tools and Techniques

Tags:

Some of the smartest people I know…

Some of the smartest people I know are ranting that certification doesn’t prove the person is worthy.  Well, of course it doesn’t.  No certification does that.

It only says you’ve met the requirements for the certificate.

Of course, they really know that.  So I don’t know why they’re making such a fuss.

A number of them have made public statements that they discriminate against people who hold certifications.  That really saddens me. Read More

Of course it’s a misnomer

On Twitter, my good friend Mike Sutton said, “CSD is a misnomer. The value of existing Certifications needs to be justified before new ones are released.”

Many of the terms we use are misnomers.  For example, “acceptance testing” is a misnomer because it doesn’t indicate acceptance if the tests pasts–it indicates lack of acceptance if the tests fail.

What is the misnomer in the phrase “certified scrum developer?”  Read More

Distributed Development

A recent post on the scrumdevelopment yahoogroup got me thinking about the age-old problems of distributed software development.  The author of the post described having a Product Owner in California, developers in CA, TX, NC, & India, and QA in India.  (No mention if all of the workers in India were in the same place.)  I’m not picking on this individual.  I’ve heard similar stories many times.

It reminded me of something I’d read in Martin Fowler’s book, Patterns of Enterprise Architecture.  On page 88, figure 7.1 shows a common but distressing architectural design of distributed objects.  In the diagram, the components for Invoice, Customer, Order, and Delivery are each deployed to separate machines.  Why do it this way? Read More

Testing in depth

In the late 1970s, in the Co-Evolution Quarterly, the magazine successor to The Whole Earth Catalog, Peter Warshall stated that geodesic dome houses always leak.  This was a bold and surprising statement at the time, coming from a man who was considered one of the finest builders of dome houses–ones that didn’t leak.

Why did he make this statement? Read More

3 Comments

Categories: Working Software

Tags:

More on Automated Acceptance Testing

Jim Shore has posted a response to the reactions about his previous post on Acceptance Testing in which he defends the way he and the teams he coaches are working.  About the same time, Lisa Crispin posted her thoughts on the topic.

As Lisa says,

I can’t tell you the one right way to test and develop software”¦.  The one right way for your team to code and test will continually evolve over the years. In fact, I’m sorry to tell you that you’ll never find the one right way; it’s a moving target, but you’ll get closer and closer to it.

This is an incredibly important point!  There may be many “wrong” ways—wrong in that they fail to achieve your objectives—but there is no “right way.”  So I’m happy that Jim and his teams are able to achieve the results they want.  I’m not saying they’re doing it wrong. Read More