I’m reviewing an article from a long-time colleague who’s just started to write. He has great ideas. And the way he’s packaged his ideas (the writing part) doesn’t do justice to them. There’s a mnemonic* I use (when I remember 🙂 to help me package my ideas better. It’s Hey! You! See? So… Hey! grabs […]
Don has a great post on Single Point Requirements. You get one example of the requirements: “This product needs to do this. Just this.” Sure enough some months (or years) later, that single example is not sufficiently general to do everything you want the product to do. That’s ok, as long as you plan to
My quarterly Stickyminds column, How Much Work Can You Do? is up. Hope you read and comment.
A couple of weeks ago (yes, I know I’m behind :-), Scott Berkun asked in Teaching programming / management the Harvard way“Anyone have examples of CASE or situation based courses for managers, designers and programmers? Undergraduate or graduate?” Yes, Scott, I do. When I teach program management and software methodology (at the graduate level
Mike Kelly posted some reflections on Behind Closed Doors: Making Progress Visible. I love it when people understand why their managers are asking questions.
I had a discussion recently with a manager who was concerned about his developers meeting their milestones. “We have “Code Complete” as a milestone. The developers say they meet it, but that just means they wrote code until the milestone date. The code isn’t complete. I can’t even tell how complete it is.” Ah,
Alan Weiss, author of Million Dollar Consulting, advises consultants to drop the bottom 10% of their work every year. That way you have to force yourself to grow and offer new (frequently more lucrative) offerings. The same advice applies to managers. When I teach management, I explain that managers have three responsibilities: To deliver
If you don’t read developer.*, consider it. Dan has kindly placed an excerpt from Behind Closed Doors: Secrets of Great Management. Enjoy!
Recently, I gave a talk about useful practices–things to consider adopting/adapting in your organization. (I don’t believe in best practices, the idea that something could be best in all situations is just not credible. See UsefulPractices for more discussion. One of the techniques I discussed was creating smoke tests for the build. We started
I met someone at the Software Development conference this week who told me he had too many people to meet with them all–even on a biweekly basis. I asked him how many people he managed. “30.” That’s not a typo; that’s the number between 29 and 31. I asked why he had so many