Contents: This month’s Feature Article: Discovering and Maintaining Your Project’s Heartbeat, Part 1 Announcements =-=-=-=-=- Feature Article: Discovering and Maintaining Your Project’s Heartbeat Some projects zoom along, making progress regularly. Others feel as if they slog along, with barely any progress from week to week, or worse, month to month. Why? The zooming projects have […]
Contents: This month’s Feature Article: How Many Emergency Projects Do You Have? Announcements =-=-=-=-=- Feature Article: How Many Emergency Projects Do You Have? A project manager at a client took me aside recently. “Johanna, how many emergency projects should I have?” I was a bit surprised and asked what he meant. “Well, my boss thinks
Normally, I’m huge fan of continuous integration. Continuous integration is when everyone integrates his or her code every day, preferably as each little tiny piece is built and tested (or in the case of test-driven development, tested and built). The developer checks his or her code in, does a local build, checks the build, and
Pawel caught me being ambiguous. See his comment, “1. I’ve seen features/fixes which required 2 days to be developed and released.” Sorry, me too. But what I tried to say was this: A feature was estimated to be some duration of person-hours. Those person-hours have come and gone. The feature still requires another 10-12
From Andy Lester comes a pointer to Hugh’s The Career Manifesto”. Andy’s writing a book called “Pragmatic Job Hunting” (working title). If you’re looking for a job, consider subscribing to Andy’s feed. Labels: candidate, career manifesto
I ran a little workshop today about transitioning to agile. I was talking about timeboxed iterations, and one of the participants asked this question. “So I don’t quite finish one of the features I want to finish in this iteration–and it’s the end of the project. I think it’s going to take me a
I’m catching up with my blog reading. Several posts caught my eye, all dealing with taking time to think: When you take time to think between sessions, the sessions may go faster. You’ll almost certainly have a better outcome. (Esther and I learned this on Behind Closed Doors.) See Ron Jeffries’ take on thinking: Shooting
Thierry poses a question I’ve heard in several of my PM workshops this week and last week: When should the team do the architectural work? Thierry’s concerned if his team continues to implement by feature, how can the team do the architectural work? If they take an iteration or two to deal with architecture,
Joshua asked me to clarify what I meant by implementing by architecture. Here’s my picture-story. When a team implements by architecture, they tend to be functionally-based teams implementing across the architecture. When a team implements by feature, they are cross-functional teams. When teams implement by feature, they do what’s needed in whatever part
Scott points out Software Product Delivery – 20 Rules? that you should do the riskiest part of the project first. (He explains that you modify that given what’s most important.) I’d add a further refinement: that what’s most important better provide the most value. If it doesn’t, do the most valuable parts first. You