Month: January 2006

Getting started with use cases

~ Andrew Stellman ~ Leave a comment

A friend of mine is introducing use cases to his company, and asked for some advice. It sounds like an interesting project — they’ll be using it for both a hardware and software component.

Here’s what I told him:

  • Spend a lot of time talking about what’s actually going to be covered in the use cases up front, and try to stay flexible.
  • When you’re working on the use cases, there’s a good chance that you’ll spend some time talking to people and eventually think, “I understand now, I don’t have to talk about this any more.” It’s useful to learn to recogize that feeling as an indicator that you need to verify everything one more time.
  • Also, recognize that when you think, “This person doesn’t really understand this, but I’ll give them what I know they need” that roughly translates to, “There’s something here that I don’t understand, and I need to tease it out of the person.”
  • Don’t be afraid to scrap everything and start over. It’s a lot cheaper to do that now than after you start coding.
  • And don’t let anyone convince you not to do that one last review — that’s the one that will find the really BIG problem.

Great review from Knowledgtrain

~ Andrew Stellman ~ Leave a comment

Take a look at this review from KnowledgeTrain:

http://www.knowledgetrain.co.uk/project-management-training-course-article012.php

I think it definitely captures what we were trying accomplish with our book. I agree with almost all of his criticisms — for the most part, they are a reflection of decisions that we made about the direction of the book. (As you know, in any project of any reasonable size the team always has to make tradeoffs!)

I liked what he had to say about our writing style, which I really think is a strength of our book:

  • There are too many books about software project management or software engineering which are dry, overly complex and boring, but this book is not one of them. It was a joy to read because their style of writing is clear without being simplistic and the authors describe things in just the right amount of detail. It seems they understand their audience and set out to write in an extremely helpful and practical way. They have certainly achieved this.

And I especially like this part:

  • I would recommend this book to anyone who works on a software development team because the book has so much practical advice to help people improve their capability to deliver quality software. Come to think of it, I would also recommend it to senior managers of companies who have a negative view of their own software development teams. Perhaps then senior managers might understand why committing resources to process improvement is one of the best investments they can make.

Exactly! I’m really glad that idea came across — it was a point that Jenny and I really thought was important.

Are you micromanaged?

~ Andrew Stellman ~ Leave a comment

Jenny and I are working on an article about how open source projects have such great practices. We’ve been talking a lot about what corporate IT can learn from open source, and what kind of chronic problems routinely and repeatedly happen on corporate projects. Our idea is that open source projects adopt practices which corporate IT teams can adopt as well. But thinking about poor practices on project teams really got me thinking about another serious problem in IT projects: micromanagement.

I have a hunch that a lot of people on development teams who are micromanaged and don’t even realize it. Like a lot of terrible practices, they just think that it’s part of being a professional software developer. I’ll bet that an “Are you micromanaged?” checklist might help open a few eyes. Here are a few things I might put on such a list:

  • Do you feel like you’re often blamed for not doing things you don’t have time to do?
  • Are you routinely asked to stop what you’re doing in order to take care of something “urgent” or “an emergency”?
  • Does your boss often fail to even follow up on your “urgent” or “emergency” work?
  • Is there a rule that you’re not allowed to release anything without sending it to your boss first?
  • Does your boss make a lot of changes to your work?
  • Is your boss constantly tapping you on the shoulder, wanting to talk about the last two hours of work you have done?
  • Have you ever been reprimanded for doing something differently than how your boss would do it, even though you got the job done in a reasonable amount of time?
  • Do you feel like part of your job is reading your boss’s mind?
  • Do you spend more time reporting your status than you spend doing your job?
  • Do you feel like you’re not allowed to make mistakes?

I think a lot of people have trouble recognizing symptoms of being micromanaged because they’ve never worked any other way. In fact, I have a feeling that if someone was able to conduct an accurate survey, they would find that a surprisingly large number of managers are micromanagers.