Archive of Project Management Articles

Why don’t more companies and teams use agile development techniques? We know some teams just aren’t aware of them – although that list is getting shorter every year. The benefits of iterative development over waterfall development are pretty well established. I don’t believe I’ve seen a study that shows that waterfall is more effective. Do people refuse to believe in the data? Or maybe they are unable to believe.

Your project is almost finished. Last week, it was almost finished. And you suspect that next week, it will still be almost finished. Why does this happen, and what can you do about it? In some ways, we’ve known about this problem for almost 2500 years But the solutions are still far from widespread.

We all know the story about the emperor’s new clothes. I’ve been thinking about prioritization and scheduling, and as far as I know, no one is promoting that we maximize value – they (and we) have been promoting that we do the most valuable stuff first. Doing the most valuable things first does not result in getting value the fastest. In this article, we show why not.

You expect analysis to happen before design, and both to happen before implementation and testing. But how much should these activities be staggered? When a project is being run with monthly releases, it might seem logical to have each group working on a different release. For example, the test team working on the current release (3), the developers on the next release (4), and architects and analysts working on releases 5 and 6 respectively.

If your team is this staggered, you have a problem. It takes four months for a requirement to be released from the time the analyst has documented it.

When you plan a release, agile user stories, or classic use cases are the best sized pieces to use in the planning – from the perspective of your customers. Each user story can be further decomposed into a set of specifications, and those into development tasks. Development tasks are the right sized unit to manage your work breakdown structure – communicating the release schedule internally with your development team.

But sometimes, it happens anyway.

The Cranky PM started a great thread of conversation asking how product managers deal with the job of telling customers (and sales folks) that a feature is not going to be available in the promised release.

Jonathan Babcock has written a couple interesting articles on preparing for a review meeting. He touches on a couple generic “good ideas” and explores one critical idea in more detail. We focus on that detail – helping participants be prepared to participate – in this article. His articles, and this topic in general are useful to anyone who runs meetings that require participation from attendees – business analysts, product managers, and project managers, for example.

To define the boundaries for our agile project, we need to define the scope. To provide a guiding framework for the rest of the work, we need to document the vision. We could create heavy-weight scope documents and vision documents. And we could run them through reviews and get approvals and wordsmith them to death.

But we won’t. Agile processes are about documenting enough, not documenting for the sake of documenting. This is a small project with an even smaller team (one person right now – but that will grow as people start helping out). An informal documentation style will be sufficient. The key element is to have something referenceable and mutable. If we can’t change the scope or the vision based on market feedback, we aren’t being agile.

These two project management artifacts seem logical to combine into a single article

Leading Answers, an agile project management blog, has a great article that details some agile techniques for release planning exercises. Their article includes explanations and great diagrams.

One of the goals of agile software development is to deliver value quickly and iteratively. One of the most effective ways to begin the software development process is with use cases. To deliver with agility, you start with the most valuable use case, bang it out, and then move on to the next most valuable use case. How do you know which use case is the most valuable if you haven’t defined all the use cases first?