Like any and every business theory, Scrum has one or two core ideas that are awesome, but could be explained adequately in a paragraph or two. This does not sell books and consulting, so it evolved into a field of its own.
The fact that there is so much B.S. in Scrum doesn't mean that it has nothing of value to offer, though.
Here's what I get out of it:
1. Sprints are a better way to organize than Waterfalls. I've experienced this over and over again personally, so I'm sold on this.
2. It's important to stop what you're doing on a regular basis to evaluate progress and problems. This always seems like a waste in the moment, but failure to do so leads to regret down the line.
3. Ship functional products as frequently as possible. This is better than waiting until everything is done, because you can get feedback early and often from the end user.
I think you are entirely right that the "sell books and consulting" is a major driver of what Agile became. I got involved in the Agile world circa 2000, but by 2010 or so my main feeling was increasing horror: http://agilefocus.com/2011/02/21/agiles-second-chasm-and-how...
One of the especially interesting things to me was that at the beginning there were a variety of different methods. People behind them got together in 2001 to figure out what was common, and that's where the Agile Manifesto came from. Of the Agile Manifesto signatories, I think only two of them were Scrum people. These days, though, most people thing that Scrum is Agile and Agile is Scrum.
I see three reasons for that. One, Scrum was the simplest, arguably the lowest common denominator; it had no technical practices. Two, it could be installed in place at existing waterfall companies doing what is effectively mini-waterfall, so there would be little disruption to the hierarchy. And three, it had a "certification" program, where a) anybody wanting a career bump could spend 2 days to get a "Master" certificate without taking any test or proving any competence, and b) any "consultant" wanting easy money could quickly become a Scrum trainer. Basically, Scrum became the Amway of software processes.
If you go by actual behavior, it turns out the highest priority at most companies is not actually to improve, to get better at making things for users. It's instead to make managers and executives feel like something is being done without disturbing the power hierarchy. Low-end Scrum fills that need adequately, letting you move marginally in the direction of agility, apply some new labels, and declare "mission accomplished".
And my point here isn't "Scrum bad", really. There are some great people in the Scrum world. My point is, "Business models shape outcomes, so be careful which you pick."
My experience is that a good team does a good job. A bad team doesn’t.
I think the focus on methodologies is to get a good result from an uneven team. Companies desperately want to treat programmers like standardized workers that can be mixed and matched as needed. The siren song of the methodology is that maybe it can achieve that goal. I have never seen this work in practice.
There are no quick fixes. People can improve but it takes time, dedication, and support.
Great job distilling the essence of scrum into three bullet points, I wouldn't disagree with those.
Here's the common pitfalls as I see them:
1. Sprints offer flexibility but unless you educate the whole company waterfall + gantt charts are what the business side wants
2. Unless you educate all members of a scrum team on what the retrospective is, and let the developers drive it, you won't be effectively improving processes
3. I've always felt conflicted about the agile "working software over comprehensive documentation value". To me it implies that documentation is easier when the product is working and/or the product might change based on feedback, so you don't want to re-write the docs. To people who don't learn scrum/agile it means "don't write documentation"
You're describing having a well defined goal, setting a critical path, and then regularly updating your progress. What we gray beards used to call "project management".
Another observation I have had, it provides much clearer and realistic progress reports to management. You can track the normalized points per day executed by the team to see their overall velocity. You have clear check points about what has been accomplished (which is why a shipped product is critical, it removes any chance for something not to meet DOD)
On the dev side, I have never attended so many meetings. Technical debt being addressed is generally against the feedback loop, unless the PO/Leads of the team make it their first priority. Grooming meetings are a mix of people who care, those who don't, and vague stories. To save time, any new story got sent to one of the devs for a sniff test before grooming, to help ask critical questions early. Typically, the request is reasonable, but may run into a contradiction of the system.
I have also found that, forcing scrum (or waterfall) on a product that is running at a difference release methodology is horrible. Got a customer that needs a new thing built by a specific date? That won't fit, unless the date is flexible and customer stake holders can be deeply involved in the process. Waterfall at least forces the customer to define the project up front and allows for calling out changes to the plan and thus changes to the scope.
As with all the above, this sits on how skilled your project manager/scrum master/product owner are at their jobs. Anti patterns abound.
Sprints are a shit idea and need to die a horrible death. The number of times we've had to break up some functional requirements for no reason other than to meet some stupid concept isn't funny ultimately it's a waste of time in itself
I can probably agree that sprints are usually more realistic than old school waterfall (arguably it depends, like all things) but why do we feel the need to perpetually sprint?
A simple kanban board seems to give all the same benefits without the constant pressure and weekly death march to meet the end of sprint commitments.
> 2. It's important to stop what you're doing on a regular basis to evaluate progress and problems. This always seems like a waste in the moment, but failure to do so leads to regret down the line.
This point is of general usefulness and applies to many areas of our lives, not just software development.
"This does not sell books and consulting, so it evolved into a field of its own."
Exactly. This is why it's stupid when managers get all hyped up about <present software development trend/> and decide everything needs to be shaken up based on what they learned at a seminar or heard from some consultant/"coach".
For the most part, those 3 points seem like easily understandable ideas, and have been used in some form by other industries, such as manufacturing, for a long time before they were presented for software development. Replace "PM" or "Scrum Master" with "Foreman" and you can get the picture of what activities are involved with a worker managing other workers and the work that gets produced.
There is so much over-complication with the current system of methodologies and nebulous acronyms that accompany it[0]. There's SAFe, Agile, Scrum, Scrum of Scums (recursive scrum??), RAD, LeSS, etc. It gets confusing and messy very quickly. Instead of focusing on doing the work, it's easy for managers to get swept up in the semantics of these frameworks and end up hurting the work by over-thinking and over-applying the principles on the workers. Scrum methodologies are guidelines that can be tweaked to fit the situation, and don't have to implemented if they don't make sense. Instead of thinking "Does this make sense?", the manager/business side tends to think "Well, it worked for X, so it must work for me!". Scrum is an editable template that should help eliminate wasted effort and mindless work, and if that's not the case then it isn't being done right.
My mental model was that ideally it is a greedy algorithm for job shop scheduling (dev time) with dt = two weeks and a horizon as long as your backlog. The biggest and most common failure mode I saw was having a bad product owner (it can be a single point of failure, devs have a team to help them out).
I completely agree. I don't get why people try to strictly follow the methodology (and then complain about it) instead of just taking the core of it and apply what work for them and their company.
I've a SCRUM master certification and still, I follow only what's good for us.
It's totally fine for me to add a task in a current sprint. If you care about finishing the sprint, you just move a task of same points back in the backlog.
It's also totally fine to allow the technical lead to add his own tasks to the sprint. You can do 80/20 for instance (business/technical values). It's not going to kill your business and will make your developers happy (SCRUM is about people, not process, right?).
>1. Sprints are a better way to organize than Waterfalls. I've experienced this over and over again personally, so I'm sold on this.
There are so many people who say, Agile or Scrum, respectively, do not need specs, the specs are just incremented with every sprint as the product itself, leading to software projects with undefined goals and overlong project time
I feel like the books and consulting came from the fact that Scrum, while it can be explained in a paragraph or two, is very hard to reconcile with the idea that what the business wants is for you to be able to guarantee that you'll be "done" (and define exactly what that means) by a particular date in the future.
I'd like to add priority next to progress and problems in the second item. Being able to pull things in and out of planning is one of the biggest advantages over waterfall.
You’re absolutely right - and that’s the e tire core point of Scrum: to promote agile methodology (which can be summed up as you just did)
However the reason there is “bs” (by which I assume you mean the process/meetings/etc) is that most teams suck at being agile. Scrum provides a more rigid framework so that a team can develop agile skills and then, when ready, move beyond scrum.
Most people think Story Points or terminology like Standups comes from Scrum too - they don’t! They’re from XP.
Scrum is exceedingly simple and suffers from being over complicated and dismissed by those who don’t understand it,
I find this article lacking, because it makes all of the same mistakes typical of these bandwagon anti-Scrum articles.
Despite working in a a Scrum team, I recognise literally nothing of the problems that are described. Our product owner works closely with both commercial and development groups to build the backlog. Pressure to build good technical solutions is reasonably balanced with commercial requirements. The development team is empowered to step in and request product changes when they think it's necessary. This happens because we are a team of skilled professionals who want to deliver working things at reasonable pace, and this applies to both commercial and development groups.
There is a weird underlying assumption in these kinds of articles that implicitly seems to assume that Scrum will somehow turn a bad team into a good one. I have no idea where that comes from. A team using Scrum still needs skilled people who know how to do their jobs effectively – and that includes the scrum master and product owner roles. Introducing it into a good team can then help to reduce the impact of common software development issues. It doesn't work for every company, team, or product – but that doesn't mean its without value.
I'd be more interested in articles that talked a little about better processes that we can use. I'm absolutely open-minded about the idea that there are other legitimate and effective ways to deliver software other than Scrum, because it's obviously the case. "These are the problems with Scrum and this is why they aren't a problem in <other process>" is more valuable than "If you have a bad team then Scrum is bad".
Having worked at primarily at “informally agile” software companies in Silicon Valley (and I count Google as one), I see an important bit of truth in the article that Scrum ideas have become the embodiment of agile, and ideas from Scrum that may not make sense in isolation have become standard practice in software development and are somehow seen as the alternative to “waterfall” development, even if they have nothing inherently to do with waterfall vs agile development.
For example, it’s
never made sense to me to have a powerful product owner while treating the development team as N interchangeable workers who may have “areas of focus” but have no roles, responsibilities, or organization among themselves, smearing out any sort of power or responsibility for technical quality like butter spread on toast. And yet, the fact that Scrum says to do it makes me wonder if that’s why everyone does it. Reading Scrum’s idea of a development team made me facepalm.
I don’t think the article is attacking a straw man that Scrum can turn a bad team into a good one. It may be pointing out that Scrum is regularly used to turn a good team into a bad one. Because everyone wants to be “agile,” even if they never use the word Scrum, they are implementing bad Scrum or cargo-cult Scrum by default.
I recognize the disfunction. What happens is that the owner of the backlog becomes the controller of how much time gets spent on what. With feature pressure, it's all new features all the time, with no scope to address debt.
> There is a weird underlying assumption in these kinds of articles that implicitly seems to assume that Scrum will somehow turn a bad team into a good one.
This assumption starts with one of the earliest Scrum pioneers, Jeff Sutherland. He writes quite clearly that he doesn't care about an individual's performance, but rather a team's performance. He also talks at length about how poor performing teams can be turned into high performing ones by the implementation of Scrum.
You can agree or disagree with him on this (I'm on the fence), but it's not at all weird that this idea is found within Scrum. It was there from the get go. It's there by design.
> A team using Scrum still needs skilled people who know how to do their jobs effectively – and that includes the scrum master and product owner roles.
That is my key beef with Scrum here. I entirely agree that done well Scrum can be effective. But how it is often done is not well at all (e.g. the two day Scrum master training course.)
I'm criticising Scrum as it's widely implemented and how that is poisoning the groundwater for all agile methodologies.
And definitely I'll get on to how other processes can be better.
To hear about better processes, you'd have to time travel back to the 90s, go thru PMI training, work with experienced project managers, earn your sergeant stripes.
> Despite working in a a Scrum team, I recognise literally nothing of the problems that are described.
Same. This process takes work, requires buy in by all levels of the company and needs to be fully understood including its error cases. It takes time and requires course correct and attention. Its not easy but done right it is effective.
I think very, very few articles actually want to touch on the reason that Agile/Scrum goes bad: Lack of management/client buy in. If management or the client aren't going to work in an agile manner as well, then that just puts the devs at a disadvantage, and makes for a crappy work environment. Devs lose any agency they had in terms of what to work on, and as a result become disgruntled and stop caring about the work.
My initial thoughts...of course Scrum disempowers developers but that's not what the article is about. I see a hyperbolic title and a bunch of complaints about how "in the real world" things work differently (entrenched opposition will always sabotage progress).
What is a manager but someone who has control over the controlled? I'm surprised with so many ppl nodding their head at this list of complaints about bad software processes at bad companies, masquerading as analysis. If you think it takes more than 2 days to learn _how_ to be a Scrum master, you don't understand the role. It's not complicated, difficult, and time-consuming enough to require a singular employee...unless your process is already screwed up. Good luck finding whatever magic bullet you think will save you that isn't Scrum-based teams.
No, it's the other way around: those arguing against SCRUM don't have to tell their reasons (bad experience suffices), but SCRUM proponents must come forward with logically sound and coherent arguments pro-SCRUM in the first place.
My biggest beef with Scrum (and why I think it's a scam) is that they renamed everything, all the processes.
Historically, there are three important sides, and roles, for each project. Product management - takes care what the customer wants to have build. Project management - takes care of what is delivered is on schedule and that there is enough material/personnel to build it. Architect/engineering lead - takes care of whether the thing is technically feasible, what technologies are used and what technical trade-offs are made.
And there was a vast literature and discussion about how these three sides affect the result of the project, and how to solve these problems.
Unfortunately, Scrum, renaming everything, acts as if the history of project management doesn't exist. And if you forget history, how are you supposed to learn from it? That makes it easy to sell snake-oil. I frequently hear, for instance, that scrum master is not a project manager, despite him having some responsibilities in this area.
And as the blog post also expounds, there is no recognition for these three different sides of each project in Scrum (ironically, there is some recognition of that in Scrum derivatives such as Scaled Agile Framework, for instance, modulo nonsensical renaming of the roles).
> the product owner often works alone and the development team simply receives a stream of backlog items that need to somehow be brought into a cohesive whole
This is the root of the problem in my opinion.
I am not interested in defending "Scrum", I don't like what I know about it, in the few experiments I've been involved in with it (not by choice), I agree it was disempowering to developers, trying to treat developers like commodities.
However, I am a fan of trying to do things agilely (iteratively, figuring out what to do next in relatively short chunks without trying to plan out the next year+).
In the experiences I've had where this _worked_ the product owner was _intimately_ involved with the development team, with lots of communication in both directions, with the development team's info and feedback effecting how the product owner prioritized and determined (and changed, agilely) acceptance criteria.
The product owner had to embrace/accept that this would be a significant time and energy commitment to them, they could not be looking to minimize their time here, and had to accept that "with great power comes great responsibility" -- that they needed feedback from developers to make these decisions properly.
On the flip side, through these good experiences, I also learned that a good product owner is _so important_ -- as a technical decision-maker I don't _want_ to be responsible for determining product priorities or acceptance criteria. I want my feedback to be taken into account, but having someone else (who is good at it) be _responsible_ for it let's me focus on applying technical excellence to achieve the goals set by the PO, and takes _so_ much pressure and anxiety off of me. Especially when I can trust them to know what they are doing it and do it well (just like they can trust me to execute well).
I _do_ think the development team needs a "technical lead" in addition to product owner, not just an amorphous bunch of people "self-organizing".
Pretending to do agile seems to be widespread thing in our industry. There are literally no companies out there not claiming to be agile. So, the word has become meaningless. Scrum is the lowest common denominator in our industry when it comes to that.
Agile implies getting things done and getting things to market. If scrum helps you do that great. If not, ditch it. In my experience, Kanban is a step up on the evolutionary ladder. Both have issues with not prioritizing essential activities related to research, refactoring, etc. that you need to guard against. There's a difference between agile and firefighting.
One worry with scrum is the roles of product manager and scrum master. In my experience these things end up being formal job titles in bigger organizations. This is bad because they are typically on the very low end of the scale. That means you end up with the least experienced people filling these roles and a lot of corporate politics. I've seen more than a few organizations that were hiring accordingly.
Our weekly "why scrum sucks" post that's really a "why my company does scrum wrong and I don't know how to fix it".
Product owners push customer value. Of course. You should too. Code quality and refactors have business value. Reduced maintenance cost, fewer bugs, faster future dev. If you can't explain that to your product owner then maybe it's not worth doing. I think your big missing piece is the collective ownership aspect. Product owner gets to set priorities, but it should be a collective discussion. Every dev should be allowed to express their opinion and it's the job of the product manager to referee.
If you do Scrum like that, you're doing it wrong (I know, no true Sctosman [1], and I know, there are actually dark patterns [2]).
I wrote a whole book about "Agile Anti-Patterns" [3]. Most of the book's content is about things that many companies get wrong when they start with agile or lean software development. Because it is very easy to get those things wrong.
Yes, those problems are extremely common. Not only with Scrum - Organizations also face those problems when they try Kanban or SAFe or whatever. Because, change in a traditional organization is hard. And to really implement Scrum, you'd probably need to change more about the organization than the org was willing to change.
But those problems are not Scrum's fault. If the team has no power, it is also not truly self-organized. And the Scrum Master is not doing their job.
You could start to improve by creating awareness about the problems. Blaming Scrum may or may not be a good idea to do that - Because, some people in your org may be invested in Scrum. Some mentoring or coaching for your Scrum Masters, Product Owners and developers and managers might be a better start.
I think the value I get out of Scrum, or XP, or any other methodology, is two-fold.
Firstly, it gives you a set of tools to use -- sprints, TDD, product owners, and so on -- that should work well together. To use them well, I think you both need an understanding of how each of those tools supports some idea or principle that the methodology promotes, and whether or not you think that principle is important for your team.
Secondly, a methodology gives you a starting point of how to run a development team. It's easier, although not necessarily better, to start from a pre-existing cohesive set of practices than to build a process from scratch. Especially if a team isn't experienced with many of the ideas, this is not an unreasonable place to start.
I think the key is:
1) knowing what principles your team thinks is important (low defect rate? frequency of releases? developer happiness? empowerment?). This is often hard to articulate. As time goes by, you might discover principles that were previously implicit, or you might find that the principles that are important to you change.
2) knowing how each part of your process maps back to one or more of those principles
3) having a mechanism that allows you to tweak your process over time (for instance, retrospectives), whether that's adding, changing or removing parts of your process
Scrum can be a sensible starting point so long as you're willing to introspect and consider which bits are and aren't working for you, and you're empowered to do something about it.
One would expect Scrum to disempower developers. After all, it is a management methodology (yes, I know some will protest at this label), and it emphasizes those things as a result. Any resemblance to software development methodology has long been lost, if it was ever there at all.
That said, an entire industry has emerged to sell this methodology, and it is supporting a vast array of jobs: everything from those selling the certifications, to the software used to track developers. There are too many vested interests now, and no company wants to admit that it burned through thousands of dollars, with dubious results, to "train" managers and subscribe to the usual software bundles.
I expect the comments here will also have the usual comments about how Scrum is great, and everyone who is critical of it is just doing it wrong.
The teams I've been on that just 'jive' usually start with some process framework but then evolve to just work well together.
There are strong philosophies in Scrum and Agile that should be kept as guidelines. The key is being agile (lower case 'a') so you can adapt to changing priorities. Continuous Integration/Continuous Delivery go a long way towards empowering developers.
Two ways to tackle technical debt in projects:
1. Tech debt sprint. If scrum master and product owner can't get onboard then they need to realize somewhere in the near future, a feature they want will either break things or take forever.
2. Break up tech debt into small efforts someone can do in short time boxes. Even do feature flags or something to make slower progress towards a goal rather than tech debt sitting in a backlog for months.
An example of a guideline is estimation with planning poker. We completely ditched estimation activities. The estimates were usually off and not good predictors of completion. The team has a cadence of ticket completion and the 'sizes' of the tickets vary some but you don't need to waste time estimating. Developers (humans) are horrible at estimating. Having a good PM/PO set expectations with the business helps.
> Scrum has become the de facto definition of Agile
That is a part of the problem. Scrum is very far from Agile. Scrum introduces processes and tools while the Agile Manifesto [1] clearly states:
> Individuals and interactions over processes and tools
That said, Scrum isn't entirely bad. Its just not what many people think it is. As a tool to change the culture of a company that has been shaped by classical project management methods for decades it is very valuable. But the process shouldn't stop there as Scrum isn't the end, its the start.
So companies which managed to implement Scrum should try to move on to more Agile practices to transform their culture over time.
I've had a lot of success working with teams that use scrum practices and agile values. Many team members (like several developers and testers) have actually gone on to become scrum masters themselves at different companies. The feedback I've gotten is that it's an empowering way to work - you choose your commitments, team aligns around a goal, priorities stop constantly changing, teams make time to improve the things that slow them down, etc.
It's hard for people to go back once they've seen it work. The people that I've worked with have said that when they do move on to other companies they didn't realize how helpful it was until it was gone. It can seem like some bullshit, I get it. It's change. It's not a perfect model. Also, when leaders or teammates behave in a command-and-control and uncollaborative way, it's a lot less fun.
Biggest personal challenges: connecting team members to real clients, integrating UX (need more people and up-leveling of team members), too-stable of teams (I like forming around new ideas and the excitement of that), being distributed, the language (Scrum Master - really?!!?), perscriptive agile peers
What’s that quote from Elon Musk - process is an excuse for large companies to keep mediocre talent?
Put enough smart people in a room and they’ll figure it out. Scrum isn’t any worse than Kanban or ‘pure’ Agile or Waterfall or Lean — every system has tradeoffs and smart people learn to adjust.
No company is perfect. Tell management how the process can be improved. If they ignore you, consider moving on.
OP here: lots of people have written about problems with Scrum (e.g. https://news.ycombinator.com/item?id=16892307 ). I'm trying to take a bit more of a systematic, longer, researched and justified view of things, so any feedback is very welcome!
I think the article confuses what Scrum is and what some (probably most) companies make out of it. I agree that there are scary things happening in practice and I've seen a lot of scrumBut and scrumAnd that really endangers a lot of projects.
My experience is that this is often caused by a lack of understanding of the methodology and how it can be applied and integrated into existing structures.
Also existing structures need to be integrated with Scrum to make it work. That is, they need to be transformed to match agile workflows.
The latter is not easy. Especially not in larger companies. I am not surprised that most do not even try to tackle this.
For me Scrum is like training wheels for agile. It’s restrictive and hinders progress at any real speed, but gives you the framework to start producing stuff in an agile way. Once you out grow it there are plenty of better methodologies, include the proper agile way which is that the structure of your product management is also a component to be iterated. It’s difficult to jump straight in at that point though.
Just a shame that most teams’ processes crystallise around Scrum. Working with self described Scrum masters is painful as they’ve built themselves into a box they can’t see out of.
This is a good article, but I disagree that Scrum's major flaw is a lack of hierarchy on the development teams. I've worked on some great self-organizing teams, and they're more than equal to the product manager. They outnumber the PM, after all.
The problem only comes in an organizational culture of "whatever the boss says". In that context, teams rarely learn to self-organize. Instead, the previously existing control hierarchy stays in place. Before, developers built whatever spec landed on their desk. Now they build whatever is in JIRA. Developers in that world can't even conceive of pushing back.
It's my belief that if Scrum had had some strong counter-balance to that, like an Engineering Master, then it just wouldn't have been adopted. Scrum won out over the other Agile processes (of which there were several) not because it produced better results, but because it was the one most comfortable for medium- and large-company managers. It provided the feeling of transformation without actually changing anything important. They were doing waterfall before, which became untenable with the rise of the Internet. Now they do mini-waterfall, call it Agile, and imagine themselves kings of the world.
https://age-of-product.com/agile-micromanagement/ another interesting observation along this line; when the scrum master is a middle manager then he will micro manage the show - because that's the way he is supposed to function.
Empowering the workers is a good idea, but it is not how most organizations work.
I agree with the criticisms of Scrum on the whole. However I find it bizarre that this article and the other one it links to (which quotes Milton Friedman, which ought to be enough to raise eyebrows by itself) crticises organisations which market themselves as non-hierarchical (or in the marketing lingo 'holacracies') when they clearly adhere to hierarchy if you think about it in any depth, just a badly organised one.
Edit: And I guess my real point here is that Scrum doesn't usually work because the development team as a whole has no way of pushing back on decisions made by the overall business hierarchy unless they just go tools-down.
Then it goes on to crticise Valve for not delivering HL3, despite that clearly being a successful business (and one where Gabe has over 50% of the $2.5 billion equity valuation... non-hierarchical, sure, whatever you say) - perhaps all of this emphasis on shipping products as fast as possible and no emphasis on the service and the interests of staff is the real problem here.
[+] [-] nickelcitymario|7 years ago|reply
The fact that there is so much B.S. in Scrum doesn't mean that it has nothing of value to offer, though.
Here's what I get out of it:
1. Sprints are a better way to organize than Waterfalls. I've experienced this over and over again personally, so I'm sold on this.
2. It's important to stop what you're doing on a regular basis to evaluate progress and problems. This always seems like a waste in the moment, but failure to do so leads to regret down the line.
3. Ship functional products as frequently as possible. This is better than waiting until everything is done, because you can get feedback early and often from the end user.
Okay, so that's 3 ideas. It's better than most.
[+] [-] wpietri|7 years ago|reply
One of the especially interesting things to me was that at the beginning there were a variety of different methods. People behind them got together in 2001 to figure out what was common, and that's where the Agile Manifesto came from. Of the Agile Manifesto signatories, I think only two of them were Scrum people. These days, though, most people thing that Scrum is Agile and Agile is Scrum.
I see three reasons for that. One, Scrum was the simplest, arguably the lowest common denominator; it had no technical practices. Two, it could be installed in place at existing waterfall companies doing what is effectively mini-waterfall, so there would be little disruption to the hierarchy. And three, it had a "certification" program, where a) anybody wanting a career bump could spend 2 days to get a "Master" certificate without taking any test or proving any competence, and b) any "consultant" wanting easy money could quickly become a Scrum trainer. Basically, Scrum became the Amway of software processes.
If you go by actual behavior, it turns out the highest priority at most companies is not actually to improve, to get better at making things for users. It's instead to make managers and executives feel like something is being done without disturbing the power hierarchy. Low-end Scrum fills that need adequately, letting you move marginally in the direction of agility, apply some new labels, and declare "mission accomplished".
And my point here isn't "Scrum bad", really. There are some great people in the Scrum world. My point is, "Business models shape outcomes, so be careful which you pick."
[+] [-] mmusson|7 years ago|reply
I think the focus on methodologies is to get a good result from an uneven team. Companies desperately want to treat programmers like standardized workers that can be mixed and matched as needed. The siren song of the methodology is that maybe it can achieve that goal. I have never seen this work in practice.
There are no quick fixes. People can improve but it takes time, dedication, and support.
[+] [-] nwhatt|7 years ago|reply
Here's the common pitfalls as I see them:
1. Sprints offer flexibility but unless you educate the whole company waterfall + gantt charts are what the business side wants
2. Unless you educate all members of a scrum team on what the retrospective is, and let the developers drive it, you won't be effectively improving processes
3. I've always felt conflicted about the agile "working software over comprehensive documentation value". To me it implies that documentation is easier when the product is working and/or the product might change based on feedback, so you don't want to re-write the docs. To people who don't learn scrum/agile it means "don't write documentation"
[+] [-] specialist|7 years ago|reply
[+] [-] mey|7 years ago|reply
On the dev side, I have never attended so many meetings. Technical debt being addressed is generally against the feedback loop, unless the PO/Leads of the team make it their first priority. Grooming meetings are a mix of people who care, those who don't, and vague stories. To save time, any new story got sent to one of the devs for a sniff test before grooming, to help ask critical questions early. Typically, the request is reasonable, but may run into a contradiction of the system.
I have also found that, forcing scrum (or waterfall) on a product that is running at a difference release methodology is horrible. Got a customer that needs a new thing built by a specific date? That won't fit, unless the date is flexible and customer stake holders can be deeply involved in the process. Waterfall at least forces the customer to define the project up front and allows for calling out changes to the plan and thus changes to the scope.
As with all the above, this sits on how skilled your project manager/scrum master/product owner are at their jobs. Anti patterns abound.
[+] [-] termau|7 years ago|reply
[+] [-] ownagefool|7 years ago|reply
A simple kanban board seems to give all the same benefits without the constant pressure and weekly death march to meet the end of sprint commitments.
[+] [-] mraison|7 years ago|reply
[+] [-] Uberphallus|7 years ago|reply
It's funny how it turned into UML
[+] [-] dvfjsdhgfv|7 years ago|reply
This point is of general usefulness and applies to many areas of our lives, not just software development.
[+] [-] siruncledrew|7 years ago|reply
Exactly. This is why it's stupid when managers get all hyped up about <present software development trend/> and decide everything needs to be shaken up based on what they learned at a seminar or heard from some consultant/"coach".
For the most part, those 3 points seem like easily understandable ideas, and have been used in some form by other industries, such as manufacturing, for a long time before they were presented for software development. Replace "PM" or "Scrum Master" with "Foreman" and you can get the picture of what activities are involved with a worker managing other workers and the work that gets produced.
There is so much over-complication with the current system of methodologies and nebulous acronyms that accompany it[0]. There's SAFe, Agile, Scrum, Scrum of Scums (recursive scrum??), RAD, LeSS, etc. It gets confusing and messy very quickly. Instead of focusing on doing the work, it's easy for managers to get swept up in the semantics of these frameworks and end up hurting the work by over-thinking and over-applying the principles on the workers. Scrum methodologies are guidelines that can be tweaked to fit the situation, and don't have to implemented if they don't make sense. Instead of thinking "Does this make sense?", the manager/business side tends to think "Well, it worked for X, so it must work for me!". Scrum is an editable template that should help eliminate wasted effort and mindless work, and if that's not the case then it isn't being done right.
[0]https://en.wikipedia.org/wiki/Scrum_(software_development)
[+] [-] salty_biscuits|7 years ago|reply
[+] [-] ggregoire|7 years ago|reply
I've a SCRUM master certification and still, I follow only what's good for us.
It's totally fine for me to add a task in a current sprint. If you care about finishing the sprint, you just move a task of same points back in the backlog.
It's also totally fine to allow the technical lead to add his own tasks to the sprint. You can do 80/20 for instance (business/technical values). It's not going to kill your business and will make your developers happy (SCRUM is about people, not process, right?).
[+] [-] wolfi1|7 years ago|reply
There are so many people who say, Agile or Scrum, respectively, do not need specs, the specs are just incremented with every sprint as the product itself, leading to software projects with undefined goals and overlong project time
[+] [-] nlawalker|7 years ago|reply
[+] [-] tomtimtall|7 years ago|reply
There is definatly a lot of companies peddling hype around scrum but it has a very lean and strong core which is in no way pulling in that direction.
[+] [-] walshemj|7 years ago|reply
One of the problems with the Scrum model is its used for every thing - just like they used to try and do every project with WF and IS9000/BS5750
[+] [-] jayd16|7 years ago|reply
[+] [-] abritinthebay|7 years ago|reply
However the reason there is “bs” (by which I assume you mean the process/meetings/etc) is that most teams suck at being agile. Scrum provides a more rigid framework so that a team can develop agile skills and then, when ready, move beyond scrum.
Most people think Story Points or terminology like Standups comes from Scrum too - they don’t! They’re from XP.
Scrum is exceedingly simple and suffers from being over complicated and dismissed by those who don’t understand it,
The blog post above is no exception.
[+] [-] OnlyRepliesToBS|7 years ago|reply
[deleted]
[+] [-] matthewmacleod|7 years ago|reply
Despite working in a a Scrum team, I recognise literally nothing of the problems that are described. Our product owner works closely with both commercial and development groups to build the backlog. Pressure to build good technical solutions is reasonably balanced with commercial requirements. The development team is empowered to step in and request product changes when they think it's necessary. This happens because we are a team of skilled professionals who want to deliver working things at reasonable pace, and this applies to both commercial and development groups.
There is a weird underlying assumption in these kinds of articles that implicitly seems to assume that Scrum will somehow turn a bad team into a good one. I have no idea where that comes from. A team using Scrum still needs skilled people who know how to do their jobs effectively – and that includes the scrum master and product owner roles. Introducing it into a good team can then help to reduce the impact of common software development issues. It doesn't work for every company, team, or product – but that doesn't mean its without value.
I'd be more interested in articles that talked a little about better processes that we can use. I'm absolutely open-minded about the idea that there are other legitimate and effective ways to deliver software other than Scrum, because it's obviously the case. "These are the problems with Scrum and this is why they aren't a problem in <other process>" is more valuable than "If you have a bad team then Scrum is bad".
[+] [-] dgreensp|7 years ago|reply
For example, it’s never made sense to me to have a powerful product owner while treating the development team as N interchangeable workers who may have “areas of focus” but have no roles, responsibilities, or organization among themselves, smearing out any sort of power or responsibility for technical quality like butter spread on toast. And yet, the fact that Scrum says to do it makes me wonder if that’s why everyone does it. Reading Scrum’s idea of a development team made me facepalm.
I don’t think the article is attacking a straw man that Scrum can turn a bad team into a good one. It may be pointing out that Scrum is regularly used to turn a good team into a bad one. Because everyone wants to be “agile,” even if they never use the word Scrum, they are implementing bad Scrum or cargo-cult Scrum by default.
[+] [-] barrkel|7 years ago|reply
[+] [-] nickelcitymario|7 years ago|reply
This assumption starts with one of the earliest Scrum pioneers, Jeff Sutherland. He writes quite clearly that he doesn't care about an individual's performance, but rather a team's performance. He also talks at length about how poor performing teams can be turned into high performing ones by the implementation of Scrum.
You can agree or disagree with him on this (I'm on the fence), but it's not at all weird that this idea is found within Scrum. It was there from the get go. It's there by design.
[+] [-] Robin_Message|7 years ago|reply
That is my key beef with Scrum here. I entirely agree that done well Scrum can be effective. But how it is often done is not well at all (e.g. the two day Scrum master training course.)
I'm criticising Scrum as it's widely implemented and how that is poisoning the groundwater for all agile methodologies.
And definitely I'll get on to how other processes can be better.
[+] [-] specialist|7 years ago|reply
[+] [-] conatus|7 years ago|reply
Same. This process takes work, requires buy in by all levels of the company and needs to be fully understood including its error cases. It takes time and requires course correct and attention. Its not easy but done right it is effective.
[+] [-] s73v3r_|7 years ago|reply
[+] [-] TooBrokeToBeg|7 years ago|reply
What is a manager but someone who has control over the controlled? I'm surprised with so many ppl nodding their head at this list of complaints about bad software processes at bad companies, masquerading as analysis. If you think it takes more than 2 days to learn _how_ to be a Scrum master, you don't understand the role. It's not complicated, difficult, and time-consuming enough to require a singular employee...unless your process is already screwed up. Good luck finding whatever magic bullet you think will save you that isn't Scrum-based teams.
[+] [-] tannhaeuser|7 years ago|reply
[+] [-] js8|7 years ago|reply
Historically, there are three important sides, and roles, for each project. Product management - takes care what the customer wants to have build. Project management - takes care of what is delivered is on schedule and that there is enough material/personnel to build it. Architect/engineering lead - takes care of whether the thing is technically feasible, what technologies are used and what technical trade-offs are made.
And there was a vast literature and discussion about how these three sides affect the result of the project, and how to solve these problems.
Unfortunately, Scrum, renaming everything, acts as if the history of project management doesn't exist. And if you forget history, how are you supposed to learn from it? That makes it easy to sell snake-oil. I frequently hear, for instance, that scrum master is not a project manager, despite him having some responsibilities in this area.
And as the blog post also expounds, there is no recognition for these three different sides of each project in Scrum (ironically, there is some recognition of that in Scrum derivatives such as Scaled Agile Framework, for instance, modulo nonsensical renaming of the roles).
[+] [-] jrochkind1|7 years ago|reply
This is the root of the problem in my opinion.
I am not interested in defending "Scrum", I don't like what I know about it, in the few experiments I've been involved in with it (not by choice), I agree it was disempowering to developers, trying to treat developers like commodities.
However, I am a fan of trying to do things agilely (iteratively, figuring out what to do next in relatively short chunks without trying to plan out the next year+).
In the experiences I've had where this _worked_ the product owner was _intimately_ involved with the development team, with lots of communication in both directions, with the development team's info and feedback effecting how the product owner prioritized and determined (and changed, agilely) acceptance criteria.
The product owner had to embrace/accept that this would be a significant time and energy commitment to them, they could not be looking to minimize their time here, and had to accept that "with great power comes great responsibility" -- that they needed feedback from developers to make these decisions properly.
On the flip side, through these good experiences, I also learned that a good product owner is _so important_ -- as a technical decision-maker I don't _want_ to be responsible for determining product priorities or acceptance criteria. I want my feedback to be taken into account, but having someone else (who is good at it) be _responsible_ for it let's me focus on applying technical excellence to achieve the goals set by the PO, and takes _so_ much pressure and anxiety off of me. Especially when I can trust them to know what they are doing it and do it well (just like they can trust me to execute well).
I _do_ think the development team needs a "technical lead" in addition to product owner, not just an amorphous bunch of people "self-organizing".
[+] [-] jillesvangurp|7 years ago|reply
Agile implies getting things done and getting things to market. If scrum helps you do that great. If not, ditch it. In my experience, Kanban is a step up on the evolutionary ladder. Both have issues with not prioritizing essential activities related to research, refactoring, etc. that you need to guard against. There's a difference between agile and firefighting.
One worry with scrum is the roles of product manager and scrum master. In my experience these things end up being formal job titles in bigger organizations. This is bad because they are typically on the very low end of the scale. That means you end up with the least experienced people filling these roles and a lot of corporate politics. I've seen more than a few organizations that were hiring accordingly.
[+] [-] tootie|7 years ago|reply
Product owners push customer value. Of course. You should too. Code quality and refactors have business value. Reduced maintenance cost, fewer bugs, faster future dev. If you can't explain that to your product owner then maybe it's not worth doing. I think your big missing piece is the collective ownership aspect. Product owner gets to set priorities, but it should be a collective discussion. Every dev should be allowed to express their opinion and it's the job of the product manager to referee.
[+] [-] struppi|7 years ago|reply
I wrote a whole book about "Agile Anti-Patterns" [3]. Most of the book's content is about things that many companies get wrong when they start with agile or lean software development. Because it is very easy to get those things wrong.
Yes, those problems are extremely common. Not only with Scrum - Organizations also face those problems when they try Kanban or SAFe or whatever. Because, change in a traditional organization is hard. And to really implement Scrum, you'd probably need to change more about the organization than the org was willing to change.
But those problems are not Scrum's fault. If the team has no power, it is also not truly self-organized. And the Scrum Master is not doing their job.
You could start to improve by creating awareness about the problems. Blaming Scrum may or may not be a good idea to do that - Because, some people in your org may be invested in Scrum. Some mentoring or coaching for your Scrum Masters, Product Owners and developers and managers might be a better start.
[1] https://www.davidtanzer.net/david%27s%20blog/2014/03/26/no-t...
[2] https://ronjeffries.com/articles/018-01ff/hills-to-die-on/
[3] https://www.quickglance.at/agile_antipatterns.html
[+] [-] mwilliamson|7 years ago|reply
Firstly, it gives you a set of tools to use -- sprints, TDD, product owners, and so on -- that should work well together. To use them well, I think you both need an understanding of how each of those tools supports some idea or principle that the methodology promotes, and whether or not you think that principle is important for your team.
Secondly, a methodology gives you a starting point of how to run a development team. It's easier, although not necessarily better, to start from a pre-existing cohesive set of practices than to build a process from scratch. Especially if a team isn't experienced with many of the ideas, this is not an unreasonable place to start.
I think the key is:
1) knowing what principles your team thinks is important (low defect rate? frequency of releases? developer happiness? empowerment?). This is often hard to articulate. As time goes by, you might discover principles that were previously implicit, or you might find that the principles that are important to you change.
2) knowing how each part of your process maps back to one or more of those principles
3) having a mechanism that allows you to tweak your process over time (for instance, retrospectives), whether that's adding, changing or removing parts of your process
Scrum can be a sensible starting point so long as you're willing to introspect and consider which bits are and aren't working for you, and you're empowered to do something about it.
[+] [-] noarchy|7 years ago|reply
That said, an entire industry has emerged to sell this methodology, and it is supporting a vast array of jobs: everything from those selling the certifications, to the software used to track developers. There are too many vested interests now, and no company wants to admit that it burned through thousands of dollars, with dubious results, to "train" managers and subscribe to the usual software bundles.
I expect the comments here will also have the usual comments about how Scrum is great, and everyone who is critical of it is just doing it wrong.
[+] [-] matt_s|7 years ago|reply
There are strong philosophies in Scrum and Agile that should be kept as guidelines. The key is being agile (lower case 'a') so you can adapt to changing priorities. Continuous Integration/Continuous Delivery go a long way towards empowering developers.
Two ways to tackle technical debt in projects:
1. Tech debt sprint. If scrum master and product owner can't get onboard then they need to realize somewhere in the near future, a feature they want will either break things or take forever.
2. Break up tech debt into small efforts someone can do in short time boxes. Even do feature flags or something to make slower progress towards a goal rather than tech debt sitting in a backlog for months.
An example of a guideline is estimation with planning poker. We completely ditched estimation activities. The estimates were usually off and not good predictors of completion. The team has a cadence of ticket completion and the 'sizes' of the tickets vary some but you don't need to waste time estimating. Developers (humans) are horrible at estimating. Having a good PM/PO set expectations with the business helps.
[+] [-] JepZ|7 years ago|reply
That is a part of the problem. Scrum is very far from Agile. Scrum introduces processes and tools while the Agile Manifesto [1] clearly states:
> Individuals and interactions over processes and tools
That said, Scrum isn't entirely bad. Its just not what many people think it is. As a tool to change the culture of a company that has been shaped by classical project management methods for decades it is very valuable. But the process shouldn't stop there as Scrum isn't the end, its the start.
So companies which managed to implement Scrum should try to move on to more Agile practices to transform their culture over time.
[1]: http://agilemanifesto.org
[+] [-] srtjstjsj|7 years ago|reply
[+] [-] heartteams|7 years ago|reply
It's hard for people to go back once they've seen it work. The people that I've worked with have said that when they do move on to other companies they didn't realize how helpful it was until it was gone. It can seem like some bullshit, I get it. It's change. It's not a perfect model. Also, when leaders or teammates behave in a command-and-control and uncollaborative way, it's a lot less fun.
Biggest personal challenges: connecting team members to real clients, integrating UX (need more people and up-leveling of team members), too-stable of teams (I like forming around new ideas and the excitement of that), being distributed, the language (Scrum Master - really?!!?), perscriptive agile peers
[+] [-] ordinaryperson|7 years ago|reply
Put enough smart people in a room and they’ll figure it out. Scrum isn’t any worse than Kanban or ‘pure’ Agile or Waterfall or Lean — every system has tradeoffs and smart people learn to adjust.
No company is perfect. Tell management how the process can be improved. If they ignore you, consider moving on.
[+] [-] Robin_Message|7 years ago|reply
[+] [-] starbugs|7 years ago|reply
My experience is that this is often caused by a lack of understanding of the methodology and how it can be applied and integrated into existing structures.
Also existing structures need to be integrated with Scrum to make it work. That is, they need to be transformed to match agile workflows.
The latter is not easy. Especially not in larger companies. I am not surprised that most do not even try to tackle this.
[+] [-] robin_reala|7 years ago|reply
Just a shame that most teams’ processes crystallise around Scrum. Working with self described Scrum masters is painful as they’ve built themselves into a box they can’t see out of.
[+] [-] wpietri|7 years ago|reply
The problem only comes in an organizational culture of "whatever the boss says". In that context, teams rarely learn to self-organize. Instead, the previously existing control hierarchy stays in place. Before, developers built whatever spec landed on their desk. Now they build whatever is in JIRA. Developers in that world can't even conceive of pushing back.
It's my belief that if Scrum had had some strong counter-balance to that, like an Engineering Master, then it just wouldn't have been adopted. Scrum won out over the other Agile processes (of which there were several) not because it produced better results, but because it was the one most comfortable for medium- and large-company managers. It provided the feeling of transformation without actually changing anything important. They were doing waterfall before, which became untenable with the rise of the Internet. Now they do mini-waterfall, call it Agile, and imagine themselves kings of the world.
[+] [-] bartmcpherson|7 years ago|reply
The value usually listed first in the agile manifesto is "Individuals and interactions over processes and tools".
[+] [-] MichaelMoser123|7 years ago|reply
Empowering the workers is a good idea, but it is not how most organizations work.
[+] [-] captainbland|7 years ago|reply
Edit: And I guess my real point here is that Scrum doesn't usually work because the development team as a whole has no way of pushing back on decisions made by the overall business hierarchy unless they just go tools-down.
Then it goes on to crticise Valve for not delivering HL3, despite that clearly being a successful business (and one where Gabe has over 50% of the $2.5 billion equity valuation... non-hierarchical, sure, whatever you say) - perhaps all of this emphasis on shipping products as fast as possible and no emphasis on the service and the interests of staff is the real problem here.