It’s About Context, People!
In any given situation, there are a ton of things that could possibly work. One of the most successful projects I ever managed was delivered using a mix of Waterfall, Agile, and RUP. We had a existing product that our customer wanted to enhance. The customer knew exactly what they wanted and never changed their mind. The teams involved had built the original product, and they knew the code like the back of their hand.
We used a big-up-front-design, traditional estimating, and Gantt charts… even on the agile side. We did ‘black box’ the agile teams, but they had to inspect and adapt their way into the overall project plan. We delivered the project on the promised due date, within something like 1% of the original cost estimated, and with everything the customer had originally asked for. My company made the money they expected to make and our client made the money they expected to make.
We didn’t do a death march, there were no 11th hour surprises, the deployment went exactly as expected.
Scrum is an empirical process control method. When you have a high degree of variability, and predictive planning methods are likely to fail, empirical process control can help manage and constrain the chaos and complexity, and optimize your project outcomes. It’s a more expensive way of managing project outcomes, but works better when variability is high. If variability is not high, and the system is well known… it’s possible Scrum is not the best choice, even on a software project.
I think part of our problem right now is that we’ve somehow decided that Scrum is the way to go no matter what the project characteristics. We get so enamored with the benefits the team gets from adopting Scrum, sometimes we forget that Scrum might not be well suited to the business needs of the enterprise. That’s not a knock on Scrum… it’s just that Scrum might not be the best tool for the job. It is up to us as organizational and project leaders to understand our options.
Comments (4)
almgren4711
I agree with you. Sometimes it bothers me that in "the church of SCRUM" there is no room for the simple view that maybe you can use other tools. So far in human history we have not found the universal tool that we can use in all situations, why should SCRUM be that tool?
A good tool is adapted to the situation you use it in, the more general the tool is you often also find that its not the best tool.
The true expert is the one with the largest toolbox and the knowledge to use the right tool in the right situation
Andrew Fuqua
Mike,
You wrote about Scrum that "It's a more expensive way of managing project outcomes, but works better when variability is high." Really? More expensive than what? If the alternative involves hand-offs (involving documents or hand-offs involving responsibility) then I would say Scrum with face-to-face communication and fewer hand-offs would be less expensive. Single-piece work is faster than batch-and-queue. No?
Mike Cottmeyer
Andrew, if I have perfectly well understood requirements, understanding of the system, and am proficient in the technologies involved, and I can break the work into discrete tasks that can be assigned to people and reintegrated at a later date, why would I need to have people in a room. Why would you assume that specializing generalists are the way to go. I would rather have a team of deep, deep specialists that were the experts in their domain. I am not trying to manage complexity or chaos… the domain of scrum… I am trying to deliver a well defined set of tasks. I would rather have a team of experts working heads down being the best they can be. I have no need of Scrum and its overhead.
Andrew Fuqua
So, we've discussed this over lunch and personal email which I deeply appreciate. Thank you. Still… I'll concede that scrum meetings are overhead (waste) if you don't need them and that you don't need them in the scenario you describe. That said, I'm going to assume we're talking a project of some significance — a handful of developers, a couple months or more of time, a non-trivial system, perhaps enhancing an existing system of some age. There are very very few architects that can /efficiently/ design the enhancements to this system up front. You are going to need 'Emergent Design' which requires some amount of inspecting and adapting, does it not? You wouldn't need to inspect/adapt for requirements — only the design. I think I've just argued your point. You don't need /Scrum/ in all cases. You may need /something/, but what that is is context specific. And hopefully that /something/ for the case you describe is lighter-weight than Scrum.
Ok, I'm out. I'll let you have the last word. :-)