To many, sprinting through Scrum feels suspiciously like Mini Waterfalls; others state that that is merely a “bad smell” and Scrum is not just a series of mini waterfalls.
Which is correct?
Although the odor may be pungent, to me it seems correct that a Sprint marathon really is just a series of mini waterfalls, at least at the important levels.
Let’s see what they have in common:
1) The delivery date is clearly defined; in Waterfall, that delivery date may be months or years in the future, and in Scrum that delivery date may be the end of the current sprint, but either way, they are fixed. The only difference is the time scale. To me, they are the same in this regard (fixed delivery date)
2) Fixed scope during execution cycle; in Waterfall, the requirements are known up front and don’t change during the execution stage, however long that may be. In Scrum, the requirements for the current sprint is known up front, and change is not allowed (must reset sprint anew). In both cases, changing requirements during execution is unacceptable. Once again the only difference is the length of the execution period. Thus, they are the same in regards to their inflexibilty to incorporate change during an execution phase
3) Status Reports, Meetings, & More In waterfall, there would be weekly staff meetings, progress reports and the like. In scrum, the situation is the same; there are daily status meetings and burndown charts. Once again the only difference is the time scale
4) Sequential Execution In Scrum, (especially “Type A” Scrum), sprints are sequential and build upon earlier sprints. They do not overlap. This is no different from waterfall, where one phase is done before another and they happen sequentially. Either can choose whether to go horizontal or vertical during these phases.
5) Retrospectives In Waterfall, after a project there is a “post mortem” at the end of the execution phase to reflect on what went on and what to change in the future; in Scrum, there is a “retrospective” at the end of the execution phase (Sprint) with exactly the same goals. The difference? Once again, none beyond the time scale.
So, we can clearly see, that Scrum is not a radical, innovative, revolutionary approach. It is merely an evolutionary and reactionary approach that optimizes for short term planning, compared to waterfalls longer term planning type approach.
Scrum as a series of Mini Waterfalls? Yes, that does seem to be the case.
The relabelling of titles and frequent lip service to intangibles like “empowerment” do not change the overriding mini waterfall nature of the method; waterfall could and often does easily allow for self organization, freedom to choose tasks, etc.
The only tangible difference is short termism versus long termism, and if the waterfalls are “mini”, then they become equal in their short term outlook. To be absolutely clear, “mini waterfall” means one that is 1-4 weeks long.
Please understand that point — some commenters below seem to have missed it — I’m comparing it to a MINI (=short timeframe) waterfall.
Jordan
Probably the key difference is the element of ‘inspect and adapt’. Yes in waterfall the concept of ‘post implementation reviews’ are common but I have never seen the outputs of such a review actually used for changing future projects. A Retrospective on the other hand at the end of each timeboxed iteration (if not performed poorly) will result in changes to the way you work that has a positive impact.
From a purist ‘flow’ perspective yes they are exactly the same:
1) understand the need/problem/opportunity
2) work out how you might deliver it
3) design it
4) build it
5) test it (lots)
6) deploy it
What is interesting is what is outside of the flow. Waterfall has change requests to handle adaptations, Agile allows adaptive change without the superfluous paperwork. Waterfall wants the ‘what we are building’ to be highly documented because 10 months down the track no one know what was built and needs it written down to test against. I don’t think we do this as well as we could (I certainly still see lots of documentation) but it isn’t near the level of detail of the old days and relies more heavily on collaborative communication. And lastly the cost to fix errors is significantly more reduced due to less lag between building and testing.
For my 2 cents it is probably around 85% a mini waterfall. Saying that the 80/20 rule means I agree with you!
Hi thanks for the comments.
So what you are saying is ultimately different, is that in a retrospective, some real change takes place, but in waterfall, change doesn’t take place.
So once again I see them as identical: In shops that I’ve come into, that have been doing Scrum for 6+ months, they don’t do anything about things raised in the retrospectives. The same thing has been going on from sprint to sprint, huge, obvious imediments are not addressed, and when I see that I hit the silk. There is no reason to think they will change in the future.
So, that kind of gets to my comment about “lip service” — the so called intangibles, which are in fact quite important, like “empowerment, change” etc don’t seem to happen, only the unimportant tangibles — like the daily scrum etc, happen with realistic likelihood that it will occur.
So, sure if the companies really were able to respond at the organizational level to things brought up in retrospectives, they would have done so already and thus wouldn’t need the methodology as a quick fix.
Using the methodology as a quick fix, they won’t (likely) make the changes brought up in the retrospectives, so what is the advantaged gained? Sure ideal companies don’t need the fix and the ones that do are non-ideal.
As far as “unnecessary” docs, I think a lot more docs are more necessary than are given much credence in the agile world. To wit, having things written down, with wireframes, means you can distribute that to N people and all of them will see the same picture.
With ad hoc verbal communication, everyone may have a different take on what it should look like, and, it takes considerable amount of time to propagate the same information.
Your thoughts?
Jordan
If your scrum retrospectives have not resulted in changes then your scrum master is at fault. Outcomes should either be revisted at the next retro (at the start) or preferably added as stories into the iteration.
As for your wireframe example – everyone should be in the same room for the conversation or if outside of a meeting the are collocated. Ideally the wireframe would be drawn on a whiteboard and discussed. A photo of the whiteboard would be taken and the age strored and catelogued in the project repository. I don’t call this documentation but you might, but it should be enough.
OK now, in the company in question, the SM was merely a line level dev. Even his manager could not resolve the impediments; even 2 levels up they were unable to.
So you blame the SM. What is it exactly the SM should have done in this situation? How does Scrum help other than blaming the parties for not being high enough up the ladder?
Also keep in mind the impediments were affecting ~100+ devs, which, obviously is beyond the control of a mere local scrum master. But Scrum promises that the SM can do anything right? So help me out here.
As per wireframe your reply seemed a little garbled but — what is wrong with PSD or powerpoint? Why does it need to be cell phone shots of a colocated whiteboard? I don’t understand this aversion to modern software.
Heard part of your podcast, at least the part about the umbrella drinks
Cheers!
Jordan
As always the written word is open to mis-interpretation, hence why a person by person discussion is needed. I think the reality is we are both agreeing with each other, but using different scenarios in our heads.
If your SM isn’t empowered to fix anything (ie the lower part of the organisation is agile but management is not) then you are pretty much screwed as an SM if it is outside of your control. But my point was the SM should be revisiting the retro items and making sure they are followed up. If 100+ devs were experiencing this then I am assuming 8+ SMs have exactly the same Retro item – sounds like a pretty powerful position to be in for a conversation starter to get resolution.
As for doco, I was merely saying documentation doesn’t have to be written and detailed. Yes ppt is good as well, but the quickest path for me is take a photo of the conversations from a whiteboard or a smartboard capture.
Well, that’s a popular way, but it’s the “fragile” and time consuming way in my book.
Oh well, not surprised we disagree about whether Scrum is any good or not.
You can read my post “Scrum as the new Command and Control” for my thoughts about devs becoming ersatz managers and designers etc.
Also I’m pretty sure the verbal word is more open to misinterpretation, especially when it’s not written down. That creates a toxic codependency where devs constantly have to ask each other or the PO basic things that could easily be looked up in a document.
It seems like a collective hand holding exercise more than an efficient and accoutable process; scrum claims to have accountability but in strict scrum nothing is ever written down so who can really prove what was said in a meeting? Documentation is not a four letter word
Jordan
Pingback: New PM Articles for the Week of November 21 – 27 « The Practicing IT Project Manager
Hi Jordan,
The title of your post is interesting, because this is how I perceive Scrum (I’m not a Scrummer by the way). It’s just an iterative approach that applies the regular waterfall model to each iteration (correct me if I’m wrong)…
In any case, I think your post is great, and I would like to republish it on PM Hut ( http://www.pmhut.com ). Please either email me or contact me through the “Contact Us” form on the PM Hut website in case you’re OK with this.
Just on paper with the steps outlined, one could agree they look the same, but with a shorter time scale. Yet, it is in that shorter time scale that things can improve. I’m not saying they “do” improve, just that they “can” improve.
Keeping in mind that over a long project cycle, things change: the market, the company, the team. The shorter time scale adapts to this. Just to name a couple: The product can be delivered with fewer features earlier if necessary. The team has a chance to remain consistent during several full cycles. It is unlikely the team will be consistent during an entire waterfall, much less after the waterfall and on to the next to apply what they learn in the retrospective at the end of a project.
If you only hold the retrospective at the end of a full waterfall, you can’t help the project you are on. But by holding it many times during a project it can help your current project which provides much more real value to those working on the project.
Sounds like you are basically agreeing with me. So why not call it “mini Waterfall” instead of Scrum? If all we are doing is changing the length of execution phases, that would be appropriate, and honest. Waterfall could use any project length. All Scrum does is change the project length and muddy the waters with orwellian newspeak.
Also, waterfall projects already were typically broken up into phases, which align closely with sprints. And they could postmortem after every phase. Once again, I see nothing new here, other than the neologisms and fanatical marketing practices.
Jordan
[edited]
Jordan — Bob, you completely missed the point that “mini waterfall” means one that is 1-4 weeks long. Please try again.
Maybe I’m a bad writer, but most people seem to have caught this. However, I will edit my original post for clarity to prevent confusion in the future.
Thanks,
Jordan
It’s not true to say that Scrum is a series of mini-waterfalls. The key difference is that in every Sprint the aim is to deliver a vertical slice of the system by cross-pollinating tasks like analysis, design, development and testing into a shared responsibility across the team. Other important differences are that the deliverable in each stage of Waterfall is a document, where in Scrum it is working software, and that Scrum doesn’t just iterate over a product it also “increments”, meaning it adds working features one by one. In Waterfall all features are defined up front and built.
In Waterfall the different elements of the SDLC are done one at a time and handed across once sign-off has occurred. Design cannot start until requirements have been analysed and documented. Development cannot start until design has been completed, documented and signed off. In Scrum every user story should encapsulate all elements of a vertical system slice to create a valuable, demonstrable function in software. So all parties work together in every Sprint. Thus a Sprint does not represent a stage in Waterfall because in Waterfall only one set of specialists is working on the project at a time.
Hi Neil
You seem to be saying the difference is that Scrum is “always” vertical slices and Waterfall is “horizontal.”
That isn’t true; as I mentioned at the top, either methodology can (and does) choose to go either vertical or horizontal.
True, “User stories” based shops tend to go more vertical, but that’s just a tendency.
What I’m mostly hearing is a caricture of waterfall — signoffs for every change and silos — never seen that in the real world any more than I’ve seen scrum masters that solve signficant impediments.
No red herrings please!
Waterfall shops can and do get going writing code etc before getting final signoffs on everything. It’s hard to believe that people really believe that everyone who doesnt do Scrum including before it existed did all the steps in the way that you describe them. It’s totally false, based on a disinformation campaign by scrummers and agile zealots (not saying you are one).
PS It’s going vertical across a user story in a single sprint — that causes the source code merge issues — think about it … or wait for the post on that subject
Jordan
If a Scrum team chooses to do horizontal slices it is not doing proper Scrum – it is impossible to deliver potentially shippable, end-to-end software if you are building in horizontal slices. All of the problems you highlight with Scrum are not failings of Scrum itself but failings of the implementation of Scrum. You are spot on about one thing though – the instances of people doing Scrum right seem to be extremely rare, unfortunately.
Scrum doesn’t work when it is implemented incorrectly, and the pain points you highlight are extremely common. However I personally have delivered successful projects using Scrum done properly and that is the reason I am a fan and know it works, not just because of the teachings of others or even empirical evidence (if it’s not my own experience then it is difficult to sing something’s virtues).
If you want to claim that about Scrum, that’s fine many people feel that way, but it is not true.
If you read the scrum guide, 2011 edition, there is nothing in it about user stories at all, let alone that they must be done vertically. It only talks about the backlog consisting of task items.
All I’m saying, is waterfall can do vertical slices if it chooses, especially if they go with phases and/or mini waterfalls, and realistically, most of them do go with phases.
If you have personally delivered projects that were a success (or even a failure) I invite you and everyone to post your report on my Scrum Success stories page or the Agile Scout Scrum Success story page or both.
Look forward to reading your field report!
In either case, if we’re talking about shorter time scales; that’s fine. Let’s talk about shorter time scales. You don’t need a scrum master or many of the other hokey things that the Scrum canon has welded to it to achieve that.
That’s what this post is all about; there are multiple paths to achieve a given outcome and noone has a monopoly on the truth.
Best,
Jordan
“That’s what this post is all about; there are multiple paths to achieve a given outcome and noone has a monopoly on the truth.”
I totally agree. I do tend to leap to Scrum’s defense however because I’ve seen so many bad implementations that call themselves Scrum (or don’t, but do Scrum-like activity), and it’s a shame that the methodology itself gets bagged because of this. At the end of the day, Scrum is an Agile framework and is not righteous in itself, or the only way to run a successful project, but the principles can lead to the higher purpose which is delivering business value as quickly as possible. In short, I do not like seeing Scrum being dismissed so readily.
With regards the ScrumMaster (and I agree it’s a kind of ridiculous name!), surely every project needs someone representing the business (the PO) and someone representing the team? Without a ScrumMaster type person, who will guide the team toward understanding and implementing agile principles (which are known and proven to deliver efficiency gains) and stop the business from meddling and reverting to old, inefficient practices like death marches, mythical man-month, heavy process and documentation, etc.?
Read the rest of my blog…I haven’t seen “too much” documentation in a decade…Another red herring. Too little? Sure. Too much? No.
You’re just offended I’m skewering a sacred cow. Sacred cows make the best burgers. Read the rest of my blog.
Ultimately the subjects that you are discussing I cover most succintly in http://jordanbortz.wordpress.com/2011/04/09/scrum-as-the-new-command-and-control/
Jordan
Pingback: Is Scrum just a series of Mini Waterfalls? | agile-development | Scoop.it
Pingback: Is Scrum just a series of Mini Waterfalls? | agile-development | Scoop.it
Pingback: Is Scrum just a series of Mini Waterfalls? | Agile in Dev Teams | Scoop.it
Pingback: Is Scrum just a series of Mini Waterfalls? | Innovatus | Scoop.it
I agree with your post.
Never the less, I think your sentence “in Waterfall, the design is known up front and doesn’t change during the execution stage,” is not correct
Just read the original paper where Waterfall was presented. There’s nothing like “design up-front and then never change it”.
See for example: http://arialdomartini.wordpress.com/2011/12/01/a-brand-new-iterative-and-analitic-agile-methodology-is-born-dont-miss-it/#thetruth
What I really meant up front is that the “requirements” are known up front, eg by design I meant “the overall design of WHAT it’s supposed to be” (a Facebook clone) not HOW you are going to design the code (MVC/SQL/NoSQL/etc).
However this is an obvious case of poor clarity on my part and I have edited it to requirements. Is that fine now? In either case, before the coding starts, in Scrum or Waterfall, the Requirements were finalized for that execution phase.
Jordan