You’ve written a project plan. Your team is ready to start. Here’s the bad news – you’re going to fail. But why? How can you avoid failure?
Category Archives: Project Management
Why Gannt Charts Are Useless For Agile Projects
What can you learn about your agile project from this Gannt chart? The one above looks out two years. It shows task dependencies and concurrencies. If you’re iteratively developing software, do you really expect to know what you’ll be doing two years from now, to know if you truly have a dependency? You may understand the dependencies with a two-month time horizon. But how much effort are you investing in creating a detailed, two-month Gannt chart? And how much value are you getting from it?
Continue reading Why Gannt Charts Are Useless For Agile Projects
Barrier To Agile Development
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.
Perpetually Almost Finished Projects
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.
Prioritization and Value Maximization
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.
Juggling The Elements of An Iteration
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.
Continue reading Juggling The Elements of An Iteration
Benefits of Agile Story Decomposition
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.
Failure To Deliver Is Not An Option
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.
Planning for Effective Meetings
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.
Continue reading Planning for Effective Meetings
APR: Scope and Vision
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