In the Spotlight - Johanna Rothman

On the long weekends, Mark and I make a concerted effort to clean up the house. That means I have to address all my little piles: go through them, recycle what I can, throw out what can’t be recycled, file others, figure out what to do with the rest. While Mark was helping me bring some of my paper and books downstairs, he nudged me about finishing the living room. “I know you don’t like clutter,” he said. “Yes, but I know where everything is. Besides, you have clutter, too.” “But I don’t like your clutter,” he responded. I started to say, “Yeah, but my clutter is different” at which point we both cracked up.

My clutter is comfortable for me, otherwise I would have dealt with it already.�� You could call my clutter technical debt, and you’d be right. I don’t mind paying it off on long weekends. Otherwise, I would do something about it more often. But the reason my clutter is different is because it fits with my mental model of the world.�� I’m sure when Mark reads this, he’ll try to change my mental models. He’s unlikely to be successful.

These same kinds of discussions occur at work, but we tend to laugh at them less. (Maybe we should.) The next time you find yourself perturbed by someone else’s perspective, consider this question: What would have to be true for the other person to be happy (or content or satisfied) with the situation?�� Partly, my clutter helps me see all the things I do, which is helpful. More clutter does not make it more helpful — there’s a point at which even I think there’s too much clutter. But seeing clutter doesn’t help Mark, and since we share a house, I need to flex a bit. I’ll continue cleaning up now.

I’ve been wanting to start podcasting for a while. Now, I finally seem to have enough tools that I can do it! Thanks to Clarke’s suggestion, I’m using libsyn, and I do believe iTunes is syndicating the podcast also. So, here is the link to my first podcast: Timeboxes Help Multisite Teams on libsyn.

I have successfully syndicated The Pragmatic Manager on iTunes. I don’t know how to give you a URL that will get you there directly. Thanks to Rick, here is the iTunes URL.

I also added the mp3 file to the libsyn page. Now I know for my next podcast:

• Make files in mp3 and m4a.
• Publish links to both those files and iTunes url

I don’t know if there’s more, but I bet there will be…

I’ve been working with several clients on their transitions to agile–or at least, more agile approaches to their projects. In each case, the managers decided to move towards agile because the technical staff were in their words, “naive” about the project goals. To be fair, none of the projects had a vision or release criteria, so it’s not surprising the technical folks didn’t understand the project goals.

But waterfall, with it’s emphases on understanding up front,�� helps create that naivete. If you could understand requirements or design up front, then the project is just a SMOP (Simple Matter of Programming). And the testing is just a SMOT, and the writing is just a SMO (Testing and Writing). With a SMOP attitude, everyone assumes the predictive schedules are correct, creating a sense of naivete for the entire project–not just the technical staff. The managers are naive about what the milestones really mean, and everyone’s naive about the entire schedule.

But there’s an even more insidious�� assumption in waterfall: that the time to finish the project doesn’t matter. This attitude arises even more if a senior manager or program manager or project manager says something like, “Quality is Job 1.” At some point, this project has to end and the product has to ship. Maybe not next month, maybe not even next year, maybe the year after. But at some point in time, the product will ship, regardless of the technical staff’s perception of quality. And that’s where waterfall lets down the entire project team.

I haven’t worked on a project or consulted with a company where they had endless time to get to release for at least 20 years. (I can only remember one project where we were not under time pressure back in the early 80’s. But maybe I can’t remember much Granted, I tend to work on or with projects in commercial organizations, so if you’re working on a government project, maybe you have more flexibility in time.

But a waterfall project organization, where you have milestones such as “requirements complete” or “feature freeze” or “feature complete” provide a disservice to the entire project and management team. We know the requirements are not complete. We know the features will change. Saying they are complete or frozen won’t change reality. But those complete or frozen milestones provide a sense of inevitability about the eventual ending of the project, and infer that since we’re “meeting” (ha!) the project milestones, that we will continue to. That’s the naive part. (See There is No Such Thing as Percent Complete and Showing Project Progress (NOT percent complete) for why.)

Waterfall is fine for a few weeks (4 or fewer), and a few people (4 or fewer) and where you’re sure the requirements are not going to change. Absolutely, positively sure. No surprises. But if you have a larger project or a longer project or you have a suspicion things might change, you want to work differently. I recommend you read my recent Cutter IT article, What Lifecycle? Selecting the Right Model for Your Project to see ways to organize your projects so they make more sense.

Naivete can be charming in people. But it makes for badly organized and executed projects and programs. Waterfall reinforces naivete. Any other lifecycle allows you to take a more empirical approach, rather than a more predictive approach. The agile lifecycles are all about empiricism, so they banish naivete–at least, about schedule–completely. Choose any other lifecycle, and you can take a mature, not a naive, approach to your projects.

I recently spoke with a project manager. He was concerned about the product managers handing off the requirements to the development staff.

He was right to be concerned. Handoffs don’t work.�� The more people think they are done with “their” part, the less likely you are to receive/finish a great product. That’s because no one can tell what they really want until they see it.

The more often the requirements-generators see the product as it’s being built, the easier it is to modify the product. The more the developers see the testers test the product, the easier it is for them to incorporate that feedback into their development.

A successful product requires everyone to participate fully throughout the whole project.�� That means you can forget about people coming off this project to start the next one. That’s because the people who are supposed to come off the project need to continue their work until everyone is done.

Handoffs don’t work. Collaboration does. Keep everyone on the project until it’s really done-done-done.

I’ve finally finished my first podcast, and don’t know where to host it. Any recommendations from you folks?