Last week, at Agile 2007, I had a fascinating conversation about geography/directions with a colleague. I explained that I needed to visit someplace and walk or drive around until I really understood where everything was. He said, “Oh, you think in postcards.” I can read a map, and write down directions. It all makes […]
I don’t have much use for Gantt charts; if you’ve determined the tasks in enough detail and far enough out to really see the critical path, you’ll be wrong in 24-48 hours. If you don’t put in that much detail, it’s a pretty picture, but not enough information to manage the project. (Of course,
I taught a workshop about transitioning to Agile earlier this week. One of the things that’s difficult for many project managers to recognize is that milestones must be deliverables–otherwise, it’s too hard to know when something is done. One of the participants had a slightly puzzled look on his face when I said that,
Glen Alleman in What’s Wrong With This Picture says this: dentifying, sequencing, and assigning durations to tasks is NOT the role of the Project Scheduler, it is the role of the project team, along with the Project Scheduler. The Work Package Manager, the Customer, the entire team that is accountable for delivering the business
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
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,
A colleague asked me what to do when you’re in an iteration and you realize that the story you’re working on spawns other requirements. I suggested that the person add them to the product backlog (the backlog of everything you want to do for the product) and re-rank the requirements in preparation for the next
So after I posted the Probabilistic Scheduling post, I was working merrily away. I had made some small progress on the book, but was still finishing up other things. Finally, Wednesday I had cleared the entire day to work on the book. I was having trouble with one chapter, so I decided to make
I’m in the midst of writing the PM book (which is why I haven’t blogged much). One of my tips is that projects have both requirements and goals–and that the PM (at least) needs to know the difference. A requirement can be a use case, user story, a shall statement, whatever. So can a
There’s a fascinating email thread started by David Anderson about What would Agile Auditing Look Like?. Part of the discussion stems from what the definition of an audit is. Audits are about compliance to a defined process. Do we need audits? Sure, for some projects. I would very much like to know that any project