I knew I was going to like The Agile Samurai from the first page: Agile is a way of developing software that reminds us that although computers run the code, it’s people who create and maintain it. Jonathan Rasmussen, the Other JR, has written a great, short, to-the-point book about how to move a project […]
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
Inez has a great review of Manage Your Project Portfolio. What resonated with me was: this book gives a more complete view of what is at stake when dealing with project portfolio management and will really help organisations to move forward faster with implementing and improving this key business issue of the 21st century, the
My column on Stickyminds is up: Measure Throughput, Not Utilization. Enjoy!
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
Lately, I’ve been working with people who say they’ve looked for months to try to find just the right person. I believe them. When I ask where they spend their time, they inevitably say that they spend way too long interviewing people who aren’t quite right. And, it doesn’t have to be that way. Here’s
I’ve been meeting people who call their teams distributed. But their teams are dispersed. That is, some team members are in one place, and some team members are in another. In the worst cases, there are separate people all over the world. For example, if you have cross-functional teams in Boston, Chicago, San Francisco, and
I’ve been working with and discussing agile program management with a bunch of people. One of the big issues is: what do we call certain people at the program level? We need a program manager, someone who sets/explains the program’s vision, develops program-wide release criteria with sponsors, has a way to articulate program status, someone
I’ve been working with teams and been a part of teams my entire work life. Not so much at university, but certainly when I started working professionally. I’ve been confused by what some people claim are self-organizing teams. To me, they don’t look particularly self-organizing. I read Brad Appleton’s excellent series of blog posts on
People often use my network to ask me for back-door references about people I know. Sometimes, I can help. Sometimes, I can’t. If I don’t know someone well enough to provide a reference, I don’t. For example, if I consulted at a client for a few days, I don’t know anyone well enough, other than