For a time, I hosted the Portland Software Development Roundtable. For a few of these sessions, I took notes and published them here.

The materials that follow are very rough outlines of our discussions: you won't find polished articles here. These outlines don't necessarily reflect my point of view or the point of view of all of the attendees.

Why do the next generation of methodology experts say it's best to start at the end of the project and work back towards the beginning?

When I expressed bafflement, the submitter added:

You asked for April 1st topics, did you not? ;-) << I guess I fooled you. >>

Some times humorous thoughts or topics that are so counter to mainstream thinking, when considered in a serious light, can lead to new discoveries. In older days this was one of the purposes a king's fool played -- to interject ludicrous ideas at the perfect moment to cause a collective shift in a group's thinking.

Attendees:

• Rodney Bell
• Karen King
• Randy King
• Rebecca Kun
• Diana Larsen
• Jim Shore

Notes from our discussion:

• What is the end? Is it the beginning?
• It's the delivery
• Start with delivery -- get feedback


• Do the plan last
• Do the design documents last
• It's the only way to know if they're correct
• It's not the plan that matters, it's the planning


• Is the end of the project its death?
• The end of the project is the start of the product?
• No, the product continues to change, so the project continues
• Products die due to software debt
• ...or never being delivered in the first place
• Example of pager-wristwatch: supplanted by newer technology
• "There was a point at which we should have realized it was dead
• Obsolescense is a project in itself
• "Done" is when we hand it over to support
• Some define "project" as "defined beginning and end"
• First delivery to production is typical end
• Hand-off to maintenance is one of the most destructive things we can do to a project


• Why is it best to start at the end?
• If it fails, don't even start!
• But even failures help you learn and that has value.
• Getting people to cancel
• The gambling fallacy
• Throwing good money after bad


• Concept of time
• What does it feel like to go back in time?
• Memento (the movie)
• Future is ahead, past is behind
• For the Hopi Indians, the future is behind because you can't see it
• The end of the project is when you can't see anything
• We fool ourselves into thinking we know what will happen
• It's cultural--we don't fool ourselves, it's given to us
• It's a mythology: "I know it." Our sense of self-esteem is directly based on our ability to predict accurately
• So we go down the path of nailing everything down rather than being adaptive. But it's like nailing Jello to the wall
• Envisioning works for an individual but our ability to envision breaks down with larger & larger groups


• Starting with the retrospective
• That's planning
• Looking at past projects and what went wrong
• ...and what went right!
• What about when there's no past projects, like a merger?
• Start with retrospective of everyone's past projects
• What's the outcome of a retrospective?
• Wisdom; organizational learning
• Project plan
• Working agreements
• Chartering
• Structure


• What about when it's a brand-new project? What do you retrospect on?
• People's experience
• How is that different from setting ground rules?
• It's the group, not the individual
• Retrospective is mining experience rather than blue-sky


• Starting with income, rewards, recognition
• One experience: more work, more satisfaction
• Start with the party
• The "welcome" party vs. the "goodbye" party
• Good way to break in to the culture
• How do you know if someone's a shyster?
• Why not to do pro-bono work:
• When the client doesn't pay anything, they're not invested.