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,
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
I’ve finally finished my first podcast, and don’t know where to host it. Any recommendations from you folks?
Refocusing: Emerging from the Split Focus Schedule Game You see your manager bounding down the hall towards your office. You know what’s going to happen before he gets there–he’s going to ask you to take on yet another project in addition to the three you’re trying to juggle now. You want to run and hide.
I’m pleased to announce that Esther, Jerry, and I will be co-teaching another PSL in Sweden in January of 2009. (You don’t have to be Swedish to participate!) Magnus has announced it, PSL Sweden 09! If you’re thinking about PSL, please join us.
Jack Vinson writes in New Grad Hires: Ready and Willing, but Are They Able?, The solution is to hire people who have the general skills, capability, and/or experience you need and then train them in the missing aspects. That’s the way it has always been. For technical staff, expect to spend time helping them develop
Some folks have told me in their agile projects that they are able to deal with technical debt as they find it. They are a lucky few. But more have been stumped: “I find something. I really can’t fix it now. But I don’t know what to do with it.” I’ve suggested putting it on
I like Roy’s analogy about the difference between unit and integration testing: Unit testing vs. Integration Testing : The Restaurant Analogy.
I’ve been writing pieces of the project portfolio book, and was wondering how to explain how managers get caught in the trap of having too many projects. Then I read Joe Ely’s Minimizing Work-in-Process for Knowledge Workers, and had an “aha” moment. (Well, I think I did. You let me know.) For many managers (and
Jurgen’s post, How to Select a Fine Technical Manager, along with the posts he responded to prompted this one. I’m not agreeing much with Jurgen today. I suspect it’s because we have very different experience. In my experience, only technical people who want to manage want to be managers–unless HR has screwed up the salary