Scrum Will Die

SCRUM WILL DIE

Now, don’t get me wrong here. I like Scrum. I think it is a good thing. I think it changed the way many organizations think about software development, but I also think it is not so good.

I remember when Scrum was first gaining traction. I thought to myself, is Scrum a fad? I knew Agile was around to stay because the amorphous thing that is Agile is a bundle of good practices that really make sense, but I often wondered about Scrum. I wondered if Scrum was over hyped by consultants trying to make money coaching people and trainers trying to make money training people to be certified ScrumMasters. I especially questioned it when I noticed that the only requirement of becoming a ScrumMaster was to breathe the air of a ScrumMaster trainer for two days. (I know there is a trivial test now.)

The failings of Scrum

Scrum addresses many problems of a development team, but it also tends to create problems. After being in Scrum environments for several years and talking to many other people in organizations doing Scrum, I’ve identified what I think are the main failings of Scrum.

Planning

Planning is a total waste of time. It provides no benefit to the bottom line. The supposed benefit of planning is to be able to identify how much work a team can do in a sprint and use those metrics to plan releases and schedules.

The concept seems solid. It seems to make sense, but the problem is we are devoting one day of a two week sprint to an activity that basically gathers metrics. That is a 10% overhead if your planning session doesn’t go over a single day. Essentially, planning’s primary purpose is to chart velocity and commit to some amount of work. Let’s break some of this down.

Velocity

Velocity is the amount of work a team can get done on average based on how much work they have been able to get done in the past. What comes out of planning is based on estimates teams give to backlog items during planning.

Again, seems like a solid concept, but here are some of the problems. First of all, estimation is almost always wrong. The only way to get a real accurate estimation is to talk about the backlog item until you have squeezed all the requirements out of it up front. And if you do that, then your planning will probably take two days.

Even if you manage to get accurate estimates, if your team is not stable and your sprint length is not stable it won’t really matter, because you will be taking the average out of something that itself is not stable.

Commitment

One central unspoken theme of Scrum is commitment. The team commits to get a certain amount of work done in a sprint. The business commits to not change the work the team is working on. These commitments are critical, because without them time boxing fails, velocity metrics fail, and trust is lost in both directions.

So, what is wrong with commitments? They cannot be followed. Everyone means well, at least I hope they do. The problem is, like a fat kid in a candy store, they just can’t help themselves. The business doesn’t want to change priorities, but a critical issue comes up. The development team wants to commit to the sprint, but the development team can’t make more code get done faster simply by wanting to. They can add more hours to the sprint, but then they are skewing the velocity. The only way the development team can realistically commit to the sprint is to ‘pad’, and that is a very bad word. Don’t ever say ‘pad’ in a development shop.

Tasking

I’ve tried to fight it. I have closed my eyes and said “NO! NO! NO! There is a proper way to do tasks without copying and pasting,” but it’s simply not true. I have tried many different techniques, have asked many other Scrum teams, but everyone essentially copy and pastes the same set of tasks. The problem is, you don’t know the tasks for most backlog items until you have had some kind of design session to decide how you are going to implement the solution. I just cannot see a way around that simple plain fact. So, what we end up doing is making up templates and tasks that are generic.

Product Ownership

Scrum says there should be one product owner. I agree with this point. In theory it works great. In practice it ends up putting a whole product’s life into the hands of one person. Which person? Well, if you make that person someone high up in the organization, they won’t be the product owner for the team, but rather the boss. The team will just do whatever the product owner says and stop being autonomous and self-managing. If you choose someone lower in the organization, you end up having someone who cannot make decisions, and now you have all these high up business people, who are basically worthless, trying to find ways to be worthwhile (which usually results in them abusing the poor product owner.) I like to call this the “product renter.”

Scrum Meetings

These seem like a really good idea on the surface level. As a ScrumMaster, I tried to make these work correctly. 15 minute stand up meetings, you say what you did, what you will do, and what’s impeding you. The problem is, if you are working together doing pair programming, and “swarming” on backlogs, you already know what is going on and you are just repeating some rhetoric. If you are not working together on backlogs and are working in isolation, 15 minutes is not enough time. So what ends up happening is you either have a 1 hour long meeting where everyone talks about technical details of issues they are having, or you have a 15 minutes meeting where everyone repeats the same stuff everyone already knows.

What next then?

I don’t think Scrum is particularly bad. I actually like Scrum and think it can be a great process for a team that can help them to learn to use Agile techniques and vertically slice the system instead of trying to horizontally slice it. The best parts of Scrum are really Agile. Scrum is kind of forcing you to be Agile and do things like creating user stories, test driven development, having always releasable code, etc.

So, why even use a process at all, or why not make our own? Rules and process are important because they keep us from arguing about how things should be done, and they keep us from wasting time reinventing the wheel. The trick is in having your process lightweight enough that it is not burdensome, but constraining enough that you can enforce good patterns and principles without having to argue about and debate them each time.

So my advice is to learn what you can from Scrum, but don’t think it is the “be all end all.” Scrum is a fad, it cannot last, at least not in the form it is now, because it has problems. But hold onto those Agile principles you learn from using Scrum; those principles will last much longer, if not indefinitely.

Related

kcchao

Planning is a total waste of time. …
Velocity
…First of all, estimation is almost always wrong….

Not only managers do planning, but also engineers need to do planning.
Besides coding, engineers need to estimate the time of their coding. If they don’t know, nobody know.

http://www.planetgeek.ch Urs Enzler

From my point of view, you’re completely wrong. I say this because what I read in this post shows me that you didn’t get to the heart of Scrum. You stick with what is written exemplary in books and not with what works for you.

Planning: planning is there in order for the developers to know what to build. That’s the main reason. Make your planning sessions shorter (estimating should be fast, don’t argue, does not have to be super-precise). Our panning meeting is about 3h for two week sprints.

Velocity: velocity is a very rough measurement. Therefore, you don’t have to squeeze out all requirements. Just say, this story is about the same amount as this from the last sprint, ket’s call it a 3. That’s good enough.

Committment: Yes, I agree, comittments are no good. But the team has to know how much work they are likely to complete in the next sprints. This simplifies looking ahead to get smoothly from one Sprint to the next.

Tasking: I really don’t get your point. Copy pasting? Don’t write tasks for things that are needed to get a story “done” (definition of done) like “write docu”, “test”. Write tasks that describe what the team has to build: “extend DB schema”, “add validations to XY”.

Product Ownership: Yes, this is the hardest part in Scrum. But if done right, provides immense advantages. If a company decides to switch to Scrum, the whole company has to change, not only the development. Otherwise “organzational gravity” kicks in and results in what you are describing.

Scrum Meetings: Do you hold retrospectives? If yes, why don’t you discuss, what you should change? If all team members know what all others do (although I thought that) there is still the part to coordinate the next 24h, who is pairing with whom, what the PO learned today from the customer, … If there is really nothing then skip it.

What next then? Kanban? Maybe. Just keep in mind that Scrum optimizes throughput (amount of work done in a time slot), Kanban optimizes cycle time (time needed to get a work item done). Make sure you know what you really want.

Wow, a long response.

Cheers,
Urs

http://simpleprogrammer.com jsonmez

From my point of view, you’re completely wrong. I say this because what I read in this post shows me that you didn’t get to the heart of Scrum. You stick with what is written exemplary in books and not with what works for you.

I both agree and disagree with you, but I think you prove my point with this one statement. When you say that I should use what works for me. You are saying that Scrum will die. You may not realize that is what you are saying, but you are suggesting modifying a process, because it doesn’t work as it is. Scrum is designed to be a lean process, if you change it or reduce it, you have fundamentally broken or discarded it. There really is no way around it. Ultimately, you are either doing Scrum or something else that is kind of like Scrum. I am not saying the something else that is kind of like Scrum will die, I am saying Scrum will die. I am saying the something else kinda like Scrum will evolve and become the next thing. Perhaps it is Kanban… I do not know.

As for planning and velocity. I have tried many approaches, and I agree with you that making the planning sessions shorter and making rough estimates is the way to go. The problem is that at that level of granularity the cost vs benefit value is not there. There is no point taking up all that time to ultimately produce something that is so high level that it is not measurable. I believe this can be successful is followed as you describe, but that requires non-change. What I mean by this is that if you can keep the business priorities unchanging for the sprint, you can keep the sprint lengths equal, and you can keep the team members the same, then you can get a useful thing out of planning and velocity. The problem is, as soon as one of these factors moves, the whole measurement is no good.

Again, on the tasking, I agree with you, but it just doesn’t work. I have tried time and time again to make the tasks be the things that the team needs to build. And this is fine with totally new code and features, but when you are looking at any part of legacy code, you do not know ahead of time what the next task will be. At any given point, I can tell you what the next task is, but I can not tell you what the task after that will be, because it is dependent on what I discover from doing the next task.

In summary, you say all the right things. And I have been on your side of the fence saying all those same things to people and to organizations. And if companies and people were to actually do all those things right and follow Scrum to the letter, they would achieve much better results. There are two fundamental problems though:

1. It won’t happen. If you had even 50% of organizations doing Scrum right, it would live, but I doubt it is even 10%, because I haven’t found one company doing it right yet.
2. Even with “perfect Scrum” there is waste. It is a good way of doing things, but it is not the best way. Because it is a process and not a set of principles, it must be perfect or it will be replaced by something better. Principles like agile are around to stay, processes like Scrum will wax and wane.

Thanks for you comments though. I am glad to hear someone saying the same thing I keep saying, although it is weird to argue against the point I am usually making.

http://www.planetgeek.ch Urs Enzler

I totally agree that most teams claiming doing Scrum, don’t do it at all.
But this is not the problem of the process.

Furthermore, Scrum is called a framework because you have to adapt it to your needs, there is no way around this. If you get no value out of defining tasks, then don’t do it. Maybe try spiking first and then define tasks.
I agree with you that Scrum is not best for maintaining software. Kanban may be a better choice for this activity.

I just want to say that switching to another agile process without getting rid of the root problems won’t help much. If you (or probably more your management) don’t have an agile mindset, then all these methodologies will sooner or later hit a wall.

Very interesting discussions here – thanks
Urs

http://twitter.com/ppetrovdotnet pip010

“Planning: planning is there in order for the developers to know what to build. That’s the main reason. ”

I’m going to guess that you raised all of these issues as impediments and management did nothing to support scrum in your organization?

that’s unfortunate.

What did you find actuallly works in your organization? managers just tell you when to commit by and how much work you ‘will’ do for them? then hammer you to work overtime if you slip dates?

http://simpleprogrammer.com jsonmez

Yeah, we have been through the whole process of impediments and talking about really doing Scrum. To me that is not the way to solve the problem. I have been doing Scrum for over 2 years and I have never seen any organization that is successfully doing a true Scrum development model. Sure there are plenty of people with powerpoints claiming to do Scrum, but to be honest most of them are lying. When you take a look at what they are actually doing, they are not doing Scrum.

I am pushing towards Kanban, with the client I am currently consulting for, because that is how they seem to want to run the process. The business wants priorities to be able to shift, and to not have to be time boxed.

What we are currently doing is ending sprints and re-planning to compensate for changes. As a result our capacity is smaller.

http://martinaspeli.net Martin Aspeli

You seem to dislike the parts of scrum which are trying to provide plans, commitments and metrics because they are imperfect by nature.

If you can get away without any of that, and just have your team work on a sprint-by-sprint basis, lucky you. You must have very trusting managers/clients with very generous budgets. I know I couldn’t get away without doing those things. At least Scrum provides some useful tools and language for producing plans and metrics, and is easier than most of the alternatives.

I think most Scrum advocates would agree with you that velocity, points-based estimates, prioritisation in the form of an ordered backlog etc are very coarse-grained tools. In fact, I think they’d claim that is a benefit. Plan enough to get something useful, and don’t try to substitute arbitrary precision just because getting high accuracy in planning is impossible.

I absolutely agree with you, though: following Scrum (or indeed any methodology) to the letter is silly. For me, Scrum is a toolbox that, along with other tools, I employ in designing a process for my teams. Scrum is a useful starting point because it’s so simple, but you need to build in additional controls or remove overheads where it makes sense. You also need to ensure you have feedback mechanisms so that you process can evolve over the scope of your project. Like software, we don’t always get the process right the first time.

Martin

http://simpleprogrammer.com jsonmez

It is true that I dislike the parts of scrum that are trying to provide plans and commitments and metrics, not because I dislike them those things, but because I don’t think they can actually really work unless you are following Scrum to the letter. In my organization I am one of the biggest advocates of “If we are doing Scrum, we are doing Scrum, not Scrum-but.” Yet, I still find that it is close to impossible to actually do Scrum. That is my point in why I think Scrum will die. I think the idea is good, but the practice is flawed.

You are right about coarse grained tools such as velocity and point based estimates. Yet, I have to ask, if this is the case, then how useful can they really be? In my mind they are now just taking up time which could be used to deliver the product.

I have to actually disagree with you on your last point though. If you are going to follow Scrum, follow Scrum exactly, no deviations. McDonalds is so successful, because they sell a process, not a burger. Good process eliminates debate and extraneous judgement calls. Ken Schwaber calls deviating from Scrum, “Scrum-but”, and he highly discourages it.

Thanks for you comments though, I do see your point.

http://twitter.com/ppetrovdotnet pip010

“…. then how useful can they really be? In my mind they are now just taking up time which could be used to deliver the product.”

that’s my main beef with processes and methodology.

http://simpleprogrammer.com jsonmez

Several people have been saying, you have to adapt scrum to make it work….

Also, I suspect he’s trying to stop people who want to be “Scrum in name only”. Unfortunately, “we’re agile” has sometimes become an excuse for programmers who don’t think they need any process at all. That usually goes very, very wrong. I’m sure Ken Schwaber is worried that “we’re doing Scrum” will become the same excuse. And yes, if you’re doing “Scrum-but”, you’re not doing Scrum, and you shouldn’t necessarily be able to use that label, which is trademarked and certified and all the rest of it. Perhaps that’s your point.

Meanwhile, back in the real world, no one process is a silver bullet. Would you use the same process to build the life support system in a spacecraft as you would a “Web 2.0″ social media service that you hope will be an overnight success? Of course not. Aspects like risk, budget, cost sensitivity, time-to-market sensitivity and many others mean that the two demand different processes.

Those are two extremes, but it’s not hard to see that these sorts of differences apply even to projects done within a given organisation. The challenge becomes that you can’t just train your managers on one process (sending them on that two-day course) and expect them to make good choices about how to adapt the process. If you have inexperienced managers, then telling them to follow a process to the letter is probably a good idea, and Scrum is not a bad one to follow. Training them on two or three company standards is probably an even better idea.

Once those managers have a few projects under their belts, I bet you they’ll start tweaking because they know that in the context where they work, those tweaks make sense. Forget about what anyone says about process X vs. process Y. Agile more than anything is about delivering value to the customer, not following some prescribed process at the expense of business value.

So back to Scrum: I find velocity, story-based estimates (the two go hand-in-hand) and per-iteration commitment useful tools. I tell my clients they’re about 20% wrong, but that this averages out. I also tell them the true cost if they want me to bring that error margin (both in estmates and tracking) down to, say, 5%. At that point, they normally agree that it’s better to move ahead with the highest priority items, especially since they’re normally a lot less sure they event want the lower-priority ones. That alone makes those tools useful to me. Highly imperfect, but highly useful.

By the way, one of my favourite books on the subject is Mike Cohn’s Agile Estimation and Planning. That’s not a Scrum book, really, but it covers the same ideas (story points, velocity, etc). I think it makes a very compelling case about why these techniques are useful.

http://simpleprogrammer.com jsonmez

You bring up some excellent points here. Thank you for making me think.

What you have made me realize, is what I am really addressing, which is that Scrum itself applied, preached and promoted to solve every software problem will die.

The points you bring up about different projects thriving better under difference processes is also very correct and an important statement. That is one of the reasons why I am leaning towards a lightweight framework, like Kanban + XP which talks about core values and a very light set of mandated process, then adding custom process and controls to fit the project.

One of the key problems right now is Scrum is being used as the silver bullet. Everyone is certified Scrum this and that. And people are lying saying it is working, when it is not working. The estimation point you bring up is also valid, but that 20% error margin is just usually not worth the trade-off of 10% of the sprint, and all the other time that goes to doing that kind of planning work (which may end being around 20% overhead.) I think this is a fundamental flaw in Scrum, which can not be easily resolved or dismissed. Again, I point to Kanban as a solution to this, although there are others, where the measurement is a natural part of the process not forced or subject to group think. Average time from start of queue to finish is accurate always, and requires no extra effort.

There is too much to be said on process and using hard fast rules to be said here. I want to address this in another post.

I will read the book you recommended. I am interested to take another look at planning and estimation.

Thanks again for all your comments, very much appreciated. You have some very good insights.

I like your post. Not that I agree with most of it – In fact, I disagree with quite a lot of what you’ve said.
But I do agree with the bottom line (or the title, in this case) : SCRUM will die.
However, it is not the death of Waterfall and other rigid or artefact-driven methodologies. These will die because they put little focus on people and a lot of focus on technical deliverables.

SCRUM will die and make way for an evolved framework, one that takes the agile values combined with the practicality and quick-start-liness of SCRUM, compared to other agile frameworks; Be it SCRUM-Ban or something else.

Note, that JIT, aka TPS, aka Toyota Production System, evolved between 1948 and 1975. It took 30 odd years for it to become what it is today, and its principles and values are being adopted in various other frameworks.

As you suggest in your piece, SCRUM per-se might die, but it will evolve into other agile software development frameworks.
Waterfall and the likes, however, are doomed to decline and ultimately disappear, much to the delight of enlightened business and technical people alike.

Great discussions (and perceptions, perhaps!) Here is mine.
My understanding of Scrum is that it is a project delivery methodology (okay, let me suppose we are in the context of software, so lets say software delivery methodology, though It was evolved at somewhere) rather than software “development” methodology. Software development has to be done in its own phases (requirement gathering to deployment) and not any other way. [I dont think we like to switch our focus of discussion to the phases of software development and their need]. Scrum sits over the SDLC as a delivery model. I think ALL that scrum talks of is the “delivery” model. Waterfall and like models focused mainly on the technical aspects of the project rather than “project management and delivery” and I think scrum is doing exactly the opposite, emphasizing ONLY on the “delivery” and never ever talks explicitly about the things that complements scrum. This is where the “assumptions and customizations bud”. Waterfall model did have an inherent delivery model.
I am not against scrum, It is good if everyone follows and to the letter.
As discussed by the author of this blog and many others who agree (or at least understand), Scrum is not a silver bullet. And scrum is not everything. Scrum is no different from iterative and incremental model. It does not state the change in the phases of development. But some “wasted time” is removed indirectly by being different in the fact that the shorter release cycles, regular communication, stake holders involvement is increased so the business “RISKS” are identified earlier etc etc. Scrum does SDLC inherently and underestimates technical aspects of it like the waterfall like models did for delivery. Scrum might die as per some of our understanding, or will evolve. We can’t predict the future but know the direction.

Scrum has benefits: faster delivery, evolved design artifacts, etc.
Scrum says follow simple process(es) and relies on “release early and release often principle which is good. It also says Don’t do anything that is not needed, may be design or a feature or detailed documentation when it is not used by anyone else; this is fantastic

My concern here is Scrum should not be an excuse. We should be using complementing tools/processes. And make the teams following Scrum aware of the fact that it is a delivery model and not a development model. Some other points are already discussed above by others in this post.

We are experiencing exactly the same problems at my company. Much might have to do with the company culture (or lack thereof). But I have the constant feeling that we are fighting to “conform” to Scrum, rather that it helping us be more productive.

Scrum is a highly viable software development methodology, and the teams implementing Scrum seldom experience failure. However, it would be wrong to assume that Scrum is a panacea for all sorts of problems and impediments surfacing during the development process. As a matter of fact, if the team implementing Scrum fails to deliver, Scrum is not to be blamed as a process by itself never goes wrong; instead, the shortcomings and flaws lie in the implementation of that methodology.

“As a matter of fact, if the team implementing Scrum fails to deliver, Scrum is not to be blamed as a process by itself never goes wrong;
instead, the shortcomings and flaws lie in the implementation of that methodology.”: You can say this of every methodology, so this statement contains very little information.

After I initially left a comment I appear
to have clicked the -Notify me when new comments are added- checkbox and now each time a comment is
added I get 4 emails with the same comment. Perhaps there is a
way you are able to remove me from that service? Kudos!

http://twitter.com/tobiasmayer Tobias Mayer (@tobiasmayer)

Provocative article (and very long discussion! I only took in parts). I’ve written extensively on the importance of understanding the underlying principles of Scrum, rather than focusing on the process. The principles are solid, and when an implementation rests on those—with people understanding them (!) then scrum will be successful. The essence of scrum of course is continual improvement, so to assume it is fixed, or for anyone to claim it is—even its inventer—is folly. How does one improve if one stays still?

By the way, I don’t see Kanban as an alternative to Scrum—neither does its inventor, from what I understand. Kanban in fact can be overlaid on top of any process, to help improve that process, or help it move into a better process, thus it can be overlaid on scrum. I’ve used it that way very successfully. I have also seen people use the “we’ll do kanban and not scrum now” approach as a cop out. Scrum raises issues, shows your organization’s dysfunctions (and your own). People don’t like that. They don’t want to look so they seek a way that they don’t have to. Enter “Kanban”. Be careful with that.

That is a really good tip especially to those new to the blogosphere.
Brief but very accurate information… Thank you for sharing
this one. A must read article!

devanand

As a software developer, when I came across scrum i said this only works for cheating people. people who finish their work and do not notify management that they finished so they can play chess in the computer before they are assigned another task. for serious developers this is useless. After coming across a manager mocking people in front of the group for making mistakes and mocking people for spending 3 days on something already planned for 4 (four) days. then I will bet by 2016 this will be gone

Gewthen

Perhaps these “cheating” people are not really cheating, but want to be involved at a higher level and are being denied that level of involvement? Sometimes people do not go to management for more work because they want to be the ones to decide what to do next, not just ask for more work with little insight into what they are doing. Many managers just give work and bark orders without explaining why.

http://www.facebook.com/yuhang.zhao.3 Yuhang Zhao

Here are my two cents:

One advantage of Scrum (and other agile methodologies) is that it makes an hopeless project to fail early and in an obvious way. In that sense, Scrum does not work on such projects. Unfortunately, a good portion of the projects fall into this category.

Sometimes we just cannot afford to allow certain project to fail (think about the budget debate in US Congress or the debates at the United Nation) no matter how bad they. Srum is not applicable in these cases.

http://www.facebook.com/budgie.mitchell Budgie Mitchell

I’m 40 years old and never needed scrum or SOLID principles in my life before, yet have always delivered quality code that works. Now when I apply for a job and say I never used these items I’m told “my knowledge appears to be lacking for the amount of years of experience I have” which makes me want to drive my large fist into the interviewer(s) face(s) . Despite the fact I was writing sprite routines in Z80 and 680×0 while these interviewers were learning their 10x table, because I don’t have the latest I’m no good. To these guys who adopt Agile because it’s the “in thing” and then dismiss those who never have used it, you are snobs and wankers. Don’t be disheartened guys.

jsonmez

You are correct, it is unfortunate that many newer developers will judge a person’s knowledge and skills level by their understanding of the new hot thing. There is truly nothing new under the sun, so a track record of delivering quality software is the most important thing to look for.
But, because our industry does change so fast and there is so much to learn, it is a significant competitive advantage to get experience and knowledge of things like Agile and SOLID.
I find myself always retooling my skills and someone like you that has a large amount of experience can probably pick up these concepts very quickly, since it is just another way of saying what you probably are already doing.

http://www.facebook.com/budgie.mitchell Budgie Mitchell

Hi J, the SOLID principles definitely are things I’ve seen before in various other guises. I’ve even been using some of them without even realising they were part of SOLID because my Resharper warns me so.

SCRUM reminds me of the methodology DSDM that I use in many ways, albeit with different terminology.

RE: Picking up tech, I will add one thing. it does amuse me that interviewers for a C# position gets snooty about OO principles with someone who hand coded asm with no modern IDEs or compiler safety nets or lint… using cassette as backup. I know how to pack a program into 64K, (or 640K haha) and as I said it insults me to be told my tech skills are lacking by some idiot with a mullet.

IMHO, this “dinosaur” here (apparently us over 40’s have the “smell of death about us” according to one agile article) is rejected because of his age and take-no-shit attitude (a product of age), not because he doesn’t know his stuff.

Andrew Finnell

Let’s say you were researching contracting companies to build your house. You have one company that has built luxury 3000-10000 SQ FT. homes with all the amenities. But, they’ve only been doing it for 10 years. Then you have another company that has been building Log Cabins for 30 years but has no experience with modern architectural designs or reinforcing struts for hurricanes. But they could build a log house with just a hacksaw and mud. nnnWho would you pick?

Andrew Finnell

This seems to indicate that some people haven’t actually research how Agile came about. The idea of doing things in short repetitive cycles is not a new fad. It wasn’t even invented by software developers. These concepts and ideas have been around for a long time.nnIf we are to analyze something like Traditional Waterfall we can see that people read the first page of the original proposal and decided to stop there. Companies a decade or two ago were full speed ahead with Waterfall, yet never implemented it according to the original author’s paper. For reference, the author discussed a discrete set of steps to produce a product. (i.e. Traditional Waterfall) and then proceeded to explain how this would NEVER work. He then adapter that process to include iterative processes into themselves such that the product and process itself improved over time. nnThe concepts behind Agile are not new nor a FAD. After financial backers have lost millions and millions year after year while investing in software development shops that continue to fail, new methodologies were proposed based on common wisdom and concepts that have existed for ages. nnAny issues with being hired probably has more to do with being closed minded and unable to adapt and evolve then it has to do with the idea of whether something is a FAD or not.

Hate SCRUM , hate hate hate hate hate , company hired vendors the build something I don’t have right to ask them questions and they walked away before testing , and who gets blame yes the guy left in company.

SCRUM also hides the voice of a person with experience , and people with less experience now do their part on their own , and turn out some real sloppy code and get away with it

SCRUM master is immune , he may botch the project and mess up assigning project functional goals and in end of it all he can walk away
gain laying blame on Few company employee developers, He does not facilitates the process of acquiring or sharing knowlege

When developers asks for documentation from vendors in scrum answer is oh they don’t produce the documentation , and this knowledge is lost so these vendors keep coming back for next cycle of project costing company more money

Daily standup are Total WASTE of time , we talk about what we will do , and this and that and then million meetings but in reality we have only 7-8 hours a day to work on items

They quality of work delivered is that it does not passes any Testing “real Testing” and these vendors harping about scrum keep using the terminology like parrot because the whole system is designed to make them immune to code reviews , or quality assurance

Only people who like it are Managers who think this process makes people productive , however in reality it makes them loose money by 200 iteration for something that can be done with 10 Cycles of Water fall because the quality of delivery in scrum is horrible

I am seriously puting it down on my monster resume NOT WILLING TO WORK WITH AGILE DON’T BOTHER CALLING ME IF ITS NOT TRADITIONAL software “engineering”

jsonmez

Now tell us how your really feel.
You have some good points.

ChiefYoungBlood

You motivated me to express all my inner demons to let my true feelings out for Scrum/Agile

Andrew Finnell

It seems your problem is with a company that did not implement Scrum properly. Perhaps this is the downfall of Scrum. I have yet to find a company that has properly implemented Scrum. There are also huge exceptions to the major tenants of Scrum that they have accepted. Then they blame the failure on Scrum when they didn’t even do Scrum to begin with. nnYour perspective of Scrum Masters is completely misguided. This tells me you were speaking to the wrong person or that team, again, did not implement Scrum properly. There are plenty of overseas companies that product sub-standard work. Whether they are using Scrum, XP, RUP or old-school Waterfall (Which is a misnomer anyways), it won’t stop companies from hiring cheap inexperienced oversea contractors. nnYou’re blaming a process that had nothing to do with the quality of work being produced. Look at the company itself.

ChiefYoungBlood

Scrum is evil , its means to have non technical folks be in influentual position.

When I see scrum masters , I only see confused folks who are not technical and they are trying to be technical and have no clue and yet they become the people responsible for directing the flow , and reporting
Scrum creates a GAP between when really is happening in project vs what managaement wants to see, we had a scrum master that kept reporting stuff good , when clearly overasea vendor were truning garbage code.

Another problem with scrum is that it breaks down functionality and we are told , the piece someone else is doing is not your concern , however later when project fails due to these ‘other’ pieces that were not our concern , it impacts deadlines and normally employee who is left in company has to do overnight shifts to fix the mess.

Scrum/Agile is sold to marketing groups or business people , as way to shorten development time , that is what the look for , however in reality
developers working remotely , may turn out crap code and then you would have to add 15 new , 2 week sprints to the mix , in order to move forward. Also the great scrum masters , are always wonderful to convertthese 15 new sprints back to 3 sprints to protect their hides when reporting goes to Uppper management.

And that RETROSPECTIVE , yep forget it after 1-2 weeks initial cycles that magical term goes away and you have no way of reporting the functional irregularities you are seeing by Scrum Masters , and overseas vendors that are suppose to be your scrum mates lol

In general I find that Scrum/ Agile works if you were lets say , working in kitchen and had sticky notes on wall for burger or sandwhich.
It is NOT engineering by anymeans. Infact it degrades the “Engineering” aspect of programming and turns it into McDonald’s food chain experience.

a) No Documentation
b) No Proper Quality in code / product , I mean would you release a financial application (HALF done???) really
c) Product oweners that don’t know difference between HTML and Stored procedure
d) Scrum Masters that pretend to be technical , however they are not they should not be in IT all together

The issue is really really compounded with Teams from overseas pretending to be your “TEAM” when they have their own agendas
knowledege share becomes a challenge with these groups working from overseas who retain the knowledge and Scrum helps them hide the knowledge in their companies and make the Parent company become dependent on their services
This results in Huge Financial losses to parent company in USA

I am part of one such project and seeing tremendous amout of money being wasted on monthly basis however they vendor keeps getting extension becasue we are SCRUMMING away … really we are scrumming away all the good stuff about Engineering under the carpet

Also here is the funny part , when the “McDonald’s” chain or SCRUM based code , goes thru QA process oh lord you know who gets to sit in those sessions yep you GUESED it … yours truely …..Only then …. WE DON’T HAVE A STICKY to stick it up the way

jsonmez

Wow. That’s a lot of thoughts on this. I have to say I agree with many of your points. I have seen Scrum be successful though, but more often than not it is exactly how you describe.

Bob Marshal

My team has been using Scrum for about two years now. It is good but I agree with most of this article. I started looking into Kanban about 8 months ago and we have started using it on a project has imposed deadlines, so doesn’t lend itself to Scrum, and it is working out well.

I just came across this and couldn’t help but respond. Almost all I can say is “haters are going to hate”. And complainers are going to complain. Am I being to harsh? Maybe but the above and most of below is total and utter BS. It’s developers complaining that just can’t just code the way they want to and the business be damned. Somebody call a Whinebulance!

You complain about estimates being wrong in Agile/Scrum so obviously you think they are accurate in Waterfall. But that is a total fallacy. And even if they were right you are then either telling the business to sit on their rear for the next year while you figure out how to create the system (and BTW make the customer/business ask for changes as painful as possible) or allow the changes and waste incredible amounts of time in Analysis and Design when those things change during coding. And we know they will change.

Agile, and Scrum, are not the simple mechanisms you all try and tear apart. They require thoughtfulness, expertise and great leadership to implement. Businesses run on great software and beating their competitors to the punch. Done the RIGHT way Agile gives companies the tools to do both, if you implement Agile and Scrum incorrectly then that’s your fault but don’t blame the process or the principles. Waterfall tells the Business to wait for a year and “maybe” they can see their software and most likely the software will be fragile as a result to Death Marches. What could be more anti-business.

I know what I am talking about as I was a Developer for 19 years and I still work closely with Development Teams.

In 2006 Steve Ballmer stood on the stage at a Microsoft conference and yelled “Developers, Developers, Developers!” until he was a sweaty mess and hoarse. Today, Businesses run more on “Customers, Customers, Customers!” I see you all are still living in 2006. Good luck with that.

CarmichaelPatriot

I’ve been a developer for almost 35 years and I’ve never met a project management methodology that added to the quality of the finished product nor the speed with which it was developed. Most just allow people who have minimal or no technological ability to feel like they’re involved in the development cycle. nWhat is required is quite simple;n1) Clearly defined requirements – Which almost never exist, since stakeholders can’t be bothered to put things down on paper.n2) Skilled developers – IT managers need to be more proactive about cleaning out the dead wood, since they just impede the artists.n3) Supportive management – IT managers need to provide their developers with the resources required to do their jobs. You wouldn’t ask a carpenter to build a house with a tack hammer and manual screwdriver, would you? Don’t ask developers to work on old, slow servers and desktops with minimal screens.n4) No distractions – scheduling developers to attend meetings cost more than just the time of the meeting itself. There’s the pre-meeting distraction, the meeting and the post-meeting distraction. Every time a developer steps away from what he/she is working on to do something else, it takes time to get back into the groove they were in before the interruption.nAll the project management in the world won’t build a product better or faster. Sorry, gurus.. You’re all wrong.

Andrew Finnell

I really like your #3 analogy. Somehow in the software world, developers expect someone else to provide them the tools they need. Contractors and Carpenters that work on houses bring their OWN tools to that project. I’m certain you didn’t mean to go down this road with that paragraph but I feel it holds true. Developers have somehow shirked the responsibility of having the proper tools to the companies they are working with instead of being self-sufficient. nnnnCarpenter’s don’t go to contracts empty handed and expect the customer/manager to provide them with what they need. Yet developers do just that.

It’s disheartening to see so many people misinterpret Scrum or blame Scrum on an invalid implementation. Most of these companies that are causing people to hate Scrum have implemented it’s methodology in name only. You’ll see companies call things the Backlog, Sprint Planning or Scum Masters but implement them in a way that is more traditional Waterfall. Or worse, they’ll use these ideas to hide poor work.nnnThe major tenants of Scrum is to be more open and provide more communication. If you are having long Sprint Planning meetings and you aren’t able to properly Point Stories because their requirements are too vast then the Stories aren’t properly broken down. nnnnThe idea of a single Story is to be small and produce a discrete single solution to a Story. It’s very easy to make Stories into huge Features, but this is not the right way to implement Scrum. You may have seen a Story that deals with User Authentication: “The User needs to Log In to the System.” This ‘sounds’ good in theory but is more aligned with an Epic. That Story isn’t able to be completed in Scrum. It isn’t defined well enough and provides no value. Yet, these types of Stories exist everywhere.nnnThen you’ll have Sprints that are always interrupted because of the latest Bug, Fire or Change of Mind by the ‘Customer.’ This is also a huge misguided implementation of Scrum. If you allow Sprints to be changed during the middle, you should not be doing Scrum. That single action completely breaks the idea of Scrum and will produce poor results.nnnA Scrum Master is a coordinator, team captain, and protector. They are not the Project Manager. If you need a Project Manager then hire one or learn how to get the information you need from the Product Owner and Stakeholders. nnnnAs for poor untested code, that seems to be a problem of the Product Owner and Stakeholders. If you hire an outside Consulting firm they shouldn’t fill the roll of Product Owner. At the end of each Sprint should be a working, releasable product. Perhaps the product doesn’t have enough features to be useful to a customer, but it should _work_. If the Product Owner accepts that work, then you’re telling the Consulting firm they did everything right. You should know in a single Sprint whether the consulting firm can produce or not. If your Sprints are two weeks, then you’ll know in two weeks. That isn’t a long time to go without knowing what the Consultants are doing.nnnThe comments on this blog are symptomatic of poor managers and leaders. SCRUM cannot fix poor leadership, poor choices in Consulting firms, and poor project management. To blame SCRUM is to blame yourself.

jsonmez

I agree with you 100%, but that is exactly why Scrum doesn’t worku2014in most cases. When it is executed well, it works great, but very few teams execute it well.nOf course, even when you do it right, there are still issues, like the ones I mention in this post. But, in general, yes, you are right.

http://www.thinslices.com/ Emanuel Martonca

As with everything in life, the SCRUM principles should be taken with a grain of salt. While it is true that proper planning within an organisation does not necessarily depend on SCRUM or Kanban, it nevertheless facilitates much of the work that would otherwise have been very hard to manage.nnWe are a mobile development company and have been struggling for years to find the best setting for developers, designer, project manager and product owner altogether. Now that weu2019ve used SCRUM for more than 5 years, we know that there simply isnu2019t another way to make things work. Especially in the case of startups.