A Criticism of Scrum

So Scrum. The most popular agile software development methodology, with seemingly around 70% of agile teams using it. What is it all about? Is it good or is it whack? Has Scrum made our lives better? Let’s dive in.

I don't often make methodologies, but when I do, I use the impossible as their foundational premise.


Scrum assumes you can reliably estimate task duration

Scrum has good intentions. Measuring your productivity. Accountability to not do more or less than we agree to do upfront. Increasing visibility for stakeholders. Communication as a team to help each other perform better. The problem is that Scrum’s methods for pursuing these things are not well suited to the act of building software. The first issue I have with Scrum is that the entire system is built around the assumption that you can reasonably estimate how long software development tasks are going to take. Unfortunately, this is extremely difficult, primarily due to 3 things:

  1. Hidden complexity. Unless you’re doing something you’ve done before, using the exact same tools and the exact same techniques, it is difficult to know how complicated a given task will be. Today’s tools and techniques change so rapidly that you’re almost never doing things the exact same way. And thus, one problem that looks menacing takes 30 minutes to fix; another problem that seems simple takes 3 days.
  2. Inconsistent overhead. Every week, customer crises, bugs that made it past your tests, issues with your libraries that demand you fork and fix, a necessary refactoring uncovered by a feature requirement, and a thousand other “things that come up” occupy our time. These cannot be planned for or anticipated, and they inject a regular but inconsistent amount of overhead that takes us away from executing the plan.
  3. Distractions that affect you differently. If you’re a developer, you operate in 2 primary modes: Flow and Stuckness. If you’re in a state of Flow (more on this later), you know what you must do and you’re getting it done rapidly. But the smallest of distractions can bring the whole thing to a screeching halt. Distractions are a bad thing when you’re in Flow. But if you’re in a state of Stuckness, you don’t know what’s wrong, and you use the Scientific Method until you solve the problem. John Cowan says, “Stuckness cannot be overcome by will or planning, only by insight, and the arrival of insight is not predictable. Striving for insight can often be what prevents it from being achieved. The motto ‘Sleep on it’ reflects the perception that blocking the conscious mind can be just the right thing to allow the unconscious mind to operate, often giving the key to the problem as if from nowhere. Distraction is an equally successful approach. During times of stuckness, therefore, interruptions are actually desirable, as they allow this useful distraction.” Since distraction affects developers differently, depending on which mode we are operating in, we cannot know whether the inevitable distractions this week will be a great help, or a great hindrance to us getting work done.

These 3 things destroy the elegance of Scrum, by making it very difficult to estimate how long work will take.

If you could just tell me how long your work will take, that would be great.

Not only that, Scrum assumes that you can estimate how long other people’s tasks are going to take! Planning poker assumes that every member of the team can have a reasonable idea of how long everyone else’s tasks on other parts of the system will take. And since Scrum advocates cross-functional teams, this means that a QA person is estimating how long a developer’s job is going to take. This means that a developer is estimating how long a designer’s job is going to take. This is totally unrealistic.

if you could just tell me how long my work will take, that would be great too.

Now, some people will be quick to point out – we don’t measure Scrum tasks by time, we measure them by complexity, or effort, or points, or something else. Unfortunately, this is just a pretty little wrapper that cleverly tries to pacify developers who say that programming estimates are inaccurate, and to satisfy project managers who still want estimates. Because even if you use this wrapper, Scrum still demands that you declare how much work you’re going to do in this sprint – in this fixed time iteration. Scrum wants you to repeatedly answer the question, “Given a certain number of workers and a fixed amount of time, how much work can we do?” By definition, this equation requires you to – implicitly or explicitly – estimate how long each work task is going to take. So, any way you spin it, Scrum assumes you can reliably estimate task duration.

For the reasons listed above, I reject the assumption that you can reliably estimate how long your own tasks are going to take, much less everyone else’s.

One does not simply estimate how long something will take to program.

Some people say that you have to estimate how long things will take for your clients’ sake. Well, I think estimates are wrong more often than they are right, so deadlines and dates tend to be inaccurate in our line of work. Making a habit of estimating things means that you often miss your estimates, and this cultivates a slippery slope that results in either client distrust due to things taking longer than originally expected, or decrease in craftsmanship as you are tempted to “just get it done” because you are trying to meet your estimate even though you know the next guy who touches that code is going to have a bad time.

I should call a meeting.


Scrum works great for people who don’t code

Scrum fits nicely into the manager’s schedule, but not the maker’s schedule. Paul Graham coined the term in his classic piece about the difference between managers and makers in regards to time management.

One reason programmers dislike meetings so much is that they’re on a different type of schedule from other people. Meetings cost them more.

There are two types of schedule, which I’ll call the manager’s schedule and the maker’s schedule. The manager’s schedule is for bosses. It’s embodied in the traditional appointment book, with each day cut into one hour intervals. You can block off several hours for a single task if you need to, but by default you change what you’re doing every hour.

When you use time that way, it’s merely a practical problem to meet with someone. Find an open slot in your schedule, book them, and you’re done.

Most powerful people are on the manager’s schedule. It’s the schedule of command. But there’s another way of using time that’s common among people who make things, like programmers and writers. They generally prefer to use time in units of half a day at least. You can’t write or program well in units of an hour. That’s barely enough time to get started.

When you’re operating on the maker’s schedule, meetings are a disaster. A single meeting can blow a whole afternoon, by breaking it into two pieces each too small to do anything hard in… For someone on the maker’s schedule, having a meeting is like throwing an exception. It doesn’t merely cause you to switch from one task to another; it changes the mode in which you work. I find one meeting can sometimes affect a whole day. A meeting commonly blows at least half a day, by breaking up a morning or afternoon…

If you’re a maker, don’t your spirits rise at the thought of having an entire day free to work, with no appointments at all? Well, that means your spirits are correspondingly depressed when you don’t. And ambitious projects are by definition close to the limits of your capacity. A small decrease in morale is enough to kill them off.

I don’t think meetings are evil, but they are very costly, particularly to makers. Most businesses and software teams need to have occasional meetings for various things, but Scrum prescribes even more, which exacerbates this issue. Between daily standup’s, sprint planning, sprint review, sprint retro, daily check-in’s, backlog grooming, product demos, company meetings, and technical trainings, its easy to have enough meetings each week to keep your makers in a perpetual state of meeting hangover.

They want me to sit in meetings for like 4 hours - ain't nobody got time for that


Meetings disrupt flow

Okay, so lots of meetings aren’t a good fit for the maker’s schedule, but why is that? Its because meetings disrupt Flow. Mihaly Csikszentmihalyi, the foremost psychologist on the topic of Flow, asks the question, “What contributes to a life worth living?”

He points out that more money doesn’t make us as humans happier. While the average inflation-adjusted income in the U.S. more than doubled over the last half of the twentieth century, self-reported happiness did not increase at all.

While the average inflation-adjusted income in the U.S. has more than doubled over the past half century, self-reported happiness has not.
Income data from the U.S. Commerce Department, Bureau of the Census (1975), and Economic Indicators, Happiness data from General Social Surveys, National Opinion Research Center, University of Chicago.

The concept of Flow is that we feel happier and more fulfilled in life when we can regularly lose ourselves in an activity we have spent years mastering.

Flow happens at the intersection of tasks that are highly challenging which occur in areas that we are highly skilled.
Flow can only happen when we are doing tasks that are highly challenging, in areas that we are highly skilled.

For software developers, this happens when they apply years of experience to a difficult task, and they are so absorbed in creating something that they don’t have enough attention left over to monitor their five senses, or think about the problems in their life, or realize that they’re hungry or tired. It is an ecstatic, literally out-of-body experience. This is where real work gets done and where developers feel most engaged and satisfied in their work.

Getting into Flow is like falling asleep. Its nearly impossible to will it into existence – it takes time, and the smallest little thing can throw it off and restart the whole process. Meetings and interruptions are the primary enemies of Flow in the workplace, so businesses that employ creative people must make a regular effort to keep disruptions to Flow at a minimum.

What if I told you Scrum spends all its time measuring things that don't matter


Scrum measures the wrong things

Techniques like burn down charts and planning poker put the focus on your ability to accurately estimate task duration, not your ability to create software that is delightful to use, meets your users’ needs, keeps technical debt to a minimum, can be quickly and easily modified, has a small number of bugs, and doesn’t require a small army of human QA testers manually running regression tests every time you want to push out a release. These are the things software teams should invest their time measuring, but unfortunately, far too many teams spend massive amounts of time and money just trying to measure their ability to guess how long work will take.

I'm not saying measuring stuff made us slower, but measuring stuff made us slower.


Measuring performance changes it in a fundamental way

Scrum has a fascination preoccupation with measuring performance. Ironically, by trying to measure velocity, velocity slows down! You see, this thing called the Observer effect throws a wrench in the matter.

In science, the term observer effect refers to changes that the act of observation will make on a phenomenon being observed. This is often the result of instruments that, by necessity, alter the state of what they measure in some manner. A commonplace example is checking the pressure in an automobile tire; this is difficult to do without letting out some of the air, thus changing the pressure.

Its the same way with Scrum – when you try to measure velocity, you change it in a significant way. This is because performance is usually measured by adding meetings and processes, activities that inherently take workers away from the job at hand. This generally looks like making cards for work tasks that come up, taking screenshots, talking about it in standup, including it in end-of-day e-mails, talking about it in sprint meetings, etc. You must understand that these activities can easily take 30-90 minutes of their time each day. Recording the work they are doing means that they get significantly less work done.

Meetings, meetings everywhere

There is generally an inverse relationship between visibility and speed. The more visibility that you want, the more hoops employees must jump through, and this additional process affects their time, morale, and momentum.

Now I’m not saying that all measuring is bad – a little bit of measurement and celebration can actually help morale – you know, progress begets progress – but it doesn’t take much before you start seeing a significant negative effect. I think Scrum’s techniques to quantify performance might work well in an environment sown with distrust: for example, an offshoring project using cheap, untested contractors. Product Owners and Managers want to know exactly what their people are doing so they can measure their performance. A lack of trust always slows things down.

This trade-off is acceptable when you need to make processes to protect yourself. But, in an environment where you trust your people and your employees are intelligent, disciplined, and have good character, measuring performance through a heavyweight process of meetings and metrics is unnecessary and self-defeating.

Organizations like the military focus on taking recruits who are very young, have no experience doing their job, and may not have a lot of discipline. But they forge them into valuable team members by placing them in a hyper-structured environment. Scrum is like this. But I don’t think the average software team is like the average group of recruits at basic training. You should hire great people, and then get out of their way and let them be awesome. Focus your efforts on hiring great people, not micro-managing them.

I like what the Agile Manifesto says – “Projects are built around motivated individuals, who should be trusted”. Either way, here’s the takeaway: Next time you propose another thing that will help you quantify stuff, just remember that in general, the more visibility you demand, the longer it will take things to get done. Ask yourself, “Am I more interested in moving fast, or in knowing how fast I am moving?”

You think Scrum is your ally, but it will break you.


Scrum addicts you, then destroys your productivity

Scrum meetings are unusually addictive. I have heard something like this numerous times:

Dev 1: “I want to talk to everyone about problems we’re having. As you can see from the burndown chart, we’re not accounting for unexpected issues that come up each week. Yet again, we’re aren’t going to meet our sprint goals.”

Dev 2: “What can we do to address our failure?”

Dev 1: “I think we need to start having daily check-in’s around mid-day in addition to our morning standups so we can ask everyone if their individual sprint goals are still realistic.”

Dev 2: “That sounds like a great idea. Maybe we can remove issues if that’s really necessary.”

Dev 1: “Yeah. I mean its been X amount of time since we started Scrum, and we *still* haven’t figured out how to do it right!”

People start having meetings because they think meetings will make them more efficient. And sometimes meetings do help you talk about important things and improve how you do business. But meetings are a slippery slope, because the more that you have them, the less time you have to get things done. And what is Scrum’s answer for not getting enough things done? More meetings and processes! When you get in this situation, people are bewildered at why they keep failing to meet their Scrum goals, they are burned out by their repeated failures, and morale suffers.

Bikeshed all the things!


Bikeshedding

Another problem with Scrum is that it introduces a thousand little things for you to bikeshed about, rather than solving the hard problems of software development.

“Parkinson’s Law of Triviality shows that a committee whose job was to approve plans for a nuclear power plant spent the majority of its time on discussions about relatively trivial and unimportant but easy-to-grasp issues, such as what materials to use for the staff bike-shed, while neglecting the non-trivial proposed design of the nuclear power plant itself, which is far more important but also a far more difficult and complex task to criticize constructively.”

Software development, like building a nuclear power plant, is hard. Unfortunately, Scrum introduces numerous trivial things into the process of creating software – things that are easy to have an opinion on – and it prescribes lots of time to talk about them in large groups. This naturally results in bikeshedding. Instead of spending time talking about how to level up our engineering game (which is a lot more complicated, thus a lot fewer people are eager to wager their opinion on) inordinate amounts of time are spent talking about how to do Scrum.

We don't have time to write tests or pay off technical debt, but we spend 12 hours a sprint in meetings.


Scrum strains the relationship between management and developers

Robert C. Martin, one of the original authors of the Agile Manifesto, gives this verbal history lesson about Scrum. What follows is a typed version of the highlights. Any errors are mine.

It was the year 1999. The world was dominated by waterfall. There were a few papers about strange things called Scrum, by Ken Schwaber. It caught a little attention, but not much. Then Kent Beck came out with another weird thing called eXtreme Programming… Kent had a vision – a vision to heal the damage between business and development. With just the right disciplines, and just the right minimal process, trust could develop between developers and the business. The business would begin to trust the developers, instead of thinking they were lazy, venal, nasty creatures, and the developers would begin to look at the business, and realize they were reasonable, rational beings, not from some other planet.

When [the three of us, along with many others] created the Agile Manifesto in 2001, Kent Beck reiterated his vision to heal the divide between business and development. Kent created the website, and we were stunned when thousands upon thousands people signed this website. So we decided to form an organization – the Agile Alliance. I was the first chairman of this organization. The next chairman was Ken Schwaber. He decided he wanted to do something else. He wanted to make the alliance a revenue making machine…

Ken came to me some time later, telling me he was going to make a class called Certified Scrum Master Class. I thought it was a dumb idea. But a dumb idea that works is not a dumb idea. People came and liked it. The more he charged, the more people came. He started giving out certificates, and he made a little organization off to the side – the Scrum Alliance. Lovely thing to happen.

Who do you think was taking these courses? Was it developers? No. See, I was a developer, and I thought it was stupid. All the developers you talked to thought it was stupid. So who was it that was taking these courses? Project Managers. They didn’t think it was stupid at all, they’ve been doing this thing for years. These project managers started to line up for these courses, and the amount of money that was gathered from that was truly astounding.

This had the effect of legitimizing Agile. Without that Certified Scrum Master course, Agile would be nothing. That caused Agile to cross the chasm and go mainstream. But the problem was that it was not developers that were taking the course – it was Project Managers.

Initially, a Scrum Master was a coach – not a manager. They were responsible for defending the process, but nothing else. He did not defend the schedule, the budget, the backlog, the stories – he only defended the process, and the role was supposed to rotate between the team members. The idea of the role was to slowly kindof fade away so that in the end you wouldn’t need a Scrum Master. I don’t think the Project Managers who took the Scrum Master course liked that particular interpretation. I think they wanted to be Scrum Masters!

So it turned out that businesses got the idea that the critical element in making a Scrum team successful was to pick the right Scrum Manager. Notice how similar this was to pick the right Project Manager. It maps very nicely. And the Scrum Master who did a really good job could stand at the end and say, “My team succeeded!” Who would get the glory and success? The team would stand behind the glorious Scrum Master! (Poses for triumphant effect)

The team would stand behind the glorious Scrum Master!

That was not supposed to be the way. Do you think that helped to heal the divide between development and business? Noooooo, no it helped to worsen the separation between business and development…

Scrum makes you go fast – so does any Agile method – because every couple weeks, you’re delivering something. Can you imagine how foreign that was in 1999? People started getting stuff done very very fast. Scrum teams, when you tell them to deliver every two weeks, they will deliver every two weeks. They won’t deliver everything they promised, but they will deliver something, and stuff will get done. They can move very very fast at first. But, something happens.

What was it that was not taught in the certified Scrum Master course? Software development practices. All that stuff that was in XP – all that stuff about pair programming, simple design, refactoring, test-driven development – that was all in there for a reason. Because when you are going fast – and you can go fast – you need something that keeps you clean. You need something that keeps the code from rotting. When you go fast, and you are focusing on getting stories done, and stories done, and stories done, the code can rot just as fast as you are moving. So what happens after a year is that the rate begins to slow… Martin Fowler coined a term – Flaccid Scrum – to describe Scrum used without any technical principles.

There came an us vs. them attitude – developers vs. project managers. It got to the point that if you went to an Agile Conference, there would be 90 talks about project management techniques, and no talks about development techniques. Or one. Or two. There was a huge bias in favor of the project management techniques. And the developers who had spawned this process now felt left out, they felt disenfranchised, they started thinking, “This has gone off to a bunch of guys who are getting pieces of paper for spending a lot of money to go to a 3 day class while the rest of us, who have been busting our butts making these Scrum projects work, are getting jack out of it. Kent’s vision had failed. The divide between business and development, had re-opened. And it had re-opened right in our midst, right in the midst of the Agile community itself, manifested by the Agile Conference, Kent’s vision of a healing of that divide had been torn apart.

What happens to a Scrum team as it begins to slow down? Velocity starts to go down. What does the business do? What does the Scrum Master do? “Guys, you keep your velocity up.” “Guys, you gotta keep getting stories done.” “Guys, we’re letting the business down.” Notice this pile of guilt that starts to grow on top of the developers, and notice who is not bearing it. The Scrum Master who is saying to the guys, “We gotta go faster.” Is actually saying, “Guys, you gotta go faster.” The team starts to falter, there are factions that grow in the team, and people start to leave in disgust, and eventually, if that’s allowed to continue, the team will go back to doing waterfall, because at least in waterfall, you have these long periods of rest.

What Scrum forget was that you cannot have speed without quality. You cannot have speed while you are carrying technical debt. And the more technical debt you will carry, the slower you will go. And this is a horrible wicked circle, because the slower you go, the more technical debt you will acquire.

Because of this, another movement was born – the Software Craftsmanship movement. This is an evidence of a split in the community. A group of us felt it was necessary to re-assert the values of eXtreme Programming into this world that was now dominated by Project Manager Scrum Master Scrum. We hope that is a reawakening of Kent’s vision. I’m not sure there is any evidence to this effect.

Today, many people are doing Scrum. Few people are doing TDD.

I would go one step farther than what Robert C. Martin says, and assert that perhaps one reason that many teams doing Scrum are not using good software practices is because they simply don’t have enough time due to the heavyweight overhead of Scrum. All businesses have to spend a lot of time building new features and fixing bugs. To use an analogy from Stephen Covey, those are the things that are both urgent and important. But the things that are important but are not urgent are the things that you really have to make an effort to do, because they tend to slip through the cracks. And these are the sorts of things that might really hurt you one day because you never got around to doing them. In the world of software, these are: writing tests, refactoring, paying off technical debt, security measures, pair programming, and mentoring. I think its very easy for Scrum to suck up all the time that you would have spent doing these things, and instead, spend it in meetings.

What if I charged people money so they could charge people money?


Scrum Monetized the Agile Movement

It has been said, “Scrum is like your mother-in-law, it’s constantly pointing out your shortcomings.” My response is that when someone tells you there is something wrong with your life, the first question you should ask is, “Are you trying to sell me something?” And the answer for Scrum is, yes. Turns out, the Scrum Alliance has made big money piggybacking on the Agile software movement, training and certifying people, who in turn charge expensive training and consulting fees. Don’t believe me?

Want to become a Certified Scrum Professional? That will be $250, please.
(Don’t forget to pay us $25 / year after that)

Want to become a Certified Scrum Master? That will be $1250, please.
(This one is $25 / year too)

Want to become a Certified Scrum Product Owner? That will be $1395, please.
(Don’t forget, it is $25 / year after that)

Tired of paying money into the Scrum ecosystem, and ready to get in on the action yourself? Just become a Certified Scrum Trainer! That will be $5000 / year, please.
(You’d better start bringing folks into the fold, or else you won’t make any money this year!)

So, the Scrum Alliance is a non-profit whose task is to help keep the Scrum economy alive for those who pay homage to it. Is that evil? Of course not. Capitalism and profit are great things. I’m sure that Scrum has helped many businesses and individuals do well in various regards. And there were people making money off Agile with book sales and the occasional conference before Scrum came around. But Scrum took it to a whole new level, and in so doing, they created evangelists who stood to profit by spreading the message of Scrum. Many people who now advocate Scrum have skin in the game – in addition to wanting you to succeed, they stand to benefit financially. So you should know that many of those bloggers, online commenters, book authors, and consultants who promote Scrum are not just teachers, they are also salesmen.

Furthermore, many of the people who advocate Scrum are non-technical – they may have never been a developer or practiced any other modern software development methodology because its not their job to write code. Many of them are project managers. So they may be salesmen who do not understand the alternatives to what they’re selling, or how their product affects people because the people using their product are different from them. So just keep that in mind as well.

Scrum is cool, but it costs us $84,000 a year.


Count the cost

Even if you don’t hire any Scrum consultants, or go to any Scrum trainings, Scrum will cost your team a lot of money. How? Because Scrum requires your team to spend a lot of time measuring work and talking about work instead of actually doing work. Let’s assume an 8-person team spends 12 hours in meetings and these sorts of activities every 2-week sprint. (It is very easy to spend this much time between stand-ups, sprint planning meeting with planning poker, backlog grooming, updating burn-down charts, sprint review, sprint retro, and demos.) So this means they spent 96 man-hours every sprint doing this stuff. We’ll say these folks are paid hourly, and the average pay on the team is $35 per hour (about $70,000 / year). That means that every sprint, the team spent $3,360 on Scrum activities. If there are 50 working weeks in a year, that gives us 25 2-week sprints.

$3,360 × 25 sprints = $84,000 a year per team doing Scrum.

If this team stopped doing Scrum, they could get the same amount of work done, send everyone home an hour early every day, hire another full-time engineer, and spend over $10,000 on an annual team retreat!

Paying a team of engineers copious amounts of money to spend 20% of their time in meetings seems like throwing money away, but that's none of my business.


Scrum is especially bad for part-time workers

12 hours of meetings per sprint may be okay for someone who is working on your project 40 hours a week, but for someone who only works on your project 25-30 hours per week, that same amount of meetings means a lot more overhead. In the first case, meetings are taking up 15% of a person’s time each week. But in the second case, meetings are taking up almost 25% of a person’s week.


Scrum says remote working is a no-no

A core tenet of Scrum is that teams be colocated and work in a shared workspace. I disagree with this. I believe DHH is right when he says that remote working is the future, and that working from home has countless benefits for the individual, the company, the local community, and the family unit – benefits that far outweigh the drawbacks. Whether its being able to hire top-notch talent that is not available in your city, reducing city traffic, allowing employees to travel and live anywhere, allowing parents to work from home and be around their family, or any of the other benefits of remote-working, I think its a trade-off worth taking.

Granted, the Agile Manifesto says, “Face-to-face conversation is the best form of communication”, but that is not as strong as saying that you must be colocated. Modern tools have largely mitigated the drawbacks of a remote team – we can have face-to-face video conversations, track our work in real-time on a digital task board, and pair program with low latency.

So let me get this straight, SCRUM is a methodology for software development, but it doesn't talk about code?


Wait, you don’t talk about what?

Scrum doesn’t talk about engineering. It is a methodology for software development, but it doesn’t talk about coding practices. At all. That is deeply troubling.

Scrum teaches Project Managers that they can be a great leader of a software development team without knowing anything about software development. This is an idea I strongly oppose. How can a general direct his troops effectively if he has never held a rifle, ridden with the cavalry, or been shot at? He can’t. Sure, anyone with power and people under them is a leader. Anyone can tell other people what to do. But that’s not great leadership. And that doesn’t mean that they’re going to lead their team effectively.

When team leaders don’t know how to code, they cannot lead by example. Since they cannot help create software assets, their job becomes to create company status updates. So, they naturally create processes to constantly monitor those people who do create software assets, thus the heavy Scrum emphasis on estimating and tracking progress.

A methodology like Extreme Programming also emphasizes spending a lot of time together, but instead of saying that you should spend that time in meetings to measure progress, it advocates spending that time getting real work done, pair programming, creating business assets, learning from each other’s technical knowledge, leveling up together, refactoring, writing tests, etc.

Yo dawg, I heard you like talking about what you're working on, so we made four ways to track our progress so you can talk about what you're working on while you talk about what you're working on.


Scrum encourages inefficiency and duplication of effort.

Because of its heavy emphasis on talking about what you’re doing rather than just doing it, it is very easy for you to talk about the same thing multiple times. I’ve worked on teams where they felt like they needed a start of day e-mail (where they committed to what they were going to do for the day), a mid-day standup (where they talked about what they did yesterday and what they planned to do today), and an end of day e-mail (where they talked about what they got done today and what they didn’t get done). Add to this your iteration planning meeting and your iteration retrospective, and its easy to see that there is a lot of duplication of effort going on.

I worked on another team that had a digital task management board, daily morning standup’s, end of day e-mails, and a physical post-it-note whiteboard. We were tracking work in 4 places, and we were doing our iteration planning meetings and iteration retrospective meetings.

Although many Scrum teams aren’t this ridiculous, some are pretty close when you stop to think about it. And this doesn’t just waste time. When you duplicate the places that communicate what work is happening, you no longer have a single source of truth. You have multiple sources of half-truth. You must cobble together information from multiple sources to see everything that’s going on. It becomes easy to forget to update all the places with everything you do.

This is why we use tools that show what things we are working on: so we don’t have to constantly talk about what we’re working on. Wondering the status of what people are working on today? Wondering if someone is blocked? Wondering what was included in our latest release? Let the board do the talking. Don’t get everyone together and interrupt their work to talk about this stuff.

I also think its redundant to have a daily standup, daily email, sprint planning meeting, and sprint review. You talk about a lot of the same things in each of these places, and you have your task management board in addition to this. Why not just pick one communication medium and do it really well? Probably my favorite is daily end-of-day emails. A service like iDoneThis can handle this automatically. This lets everyone start their day whenever they want to, no one gets interrupted out of Flow for a standup or mid day meeting, and people can work as late as they like. A bonus of the end-of-day e-mail is that if everyone focuses on making nice screenshots and writing good documentation in their e-mails, you can reuse this content for release notes or a blog post that goes out to customers.

What if the Masters of Waterfall secretly made Scrum so they could hijack Agile and turn it back into Waterfall?


Scrum contradicts core ideas of Agile

In some ways, Scrum feels like it goes against core ideas of Agile. The Agile Manifesto says, “Individuals and interactions over processes and tools.” Scrum is a highly structured process, with lots of overhead. Instead of optimizing for individual developers and good development practices, it lays out a heavyweight process that actually gets in the way of craftsmanship.

Similarly, the Agile Manifesto also says, “Responding to change over following a plan.” Well if Scrum isn’t all about making and executing plans, I don’t know what is. In contrast, Kanban seems more Agile-ish. It has a continuous flow instead of timeboxed sprints, you can change stories / work whenever you need to, instead of waiting until you’re in between sprints, and the entire idea of daily commitments can be done away with.

Commits to doing one thing today, then five more important things come up.


Daily commitments promote feeling sorry for your work

Ahh yes, daily commitments. I can’t tell you how many times I have been the embodiment of Bad Luck Brian here. I was looking over my journal and noticed this entry.

Today I had nine things come up that I didn’t expect. At the end of the day, I had done those nine things, but I still hadn’t finished the one thing I committed to do that morning. It was one of my most productive days in a long time! But you know what? At the end of the day, I felt sad instead of feeling proud of the amount of work I had done.

Instead of celebrating all the ways I had helped people, satisfied all the “thing” requests I accommodated, and the hidden complexities that I overcame, I felt like I had failed. Daily commitments do that.

I committed to doing this today, but its the end of day and its not done


What are daily commitments good for?

The idea of “committing” to doing things each morning doesn’t sit well with me. It flies in the face of hidden complexity and is directly at odds with craftsmanship. Whether its intentional or not, this practice cultivates the following things:

  1. Encouraging dev’s to work overtime when they haven’t fulfilled their commitment by the end of day (sustainable pace fail)
  2. Encouraging dev’s to ignore craftsmanship and just push stuff out there (quality fail)
  3. Giving management the illusion of control over how quickly stuff gets built (reality fail)
  4. Giving management the ability to place the blame on the developers when things don’t get done according to their “commitments”, when the problem all along is not the developer making a bad estimate, but management instituting such an unrealistic practice (responsibility fail)

It’s not just bad business, it’s bad morals. It’s dishonest. And that’s what I most take offense with. Writing software has too many variables to be able to honestly say, “I commit to doing this today.” And if your team goes along with this little estimating game, you are affirming to management and/or your customer that this sort of business practice is okay.

Mowing lawns? Sure, that’s easier to consistently guess how long things will take, so it’s easier to say that you’ll be able to do things in a certain period of time. But the same cannot be said about software. Keeping my word is important to me, and due to the nature of software, I feel is unethical and unwise to estimate and commit to a certain timeline for every daily task I undertake. Committing to get XYZ tasks done on a daily basis is something I will not do, for the sake of keeping my word, working at a sustainable pace, protecting my family, building things with quality, and promoting good business practices with the people I choose to work with.

So Wow, Demo Time, Product Owner, Self-Improvement, Such Conclusion


Closing thoughts:

I want to end on a positive note, and talk about some of the things I like about Scrum:

  1. Self-improvement is good. Scrum’s retrospectives taught me the value of occasionally taking a break from slinging code to brainstorm as a team about how we can improve and level up our game. As my old mentor Anthony Crumley used to say, “Our processes are the source code that we as a human team runs on. We should refactor it regularly to keep it clean.”
  2. Regular demo’s are good. It doesn’t have to be long or formal, just show the customer/management what you’ve been working on. If you want to be more lightweight, try screenshots in an end of day e-mail or attached to completed cards on your digital task board. Not giving the customer/management some sort of visibility is a recipe for disaster.
  3. The idea of a PO is good. I’ve come to appreciate a PO since working on Scrum teams, and I’m surprised that many projects don’t have someone who plays this vital role. You really do need a single person who has the power to authorize changes in the app, and this person needs to be available to developers day-in and day-out.

So there you have it. My intention in writing this post was not to bash the people who created Scrum or the people who promote it. I bet they are nice people who genuinely wish to improve the world of software development. Scrum helped Agile cross the chasm and truly go mainstream, and I think that good has come of that. Personally, I have learned some good things from Scrum, and I think there are situations where it can work. But I’ve also learned that Scrum is not for me, and I wanted to write down the pain points and frustrations that my friends and I have experienced on various teams using Scrum.

I hope this piece gives people some food for thought. If it made you laugh, if you have any Scrum stories of your own, or if you have any responses, I’d love to hear them. Thanks for reading!

  • Paul

    Aaron I loved your article it is very insightful and brings to light the opposite point of view of SCRUM that so many people/organizations are pushing today… It was a breath of fresh air.

    • http://wendt.se/blog/ Fredrik Wendt

      I agree that this article perfectly describes the most common, and sadly, unquestioned view and understanding of Scrum. I urge you, who seem to be able to reason and question, to at least read the Scrum Guide. It takes about an hour, and enlighten yourself. You’ve been seriously mislead.
      No, Scrum is not a silver bullet, but most of the issues here are simply wrong – basic misconceptions of what the framework actually includes and suggests.

      • Jan

        Trying to get an ROI in your certification? 😉 Tell me what advantage Scrum has over RUP or OpenUP please.

        • http://wendt.se/blog/ Fredrik Wendt

          Uhm, I think the question is kind of moot. There’s no _general_ “betterness” of one way of doing things over another – most ways of working makes sense in the right context. Would you agree? If not, please tell me the advantage RUP or OpenUP has over Scrum.

          • Jan

            UP has an architecture-oriented approach that begins with requirements gathering, process analysis and business modelling in the inception and elaboration phase.

            This allows the stakeholders to have a very precise overall view of what will be delivered on the deadline date. Furthermore the stakeholders know what will be done by when (which milestone) and at what stage their influence can no longer be taken into account if the deadline needs to be met. This architecture-oriented approach also allows to identify critical interfaces in early stages.

            With UP it is down to the PM team in their analysis phase to ensure the end result delivered is what is required by the customer and not just exactly what the customer asked for. With RUP a complex analysis, modeling and design phase replaces what is all down to the Product Owner in Scrum.

            Regardless of “Sprints” in RUP customer can request any changes to the ongoing project at all stages considering its effect on the project. RUP has no limit on the size of the project itself. From my experience I would say that Scrum is ok for small development teams of up to 9 people with no enterprise environment in the back.

            But when it comes to large enterprise projects involving numerous systems, interfaces and people across the globe from my experience (doing RUP as a PM for over 10 years now), there is nothing that can beat RUP or OpenUP with its approach. What do you think?

          • http://wendt.se/blog/ Fredrik Wendt

            I’d say you’re selling all the promises of Waterfall/*UP vs Agile Manifesto. I don’t think there’s a one, single holy grail for software development (I think that’s a “one tool to fool them all”-approach), but rather many solutions to (what may look like) similar problems.
            I believe the context (people, size, uncertainty vs “knowns”, skill set, previous experience, risk adverseness, trust, culture, …) should influence what you go with. As these things can change rather rapidly, I hope whatever framework/model/process you go with allows for adapting to meet the needs of that context. (Whatever you call it, I’d never work without the equivalent of regular Sprint Reviews and Sprint Retrospectives. Whenever I’ve observed organisations starting to pick up on the purpose of these events, and starting to act on what is surfaced – things really start taking off.)

      • http://www.breck-mckye.com/ Jimmy Breck-McKye

        You say that I’ve been misled, that the original vision bears none of the bureaucracy and distrust Aaron describes, but when it’s what he’s seen in every team practicing “scrum”, and it’s what I’ve seen in every team practicing “scrum”, and likewise so many of my colleagues, I tend to think the ‘original vision’ is moot. The definition of it has been so ossified and toxified, that I think your best idea would be to republish its original manifesto under an entirely new name. Rescuing the reputation of “Real Scrum” can only legitimise the awkward chimera of “Corporate Scrum”.

        • http://wendt.se/blog/ Fredrik Wendt

          I think too that putting the Scrum Guide out there has not been effective in getting “better” Scrum out there (at least not yet). If only there was a crystal ball to predict what would work in a complex system … 🙂

  • Kevin Jones

    I really liked this. It’s a long read, but totally worth it.

  • thnk2wn

    Very well written, detailed post of many of the problems companies having doing SCRUM, and some good humor as well.

    My only constructive criticism is that it feels like nearly all a criticism of the problems and not near enough of potential solutions to those problems, alternatives, and tradeoffs; to that end it may appear as a rant to some. So if we drop something from SCRUM or drastically change it, it may solve some problems but create others, so if those things are still needed in some way, what are ways of doing it better?

    This speaks well from our point of view as developers but how do we reach that good middle ground to optimize something that works well for management and developers?

  • badabam_de

    For me it just looks like you did not get how scrum works. Maybe the company you are working for is doing it wrong, but most of what you say about scrum seems wrong. Scrum says, that you can’t estimate the time you need. That’s why you estimate complexity. And it is fine that you are just guessing – you will get better with the project. *Of course* you will be able to guess, what tasks are complex. Also: Scrum says you should not change the commitments. So if you do it right, there are no”disturbing extra tasks”. A Scrum master normally makes sure that everybody can work on their tasks.

    There is much more I disagree with (eg remote work is not allowed, we did that in the last two companies I worked with. Works with scrum the same as it would without).

    Maybe talk to people that use Scrum as it should be used, the will tell a different story than you.

    • cresquin

      > *Of course* you will be able to guess, what tasks are complex

      This is the problem. Some tasks you’ll be able to guess, most are full of hidden holes and edge cases.

    • agaace

      Another issue is pressure. I was often given a deadline of a day to provide my estimates for an entire 2-week sprint where I vaguely even understood what the features were about. To know the complexity, you often need to spend time with the code to see all the parts of it. By the time you can confidently estimate complexity, you know most of the code you need to write and you could probably sit down and write it down in a few hours. Problem is, there is often no room in Scrum for the time spent estimating complexity – which would effectively be time spent doing feature design without actually writing a single line of code – scrum doesn’t like it because you can’t deliver much afterwards, other than maybe writing a “technical spec” that adds several hours of time overhead to the feature (and devs hate writing specs, and then you have a spec review meeting where everyone will criticize it and maybe you will need to have another meeting to brainstorm other ideas and work a compromise).

      The best method of agile work I’ve ever experienced was a bunch of core devs familiar with the system get together spontaneously in the hallway, brainstorm ideas for a feature on a whiteboard, compromise on a solution, then go back to their desks to code it. Unfortunately, this doesn’t scale when 1) the team grows larger than 3-4 people 2) is too expensive to use for every single feature, so it can only be used for the most crucial features 3) is costly just like an another meeting 4) any form of unplanned spontaneity doesn’t fit well with scrum, because often the best solution is to change the order of features to be implemented – i.e. change the priority of the backlog.

      If I was a lead, my solution would be small teams (4 people max for the smoothest communication and inclusiveness), a dynamic bucket list of things to do (like a shopping list – you add and/or remove things as you feel it) and maybe a weekly meeting focused on devs understanding business priorities (information like “if we don’t get this done by X, we’ll lose our biggest customer”) and business understanding dev priorities (info like “if we don’t refactor this code now, our servers will become unreliable when we get more customers in X weeks, and customers will complain”). Whenever I got the opportunity to *really* understand business motives behind various managerial decisions in my project, I felt happy like a child and those were the times I delivered my best work. My take is – teams are like intimate relationships – honest communication, understanding and support for a common goal are key for long term success. Imagine a couple where the wife or the husband constantly tracks the other one’s “performance” (imagine frequency of cleaning the house, financial spending – whatever random metrics you choose) in an excel spreadsheet and constantly creates pressure to sustain high “performance”.. would you feel comfortable in such a relationship? Would you last long in such relationship? Would you avoid conflict in such a relationship?

      But maybe I’m a rare dev seeing dev projects not as a rat race but as a human relationship working towards a common goal we all understand well and believe in.. because I’m a woman, yea a lady developer, I hear we’re rare like the unicorns.

      • http://www.ponderyourpath.com Aaron Gray

        Excellent thoughts, thanks for taking the time to share. I love your analogy about a husband and wife constantly evaluating each other’s performance, and how this undermines trust in the relationship. Very fitting and similar to the relationship between the business and development sides of a team / company.

  • Christopher Phillips

    This article is perfect. I would like to get it tattooed on my back. (Yes, that would be painful, but not nearly as bad as working in a scrum shop was.) You have described exactly why Scrum is killing the art of software development – or at least taking all the joy out of it.

    • http://wendt.se/blog/ Fredrik Wendt

      Instead of paying for that tatoo, invest one hour and read the Scrum Guide. It’s free, should go much faster, be less painful (I hope) and hopefully it’ll stay with you as a good thing to carry with you through life.
      http://scrumguides.org/scrum-guide.html

      • Christopher Phillips

        I have read the Scrum Guide and been through Scrum training at work, and of course used Scrum as the process on several projects. I would not be critical of Scrum if I had not tried (very hard) to make it work.

        Instead of being condescending toward anyone who is critical of Scrum, invest one hour and read Debugging The Development Process. You may learn a lot about what makes software teams function – or fail to.

  • Bruce

    Wow. I mean wow. I’m speechless.

    I’ve been working with agile teams for over 15 years now. I honestly can’t tell if you’ve actually ever done Scrum or not. Your understanding of planning poker and estimation in Scrum is deeply flawed. And, like a lot of people in our industry, you continue to misunderstand the dangers of optimizing for individual performance over optimizing for team performance. But at least you’ve learned how to use memes.

    About the only thing that rings even remotely true in this article is that Scrum monetized agile, something I dislike intensely.

    • Nuno

      I vote for more memes. More research is fine also. 🙂

    • Christopher Phillips

      It is very clear from this article that the author has, in fact, “done Scrum” before.

      • Bruce

        Interesting. I had a difficult time recognizing it.

        • Christopher Phillips

          Sometimes we do scrum, sometimes scrum does us.

          • http://wendt.se/blog/ Fredrik Wendt

            Way too often, after crossing the chasm, do we understand what it was “they” (on the other side of the chasm) did that actually made things work. “Oh, they stood up together once a day, let’s try that (and ignore the purpose of why they met like this)! They shipped often, almost regularly – let’s try that (and ignore the quality aspects that you really can’t see from the outside).”

    • Petr

      Wow. Given the fact that Agile manifesto was created 14 years ago, working in Agile team for over 15 years looks impressive

      • Bruce

        You think that agile methods popped into existence the moment the manifesto was written. Fascinating.

        What year was “Extreme Programming Explained” published?

        • Petr

          Sorry, I don’t very carefully follow shamanistic practices

          • Bruce

            Really? No one could tell.

            And yet you felt qualified to comment. Awesome.

          • Christopher Phillips

            @Bruce: Soooooo… what’s your favorite programming language? 😉

          • Bruce

            I’ve used C, C++, Java, Ruby, and C#. I probably like C# best, but I’m not sure I could articulate why. I generally like whatever language is necessary to get the job done.

            What’s yours?

          • Christopher Phillips

            From a computer science POV I think Java is the purest language. In the real world, straight C compiled through a C++ compiler is what keeps the lights on.

            From that mix of languages, I’d guess that you are working primarily in the web/enterprise domain. IME, Scrum is a better fit in those applications than it is for product development.

            Someone else said it here in the comments that Scrum optimizes team performance over individual performance. That is great if you want to drive your team’s output to the median. But you need to let your rock stars strut their stuff if you want to do the exceptional.

          • Bruce

            I’m unconvinced. Or, at least, I have never seen anything in my work that indicated that rock stars cannot excel in Scrum. In fact, easily the greatest developers I’ve ever witnessed were part of an Extreme Programming team.

            I also think there are a lot fewer rock stars than most developers want to admit. What do you consider exceptional?

          • Christopher Phillips

            Extreme is not Scrum. HUGE difference.

            There are very few rock stars, but not hard to find if you know what to look for.

          • http://wendt.se/blog/ Fredrik Wendt

            Christopher: Do you have any data/research that suggest that having “rock stars strut” is benefitial over have “highly well-operating teams”? (I’m not questioning the validity of your argument, I’d simply would love to know if there is in fact one defined model which clearly, from all points of view – or at least weighted/combined – suggests that one is superior to the other. Wouldn’t that be great?)
            Frederick Brooks suggests (Mythical Man Month) the same thing you do, that we should model our ways of working around “the highly skilled surgeon” with squads of followers prepping, patching, supporting and cleaning up from the sides. Make sure the “rock star” operates as they think is best.
            Daniel Pink suggests that we should strive for atonomy, mastery and purpose to “release” the potential of our organization. Frederic Laloux suggests that no one model of operating(viewing the world is supperior to another, simply that they’re better suited to different contexts.

            I too, have been thinking about if the type of software product being developed is a factor to consider when choosing whether to apply Scrum or not. IME, a big monolith (150 programmers) with architecture not enabling team autonomy in terms of feature complete delivery/work, adds for additional … tention. Whether that challenge means waterfally alternatives is better for the company, organization, teams, individuals or even the product in the marketplace – I have way too little data to form a general opinion about.

          • Christopher Phillips

            The only data/research that I have is more than 30 years experience developing software for a wide range of applications on a variety of teams. I have seen large teams and small teams, corporations, startups, waterfall, extreme, agile, scrum, spiral, kan ban, death march, and every other process you can (or can’t) name, and I’ve had to answer to the outcomes.

            By far the most successful teams I’ve worked on have been smaller teams thoughtfully organized around the specific strengths of the people on the team. I would rather have a team of five rock stars than a roomful of fifty droids any day of the week. And if you can’t assemble the right team, you should think twice about taking on the project.

            That being said, what defines a “rock star” is different in the context of each new project – though some know how to shine in any situation. Everybody has the ability to be a rock star if they are given a role that leverages their skills while challenging them to stretch a little bit.

            Don’t think of a single rock star and his entourage. The right model is an epic rock band made of great players in every role, from the lead guitarist to the bass player to the guy selling tee shirts in the lobby. Rock stars all.

            When a rock star is strutting, they feel engaged in their work and they will give their best performance. What more could you ask for?

          • http://wendt.se/blog/ Fredrik Wendt

            The (debated) Standish Group suggests the primary factor for success of an IT related project is size, ie number of people involved. I too would prefer rock stars you describe, and I’ve seen a couple of them through my years too, and I totally agree with 5 rock stars vs 50 droids. But, that’s almost like a universal truth – put a group of experts/rock stars in their fields together and they will perform well.
            I find it more interesting to look at a group of 6-7 average Joes/Janes, and I read you comment as “if you have one rock star in this group, that person’s performance should not be second the improving the overall team’s performance”. Frederick Brooks had this view and explained in Mythical Man Month – mimic that of surgeons and operations: put the star surgeon in the middle to lead the work, and a set of minions to support whatever the rock star want to do. The minions will do some prepping, cleaning, supporting, repetitive work, … I may just have read your comment wrong.

          • Christopher Phillips

            “…the primary factor for success of an IT related project…”

            And this is The Great Divide. In my experience, IT is a vastly different world than Software Development as a whole. IT projects tend to use established tools and technologies to build customized business solutions. It is not about being “cutting edge”, competent IT managers are still running everything on Windows 7. In my experience, Scrum is very good for this kind of project because there should be few surprises. For example, most companies don’t need a revolutionary e-commerce solution, they want one that is stable and mature. There should be no need for a lot of creative software development in order to churn out web pages for your .com, just implement the features from the backlog. Sure.

            Where Scrum is lethal to organizations is when it is applied to product development work. This usually involves doing something brand new using the latest tools and technologies. (Otherwise, why are you even bothering to develop it all over again?) Surprises along the way will happen, and you can’t wander aimlessly unless your employer has very deep pockets. Some amount of planning and up-front architectural work is needed, and the system should be built and validated in an orderly manner – not slapped together in order to implement feature X by the end of next week.

            Many organizations buy into Scrum after they see it succeed in IT, only to watch it fail horribly in other problem domains. I think many managers and executives just don’t know the difference between “coding” and “software engineering.”

            Do you…?

          • Christopher Phillips

            WRT “rock stars” – my view is that every team member should feel like they are a rock star. That does not mean they can all play lead guitar during the big solo break. It means they should each feel valued, know their place on the team, and know that they are being groomed to gain experience and move up the ladder over time.

            The surgeon model still treats the rest of the team as less-than-special, and this is where it fails. You need to fully engage the entire team by recognizing the unique value each one brings to the table.

            If a team member doesn’t bring anything to the table and has no potential for growth, they shouldn’t be on the team. If you aren’t actively developing your people, they will find other options for advancement outside your organization.

  • Brenton

    lol….pretty easy to spot the Project Managers, as opposed to the Developers, in the comments here 😉

    • hoangtranwork

      Devs are those who like meme ^^

      • Michael Washington

        Agreed 🙂

  • http://kevinsuttle.com/ Kevin Suttle

    So much time spent working on working. The amount of time and money lost on this misguided effort is a travesty.

    • http://wendt.se/blog/ Fredrik Wendt

      Agree – it’s a shame that the people didn’t put empiricism to work and started using their brains instead of following whatever someone tells them too. I heard humanity, during the renaissance, started questioning things and deviate from simply doing what “the so called authority” told them to be “the truth”. You would hope highly skilled university graduates of the 21st century would know better!

  • http://www.nomachetejuggling.com Rod Hilton

    What a fantastic article that’s been utterly ruined by incessant meme images.

    Seriously, this article would be 100x better with no images at all. You wrote something interesting and insightful and then made it look like some 9gag post.

    • http://www.codysand.com/ Cody Sand

      I thought the memes were hilarious. To each his own.

      • http://www.Marisic.Net/ dotnetchris

        They were spot on.

    • http://convertwith.me/ flywebguy

      Yeah, going to have to disagree with you on the memes. Memes are developer food – it’s how we communicate with each other.

  • RaoulDuke

    people don’t understand scrum, and in my “professional life” I almost have never seen real scrum 😉

    • http://www.Marisic.Net/ dotnetchris

      I almost have never seen real scrum

      Suppose this statement is accurate, is a process a good one if no one is able to do it for “real”?

      • http://fluidcircle.net/ Michał Parkoła

        Yes. Something can be good even if most people are doing it wrong. “90% of everything is crap” see https://en.wikipedia.org/wiki/Sturgeon%27s_law

        • http://www.Marisic.Net/ dotnetchris

          Would you drive across a bridge that was built with a “can be good” process, similarly go in a submarine that was?

      • Christopher Phillips

        Or put another way, is my software any good if nobody can figure out how to use it?

        • http://wendt.se/blog/ Fredrik Wendt

          Agile ways of working, at its core, questions many of the “truths” and “facts of life” our industry has taken for granted for a long time. Not to mention existing business models and consumer/producer arrangements. Agility questions all of that, and wants the business to get involved in a completely different way compared to what the industry started out with. On the IT side of things, as the business wants higher flexibility and work under higher degrees of uncertainty, we can’t continue to build things like we assume we can adress all major concerns up front.
          It’s revolutionary to a majority of our industry.
          Now, I think that a huge amount of people who still believe in these old held “truths”, when they first are introduced to these new concepts, they don’t accept that the sun is the center of our galaxy, and bend whatever they hear to conform to the earth-centered view and understanding. Even when you put data, business cases, white/brown/blue/yellow/whatever papers in front of them.

          Is that the failure of the concepts (Scrum), or the failure of man (individuals)? Does it render Scrum no good as a concept?
          (I totally absolutely think that Scrum has _not_ transformed our industry into leaving these fallacies behind, embracing empiricism and grow up to the truth that what we’re doing is really hard. So sure, I think it failed on that point. Done professionally, Scrum does work. But like others have pointed out else where here, no process or framework will save fools from making the same mistakes over and over again.)

          • Christopher Phillips

            “…we can’t continue to build things like we assume we can adress all major concerns up front.”

            This statement of yours represents an absolute failure of competent engineering intent. We, as engineers, cannot deliver incomplete software designs under the guise of “completed” work. Businesses may occasionally choose to sacrifice quality to meet a ship date, but this should be the exception – never the norm. If I was being routinely asked to deliver code without being given the time to design it properly, I would look for another job.

            “Agile” encompasses a broad range of processes, many of which work very well and have revolutionized several engineering disciplines. “Scrum” on the other hand, is a specific process that attempts to simplify the management of software projects. A criticism of Scrum is NOT a blanket rejection of all Agile methodologies.

            My issue with Scrum is that, by default, it assumes a very naive definition of “complete” software and does not emphasize the importance of system architecture and long-term planning.

          • http://wendt.se/blog/ Fredrik Wendt

            My wording may not perfectly express what I meant: I’m not saying it’s impossible to define and design things up front that will work out perfectly. There’s lots of examples of this out in the world.
            I do argue that the majority of such attempts, in general, has proven to not work out so well. The Waterfall paradigm of constructing complete software has often lead to too bad outcomes. Iterative and incremental development of systems have proven more successful. In order to do this in an iterative and incremental fashion, you’re forced to (or quickly learn) to adhere to proper software engineering principles and practices.

            I agree Scrum doesn’t address how to actually build software, and intentionally so. It’s a too big a topic, and it’s also context specific. Not all software and projects needs a common ground. Scrum does require you to define what qualities your software should adhere to, a Definition of Done, or you shouldn’t start Sprint Planning.

            So I don’t agree it has a naive definition of “complete” software – I argue it says “this is a topic you MUST address, and it’s too big to be handled in a meaningful generic way”. Scrum also doesn’t say it’s applicable for all software development initiatives. If you’re not in a situation of high uncertainty, to domain (what) and tech (how), then Scrum is probably not a good fit.

  • TCbanderstnatch

    Search and replace “Scrum” with “The wasteful stuff people do in the name of Scrum” and yha got something here.

    I coach teams to focus on the valuable stuff (OUTCOMES) Scrum and the other Agile approaches are supposed to produce and challenge them to change whatever they need to so they actually get those outcomes.

    So what do you care most about?….

    Working in flow state?
    innovating like crazy?
    leaving code easier to change and understand?
    eliminating blocking and waiting?
    squashing risks before they eat your lunch?
    making good decisions fast at the ‘right’ level?
    Fixing bad decisions fast when you screw up?
    demolishing the crushing drag of inter-dependencies?
    finishing the most valuable stuff first?
    building what the customer / market actually wants?
    being proactive rather than reactive?
    making sure stuff actually does what you THINK it does?
    having a blast working on a great team?
    get stuff out into the market where it can make us money?

    It’s stuff like this that matters. Not process.

    I’ve seen Scum teams nail every one of these and succeed at none. No process or framework on the planet guarantees a single one of these outcomes. Achieving these goals is a consequence of teams and organizations focusing on these goals and figuring out how to make them happen in their unique context.

  • Steve

    I kind of lost it when I saw “Agile” and “methodology” in the same sentence. I’m a DBA and I’ve worked in close proximity to several RAD projects over the years and none of them have worked. Based upon my personal observations, I conclude that any Agile approach is basically a bunch of programmers making it up as they go along, based upon the mistaken belief the project is making progress if they can show the end users some screens pretty quickly. Erm…that’s called prototyping!

    So the DBA is there to inject some sanity to proceedings and wants to ensure the database design works, is robust, scales well, is properly normalized, supports the expected workload and transaction throughput and above all is documented properly. All things which mean NOTHING to the little darlings who think coming up with a flash looking pull down menu is the last word in application system excellence. But hey, the manager/project manager wants to see progress (i.e. finished screens) and the DBA is the bottle neck because of their change control procedures. So why not just let the programmers design the database structures themselves? That’ll be way quicker, right? So the application is completed and deployed at break neck speed and all the front end people pat themselves on the back for a job well done. Except database performance sucks, has concurrency issues, doesn’t scale and locks up when the batch jobs kick in. But hey, no problem – that’s why we have DBAs, right? That’s why they’re there, to fix this stuff, right? WRONG!

    DBAs don’t tend to wander over to the programmers’ desks and tell them how to write their code in whichever language, framework or whatever that happens to be the ‘cool, new approach’ that week. So why is it programmers think it’s OK to dream up database structures then throw them over the wall at the DBAs and tell them, “implement that and like it”? It’s bizarre! Especially since they’re the same people who when you ask them questions like, “How many rows will be in this table initially and 6, 12 and 18 months from now?” or “Is this table predominantly read or update?” or “Will this table see high rates of delete activity?”, they have absolutely NO idea!!! So, well qualified for understanding and ‘designing’ the database structures which sit behind their code. OMG – you couldn’t make it up. Well, actually Agile practitioners do.

    • http://www.Marisic.Net/ dotnetchris

      To be fair, anti-normalization is what it takes for database to scale. Similar to your statements about transaction throughput, a highly normalized database will have awful transaction throughput due to very wide locks it takes over numerous tables.

      • Steve

        Note I said “properly normalized” not “highly normalized”. An appropriately skilled and knowledgeable database designer will design for the expected load and throughput, whether that be high insert OLTP, read only DSS or something in between. My point boils down to the old adage, ‘horses for courses’, i.e. let the programmers do what they’re good at and let the back end folks like DBAs do what they’re good at. In my experience with RAD/Agile, that’s not what tends to happen and it’s often left to the DBAs to crowbar performance/scalability/data integrity into something which wasn’t thought through during the mad rush to get ‘working’ software out the door. That’s my peeve!

        • http://www.Marisic.Net/ dotnetchris

          Fair enough. I read properly normalized to automatically mean 3NF or crazily 5NF (actually worked at a place last year that the DBAs required 5NF)

    • http://www.kalle-online.net/blog/ Robert Kalweit

      Hey Steve, sad to read that you’re yet another victim of bad ScrumMasters AND Project Managers, as both Frederik and I have pointed out above.

      Scrum doesn’t mean “no planning”. It neither means “dev teams do everything”. In the setup you describe (and half a dozen I’ve worked in) it would have been better to *involve* you from the start. Which is what a (cross-functional!!!) Scrum team should do: Involve people of all practices required to get the job done.

      Requirements should never dictate the DB design. Same as the DB design should never dictate what features are being built. The truth lies in between and the only way to get there is by collaboration. This is what Scrum and (good!) ScrumMasters should foster!

      All the best!

  • David

    Terrific read. I have always been suspicious of SCRUM and its associated buzzwords. It’s micromanagement-intensive and puts _less_ trust in the developers. Since when did problems become “user stories”? Why should we have to stand up in meetings and call someone a SCRUM master? Am I really the only one who finds these things ridiculous? I work on a small team that gets things done quickly. We are pretty informal, but disciplined about testing. We will grow in the near future, and I’ll be staying far away from the Agile coaches. Instead I’ll look to hire programmers who know how to write code and are nice people to work with. See? You don’t need to purchase common sense.

    In a way, it’s a relief to know that, no, SCRUM is not a magic solution to the difficult problem of building software. It’s just the latest management snake-oil fad. It’s for managers, not developers. We work best when we are allowed to write code, not provide the currently-fashionable version of TPS reports every day, both verbally and in writing.

    • Steve

      I just bought you a virtual beer, David. Well said sir!

    • http://wendt.se/blog/ Fredrik Wendt

      David, The Scrum Guide is 16 pages long (Letter or A4) and available in HTML at http://scrumguides.org/scrum-guide.html It takes just over one hour to read for most people and I urge you to do the same. You’ll find that (among other things): Scrum says nothing about standing up during Daily Scrum; there’s some legacy around the three questions (I honestly expect them to go away in the future) you’ll see they’re refrased to focus on a common goal and what we know of remaining work needed to reach the goal; I don’t know about micromanagement (there’s no burn down and the only ones that should talk about remaining work is the dev team among themselves); the development team is completely trusted to decide when work is completed (not finished=time’s up) and that they hone their quality/standards (Definition of Done) and also how much to forecast to be completed (not commit to/no promise) during the sprint; there’s no mentioning of user stories.
      You’ve been ill informed about what (Professional) Scrum is and I hope you really take this challenge on to actually read the guide – it’s a fast read and it completely respects and trusts developers. Anything else is the ill-doing of individuals who don’t know better, and do not understand Scrum.
      (And yes, Scrum is in _no_ way a silver bullet, and being suspicious is generally a good idea.)

      • Markus Pfundstein

        I completely agree. The problem is not with Scrum but with how it is implemented at companies. I am a Senior Software Engineer turned Scrum Master. As an Engineer, I really hated Scrum, precisely because of all the issues raised in this blog post. But when I began to really study Scrum, I kinda saw the light, learned that 100% of the companies I worked with implemented it in a wrong manner, and decided to become a Scrum Master.

        I try now in my current job to correct this and to implement a true Scrum process. Its really hard but you can reap the benefits very early one. Points that I learned:

        The PO must know fully what his/her role is.
        The SM must 100% enforce Scrum. No tradeoffs
        The team is the most important entity. It must be respected and enabled/trained to act in an organised-manner.
        Quality produces speed. PO must understand this.
        PO must make sure that stories are well-defined. Shit-in, shit-out.
        Everything must be made transparant. Everything(!). Not to blame, but to be able to gain insight.
        Story points are just that, story points. Don’t put hours on it. After x sprints, the team has found a good style and during time they come more reliable.

        The rest follows.

    • commonsenserules

      It’s a fad.. A long-running, annoying fad that is for managers and peripherals, not devs. There are lots of fads that move through software development.. the cloud is a fad. Many companies were initially nervous to move their server systems out to the cloud because they were worried about issues like security and control, and rightly so. But, now, after many years of it being rammed down their throats… They’re doing it anyway! These things are marketing entities that create jobs for people – the problem is, they’re jobs for people who don’t really help the process of software development – in fact, they often hinder it. So, actually, the overall cost of IT projects is unnecessarily, and sometimes grossly, inflated. Additionally, productive team members have to regularly endure encounters with new team members who have no idea about software development, but have uttered the proper series of buzzwords to someone. SCRUM and Agile are also an excuse for project leaders to dismiss planning and requirements gathering.. they’re able to neglect hiring those resources and it’s all OK under the guise of “Agile”. What most projects really need is for people to come in and intensely manage the important things like “What are we doing?”, “Whose doing what and in what order?”. After that, architects and devs should be left alone to create and do what they do best.

      We work in an incredibly “stylish” industry… many people want in if they can get in. And, since management often doesn’t understand the technology and processes that underlie projects, and because sales and marketing are King, each time one of these fads takes hold, it’s an opportunity for people outside the industry to make their way in, and we see influxes of these people. I can guarantee you that I can open up Monster right now and find a posting for a “Cloud Manager” or similar.. WHAT IS THAT?

  • mweinand

    Seems like you are in an environment that is clinging to old management strategies while “doing Scrum.” Scrum is not a process for supporting a production application, it is a process for implementing features. One of the main tenants is the time spent each sprint by the team members is consistent. You cannot accurately forecast a team’s progress if the time commitment each sprint changes.

    If “5 more important things” come up, your management team is not respecting a true scrum process. Once the team commits to the work in a sprint, the work that team takes on should not change. You can add things to the top of the backlog but not to the current sprint. It is possible to accommodate a set amount of time each sprint for high impact feedback items, but again the important point is consistency.

    With a strong definition of done and proper grooming, there shouldn’t be many big surprises that come up. The definition of done needs to include all of the quality metrics and deployments to environments, and your team composition must be such that the definition of done is achievable. As soon as you start bending and not writing unit tests, introducing other tech debt, to “get it out the door”, you are calling things “done” that aren’t actually “done”. If you don’t build in the quality from the start, you are preparing yourself for problems in the future.

    The other important point is the development team should be driving the process. The team should not commit to any work they don’t feel can be accomplished in the sprint. It doesn’t matter what process you follow, development teams need to be able to estimate the duration of tasks. You certainly don’t want a manager to be the estimator. With scrum, you estimate relatively to other PBIs that are about the same level of complexity. If you truly don’t know the level of complexity, you can do a spike to gather more information.

    I have the benefit of being a developer and scrum master in an organization that fully adopts the principles of scrum and lets the teams work to figure out what works best for them. It sounds like you are in an organization that follows psuedo scrum but hasn’t given up on the managers making decisions the teams should make.

    • http://www.Marisic.Net/ dotnetchris

      your management team is not respecting a true scrum

      No true Scotsman fallacy https://en.wikipedia.org/wiki/No_true_Scotsman

      • mweinand

        Alright, if management is interrupting a sprint with work that the team has not committed to in sprint planning, your team is no longer practicing scrum. Scrum does not allow you to take on additional ungroomed work in a sprint unless all of the PBIs are already done. You cannot say scrum doesn’t work if you aren’t actually doing it and management isn’t letting it work.

    • http://wendt.se/blog/ Fredrik Wendt

      Great comments except for this thing about commiting to amount of work.
      “Once the team commits to the work in a sprint”, “commit to any work”.
      Where did you get this idea of commiting to scope in a sprint? Scrum has moved on, I encourage you to do the same! Please search for “commit” in the http://scrumguides.org/scrum-guide.html

      I too have had multiple hats in my days, but I’d like to know how your teammates can tell – when you speak – whether they’re listening to the voice of a team member or to that of a Scrum master?

      • http://jasontknight.com Jason Knight

        Great stuff through the comment stream. I’d like to hear more about the voices you speak of; which are beneficial to use and at which times?

        • http://wendt.se/blog/ Fredrik Wendt

          No 100% sure I follow (so please correct me if I’m way off here).

          Say that you’re in a Sprint Retrospective, and you’re discussing how the last Sprint Planning went. Now, if one person in this group is both a Scrum Master and Development Team member, and that person says “I think X is the wrong thing to do, I want us to do Y instead”.
          For the other Development Team members, they have to decide if they see a Scrum Master trying to ensure the framework is correctly used, or is it a suggestion from a mentoring/coaching role, or is this simply a teaching moment where the SM is teaching is some basic stuff we should just accept, or is it simply an opinion from a fellow dev team member.

          A Professional Scrum Master knows that they need to balance different “stances”, such as teaching, mentoring, coaching, facilitating, and use this to best benefit the full Scrum Team and organization. This is typically a hard thing to figure out, and takes self-discipline in order to suppress your own opinions in order to have the team learn how to handle conflicts, or not offer solutions in order to have the team grow in that area etc.

          These are just a few examples of the difficulty of playing the SM role professionally, while also being a Development Team member. Was this what you were asking for?

          • http://jasontknight.com Jason Knight

            Thank you for the clarification. What you say makes perfect sense and is in line with the tension I feel when sharing SM and Developer roles. It feels much harder to me sharing the roles, but full time SM’ing brings is own challenges. It can be easy to condescend and nit pick to feel superior instead of leading through humble service.

  • http://www.Marisic.Net/ dotnetchris

    I have to point out there is a way to estimate software projects in a reliable and accurate manner. I talk about it extensively through the comments on this post: http://www.daedtech.com/prediction-markets-for-software-estimates

    Many of your points are totally valid no matter what you do. If you allow your team members to be pulled off their project to work on other things, the project will not be finished on time ever.

    Measuring work in hours or even a day or 2 is a horribly unit of measure. This infinitesimal scale will lead to estimates continuously being off by entire magnitudes [hours are days, days are week(s)] Work needs to be in meaningful slices, generally several weeks. Work estimated by competent people to be 2 weeks will not grow to be 2 months. A 2 week slice becoming 2 months shows a profound lack of knowledge that went into that estimate or a radical leakage of work.

    Lastly when you have a full project plan, some activities being finished early will counter balance those finished late. If you’re working in time slices of hours and days, you will never get a benefit from the tasks that finish early. 1 hour caught up will not offset the 4 hours or 4 days late another activity is. Also in a well thought out project plan very few activities overrunning will delay the whole project, only the most interdependent (which should be done by your best personnel) or if you have a cascade of late activities that they become the bottleneck (which only happens from bad project management, good project management would interdict before this happens)

  • Sreerupa Sen

    Loved the article, it puts into words all those vague disquietudes one has about scrum but doesn’t voice 🙂

    • http://wendt.se/blog/ Fredrik Wendt

      That’s sad. One of the core tenets of Scrum is empiricism, which requires transparency to work, which can only come when we stop holding back what we actually see – ie being honest and frank. Scrum should foster transparency and allow you to iterate on what we discover (and hopefully learn).
      If we don’t put out our concerns, how can we improve and learn? (And no, Scrum doesn’t solve anything. It only puts a few inspect and adapt loops in place for people to have the chance to really iterate over what works and what doesn’t.)

      • futurePrimitive

        “Vague disquietudes” are an uneasiness that is difficult to explain — especially so when expectations are colored by the pervasive claim that Scrum is the best thing since sliced bread.

  • gsills

    It is easy to separate comments coming by programmers from comments by PMs. My take on it is that while processes (A.K.A. methodologies) can be a net help or a net hurt, they are largely besides the point. A team that is failing doing cascade waterfall will fail just as badly (at least) using any agile methodologies. And yes, these methodologies are about people, not about software.
    All of the software methodologies I have seen during my career are all just experiments revalidating the premise of “The Mythical Man Month”. It is forty years later and people cannot get it through their thick skulls that programming is much more like creative writing that carpentry. Perhaps if we replace project “MANAGERS” with project editors who can actually write code (you know like an author has an editor?) we might see some progress with managing groups of programmers.

    • http://convertwith.me/ flywebguy

      You sir or madam, just won an award for that suggestion. A project “editor” would be SO MUCH more beneficial.

    • http://wendt.se/blog/ Fredrik Wendt

      That’s how I see architects. Helping with drawing the outline, having a plot and idea, then helping staying on the path (or develop it as needed). Now, with complex software, with high level of uncertainty on what we need to do (requirements unclear) – this “outline and plot” will need to be heavily revised. That to me is what emerging design/architecture is all about.

      Build on what we know now, and realize that down the road,
      we’ll learn what we knew, was actually not at all “known”. YMMV 😉

      • bananaboat

        YES! Thoughts as a designer and front-end developer…I think a lot of developers are uncomfortable, at least where I’ve worked, with the idea of designers in particular “taking over” and being in control. But a good designer isn’t seeking control – they’re seeking the best possible solution to the problem at hand, regardless of who came up with it. Their job is to take all the pieces, all the problems that need solved, the functions that need performed, the expectations and physical / cognitive limitations of the users, the time, labor, and budget constraints, etc and try to balance all of them to create – in the best cases – a plan for the final product to be followed as closely as possible (stress on “as possible”). A good designer is always open to changing things if they don’t work for whatever good reason, with an almost ruthless obsession with, eventually, through iterations and testing and feedback, getting at the purest and best essence of the software, product, etc. We don’t hesitate to kill our darlings, no matter how many hours, how many late nights and early mornings we spent creating them if they aren’t what is needed. That work is rarely wasted, and almost always has a use at some point, even if that usefulness is just in discovering what definitely does not work.

        I have gone off on a tangent. Basically, designing the product ahead of time and keeping an eye on that overall concept while being flexible on the implementation is super helpful. I really need to get some stimulants in me, the ADHD is strong today.

    • Vassilis

      ” It is forty years later and people cannot get it through their thick skulls that programming is much more like creative writing that carpentry.”

      Dear sir or madam, today you have won the Internet. Congratulations.

      I enjoyed your comment to the last full-stop.

      • JP

        Oddly, I’ve done all three for money in my life, and they are all very different. I wouldn’t say coding is closer to creative writing than carpentry. The activity I found that is most like coding is drafting legal contracts. They are long-term formal documents, often worked on by people with different specialties, that can be “wrong” in both a syntactic and semantic sense, and can also be “right” while being more or less elegant and readable and maintainable. Lawyers don’t have the luxury of talking about ‘craft’, usually.

        Ultimately, coding is no more creative than carpentry (and substantially less so than most forms of writing). It’s unlike most existing disciplines, and should be treated as a distinct activity with distinct processes.

        • bananaboat

          I think it probably depends on what you’re developing and in what sort of company. When I’ve worked on things for myself or for more creative projects, it felt exactly like writing – it is after all. We call the different types of codes “languages” because they are and mostly require the same type of thinking.

          Those languages can be applied in many ways, just like any of our spoken and written languages. Sometimes they can be applied for a legal brief or technical writing, sometimes you can work alone on a creative and experimental story, poem, or song (all of which, with the exception of very fringey stuff, do in fact have rules and some type of meter, syntax, expected narrative structure, etc), sometimes you work with a whole team of fact checkers, editors, and journalists on a non-fiction piece or an article for a major paper. All of those acts are creative in some way, all of them have entirely different processes, and all of them, to my mind have code equivalents.

          Being a designer, front end developer, writer, and artist I perhaps also have a unique view of these things. I think they all require a similar process in terms of creation and time management. All of these disciplines, with the exception of the most cut and dry, specific tasks, require a LOT of down time and a lot of unstructured exploration in order to produce anything meaningful. Freedom and restriction both play a really important role – with ultimate freedom and no constraints, the infinite solutions available to a given problem are almost always overwhelming, but with too much constraint (particularly on time) it becomes very easy to burn out or feel equally overwhelmed by the scant amount of time, resources, etc to work. They all require constant learning and taking in lots of outside information to continue to get better and solve problems in innovative ways, and that inspiration can come from literally anywhere – I have solved coding challenges in my sleep, at museums, or working on totally unrelated projects plenty of times, and have had similar moments of eureka in my other creative pursuits as well.

          I feel like I’m rambling right now, I may fill in these thoughts further later.

  • Mike

    This article points out a lot of challenges you run into doing software development. But, assuming that those challenges should be tackeled by using scrum is wrong. Scrum is not a silver bullet.

    Scrum is just a simple framework. It’s the choices you make within that framework that matter. Scrum helps in making good choices and evaluating (measuring) if it was the right one.

    My reaction to a few of points made in the article:

    -High overhead costs due to meetings.
    This, to be frank, is nonsense. When you get better at it the meetings will become more and more efficient every sprint, so the costs wont be that high. What would the alterative be? Writing documents? Other kinds of meetings?

    -Meetings disrupt flow.
    Yes, thats true. And it goes for scrum meetings, but also for Prince2 meetings, visits to the dentist, phonecalls etc.
    At least with scrum there is room for acknowledgeing useless disruption and the scrummaster can help, for instance by choosing the ideal moments for meetings so to minimise flow disruption.

    -Inconsistend overhead, customer crises, bugs etc.
    I have had my share of those and have tried al kinds of things. What works depends on the product, it’s lifecycle fase, the team etc.
    Sure a crisis can sometimes destroy a sprint, but at least the most important items (at the top of the sprint backlog) probalbly will be done, and you can messure the crisis itself if you choose add the crisis to the sprint. That helps you in the future.

    -Scrum addicts you, people start having meetings because they think it will make them more efficient.”And what is Scrum’s answer for not getting enough things done? More meetings and processes!”
    I wonder wich scrum guide you have been reading.
    Get a good scrummaster.

    -Scrum strains the relationship between management and developers
    Not if you teach management how scrum works, it is a well documented flaw not doing so.

    tata

    Mike

  • Erik Weber

    So what do you think we should do then? Surely not waterfall, that’s horrible for developers also. What’s the best way to get working software out the door in your view?

    • http://www.ponderyourpath.com Aaron Gray

      I think all teams are different, so everybody has to think about what is the best fit for their situation. Furthermore, no methodology is perfect, and I wanted this post to be focused on Scrum, and not Scrum vs. something else. That being said, if you look carefully at my suggestions at the end of most of the sections, you’ll get some clues as to the techniques and practices that I think are most useful. 😉

  • Voomas Telka

    Project slowdown due to complexity is inevitable. Good programming practices, as well initial insight and previous experience, can postpone it for some time but eventually Metcalfe’s law will kick in. The problem is, that the value of your software is not in it’s components but in the relations between the components. Unfortunately these valuable connections make also the programming a hard task. All the stories and features and other things you add to your software are usually not isolated but are related to other system components.

    Scrum and all the other methodologies I’m aware of pretend that software is simple, e.g. number of important relations between its components is small, or it can be made simple via refactoring, “right” design or some religious practice. Practice on the other hand shows that software is complex, the complexity grows in time and relations cannot be ignored. Due to that all the belief systems, that assume simple software, are doomed to fail. Scrum assumes, that time estimates are accurate, but they are not because software is complex. Ironically, when you start your project then your software is simple and thus Scrum will work but anything else will too. Clean coding or whatever it is called, assumes that you can remove the relations via refactoring but in fact you just obscure your code until you cannot recognize the relations any more.

    P.S. What the heck is “rotten code”?

    • http://convertwith.me/ flywebguy

      Rotten code is code that doesn’t get cleaned – even if nothing changes in your code, the webkit browser that accesses it will change, the database that it’s tied to will upgrade, etc… thereby turning it into legacy.

    • Christopher Phillips

      Great observation. I think this is the really root of the problem with Scrum as it is applied in many organizations.

      Scrum tells the PO that (s)he can prioritize the backlog into any arbitrary order. This gives the illusion that “done is done,” when this is almost never the case in a complex software system.

      It would be like writing a novel. Your editor tells you to start by writing Chapters 1, 3, and 7. A few sprints later when you get to work on Chapter 2, you realize that the story would be much better if you could go back and tweak the adjacent chapters. But if “done is done” then you should not be working on those other chapters at this point.

      Scrum reinforces the fallacy that software is composed of a set of unrelated features that can be implemented independently. Instead, the team loses velocity as the complexity of the system grows and the interdependencies increase. (The exact opposite of what happens in much-maligned Waterfall.) This is a terrible way to build a reliable system.

      • http://wendt.se/blog/ Fredrik Wendt

        Really, does it? A PO that doesn’t listen to one of the primary stakeholders, the dev team, is a fool. But don’t blame Scrum for having fools in the world. If you read up on the Scrum Guide, you’ll see that the wording has been improved _to emphasize_ that the backlog is _ordered_ in a way that brings value. The PO is responsible for maximizing the value of the work done and being accountable for listening (and not listening) to stakeholders. Now if the dev team tells the PO “this is a crazy order – you’ll build a terrible product this way”, then it’s up to the human to be intelligent and act on that information. No simple 16 page framework can shield humans from making bad decisions. I don’t think Scrum tries to, only mandate to bring transparency around the work done so you can learn what decissions where good and what can be improved. Empiricism, set goals, gather data, inspect and adapt. Yes, this requires humans to use their brains (to analyze and make intelligent decisions). No framework can do that for you. (That’s what religions try to do, right?)

    • http://wendt.se/blog/ Fredrik Wendt

      “Scrum and all the other methodologies I’m aware of pretend that software is simple, e.g. number of important relations between its components is small, or it can be made simple via refactoring, “right” design or some religious practice.”
      Interesting! What has made you come to this conclusion?
      In my experience, Scrum – a framework, not methodology – explicitly states that it’s suitable for complex product development, where uncertainty and complexity is high (keep away if what you’re doing is simpler). Scrum “mandates” continuosly investing in improvements (there’s a role specificaly set out to make sure we continuously improve our work), to compensate for the natural slowdown of a growing system (and thus needed attention to keeping the code base healthy and workable as new requirements are introduced) – how else could we “reach” the sustainable pace that the agile manifesto is so clear about?
      Scrum does not require estimates, that’s just wrong. Your organization and business model might, but Scrum doesn’t.

  • http://wendt.se/blog/ Fredrik Wendt

    Full transparency: I’m a Professional Scrum Trainer with Scrum.org. 2,5 years ago, I was not. I still code. In the rather limited training I do (~20 days per year) I mostly do technical training. My kids gets food from money I make from pushing code, pairing and setting up CD pipelines.

    I’m sorry that this is your experience of, and understanding of what Scrum is. I completely agree that this description of how it’s played out in, unfortunately is true in 99% of the cases. This is far from the only write-up on how bad things are too often run.

    Commiting to completing an amount of work, for instance, is not in the Scrum Guide – for all the reasons you’ve pointed out and a few more. Nor is estimating work – you’re fine doing nothing but gut based feeling of “is this enough to plan this Sprint?” and still play by the Scrum rules! Scrum wants Sprint goals though, to steer direction of product evolution and help the team feel as one team (as opposed to a number of people that just happen to sit close together and work on disparate things). Another idea with goals is to enable a PO to set the direction and leave it up to the (truly cross functional) dev team to do whatever smarts they can to reach that goal. (Not all contexts allow for a PO role that is with the dev team all the time, but instead spends more time with stakeholders etc.) The dev team should know enough to make decisions within the Sprint.

    There’s no sane Scrum trainer that says the Sprint backlog is cemented to any changes. That’s just borked. On the other hand, not being able to have a rough idea of what we should work on for the next week or two (Sprint) sounds very _reactive_ (to the market), instead of directed (we know what we think our product should do, let’s build and measure). It _may_ be a sign of poor understanding of your market or product’s place in that market. But I completely understand that Kanban-ish one-piece-flow feels more Agile. Especially if you live under the illusion that Scrum doesn’t allow you to ship/deliver multiple times per Sprint, such as when you’ve completed a PBI/User Story/call it what you want. Again, there’s nothing in the Scrum Guide limiting you to one release per Sprint, except _at least_ one per Sprint.

    Your description of Daily Scrums seems like a school book example of “Dilbert Standups”, something most Scrum Masters should know how to move the Dev Team away from. A properly trained dev team should also know the purpose and move away from “the three questions”.

    All in all, this is an excellent write-up of flaccid, amateur Scrum. I’ll include it in my prep e-mail sent out to my Scrum Master trainings, and make an exercise of pointing out all things they see clashing with (Professional) Scrum.

    Thanks, cheers, and may empiricism keep you on the bright path to increased agility! 😉

    • http://www.ponderyourpath.com Aaron Gray

      Hey, thanks for taking the time to post a thoughtful, balanced response from the other side of the fence. Although I personally disagree with your position on this topic, I respect that you have both the technical and business knowledge to lead and mentor the people working under you. I think that is awesome, and that folks working under people like you are a lot less likely to get hurt by unrealistic expectations or unwise practices. Take care! 🙂

      • http://wendt.se/blog/ Fredrik Wendt

        Thanks, and I’m not sure there’s a fence though. My position is that there are way too many “Scrum Masters” and “Agile Coaches” out there, who simply don’t get the basic concepts of agile, and they are hurting just as much as they are helping. I don’t have a cure, other than pointing out the flawed ideas and behaviour they present.
        Oh, yes – doing away with sprint sure allows even higher business agility, for sure! (With that I assume you mean you can ship/release after each story/card/item.)
        I didn’t have the time to make a proper writeup, but the HTML source at http://fredrik.wendt.se/2015/10/29/excellent-amateur-scrum/ contains notes on misconceptions on what Scrum predicts and don’t.
        Anyhow, thanks for your reply!

  • http://developingux.com Caleb Jenkins

    This article clearly points out how bad things can be… when things are bad.
    “start of day e-mail (where they committed to what they were going to do for the day), a mid-day standup (where they talked about what they did yesterday and what they planned to do today), and an end of day e-mail (where they talked about what they got done today and what they didn’t get done).”

    Obviously this is ridiculous as you point out in your article. Any coach worth their salt should have ended something like this immediately. I’m curious how practices like this survived your team retrospectives? Having worked on many amazing Scrum teams – that were such a breath of fresh air, after a career on waterfall projects – I find it sad that so many people seem to have had a “cargo cult culture” run in with Scrum – instead of an honest, pragmatic approach that works for the team working it.

    Scrum is incomplete by design, but it sounds like the teams you’ve worked with added all sort of bad overhead that should never have been there.

    Best of luck.

  • http://convertwith.me/ flywebguy

    this is literally what it feels like to read this article…

  • Andy Brandt

    What you describe is not the Scrum that I have known and practiced. It looks like thing I encounter in organizations that sometimes is called Scrum because this is a popular term. I think you should first learn Scrum proper and only then comment about it, as of now your comments are misleading people by entrenching their belief what you describe is Scrum. It is not.

  • Chad Howell

    Well written and insightful. Another area you could examine more deeply is Scrum’s effect on intrinsic motivation – the research summarized in Daniel Pink’s book, Drive – an excess of rules and controls undermines autonomy, diminishing intrinsic motivation.

    • http://wendt.se/blog/ Fredrik Wendt

      Here’s a thought:
      “I (PO) have an idea of what will bring value to us and our product that we’re working on. I have a vision and I think the next goal should be something like XYZ. What do you think of you (as a group of skilled programmers, designers, analysts, architects, …) decide how much work you want to plan and forecast that you can complete in say 2 weeks. Or say 3 weeks if you think that makes more sense to you. And then you, yourself figure out how to organize and carry out your work. This framework suggest you inspect your progress towards the goal we setup, together, so that you – as a group – can decide on how best put your efforts together to reach towards that goal. After some time, we’ll get together to learn what’s been completed, gather input based on what’s in the product and talk to stakeholders how we could move forward. Oh, and we’ll also start thinking a little bit about future work so we have some sense of what’s coming up next. Every once in a while, we should also stop to think about how we’re doing as a group. What should we do to improve the daily work for all of us, so that we – with a sustainable pace – as a group can increase the value of our efforts.”

      As far as I know, Daniel Pink doesn’t say that having a vision, a goal and ambition is killing intrinsic motivation. Scrum builds on two things: self-organization (which requires boundaries (you, dev team, is accountable to quality in what we build so no-one can say how fast you need to work – you “own” this, you)

      But yes, if you read Laloux’ Reinventing Organization, having one Product Owner clearly isn’t Teal, perhaps Green but could also be Orange.

      • Chad Howell

        I would be very interested to see you (or anyone else) directly rebut the main point of his argument – that Scrum is built on a fallacy “that you can reasonably estimate how long software development tasks are going to take”.

        • http://wendt.se/blog/ Fredrik Wendt

          Sure. I’d like to know what has made you think _that scrum is built_ on this fallacy?

          0) I completely agree that it’s a fallacy, nothing to debate on this point here.

          1) I agree the Scrum Guide expects the Dev Team (DT) to estimate effort/complexity/size/anything but time, and the the PO to estimate value, for all items put into the product backlog. The main point is to help the PO make some kind of decision what to say NO to (low value, high cost).

          2) Nothing in Scrum expects either role’s estimate to be accurate. It’s a guessing game. Sprint Review is all about looking at “this is what we have in the product increment, what can we learn from this? Should we ship? Should we abandon ship? Are we missing key features to make it valuable to the market?” or if you’re more progressive “these are the experiments we carried out during the Sprint, and these are the results – let’s analyze and compare to our predictions on expected change in behavriour with our users/market”
          If you have the idea that this is where you supposed to learn how poor your estimates was, so that key management people can point fingers at developers poor estimation “skills” – that’s just wrong. That has nothing to do with Scrum, at all. It’s just unprofessional behaviour from individuals who knows zip about software development (and propably as much about Scrum).

          Scrum is built on two things: empiricism (build, measure, learn cycles when we talk about products, inspect-adapt loops (PDCA if you like) when we talk about process and soft things like human interactions, aka processes) and self-organization (as a minimum: noone outside the dev team should tell them how to do their work). Neither PO, SM or any other non-dev team member should look at sprint burn-down graphs (if the dev team chooses to use such a thing, Scrum does not dictate such a thing).

          http://scrumguides.org/scrum-guide.html

        • http://wendt.se/blog/ Fredrik Wendt

          3) Scrum does NOT require a team to commit to deliver an amount of software/functionality during a period of time. (At the end of sprint planning, the dev team should be able to answer what their plan is, in order to try realize the sprint goal.)

        • http://www.kalle-online.net/blog/ Robert Kalweit

          Estimating a software development task is going to take is plain wrong.

          Mid- and long term planning (which really is just one aspect of Scrum) is based empiricism and physics:

          To know how long it takes ( t ) to cross a distance ( s ), you need to determine the velocity ( v ).

          That’s why good (!) ScrumMasters will never ask a team HOW LONG something takes. They will have a team roughly estimate the requirements in points (the unit doesn’t matter!). Just set them in relation to each other. Every developer is able to say “This requirement probably requires double the amount of work than the other.” (see – no talk of time here). Over the course of say 3 sprints, the team will get a good feeling how much of these points they finish. (Better “requirements worth these points”, but I’ve also estimated in pancakes with one team, just to show them that terminology in this particular case doesn’t matter at all.)

          Now you (roughly!!!) know the velocity ( v ). If someone asks you “When will the project be finished?”, spend limited time with the team to roughly estimate the remaining backlog ( s ).

          To find out when (roughly!!!) you’ll be done divide ( s ) by ( v ) to get the time ( t ) in “number of sprints”.

          This is a very advanced practice. I’ve done it with my “agile benchmark team” and was able to predict software development (yes, I just wrote that!) to be done 6 months in the future with an accuracy of +-5 days.

          It requires many other aspects of Scrum to be done properly:
          Good, clear user stories; regular Backlog grooming; a team knowing the domain; a performing (not forming, not norming, not storming) team! Any of this not happening decreases the accuracy and renders long-term planning useless.

          Unfortunately in most environments and probably with +50% of projects not all of the above preconditions are given. ScrumMasters and (Project) Managers believing they can still earn the (proven) benefits of Scrum without providing (or at least striving for) those preconditions don’t deserve to be called EITHER ScrumMaster or Project Manager!!! These people are doing it wrong, “helping” other people doing it wrong and thus they are the reason for well written and true, but sad blog posts like this!

  • George Barbulescu

    I came to your article through linkedin I think. I don’t have a lot experience with Scrum, but, Scrum fails I my humble opinion, of establishing a trust relation between business and development team. This is where it all starts and usually where it ends. Why, because development team has no argument in this discussion usually it is oriented on business: this feature will bring us more money, this feature will allow us to be first of our kind and etc. Unfortunately business has a lot of power here, because the money don’t come because I write some software or you, it is because that software was sold to someone that fulfilled it’s requirements. That someone doesn’t give a crap of how the software was done it’s only wish is that it’s requirements are fulfilled, I can give you an analogy in terms of cars industry, we all drive cars because there is a need to be somewhere, usually the manufacturing techniques are not so important when buying a car, but there are other like consumption, engine power etc. It’s exactly the same in software world, we can choose to see it, or ignore it, but that’s where you will end.Because of this we tend to blame everything that has related to business but not directly and instead we blame Scrum.

    I am no Scrum advocate, in any terms, but if we are blaming Scrum now instead of blaming the business side not fulfilling it’s job, than we are all hypocrites. If a business requirement is changed in the last day of a sprint, or you can not reuse some portion of the access layer in other side because a colleague was rushed to please the business, than guess what, it’s business fault not yours, you should not stay late hours to fix that, instead write them a nice email explain, that because of this everything will be stall and make them understand that, also business must understand that any change in the requirement, it will require adjustment, also business must understand that if a deadline was missed it’s their fault too. That’s what scrum should be all about, we are in this together if some part is not doing his part well, than each part will suffer. This should scrum teach essentially, instead of stand-up,retrospectives, check-in and other stuff, you should do your job and understand that it is important. If this thing is understand by both parties than Scrum can be successful, but in real world it is not always done like this and in the end we think that waterfall was good.

    I don’t like any of these methodologies written by someone who have not written a single line of code in their life, but teach development how should organize their work. I agree XP, was something outstanding in 2000’s but right now, we should understand that a thing is done when a thing is a done, there is no half play in this side, framework. libraries appear and go, what you did yesterday has a big chance of not being available today, learn to live with that as developer, and commit to your work only(and by work I mean code only), if a day was lost with meetings than that day you should not be paid for(it may sound harsh but it is a fact).

  • Aslan Kerim

    I think you are / were not in a good team 🙂 You are twisting very good my friend. But all you said is twisted things. I am sorry for you that did not understand Scrum or Agile.

  • odalet

    Long, but worth the read!
    I’d personally add another grief: Scrum tends to add unsustainable pressure on team members who are really committed to the project: unless team members are all equally committed (which is rare), the one person who is more involved will take upon herself to have things correctly done. This is a benediction for management: because there’s never finger-pointing and the team is considered a whole, the team would be blamed; but only committed members will take the criticism into account… This is very pervert.

  • Reed Schrichte

    As a full-time developer for 30-some years, I can safely say that Scrum has been more hinderance than help, another hoop to jump through, another Golden Calf to pay pious homage to publicly then sneak behind its back and get the real job of software development done. Perhaps there are places that Scrum is a good fit for, and principle has it’s place for sure, but when principle takes on a life of its own and runs roughshod over practicalities, something is very wrong. My hat is off to you, Mr. Gray, for such an authoritative accounting of the Emperor’s lack of clothing.

  • I-Scott

    I am sorry but even a few lines in it was clear that these views are not based on the true spirit of scrum but more on this is how it appears to be used in the world. I agree with @fredrik_wendt:disqus, that some time invested in truly understanding scrum would work wonders.

    • Christopher Phillips

      I don’t think it is the developers posting here who don’t understand Scrum. But for Scrum to actually be effective, YOUR ENTIRE ORGANIZATION must know how to do it correctly, and everybody who interacts with the development team must operate fully within the Scrum model.

      Even a few lines in, it was clear that these views are based on real-world observations of actual teams trying to use Scrum. The author’s experiences clearly resonate with a large group of people here.

      Is a process a good one if it is so brittle? Or so difficult for so many organizations to implement correctly and effectively? Is a process a good one if the company needs to hire an “expert” to make sure that everybody can understand how to follow it?

      Have you ever seen a traffic cop actually make traffic flow faster? To improve scrum, I would replace every “Scrum Master” with either a developer or a tester. More hands writing/testing code, and fewer arguments about what flavor Kool-Aid we should all be drinking.

      • I-Scott

        I agree, I don’t think the developers don’t understand, I think that the article is solely based on personal experience of bad scrum practises and not in looking to understand why its bad and try to improve it.

        Scrum is empirical in nature but that means you have to reflect for ways to improve it for the benefit of the team so that they can do what they are supposed to be doing. If that means having to change or remove processes then thats for the team to decide.

        If the team decide they don’t wont retrospectives so be it. If they later start to wonder why nothing is changing or management are stepping in and directing, who’s made a bad choice and should revisit their thinking.

        I believe in the team making choices in how they work and improving themselves, if they use scrum then its up to them to improve it. If they use Kanban and don’t like it change it. In short don’t moan about it, change it, before someone elses imposes it

      • http://nakedalm.com/blog Martin Hinshelwood

        I agree and would suggest that everyone in the organisation needs to level set about the expectations in Scrum, how they should interact and why. Existing Culture of an organisation is the immovable object in the way of any change.

  • witko

    Absolutely great post!

    I have had problems with Scrum for a very long time and you summed it all up nicely with very good detail to back up your points.

    Extreme Programming plus a bit of Kanban with a sprinkle of Lean Software Development can work wonders – depending on the context of your work place of course!

    I become infuriate with what Scrum has done to the great items described in the Agile Manfiesto. I think it’s such a shame that Scrum seems to be the ‘goto’ solution for ‘Agile’.

  • billy falconer

    interesting article, thanks!

    I think the key to the success of any agile team is to use a methodology like scrum as purely a framework to begin with for a new team.

    Then as the team gets to know what they are doing, they should decide which parts work for them over time. it might be also that the changes to their sprint processes are revisited several times, or even take key elements of different approaches to fit the current situation. Regular retros are vital for this to work. It also takes leadership to empower the teams to self organize so they can make delivery more efficient.

    Totally agree on the need for regular customer feedback and demos, and that devs do work in 1/2 day blocks. work prioritization are also very important, as we want to know what to work on next with the most business value. this is is often hard to get right in my experience.

    However, having a focused daily stand up / catch up is really necessary IMHO, as team communication is vital in to ensure if any item is blocked then it can be sorted out with all team members present who may have a take on the issue, therefore a good time to collaborate.

    I don’t advocate using scrum as a strictly defined process that cannot be broken – it can be used as a stick to beat teams with, not good for a teams soul.

    and by the way, I have been a developer, so understand this need as a scrum master to ensure a dev’s coding/ designing time is not wasted in any way. I think that having been there at the coal face helps agile adoption.

  • http://www.carnazzo.it/ Marco Carnazzo

    I think you just have a bad scrum master ☺

    • Christopher Phillips

      Indeed. A bad scrum master would blame the team, never the process. 🙂

      • http://nakedalm.com/blog Martin Hinshelwood

        A bad scrum master would blame anything but themselves. None of the issues described in this post are about Scrum. They are about the organisational impositions and cultural norms in this particular environment. Most organisations fail to move to wards agility because they fail to tackle the culture.

  • Seth Orell

    This resonated. Thank you for taking the time to write it up, Aaron.

  • Fredrik

    These are just some of the misconceptions that I feel that this post is full of. Unfortunately many of these misconceptions are portrayed as being the “truth” about what Scrum is when Scrum is being misunderstood and misused and then thrown out because “it did not work”.

    Some thoughts on the post, I am not addressing all misconceptions.

    On estimation. This is not specific to Scrum and is hard regardless of what framework or methodology you use. Advantage with Scrum is that you can backup your estimates with some empirical data, namely the teams velocity.
    There’s also a big #noestimates debate trying to limit or get rid of estimates altogether which I think is fully compatible with doing Scrum. Frequently delivering small pieces of work help minimize the estimation problem.
    There is also nothing in Scrum says that you need to estimate your tasks. I would almost claim that this is an anti-pattern and often waste. I don’t have any data but from my experience I think that it’s not very among teams either.

    On meetings.
    For a one month long sprint scrum prescribes MAX 8 hours of sprint planning, MAX 4 hours of Sprint Review, MAX 3 hours of sprint retrospective. and MAX 15 minutes of daily stand-up. For a 22 workdays sprint (i.e. a month) that means less than 3 days of “meetings” This is the maximum time and if you can successfully do your sprint planning in 1 hour, fine. I can’t see how this can be considered this being excessive. More important, if your team feels that there is no value in these meetings, you as a Scrum master must step in and do your job. Get to the bottom of why this is and address that, don’t just stop at “there’s too many meetings”.

    On measuring.
    Scrum does not prescribe any burndown or task estimation. If the PO is doing their job, the team will work on the thing with most business value, all the time. It is up to the team to set the standards for the technical practices and as many have said before, Scrum alone is not enough, you need solid technical practices, as does ANY team that do software development.

    On monetizing the movement. The PSM from Scrum.org costs $150, requires no course (although I would strongly recommend one) and has no annual fee. I have not attended any training from Scrum Alliance but I agree that an annual fee is flat out wrong.

    On part-time workers/co-location. I agree that out-of-office work is increasing and likely there is no way to turn the clock back on that, but do NOT kid yourself. Getting a team co-located is vastly more efficient than a distributed team. Modern tools makes remote work easier but it’s no way near the efficiency of a co-located team.
    Often you don’t have an option, you’re team is distributed whether you like it or not, but don’t think that will be efficient as a co-located team.

    Scrum is a really simple framework, but still very hard.

  • http://jasontknight.com Jason Knight
    • Claudia Spircu

      Reading this article was like a breath of fresh air for me, as I am doing Scrum for 2 years now and I always felt that something was wrong. I liked very much the idea of flow, it describes that state exactly when everything is crystal clear in your mind when programming. Every interruption brings you out of it. And for us the Scrum Master itself is an interruption by just asking if everything is OK and wanting to do some small talk!
      And I also experience with my Scrum Master that we perpetually talk about how to do things better instead of really doing them!

  • Jan

    Love this article! I used the Unified Process successfully numerous times. Scrum for me is a no go. Customers expect deadlines and milestones. Devs need 5 days or more fully concentrated on development. Scrum is anything but useful for Software projects or projects at all. I am shocked how many companies use it for enterprise projects where you need business and process modelling, use cases, UML etc

  • http://failfastmoveon.blogspot.de/ Michael Küsters

    Just stumbled across this post. Some of the things you say are not inherent to Scrum as per Scrum Guide (such as: Daily commitment) but caused by poor understanding, which typically comes from PM-gone-SM people.

    What really echoes with me is: Scrum is actually apathic towards software development. You can have a 2-day SM course without ever touching how Software is developed.
    How can you guide/coach/support a team in doing stuff you never heard about?
    How can you work as SM when you don’t even know what technical debt is, how to recognize or combat it – or what it does to the product, team and individual?
    How will software become better if you don’t deal with poor Engineering practices? Is organizational structure really the only problem when developers don’t even know what CI is?

    • http://nakedalm.com/blog Martin Hinshelwood

      🙂 I talk about and focus on Software Developer whenever I teach a Professional Scrum Master course, as do all of my fellow trainers at Scrum.org. My focus is on guided empiricism, engineering excellence, self-organising teams, and values like courage, focus, openness, respect, & commitment. Without practices, values, and engineering excellence you will never build either the right or quality software…

  • Pingback: Product Managers and Scrum – Digging Deeper Into the Framework | Pm Paul()

  • Chris Raymond

    I play the role of UX and UI designer in a smallish startup, and read this article and comments with great interest. If it’s tough to truly integrate software development best practices into Scrum, it’s even harder, in my short experience, to integrate Scrum processes with UX best practices.

    I wonder about “doing UX’ work in one sprint and then development in another, which seems like accelerated waterfall rather than Agile scrum.

    I wonder if marking User Stories as “Done” from a UX perspective, without testing any prototype in real time and iterating, is true to Scrum/Agile. This is a completely different work environment for me, and I have no basis to know if the issue is how UX work relates to Agile, vs not truly following the principles of Agile scrums. But I enjoyed the give and take here!

  • Pingback: Looking at the ideas behind SCRUM - Microsoft Dynamics CRM Community()

  • http://www.glio.co.za/ Emile Silvis

    I just read this entire article purely by looking at the memes. Well done, sir.

  • John Christian

    This was painful to read. And yes it made me laugh, perhaps not for the reasons you intended. Scrum is a skeletal framework – by its very definition you need to adapt it to make it your own. if 4 hour meetings aren’t suitable – don’t do them. if any measurement scrum prescribes isn’t valuable – don’t measure it. please. please. stop with the dribble.

  • bananaboat

    This is a soothing balm on a Monday morning. I looked at my schedule today and wanted to scream. The meetings are not long, but they are many and they are spread throughout the day in a way that gives me only about 2-3 hours at a time for anything, which for a designer and front-end developer (especially one with ADHD) is really only about 30 minutes of truly productive time.

  • yesji

    Great read. And so comprehensive too. I’m glad I chanced on this article.

    Every cogent argument against Scrum has already been covered here but I’ll offer my rant nevertheless.

    Programming is a creative task. In Preface to his Art of Computer Programming Prof Don Knuth says: “programming a computer is not only a scientifically and economically rewarding endeavor but also an esthetic experience, much like writing poetry or music”. I don’t write code — I write and rewrite and rewrite it. I begin with a certain idea in mind, and oftentimes I take it through several iterations and step-wise refinements before I stop satisfied with the result: when it not only meets requirements such as tech specs but also aspects such as elegance, simplicity and maintainability of code that no manager seems to demand from you or pay you for. (It’s not that I’m in so in love with or fascinated by my work that I lost sight of business needs and priorities. But Scrum people seem to think so, and seem to think I cannot be trusted).

    If any process can cater to this unusual nature of programming at all, it seems to me it must be one that’s loosely structured, with a lot of flexibility thrown in, which Scrum is anything but. When I stand up at one of those insufferable meetings and tell the Scrum master that I’ve canceled yesterday’s idea and am now toying with a new one, she doesn’t like it. She even panics. Am I on schedule? Why couldn’t I think through this detail when I gave the estimates? Am I up to any good at all? Scrum seems made for superhero programmers who think through all minutiae right upfront, and can almost mechanistically convert their single-pass design into code in a single pass.

    Fred Brooks said long ago in “Mythical Man-month” that more software projects failed for lack of calendar time than for any other reason.That holds true no matter what process is followed. Scrum makes it worse, because it steals time away from what the programmer knows are priorities, but must be jeopardized in favor of The Process.

    Managers have more to like about Scrum than programmers have: it gives them the illusion of insight and measurement. So does the bureaucracy that has sprung up around it: Scrum certainly created new jobs. But I have not met a single programmer who genuinely loves it.

    Putting on my conspiracy-theorist hat: Scrum seems to me like a fascist cult packaged in nice-sounding, politically correct terminology. “Self-governing” teams, for example. That’s meant to take the onus of oversight (and blame for failure) away from management and put it squarely on the team; watch out if you are new to Scrum.

    But Scrum aficionados claim the problem is not with Scrum. You are not following “Real Scrum”, they say. Haven’t we heard that one before? The defenders of every cult explain its excesses away in exactly the same words.

    • http://wendt.se/blog/ Fredrik Wendt

      Not sure where to start. I am sorry that someone called themselves Scrum Master and that you spoke to that person during Daily Scrum – you shouldn’t! The fact that this Scrum Master so clearly failed to portray two of the five core values of Scrum (courage and respect), I hope you can see is a clear tell that you’ve come across some weird shit.
      Yes, there are different interpretations and understanding of Scrum, there will always be. I think what you’ve observed is close to this excellent version of this rock classic: https://www.youtube.com/watch?v=xYLKafe9uU0

      Yes, there are scores available for this song. Yes, the Scrum Guide is out there for Scrum. It doesn’t mean everyone “gets it”, or even gets close, or that you may even recognize some key points such as core values.

  • markzona

    Thanks, this is exactly what Scrum is about. Scrum is demotivating, it wastes a lot of valuable time, and it is every expensive for the company. I absolutely hate it.

  • Ej Smith

    I found this article to be less a condemnation of Scrum as a methodology (if you’ll forgive the use of that term) than a recount of bad experiences with the improper use of Scrum, and with poor management practices in general. Of greater concern to me, however, are the numerous misconceptions of Scrum the author is perpetuating.

    It starts with the first paragraph…”The first issue I have with Scrum is that the entire system is built around the assumption that you can reasonably estimate how long software development tasks are going to take.” Putting aside the self-revelatory aspects the author’s willingness to indulge in hyperbole (use of absolutes like “entire” is a blatant tip off), a focus on the assertion that it is somehow unreasonable to expect developers to estimate levels of effort for a proposed amount of work (defined here as a deliverable, tested, working piece of code that meets pre-establish quality standards) surpasses the limits of credulity. The author seems to believe that SW development is too complex, mysterious, and/or artistic of an endeavor to measure and therefore control. Since this assertion seems to fly in the face of the tenets of responsible management it would appear an impasse is constructed right from the start: A case of don’t box me in, man VS. When might we expect something of value in return for your paycheck – not to mention all the other expensive resources we have placed at your disposal? To argue that estimation is just too hard to do seems, to me, an irresponsible cop out. Yes, it is hard, but not impossible, and over time, if we apply some discipline and employ proven methods, we can all get better at it. The last time I checked we were all being paid to accomplish difficult things, so how about we step up to this challenge rather than making excuses for why it can’t be done.

    The next assertion I found disturbing is that meetings are not useful, or even detrimental to the SW development process. Sure, poorly structured and poorly managed meetings suck, but they needn’t be that way. A good meeting is just that – good: a valuable use of everyone’s time. I believe this issue is best addressed by simply applying professional standards to our meetings, be they SW related or otherwise. This leaves the issue of appropriate meeting frequency and duration. Well, Scrum is rather explicit on the subject. There are five types of meetings, or to be faithful to the Scrum nomenclature, events: 1) Sprint Planning (4 – 8 hours for a one month Sprint (not the two week sprint the author uses); 2) Daily Scrum (15 minutes); 3) Sprint Review (2 – 4 hours per Sprint). This includes demos; 4) Sprint Retrospective (2 – 4 hours per Sprint), and; 5) Release Planning Meeting (4 – 16 hours per Sprint). So that’s a minimum of 17hrs; maximum of 37hrs. This represents 10.5% and 23% of the working hours in a month, respectively. Rounding up, that’s an average of 17%. If anyone feels that these figures represent and undue burden upon a developer who is part of a larger team that (most rightfully) depends on their presence to exchanging valuable information necessary to keep the project on course and, yes – you bet your ass, to report on progress – well… I invite you to develop a more efficient and robust method, and then buy yourself a tuxedo or gown to wear in Stockholm when you are awarded a Nobel Prize for your contributions to communication theory and practices (I’d also like a shout out in your acceptance speech :-). A last few words on meetings: The notion that meetings interrupt “flow”, or that they impose a schedule that is intrusive to the creative process… Perhaps, but you know what, Coltrane, sometimes that’s the way it crumbles, cookie-wise. Cope. Adapt. Realize, you are part of a much larger system, and that that system’s time management norms are not going to be changed simply because you, as a member of this system, find them inconvenient. Finally, flow is neither a common or sustainable phenomenon. As many athletes and musicians can attest, it is a wonderful thing, but never something that should be relied upon for success. If people only performed well when they achieved flow, then not much of anything would ever be achieved. As a manger of mine once said: Sometimes a job is a job.

    I could go on, but who’s got the time. I’m not trying to sell a book here. I simply wished to point out why I found this article to suffer from a rather insular and self-regarding perspective that fails to account for the larger picture i.e. SW development exists within the context of a business ecosystem. If the counter-argument is that SW developers would be more productive and produce higher quality code if they were just left alone, I would then point to decades of failures produced with that approach. Scrum, like any other SW development cum Project Management methodology seek to bridge key aspects of the perennial communication gaps between developers and management. Is it perfect? Hell no. Is it useful? I think so, and so do millions of developers and others whose responsibilities extend beyond cranking out code.

  • http://www.gugames.eu Guga

    I always hated all these fads and buzzwords and fancy ways of thinking that code happens by magic instead of having people sit in front of a screen thinking. I always felt, whenever I spoke with managers or masters or whatever, that they were too self-fulfilled with saying “if we stick to this ritual we will produce code”, and I could’t disagree more with their vision. Yes, you can tell I’m a developer.

    But I must admit Scum has its advantages, if you don’t get too catholic about it. I worked at a small company that was basically a subsidiary for $other_company, we had our own products but 99% of the team was working on $other_company_software. We didn’t work with Scrum, we just… developed. And it was quite frustrating. I have no idea how they planned their things at $other_company, but I often had my project leader, which was a developer from $other_company, randomly deciding that I had to develop parts of the projects. He was basically just programming, then noticing something was needed and saying “hey Guga, develop this”. I was his library. I hated it.

    Then I left and entered another company where we do Scrum. I hated it in the beginning, we all hated it, and it showed. We never played poker or whatever, everyone just estimated his own tasks and we deducted numbers every day from the chart. But then we abandoned that. We noticed that it made absolutely no difference to our work. The numbers seemed random to begin with, but then it happened for example that someone found a quick and clean way of implementing something that was thought to be a looooong task… and he had to deduct almost all his estimates from the chart. It happened more than once. That was definitely going to distort the whole burnout estimation, leaving us with no means of telling whether we still were producing enough in the sprint. You know that false sense of accomplishment when you think that, since you solved the big thing quickly, you have enough time, so you begin to work less concentrated? Well, you can see where this is going.

    In the end, we said “let’s forget about Scrum”. We kept the user story structure, the sprints, daily standups before lunch and sprint reviews. But estimation became “I think I have enough to do for these weeks”, we have no burnout charts. And we’re extremely efficient with that. I’ve never worked better.

    I feel that a development process is like a soccer coach. Having good schemes and knowing how to put the players on the field can help you a lot, but in the end, matches are won by goals, and goals are scored by the players. The best coach in the world with a team of amateurs would lose all his matches against the best players in the world without a coach. And so is Scrum: even if you follow it perfectly as it is intended, software will be written by the developers. You can’t just glorify Scrum, because it won’t work for everyone.

    • http://www.ponderyourpath.com Aaron Gray

      Good thoughts, thanks for sharing. 🙂

  • Pablo Lascano

    Thanks for this post, I have really enjoyed reading it.

    A lot of “you are doing it wrong” comments. I’ve even read that “this is true in 99% of the cases”. So, even when only 1% of the cases “are doing it right”, is not Scrum fault, is fault of the 99% of the cases that does not understand the Scrum Guide. Well, when 99% of the students fails the test, is not theirs to blame…

    • http://www.ponderyourpath.com Aaron Gray

      Very well said. 😉

    • http://wendt.se/blog/ Fredrik Wendt

      It’s always about perspective, right? 🙂
      I fully agree the Scrum Guide alone has been terribly ineffective.
      I know both Ken and Jeff has great belief in humanity and the intelligence of individuals: provided a small framework with explicit steps in the process to inspect/reflect and adapt, people will figure out how to find a sustainable way of working (one of the principles from the Agile Manifesto).

  • Marcello Dias

    Hello Aaron,

    In fact Scrum is so terrible,that in one article you can´t explain how it is bad.
    I wrote one myself with my 2 cents,explaining why I think Lean Kanban to be a thousand times more realistic,and effective.

    https://www.linkedin.com/pulse/why-lean-kanban-much-better-than-agile-scrum-marcello-oliveira-dias?trk=pulse_spock-articles

    • http://www.ponderyourpath.com Aaron Gray

      Just read your article. Thanks for sharing your experiences. 🙂

  • Pingback: Spreading agility is no mathematics: the benefits and pitfalls of scaling frameworks - Henk-Jan van der Klis()

Back