When Ken trained me on Scrum, he was very clear about the fact that Scrum in and of itself was not sufficient for project success. Scrum punts a large number of important decisions to the "Project Owner," and therefore it is a very poor fit with projects that don't have an active,hands on project owner or proxy for the project owner.
if you have a incoherent project owner whose priorities drift from sprint to sprint, you will end up with a beautifully executed, disciplined execution of an incoherent product.
Scrum forces the client to decide which features are most important. It bribes them with the idea they can have some things next week to avoid a death march 6 months from now.
This helps to create useful products without wasting time building useless things.
As long as the most important 80% works chances are the project will be considered useful even if it does not do everything. Which is important but it requires a skilled team to execute well over time.
> Scrum forces the client to decide which features are most important
Aaaaah, I think it's fair to say that Scrum forces the client to declare which features are most urgent and that in the ideal project the client aligns urgency and importance. However, just like real life, it is difficult to align these two orthogonal concepts.
Sometimes things become urgent because they are tantalizingly easy to do.
Sometimes things become urgent because someone important thinks they are important.
Sometimes things become urgent because the client is personally invested in them.
I agree that "as long as the most important 80% works chances are the project will be considered useful even if it does not do everything," but I am cautious about assuming that just because you ask the client to name the most important features ona sprint-by-sprint basis that you will agree in hindsight that the most important 80% of a product got done.
> if you have a incoherent project owner whose priorities drift from sprint to sprint, you will end up with a beautifully executed, disciplined execution of an incoherent product.
Could not agree more with that. And I think that's one of the pitfalls of Scrum: that it works well if you have a relatively well defined project that's not really going to change. If you have to change around your whole system every sprint, nothing is ever going to get done.
Interesting. I thought one of the main advantages of Scrum was to be able to adapt to changing requirements.
From wikipedia:
"A key principle of Scrum is its recognition that during a project the customers can change their minds about what they want and need (often called requirements churn), and that unpredicted challenges cannot be easily addressed in a traditional predictive or planned manner.As such, Scrum adopts an empirical approach—accepting that the problem cannot be fully understood or defined, focusing instead on maximizing the team's ability to deliver quickly and respond to emerging requirements."
I have to ask: how often do these formal buzzword project management techniques find their way into the real world? I've not been doing this long, but it seems to me that the folks who set deliverables either don't use these methodologies, or use an unnamed amalgamation. Am I wrong?
Agile methodologies have made their way into many startups and established companies. When I was working at Comcast large portions of the software engineering groups was starting to sync on a product cycle.
That being said - I've not seen much consistency across implementations. It generally breaks down to some sort of product backlog which is worked on in small chunks on some cycle (months, weeks, two-weeks whatever...). This is a pretty basic change to the normal waterfall cycle and easy to implement, and works well for many teams.
The rest of the Agile/Scrum/pick your particular method is left to the project/product/SE manager and you really have to find what works for your team, and I'm not sure makes that big of a difference in the end.
It depends entirely on where you are. Some projects are a completely chaotic mess, of course. Some have a methodology, perhaps cobbled from bits and pieces of conventional wisdom, but they don't give it a name. Some explicitly declare a methodology and pay attention to its rules, more or less. Some, alas, become religious devotees of a methodology, train a police force to enforce the rules, and go into full blown cargo cult mode.
But all real-world instantiations of methodologies are, in some sense, "amalgamations". For one thing, none of them are complete. As both the article and Raganwald point out, Scrum is far from a complete description of what you need to do to organize a successful project, just as using Lisp and Emacs aren't sufficient conditions for producing great software.
Way more often than you think. When I did my Scrum certification, there were people from lots of the financial corporations in NYC. I know Verizon is slowly starting to have its people get certified.
My biggest problem with that is that I think a lot of these companies are having their people learn Scrum because they think it'll be their silver bullet, as if taking a bunch of people and having them start doing Scrum will suddenly turn all of their failed or ultradelayed projects into victories.
I've used Scrum at MTV Networks and at Conde Nast. I heard from a ex colleague he was trialling Scrum at Time Warner.
Scrum worked very well for us at MTV Networks with the project I was working on. Due to us having a very experienced Scrum Master and the Project Owner being very active and understanding how to prioritize his requirements.
We're talking about management here. The old quip about 'herding cats' comes pretty close to the truth. So there's a large amount of uncertaintanty involved. Buzzwords give a sense of security, even if there's not much behind them. Six Sigma. ITIL. Scrum. Paradigm shifts. Proactively promoting synergy.
Scripps Networks Interactive uses Scrum with varying degrees of success (as one of the early comments noted - it depends on the skills of the project owner - but even without that, it helps keep dev focused on deliverables that work).
What feels least sufficient to me are systems for learning Scrum, or XP, or any blend of practices/patterns/principles well enough to do more good than damage. We therefore generalize from poor data. We draw conclusions from poor execution during the learning curve.
Another big issue for me, in SW Dev, is the opacity of "code asset" deterioration as we start to iterate features through it quickly. Scrum can exacerbate that. Once we start cranking the Sprint crank, poorly disciplined programmers can hack the code to bits even faster than before, without stakeholders noticing.
Hence agile wags once called Scrum "XP without the P".
if you have a incoherent project owner whose priorities drift from sprint to sprint, you will end up with a beautifully executed, disciplined execution of an incoherent product.