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.

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:

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. 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. 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.

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.

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.

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.

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.

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.



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 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.

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.

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.

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?”

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.

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.

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) 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.

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.

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!

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.

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.

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.

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.

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.

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.

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:

Encouraging dev’s to work overtime when they haven’t fulfilled their commitment by the end of day (sustainable pace fail) Encouraging dev’s to ignore craftsmanship and just push stuff out there (quality fail) Giving management the illusion of control over how quickly stuff gets built (reality fail) 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.

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

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.” 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. 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!