Project advice from a solo circumnavigator

Tonight, we attended a lecture by Rich Wilson about the 2008-2009 Vendee Globe, a race around the globe by solo sailors in 60 foot overgrown sailing dinghies.  While many sailboat racing talks get rather monotonous, this one was fascinating.  Instead of talking just about boats and gear, Rich spoke mostly of the experience and the people involved.

He offered some advice that I think fits well with software projects:

In a race of four months, going 22 knots for a day doesn’t mean much. It’s just an opportunity to break things. It’s more important to raise the average speed from 10 knots to 11 knots.

This says something about sustainable pace, but it also says something about our tendency to measure ourselves by our peak performance according to some measure.  Let’s face it–we’re only at those peaks for brief moments.

In the normal world of human endeavors, rather than artificial contests, the measure of “best” is never a measure of a single attribute. I would say that the measurement scales for our performance are so numerous and varied that we are never “best” by all of them at once. Perhaps we are not at our peak even for brief moments.

Yet we can always strive. And even when we don’t achieve that which we desire, or that which we think we’re capable of achieving, we may still be doing our “best” under the circumstances. In fact, how could we not?

Accounting for Spikes

The term Spike Solution is associated in my mind with the early days of Extreme Programming.  I’m sure that it is built from prior ideas, as everything seems to be. If the term and the concept it describes predates the Chrysler C3 project (Ron Jeffries mentions using it there), I’ve not yet uncovered it. Ron credits Ward Cunningham for the term.  I’m sure there are predecessors, even if not expressed as distinctly.

The goal of a spike solution is to answer a question. For example, a spike may be used to test the feasibility of an algorithm or 3rd party library. It may be used to explore design alternatives for solving a sticky problem.  It’s called a spike because it drives all the way through the problem, but as narrowly focused as possible. It’s not a complete implementation. Associated complexity that is secondary to the question is likely stubbed out to reduce the clutter and increase the focus. Read More

If Scrum certification is the answer, what might be the problem?

Ron Jeffries has written a nice article on some of the effects, both positive and negative, of the Certified Scrum Master (CSM) program. On the positive side, he notes that it does interest people in training. I’m less optimistic that the training they receive will result in many improved projects. The CSM training teaches people how to follow the Scrum process, and tries to give them a little boost in courage for dealing with the inevitable impediments. Is that the difference between a troubled project and an improved one? Read More

No Comments

Categories: Responding to Change

Tags:

So you want to make your organization Agile

When I first discovered Extreme Programming a decade ago, I was a software developer wanting to produce the best, and best fitting, software that I could. In those days, it seems that most Agile adoptions were from the bottom up.

Now I find a lot of Agile adoptions are from the top (or, at least, middle) down. Managers have heard about the improved results that companies are achieving using Agile development, and they want some of that for their organizations. That’s not surprising, and it should result in both better results for the organization and better work life for the employees.

Unfortunately, it doesn’t always work out that way. What is it that goes wrong with these top-down Agile transitions? More importantly, how can a well-meaning manager conduct a successful Agile transition? Read More

It’s a mystery; I just know.

The first words I learned to read were “off” and “on.” I noticed them on the light switch. By the sounds of the names of the letters, and the effects of moving the switch up and down, I made the connection to the words.

After that start, I was on my way to becoming an avid reader.  It’s not that I read great literature or learned essays. I read pretty much anything that was in front of me. Read More

5 Comments

Categories: Tools and Techniques

The Use of Documentation

Documentation! It’s what we do.

People approaching Agile software development for the first time often ask about what documents are required.  When I ask developers what annoys them most about other peoples’ code, I frequently get the answer that it’s not documented well.  And I can’t tell you how many times I’ve heard people express the opinion that Agile software development is undisciplined because you “don’t do any documentation.”

Why is documentation so important to us? Read More

Je suis fatigué.

I’ve been on the go quite a bit the last couple months, and my posting here (or lack thereof) bears witness to that.  I’ve had lots of thoughts too share, but little time and energy to put them into words.

These hurried times included a trip to France, and one of the highlights was visiting the Paris Coding Dojo, the origin of the term.  What an enjoyable evening!  No trip to Paris would be complete without it.  (Well, maybe that’s not true for everyone.)

The short version of the story is that the coding dojo takes a little bit of time to thoughtfully examine our craft and the way we practice it.  The comments made during the dojo were a reflection of the importance that small nuances have in the pursuit of effective programming.  I advise everyone in the software development community to find ways to hone their craft outside of the daily grind of delivering work.

And many thanks to the participants of the Paris Coding Dojo for conducting the meeting principally in English for my benefit.

Normally, I’d relish a mention on InfoQ

This article on InfoQ bothers me.  It seems to draw only from Dave Nicolette’s blog post [now lost due to the defacement of his old blog] and the subsequent comments.  Dave’s post is similar, in my mind, to a trip report that someone might give to an organization after a class or conference.  He goes into some detail about what happened at the first ever Certified Scrum Developer course, and muses about what he learned.  The bulk of the comments are an interchange between Dave and Tobias Mayer where, it appears to me, Tobias doesn’t think that the course comes up to the standard of the CSM course.  This is, of course, based on Dave’s description, as Tobias wasn’t present at the course.

The InfoQ article mentions me by name, but doesn’t mention other participants other than Dave.  It also misquotes Dave [now edited without any indication of doing so], and implies that the learnings that Dave got out of our retrospective conversation after the course was a list agreed upon by both of us.  There was apparently no fact checking done on this article.  Certainly no one spoke with Ron Jeffries or with me about it.  I find the article misleading enough that I need to respond.

I had planned to write about the course, but this isn’t the article I’d planned. Read More

The Importance of Detailed Planning

I recently wrote on The Importance of Precise Estimates.  This is a related topic.

Mark Levison called my attention to an article by Michael Hugos subtitled ‘Agile projects require more planning and coordinating than waterfall projects‘ on CIO.com.  In this article he advocates answering the question, “Has the scope of any project task changed?” at every daily standup.  He uses this information to update a detailed Gantt chart to provide to senior management.  In Michael’s words,

It also gives senior managers who are not on the project (but who are still ultimately responsible for what happens) the information they need to feel comfortable. And that saves project team members from being distracted by endless management questions and misplaced advice (and nothing kills agility faster than endless management questions and misplaced advice”¦).

Michael, in LOLspeak, “Ur doin it wrong.” Read More