Archive for October, 2007

TurboGears 2 sprint

I’ll be hosting a TG2 sprint here in Ann Arbor Michigan on October 27th, hopefully we’ll also have a large virtual presence from folks around the world.

I’ve created a page on the Wiki for Sprint Organization tasks: http://docs.turbogears.org/SprintOrganization

If the sprint goes well it could get us very, very close to the point where we could reasonably do a TurboGears 2 technology preview release.

The main things we’ll need to do is sync up with the latest pylons, improve our tests, and do some basic doc organization work (migrate some information from the doc strings to the docs wiki, and create some pages which link to external docs). There’s lots of other things I want to do like improve out user authentication/authorization/registration support, or create a toolbox tool for helping create SQLAlchemy models. So, there’s tasks for anybody who can lend a hand.

If you’re available and want to help out (either attending physically or virtually), feel free to add your name to the wiki.

Likewise, if you can host a in-person sprint in another location, please feel free to edit the wiki with that information.

Overheard in conversation

Action causes more trouble than words.

Not sure who said it. Not sure what they were advocating. Which is why I like it.

Save your software project by telling better stories!

Johanna Rothman, has an interesting post about article about Project Vision.

She makes the argument that your project needs a clear vision, which sounds like common sense. But, if my experience as a consultant and software developer is anything of an indicator of what’s really happening in the world, vision statements are about almost anything but clarity.

Telescope

If those of us in the trenches getting things done are going to make good decisions from moment to moment, we need to know the problems we are solving, and have a clear understanding of what’s not included in this project.

Ideally software project managers will make the project vision so simple to understand, and easy to remember that anybody who even talks about your project knows your vision.

Generally that means telling a good story, a story about users and the pain they have now, and the relief that your project can bring — a story that defines exactly what’s special about your project.

For example, I managed a project where the story was “Create software that makes it possible for large manufacturers to stop slowly, cumulatively, wearing their their workers bodies out.” The defining characteristic of this software was that we had to make it “easy for manufacturing employees at large multinational corporations to do the right thing by 1) determining how likely jobs are to hurt people and 2) implementing fixes quickly. ”

That vision statement isn’t perfect. But, given a choice between spending time on making small improvements in injury prediction by gathering more data and implementing a more complex injury prediction algorithm, or on making data entry easier and more intuitive, it was immediately clear to everybody on the team which choice to make.

And it’s definitely better than this project vision: “We are building a framework for automating complex business processes that require multiple people to interact with data over extended periods of time using SOA, BEPL, a customized work flow engine, and a Domain Driven Modeling.”

Who the heck even knows what that means?

The first problem is that it tells us what technology we’re using, but not what problem we’re solving.

The second is that there are no real people in there — we have no idea what problems the ultimate users of the system are trying to solve or how this software will help them. The development team had a lot of talent, managment was very invested in this particular project, and there was a lot going for this project. But the project was a failure.

storytelling

Project managers tell stories that stick, stories that about how people’s lives could be better in the future. And when things work, we build that better future one line of code at a time. From childhood on, good stories engage us at a visceral level, you don’t have to try to remember them, they stick in your gut, and are hard to forget. The quality of the stories we tell matters!

The problem with that project was that nobody knew where things were going, and for the entire lifetime of the project there was no clear understanding of what needed to be done to finish software, and there was a lot of feature thrash (features built, rewritten, remove, and re-added later). And all of probably have been fixed if we’d just had told a better story about what we were trying to do.

You can think of a Project Vision Statement as a 30 second elevator pitch for why your project is important and how it will help people. Elevator pitches need to be memorable. A good story keeps people focused, motivated, drives small everyday decisions, and otherwise is the foundation for a successful project.

I think a lot could have been done for the second project by having a simple, concrete, focused story of what we were trying to acomplish.

I’ll definitely have more to say about this, but I’ve been reading Made to Stick, and I heartily recommend it to anybody who wants to get other people to remember the points they make. It’s in the business book section, but it’s really a book about how to tell stories that stick with people. They’ve done a lot of research into Urban Legends, and other extraordinarily sticky stories, and the book is filled with interesting tips for anybody who wants to be able to communicate their ideas more effectively.