On the bike at the gym this morning, I thought about increasing my level. When I exercise, more friction is good. But when you develop or use products, more friction is bad. Brian Marick talks about this when he speaks and writes about “ease” for development teams. If you’ve encountered a web page that made […]
I’m at the Much Ado About Agile conference this week, in beautiful Vancouver. During lunch one day, one of the conference participants started talking about premature optimization of code. Well, I know a few things about that. When I started to work professionally as a developer, I wrote in assembly language. We had 256 bytes
Daniel wrote a lovely post, Kill, commit, or transform your projects over on praglife. Keeping projects around that are not staffed, multitasking on several projects (committing to none of them), and running away from reality doesn’t help anyone. The projects don’t finish faster–they finish, if at all, slower. The people don’t have a sense of
On mailing lists, when I speak, in email, people ask, “When did ‘some principle, approach, or whatever’ start?” A long time ago. Timeboxes have been around forever. I’m pretty sure that when the Pharoahs told their architects to build a pyramid, they said, “And do it by this-date! Or else!” I know that military projects
Chris asked in his comment, how about using the word ‘abandoned’ for projects that are “finished”? I just don’t think of completed projects as abandoned. Let’s separate the product from the project. Projects complete. Products may never be done, but projects do finish, sometimes whether we want them to or not. I was working as
I was thinking about the automakers, and how they want many billions of $ from Washington (please, noooo). I don’t know what their strategic planning is, but it seems not to have changed from the 1960’s. Certainly, when I started buying cars in the 1970’s, I could not afford the low quality/high price/low gas mileage.
John Cook, wrote a lovely post, Peter Drucker and abandoning projects, explaining how Drucker talks about abandoning projects. (John, thanks, I will definitely be referencing Drucker in the PPM book.) I haven’t been using the word “abandon” when I describe stopping projects. I’ve been using the word “Kill” and the concepts of permanently stopping projects
Glen Alleman has a post about program management, Managing Multiple Projects is Called Program Management which got me thinking. (I’ve written about program management in the past also: Program Management: Multiple Projects With Multiple Deliverables.) But in the portfolio management book, I defined a few ways to think about your projects as programs: You, and
If you’ve never been a victim of Medieval software project management, wow, I’m impressed. You don’t have to read the rest of this post. But if you’ve ever tried to break free of a legacy product/project, and haven’t been able to, you are not alone. The problem is we can’t create a knowledge management system
Want to save time on your next project? Improve working relationships? Understand what contributed to your success–or what didn’t? You’ll need a retrospective to do these things, and if you want a great retrospective, you’ll buy a copy of Agile Retrospectives: Making Good Teams Great by Esther Derby and Diana Larsen. A retrospective provides