Hacker News new | past | comments | ask | show | jobs | submit | page 2 login
Scrum is fragile, not Agile (dennisweyland.net)
534 points by pplonski86 51 days ago | hide | past | web | favorite | 322 comments

The position may be right, but it's so badly argued. Arguments he uses in support:

- the dictionary definition of "agile" - how many times the word "agile" appears in the Scrum Guide - how "lengthy" the Scrum Guide "seems" - that Scrum is a process, so does not "sound Agile".

Ugh. How did this reach #1 on HN?

I think because people are frustrated. My read of the conversation is that there's a lot of latent resentment towards modern Agile and Scrum practices.

At least the discussion in the comments is better argued.

A long time ago, ppl figured out that no one process was right for every organization, project, technology, etc. They created process frameworks (things used to create a process) and they saw that they were good.

Then ppl came along and said that they were "too complicated" we need something Agile! In actual fact, those ppl didn't understand the process frameworks and just created a specific instance of one and they wondered why it didn't work for all projects, organizations, technologies, etc. And then they said those processes are "too simple" - what can we do? "Maybe we should create a way of generating a process?", they then said. And so it went...



Are we still talking about these dated concepts?

Agile is a mindset.

Understand the mindset, absorb it, make it yours, and build the process that's working for you based on that mindset.

Stop complaining about Scrum, it's just a tool, and tools deprecate.

Yep, I've never been in a team where the process was not a regular topic of debate. Once it stops being a topic of debate, it actually just means people are no longer adapting. I prefer a good dose of pragmatism here. Changing the rules all the time is very draining on team morale. Similarly not adapting to obvious process issues is equally demoralizing.

Since everyone is doing, or claims to be doing, agile, the whole notion is completely meaningless. Unless they are actively advertising to be doing some form of waterfall, you can safely assume there is some notion of iterations involved.

What matters more these days is whether the team is mature enough to have continuous deployment without process bureaucracy. Deployment fear is a good sign the process sucks. If you have a need for human gatekeepers, something is wrong with the test automation. Deploying often and with confidence is a good sign you are dealing with a smoothly running team.

I don't really have that much industry experience but have been reading a lot about development processes and practices. It seems there just isn't one development process that will solve all your problems and allow you always create successful software. To me it seems you just need to find what works for your team and continuously work on improving on it. What might work today, probably won't work for your team tomorrow so you need to always look at how can you improve your process.

ACM recently had a series of webinars[0] by Ivar Jacobson on Essence[1]. Essence was kind of confusing at first, but it is essentially a language to describe practices from the different processes. The idea is that you can build up a library of the various practices in your company and allow teams to pick their own and evolve their process by swapping out practices that just don't work out. Essence seems like an interesting idea, especially if it allows teams to create a development process that fits them.

[0]: https://www.sigsoft.org/resources/webinars.html

[1]: https://www.ivarjacobson.com/services/what-essence

I have decades of industry experience and I mostly agree.

> find what works for your team

For the combination of team and project. Different software projects need to take very different tradeoffs in how they managed. Use scrum in aerospace for flight control, and people will die. Use scrum for system software, and you'll have hard time delivering quality and performance, system software often requires non-trivial amount of engineering. Implement NASA's best practices when working on videogame or web app, and you'll blow budget.

This article is from 2002 but still good: https://www.joelonsoftware.com/2002/05/06/five-worlds/

You may not have much industry experience, but you’ve managed to hit the core of the problem. There is no one process that will work for every team, or even every project.

Every team at my workplace runs a different process. We’ve got a team developing new features who are running an iterative agile process, allowing them to react to changes ok requirements or unexpected issues with as little disruption as possible. We’ve also got a team doing B2B projects, essentially rebranding our mobile apps and platform for different companies, and that’s pretty traditional waterfall - I wouldn’t in a million years use waterfall for new features, but when you’re running through a set of well understood tasks that need delivering on schedule to coincide with work by third parties it gets the job done.

Scrum is micromanagement. I think it’s as simple as that.

no this is completely and entirely wrong.

on the contrary: you have a PO in charge of communication and priorization of features and a dev team in charge of developing- no manager on top...at least in theory...

From all the comments, I see that arguments are there both ways. I also understand that we should follow a process that bets suits the business. I would really like to know how we could set up an Agile process provided that is what is required.

Is there anywhere this would be documented to explain - a. How an agile process in initiated? b. How an agile process is maintained?

I have been part of a team with mis-applied agile processes -

1. Requirements change frequently. And not due to users asking for them. More like the Project Managers asking for more configurablity.

2. Requirements are not thought through. Even the simplest cases.

3. Changes don't get vetted by users. Instead, we go through another round of requirements!

4. Every once in a while requirements (and teams) get re-organized, re-planned which puts all the developers off.

I have also been part of a team which focussed on deliveries. This team has been able to write tests and iterate over requirements fast. The satisfaction level of all the developers in the team as well as the project owners were high.

1. Requirements were phased.

2. Whatever was required to be done in each phase was thought through as far as possible. Anything that wasn't clear or was more complex to think out was sent back to the project owners / users for clarity.

3. Code and tests get written. Phase delivered.

Although this process was extremely successful, I don't know if I would call this Agile.

I agree that Scrum is fragile but not that it isn't agile.

It's agile up to the point that it is broken, which happens often due to it's fragility. That it is easily broken is an unfortunate but unavoidable consequence of its complexity, and common misunderstandings/misuses.

Scrum is complex because large software projects (large as in number of people, budget and expected velocity) are never simple to manage. Scrum is complex because correct usage can not be read from a book nor gained from a qualification - it requires experienced judgement to pick the optimal usage and apply it to a team and project.

Nothing can beat the effectiveness and efficiency of a single strong developer working on a stream of well considered backlog items. That is engineer nirvana! However many projects simply require more velocity than one person can manage. From here, there is a whole spectrum of processes that should be chosen depending on resources and needs. From my experience, full scrum kicks in once you have four or five engineers on the same system.

Product management is a key point of failure in Scrum, true also with other processes. But it's felt so much more when an entire team grinds to a halt and an iteration fails.

If Scrum doesn't feel agile then you are doing something wrong. This is exactly the question the team should be asking itself at retrospectives (doesn't need to be three questions!). What's changing in your process sprint to sprint? Scrum masters are there to facilitate incremental process changes driven by team members, not a system that doesn't result in agile software delivery.

The author had really bad experiences. SCRUM is super agile when done right. Change can be introduced during sprint transitions (reviews, retrospectives and planning) - never in the middle of a sprint. Doing so will kill moral and break the rhythm of the dev team.

SCRUM is meant to be owned by the developers - not management. Shame on companies that hijack and impose such process.

SCRUM gives dev teams rhythm with sprints. Allows them to deliver mini releases of functional software in 2-week increments (could be 1 to 4 weeks too - lenght should be decided during planning). The goal of a sprint is to be decided by the developer and doesn't have to be about the software. Can be about learning, improving as a team or helping team members to grow. Here are a few examples I've seen: - Measure 5 metrics in Kibana - Marie-Pier leads sprint review demo - Try self-merging PR's and measure the results - No more loose ends Of course, in parallel the team builds and delivers an increment of functional software.

The planning, review and retro rituals are paramount. SCRUM can only work well if those are well planned and executed. The retrospective is particularly important to allow the team to improve themselves. Its an opportunity to change their own process (i.e. change the definition of done).

Contrary to wide belief, story points are not part of SCRUM. Its a mechanism that can be used to gauge the size of work - it should be up to the dev team to decide whether to use them or not. Again dev teams should own that process - should not be imposed by management.

These lessons I've learned in the past two years thanks to an awesome SCRUM evangelist we've hired. I'm proud to say its changed our lives for the better.

I'm doing Kanban right now at my job and, I have to tell you, it's so liberating.

I hate artificial deadlines (i.e., sprints). Kanban let's you focus on the work without all the process distractions.

In my current team, we post our daily status on a slack channel: what we do yesterday and we are going to do today. We try to keep to one or two points. We have remote people so that works out well. Standup is optional. On Monday meetings, each person tell one thing that we are going to do. Sometimes it is two things but the point is to focus.

This is the way it should be.

Meetings should only be between business / leads to get scope onto canvas.

If I'm blocked I'll seek out the person who can most help me. I can easily find 5-10 minutes to write out a summary, but on my terms when I'm not in coding mode.

Now, I'm freelancing, likely to be team lead for the company assuming they get financing - and I keep taking notes and reading ways to organize better. We have a ton of work to do, it's a financial mobile app that has 0 tests on the api (I'm single-handedly running the API development Laravel + vue (for some web views)). Money is tight so I'm the only dev on web side and we have 1 ios dev.

The hope is to be full-time at this by Christmas w/ a 6 figure salary (my first +6 figures).

Scrum truly does end up being "Waterfall" most of the time, in my experience. I think this is largely because teams or management inevitably get bored with projects and end up shifting priorities regardless.

From what I've seen, projects almost always start out in a requirements/analysis phase because management, stakeholders, etc., need the reassurance. I've yet to see any public-facing project of meaningful size start out releasing actual MVPs as opposed to "big bang" releases.

Design often happens first because engineers don't want to(and sometimes can't) begin coding away and then receive designs that are either counter to their existing work or are unworkable; management usually sides with design because, well, it looks cool.

Engineers eventually get coding, but non-automated testing doesn't really occur until later because it can be impractical to have people testing unfinished software. Then there's alpha testing, users break the software, engineers fix bugs, A/B testing of different versions of features, then beta testing, where users again break the software and the engineers fix more bugs.

The project continues to drag on because the first 80% of a project is always the easiest part, and management is always hesitant to release "unfinished" software.

Inevitably, there's a big bang release, by which point management has already gotten bored and has dreamt up other "big ideas" for the team to focus on, at which point the project is, for all intents and purposes, placed into maintenance limbo where bugs are fixed, junior developers place their awful code, and a new "feature" is added now and then to satisfy the marketing department.

Senior developers rationalize the waterfall-like nature of the project, so they opt for "continuous integration", but all that ends up translating to is maintenance limbo without versioning.

The actual next version of the software doesn't get built until after most if not all the original team left, and the original software became "legacy" enough that bugs keep popping up and the new engineers don't want to touch the old code. Management eventually gives in, for better or worse.

Am I wrong? This is what I've seen happen to the vast majority of software projects, all under companies that were either Scrum, Agile, or pretend "Agile". Maybe I've just had bad luck.

I wish more teams could pick and choose what methodologies to use for their purposes, rather than buy into MLM garbage.

Said it a million times before - I deal with way more process and paperwork using scrum than I ever did with waterfall. I'm not saying waterfall was an answer, but at the places I worked on it, it did a better job of staying out of my way.

The SCRUM guide is not long, it's 19 pages in a large font. If I remember correctly it does not even mention a lot of the processes which make up SCRUM for many teams.

However the article is not wrong, it's too easy to make SCRUM all about the process, without changing anything about interactions, developer empowerment and feedback cycles.

I think the SCRUM doesn't do a good job of putting limits on what is still agile SCRUM and what is not. Maybe because it's written in such a friendly language.

The aim of Scrum, and other methodologies tagged Agile, is -- near as I can tell -- to emulate a good programmer with a team of mediocre programmers. Not that all developers working on Agile teams are mediocre programmers, only that the business wants to achieve good-programmer results while still being able to leverage the wider talent pool and lower risk and cost offered by hiring mediocre programmers, so it tends to adopt formalized processes designed to work well with them in the hopes that following the process will make them achieve good results. The process is a formalization of the relationship a good programmer has with their client, which is known to produce good results; therefore, the process must also produce good results by definition (and any failure to produce good results can immediately be blamed on lack of adherence to the process).

Unfortunately there ain't no such thing as a free lunch, and when you emulate you necessarily incur overhead, which can be prohibitively large if you're emulating something powerful -- plus, if you have actual good programmers on your team, they will either quit or start emulating mediocre programmers to remain compatible with your mediocre-programmer process. Either way, you lose the benefits of having them.

The problem often is that scrum (or any iterative process) fails when it's not paired with good XP engineering practices. There's constant learning and change on the product side, which drives constant learning and change on the implementation side, the code needs to be constantly refactored to best handle the changes.

TDD/yagni/refactoring allows you to keep your code base nimble. I can't imagine doing an iterative process by slamming features in one after another without refactoring the code as you go to handle what "you now know", or not having good test coverage to support the changes you need to make.

Refactoring also shouldn't be something the PO is aware of, it's not a story, or a 2 month break from feature development. It's part of the job as each story is implemented. Yes, sometimes you don't notice a good way of doing something until some time passes and that area of the code becomes a bigger refactor than usual, just have to deal with it as soon as possible.

That's a bit of an easy critic of Scrum on its literal sense rather than a critic on what doesn't work or isn't agile or is fragile. I've seen Scrum badly and imperfectly implemented everywhere I've been, yet I think this is preferable as having a strict interpretation of its principles and processes. I don't care actually if Scrum is intrinsically not agile (or Agile): I think what matters and is actually what's happening is people adopting Scrum with agility.

It has good principles like backlog, sprint and daily meeting. If teams only pick one of those or anything else and that it help them, great! By the way holding solely Scrum accountable for failures is narrowing down the analysis to only one part of all things that can go wrong and have nothing to do with Scrum. That's a cognitive biases concentrate.

Reading the comments on this post are truly sad. The amount of "me too" juxtaposed with "actually, this isn't a true scotsman" are truly mind boggling.

I wish there was a prescriptive way to successfully make and deliver software. I have seen very little evidence that there is.

This is very light on specifics? What, exactly, is fragile about Scrum? Where does it break down, and what can I do to prevent it from breaking down?

Without that info, this just feels like buzzword bingo, a la "What should I write about to stir the pot today?"

Although I have remained sceptical of Scrum, I do find it a bit strange that many of the negative comments about Scum here seems to be related to not doing Scrum (The old, you are not doing Scrum properly). All the talk about managers, and being told what to do in a sprint etc. None of that sounds like Scrum to me. Isn’t the whole idea of Scrum about self organising teams (?), independent of management etc. All you have is a Scrum Master to facilitate the process, and a Product Owner (part of the team) who prioritises the backlog because that role has an understanding of what is needed to solve the problem at hand (in terms of functionality needed).

I think that longer term strategic planning is missing from the Agile Scrum manifesto.

Agree with the Software development priority queue part being good thing.

Long term planning was in the waterfall process which does not work that great either since it tends to over focus on planning.

How do you find a good balance between Agile and Waterfall?

I think it can also be different what process works well if you are a startup and need to deliver a MVP minimum viable product as soon as possible. Compared a bit to if you are a long term enterprise company and need to maintain your code base over time. Ie dealing with technical debt from short term solutions vs long term stable.

Strategic planning doesn’t belong in a process designed to provide constant iteration on a two week basis. In successful organisations I’ve worked with strategic planning is one of the things that feeds into the backlog of features to be developed, and runs in parallel to development.

In my experience, I was lucky to apply Scrum and Agile correctly so now I understand them and can distinguish between them. In my current job, there are no chances to replicate those conditions and I do not expect Scrum to succeed (although we use a lot of Scrum terms to define what we do).

I think one should have experienced a successful scrum project before being able to criticise it.

Scrum is a tool: you may be Agile without using Scrum or you may find easier to be Agile using Scrum. Doing Scrum does not make you Agile. Scrum is hard and implementing it takes different skills than those proven by individuals who can write code.

Honestly, the comments on this thread baffle me. Endless complaining about scrum and everyone who is not a developer is apparently clueless about software. Is this an adequate reflection of reality? This doesn't seem like a very mature attitude. Scrum is a simple framework with only three roles, the development team being one of them - so if the process fails you are (partly) to blame for it yourself as well. Take responsibility!

What's the better alternative? What have you been doing to make things better? The answers to these questions as much more interesting than endless complaining.

Where this stuff really fails (IMO) is when execs throw together a half-baked structure around a project, and throw minimally qualified human resources and a few consultancy firms at it. Knowing that "shit rolls downhill", it's always the developers who end up sweeping up the mess working endless hours trying to make deadlines, ensuring everyone further up the hill looks good to their bosses, while praying that their project doesn't get terminated.

In my experience this seems to be an issue unique to enormous corporations. When I used to work at small / medium-sized companies this never happened.

> In other words, it is a very specific and well-defined process. This does not sound agile and it also does not sound Agile (remember: “Individuals and interactions over processes and tools”)

This is a many times debunked myth about the Agile manifesto. Even the authors themselves explained that "Individuals and interactions over processes and tools" does not mean and shouldn't be taken as "no processes".

Also, agile is not about moving quickly but about being able to easily change direction any time, therefore dealing better with changing environment.

I searched the entirety of the Scrum Guide (https://www.scrumguides.org/scrum-guide.html) and could not find a single reference to "agile". And a quick Google search about the origins of Scrum reveals:

In the early 1990s, Ken Schwaber used what would become Scrum at his company, Advanced Development Methods; while Jeff Sutherland, John Scumniotales and Jeff McKenna developed a similar approach at Easel Corporation, referring to it using the single word Scrum.

Scrum is a communication contract between customers / stakeholders, managers and dev teams. It is a poor cure for social and managerial dysfunction, but it is a cure.

Scrum is a problem when it is mandated and imposed on functional organisations that do better and more fluid communication. This is often done as a way of flexing corporate power and does huge damage.

A key problem is that we do not have ways of auditing and measuring the performance of software teams no matter what methods they are using - until then this is all anecdote.

> A key problem is that we do not have ways of auditing and measuring the performance of software teams no matter what methods they are using - until then this is all anecdote.

Of course we have ways of doing that - one is the code quality, another one is historical performance on agility.

I wonder what happened to so many developers that turned them so jaded and cynical towards scrum and project management. So far I've dealt with the good and bad of scrum with a good pinch of horrendous PMs in the mix, but I still came out of it with a positive view of the framework. It is hard to run it somewhat smooth and takes lots of motivated people to accomplish[1], but the result had a positive impact on my day-to-day work.

1 - Some people said that this can be a failing of scrum and I 100% agree.

Scrum only works if you need sprints, and you only need sprints if you have non-engineering stakeholders whose mandatory approval can only be attained in one meeting per sprint length.

Some large orgs really work like that, where the approval of one ham-fisted iron-gripped executive is deemed more important than hundreds of thousands of dollars of engineering talent going to waste. I don't think this is very effective but alright then.

Everybody else should just be using Kanban boards with periodic review.

Reading all the comments out there, there is some atrocious stuff people call Scrum. I'm not even a huge Scrum fan, but it folks seem to criticize what people do in the name of Scrum instead of what is actually in the process.

The TLDR of Scrum is simple: (product) management gets to set the priority of things every 2 or 3 weeks. After that, we see what got done and check to see if the priorities are still the same.

If the priorities are wrong, don't blame Scrum, blame management. If tech debt is increasing, don't blame Scrum, blame management.

There's no magic bullet to determine what is important, and certainly Scrum Master training won't help an incompetent manager a competent one.

I don't think I have ever seen it done as badly as some of these comments. Scrum itself is a very light and quite flexible framework, half of the complaints here aren't even Scrum related. User stories aren't part of Scrum, neither are story points or burndown charts.

Of all the people complaining about Scrum it doesn't sound like any of them have read the Scrum Guide. Symptoms of Scrum are not managers pressuring people at stand ups, squeezing 4 weeks of work into 2 and having a "team" of 20 people. These are symptoms of poor leadership.

Has anyone ever tested whether Scrum or Agile actually work better than "Waterfall" for software development?

Agile works fine, if you ignore the Scrum hocus pocus. Stick to basic project management principles (work on one project at the time, wrap things up before moving on to the next project, set aside a bit of time for unrelated work) with the stakeholder put at the center of what you're up to.

The problem with Scrum is that it's usually (always?) implemented as serialized waterfall projects with completely arbitrary looking deadlines (i.e. the sprint's length). All too often things get sort of done but not done quite as well as everybody would be happy with. It's stressful for everyone involved and, insofar as I've seen it used, it makes accumulating technical debt even more likely than more traditional waterfall projects.

I dunno, by now I would actually be really happy with a waterfall requirements document.

Waterfall was terrible in many ways but it seems to me for all the problems with that methodology that "agile" has fixed it has created at least one new one, and often more.

I’m quite amazed by the lack of substance in this article. It takes potshots at certain ideas and processes, without managing to explain these potshots, or even coherently explain the ideas and processes. It is a flimsy opinion piece with no substance, but a clickbait title so everyone ran here to comment.

What a virtuous cycle

Reminds me of this goto conference talk from one of the original Agile developers "pragmatic" Dave Thomas.

Speaks a lot bout what agile truly is and how scrum is a very large mismatch.


“To me it seems that one very important part of high quality software development is to maintain a simple priority queue of tasks. The weight is a combination of the value a task provides for the customer / developers and the estimated effort to implement this task.”

A.k.a. common sense :)

Agile – the only word in the English language that inverses its meaning when capitalised.

Scrums point for me is to prepare your development time. Talk about the issues, prepare the issues, ask the client, make a mock-up and then implement in code.

Usually it's hack together something and see if it sticks, which is awful.

You may find this very much relevant: https://www.youtube.com/watch?v=OOAMNOso46g

just to offset a bit about scrum being bad: I have used SCRUM over 15 years to run teams and it worked. Most of the problems I am hearing on here are culture problems and no process can fix that. Regarding planning, a day per scrum is normal - sometimes longer, you have to use your judgement to determine when to move from design to implementation. Also, heavy use of spiking stories to learn enough to create the right design is important

Can you explain a little bit more about your "spiking stories" and how you use them?

The best of agile can be summed up in one piece of advice: "Create short feedback loops". Nail that and you can't go too far wrong.

> "We are simply caught in a rat race and not able to make a short break in order to look at and learn from all the things that happened around us, maybe even before our time."

But isn't that exactly what Scrum wants you to do? After every sprint, you spend some time to reflect, look at how you're working, look at the bigger picture, etc.

Scrum is by no means perfect; it's a tool, not the infallible silver bullet the author wants it to be. If you misuse the tool, you're still going to get wrong results, but that's the same with every other method.

The real question is: is there a better way to do it that can easily and reliably be implemented by large corporations? I think the popularity of Scrum is probably due to it being more successful than what was used before.

It might not be truly Agile, but for large corporations, being truly Agile may be a bit much to ask. They need reliability and reproduceability, and that means they're always going to need some focus on processes and procedures, and can't always rely on people who might leave or have something happen to them. Not that Scrum is always a good fit for those processes and procedures, but it does help make it appealing for large companies, and at least it puts a good part of the process in the hands of the people who will be using it.

tl;dr: Scrum is not perfect, but what is?

uh oh, is this the one article that will make people go "A-HA, told you so?" #confirmation-bias

and, I never saw so much interpretation of what something should be as with Agile.

not everyone is entitled to say or mean something, that includes myself and this post.

"ahh-gee-lay! must be italian!"

Agile itself is pretty bad too. “Responding to change over sticking to the plan” is pretty much the single biggest reason why I see projects fail.

I think the key motivation of agile is the recognition that the plan made in advance is often not right.

If completing "the plan" is seen as success, then of course sticking to the plan is the best way to success. But if maximizing business/user value is the success, then "no plan survives first contact with the enemy." (I don't like "the enemy" concept, but this is a famous quote that gets across the concept).

And I think the reason why "agile" fails is because many actors in many organizations find they are effectively rewarded for "completing the plan" regardless of business/user value, indeed.

This is just not accurate. The types of changes thrown in after early requirements gathering are most often coming from product managers and executives, not from customers and not driven by genuine feedback or budget constraints, etc.

“Sticking to the plan” does not mean rigidly enforcing zero changes, but rather means keeping a commitment to the general scope and direction that was mapped out. Compromises should require extraordinary hard evidence before being accepted.

This is really why Agile as a general set of guidelines is so easy to subvert and ends up being a misused tool in most every situation where Agile is deployed (Scrum of otherwise).

Project management guidelines need to start out by specifying a way that quality is strictly disallowed from being subverted by competing interests that lobby for changing the plan.

If a set of software project management guidelines doesn’t start out with an unchallengeable quality-above-all-else mandate that creates policy barriers to the natural entropy of different interests trying to lobby for why their preferred change has to be made, then it’s doomed to just get politically subverted.

Doesn’t matter if it’s Agile, Waterfall, extreme programming, whatever.

“Sticking to the plan” in the sense of setting up preemptive, high-cost barriers to anti-quality modifications to what was agreed is _the_ thing.

The problem is that if the environment or requirements have changed and you don't take account of that then you may have a successful project delivering a product that is no longer relevant.

This is the overblown excuse people use to argue for their preferred changes, when really the environment or requirements usually don’t change, and when they really do then either it’s small and you should still stick to the plan or else it’s big and the need for change is so overwhelmingly self-evident that you don’t need things like Agile slogans to generate motivation or buy-in to change things.

Either way, harping on the idea of “but what if circumstances changed” is mostly just what corporate politicians do to subvert people demanding evidence for the requirement of changes.

Nothing can replace Will and Wisdom

To think of scrum as a process is wrong. It's actually an organizational pattern language. The idea is that social interactions are a complex system and there are patterns of interactions which, from experience, seem to work in certain contexts.


It's not even software specific. Which is actually a strength.

Example, one common misconception is the daily standup is a status meeting. In fact you are supposed to replan in standup, it's a tiny planner. Not sure how you can call the ability to pivot every day not agile.

EDIT: Unpopular option, software quality is poor and it has nothing to do with scrum.

I'm already able to pivot every day—it's part of the autonomy inherent to me being hired as a professional. I can make decisions about my work, and ask my colleagues to make decisions about our group work, as necessary to deliver on business needs. Making a process and a specific time about how to get approval to pivot is less agile.

You ability to pivot as an individual is already limited based on your team. In fact a unilateral pivot is destructive and can inflict pain on everyone else. I'm not sure how having implicit and ad-hoc patterns of interactions is agile. Why? because you can't improve what you can't see.

I guess part of my skill as a professional is knowing how to work with my team, communicate as needed, understand whay they need to deliver business results and get them to understand what I need to deliver business results, prioritize as needed, and make sure I'm not inflicting pain on everyone else.

If you don't have that level of trust in your team members, sure, formal process makes sense. And I'm all for it if that's what's needed to deliver business results successfully. But you're then valuing processes and tools over individuals and interactions, following a plan of when and how you may respond to change over letting individuals figure it out, etc. Again, it's perfectly okay if it's not agile if it's what the business needs. But my assertion is it's not agile.


Agile is a subset of TPS (toyota production system)/Lean applied to software.

Actually, lean is lean applied to software. Agile is Henry Ford's interpretation of lean applied to his factories, applied to software.

And scrum? TPS is explicitly an influence on scrum.

Scrum is just an instance of the agile manifesto. TPS/Lean > Agile > Scrum.

Kanban for example is another instance of the agile manifesto.

Scrum existed before the agile manifesto. It's probability more accurate to say Agile is a mix of those things.

Registration is open for Startup School 2019. Classes start July 22nd.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact