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
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
I had the opportunity to read Practices of an Agile Developer: Working in the Real World. The book has 45 tip to help developers become agile. And, it’s clear that Venkat and Andy know the problems of becoming an agile developer, because along with each tip, there’s a devil-thought to show people what happens
When I do assessments, I ask for lots of project documents and data. A few years ago, I was working on an assessment for a very large system, so I asked for an architectural picture. I was surprised–this million plus LOC system had no picture at all. No wonder it was so hard for the
I recently spoke with a recruiter who told me, “I just can’t seem to find agile candidates. No one has “stand-up meetings’ listed on his resume.” When you’re reviewing resumes, it would be nice to find some keywords so you could see if the candidate has had agile experience–but it’s unlikely. However, implementing a few
Senior managers — the people who make strategic product decisions — need to know when they can expect those products to release. The organization of current product releases against a timeline is a project portfolio. And, planning the project portfolio in an agile environment is different — but not harder — than planning the project
I’m working with a group of people who are new to iterative development. They’re doing more of a staged delivery lifecycle than an agile lifecycle, but they are releasing about once a month. They don’t like it, because they say they’re releasing too frequently. The problem is that their planning and releasing take too
In the immortal words of Dilbert/Scott Adams, “Agile programming doesn’t just mean doing more work with fewer people.” See today’s cartoon.
I met a manager recently who relayed his technique for making sure his testers stayed focused on their jobs. “Our defect-tracking system logs people off after 30 minutes of idle time. If they’re logged off, I know they’re not working.” This was a new one for me. I’ve heard of counting lines of code.