Waterfall in a Scrum world, yes it is possible. See how below
Can you do waterfall at the same time you are doing Scrum? Let's explore the subject a bit...
We all know what problems there are with waterfall and long term plans that are not changed. We start executing the plans and see that things don't really work out as we thought but we stick to the original plan anyway just delaying the project but trying to deliver the same scope we agreed to.
This has a knock-on effect on the subsequent projects (there's never only one project), and other projects get delayed, but not changed because that would require changing the plans (portfolio, roadmap, strategy you name it!) and the chain goes on, ad infinitum...
The fact is that any plan that is not changed based on what we learn during the project will have the same effect that a waterfall plan has: delay later projects and provide no visibility when the projects will be completed.
So, here's the problem. Many teams and companies are doing Scrum. They have their Sprints, their Sprint plans and they change the overall scope to meet the deadlines. They may even be releasing those projects on time. But there's something more macabre at play here. Despite being able to release projects on time these teams and companies are still riddled with problems: overtime, being late in some (but not all) projects, not being able to react fast to customer requests such as support requests, fix requests, etc.
How come? What's the problem? Well, the fact is that for Scrum (or any other Agile method) to work you need to really have plans that change. It is not enough to have team-level or single-project plans that change, you need to have the whole R&D, the whole company understand that portfolio plans, roadmaps also need to change!
Imagine this. Your team is working on one project and delivering on time, but, without your knowledge, someone in the company has agreed a roadmap that actually requires that your team start working on another project before you finish the current one. Obviously they never thought to ask you your opinion and your project manager even agreed to it, albeit many months ago.
The consequence: your resource plans are now fixed! Your company booked their R&D 100% without any room for changes (after all, we don't want any people twiddling their thumbs do we?).
Since the project that you are working on changes (as it should), you actually get to work on some features until the last sprint, which in practice means that the project that was supposed to start, cannot. Your roadmap just changed, but the VP of R&D does not accept it. "Just push harder" he says. Your team continues to work overtime and you can actually deliver that "extra" project almost on time. But as it happens, there were other projects you were supposed to be working on at that time, and they could not be started. So the roadmap was again affected. And this negative spiral has no end unless the whole organization acknowledges that company-level plans need to change as much as team-level plans do!
See, you can do waterfall at the portfolio level while you are doing scrum at the team level.
Be at least as careful with your commitments to the long term as you are your Sprint commitments!
at
13:32
We all know what problems there are with waterfall and long term plans that are not changed. We start executing the plans and see that things don't really work out as we thought but we stick to the original plan anyway just delaying the project but trying to deliver the same scope we agreed to.
This has a knock-on effect on the subsequent projects (there's never only one project), and other projects get delayed, but not changed because that would require changing the plans (portfolio, roadmap, strategy you name it!) and the chain goes on, ad infinitum...
The fact is that any plan that is not changed based on what we learn during the project will have the same effect that a waterfall plan has: delay later projects and provide no visibility when the projects will be completed.
So, here's the problem. Many teams and companies are doing Scrum. They have their Sprints, their Sprint plans and they change the overall scope to meet the deadlines. They may even be releasing those projects on time. But there's something more macabre at play here. Despite being able to release projects on time these teams and companies are still riddled with problems: overtime, being late in some (but not all) projects, not being able to react fast to customer requests such as support requests, fix requests, etc.
How come? What's the problem? Well, the fact is that for Scrum (or any other Agile method) to work you need to really have plans that change. It is not enough to have team-level or single-project plans that change, you need to have the whole R&D, the whole company understand that portfolio plans, roadmaps also need to change!
Imagine this. Your team is working on one project and delivering on time, but, without your knowledge, someone in the company has agreed a roadmap that actually requires that your team start working on another project before you finish the current one. Obviously they never thought to ask you your opinion and your project manager even agreed to it, albeit many months ago.
The consequence: your resource plans are now fixed! Your company booked their R&D 100% without any room for changes (after all, we don't want any people twiddling their thumbs do we?).
Since the project that you are working on changes (as it should), you actually get to work on some features until the last sprint, which in practice means that the project that was supposed to start, cannot. Your roadmap just changed, but the VP of R&D does not accept it. "Just push harder" he says. Your team continues to work overtime and you can actually deliver that "extra" project almost on time. But as it happens, there were other projects you were supposed to be working on at that time, and they could not be started. So the roadmap was again affected. And this negative spiral has no end unless the whole organization acknowledges that company-level plans need to change as much as team-level plans do!
See, you can do waterfall at the portfolio level while you are doing scrum at the team level.
Be at least as careful with your commitments to the long term as you are your Sprint commitments!
Labels: agile, management, portfolio, project management, project smells, roadmap, scrum
RSS link
1 Comments:
Interesting point, and it rings true. In some companies the project initiation process, the process for allocating staff to projects and the development processes and methods are all completely independent of each other.
I've seen one very large company where projects are launched and scheduled without any consideration of whether there are sufficient people available to do the work.
If there are not then project managers are supposed to hire contractors or raise change requests (difficult) to reduce the scope or push back dates, or just take any available staff, however unsuitable. This places huge strains on key staff, damages morale and has predictably disastrous results for quality as inexperienced and poorly trained teams try to achieve the impossible with the key skilled staff dropping in to help now and again.
That company will eventually attempt to do Agile projects, and will find that it just doesn't work any better unless the most senior executives learn that they can't simply say "I want X done by Christmas" without considering whether the skilled people who will have to do the work are available or already working on the existing "must haves".
By
James Christie, at July 22, 2009 4:04 PM
Post a Comment
<< Home