A brief list of what Scrum gets wrong - <AUTHOR> https://medium.com/@ard_adam/why-scrum-is-the-wrong-way-to-build-software-99d8994409e5 <comment><USER2> Scrum isn't good or bad, but the way the OP (or their company) uses it seems to be a reflection of an inflexible culture.

For example, the OP argues how scrum strips engineers the autonomy they need to get the job done and how it's super inflexible. When we did scrum with my team, the scrum master role was rotated among engineers, growing each of us significantly as professionals. We also made changes to the "core" of scrum after our retrospectives when we decided it was stuff that did not work for us. When management tried to use story points for tracking or forecasting we told them to forget about the whole thing. We added bugfixing sprints after we observed the bugs piling up.

I can go on - we made scrum work in an environment where we were empowered to do what makes sense. The crux of the post seems to be that OP has some very rigid management and devs cannot change the mindset.

Instead of complaining about scrum, I suggest the OP either try changing the culture from the team level. Or if it won't work, just get out and work at a place where there is sane management who does not drink the rigid scrum kool- aid. Luckily, there are more and more places like that these days.

<comment><USER3> > Scrum isn't good or bad

I must have heard this at least a dozen times in the last months. OOP isn't good or bad, Exceptions aren't good or bad, Scrum isn't good or bad. It makes me mad. Guys and girls! Software is not a contest in being liberal and tolerant. There are methods and techniques that are objectively better than others in reaching most of the goals that are important. You wouldn't contest a F1 driver on a bicycle - not on a race track. And engineers who really know their stuff usually agree on how to build software in a given domain. I do not know of any success stories using Exceptions on Kernels or RDBMSs or even most server software. But I know people have tried, and even they agree it was a bad idea.

If you want to say Scrum isn't good or bad, depending on how you tweak it so it sucks less, then I say it's definitely bad. It's not a solid method that helps you reliably reach your goals.

If you want to say Scrum isn't good or bad unless metrics are defined (that doesn't seem to be the case here), then you are right, but it's a meaningless statement.

<comment><USER4> > OOP isn't good or bad, Exceptions aren't good or bad, Scrum isn't good or > bad. It makes me mad.

It's all true though. Do whatever you want, all that matters is that you do it _well_ \- you just can't simplify a good software engineer down to techniques like these.

I recommend reading this piece from a guy who studied software development methodology for over 20 years: [http://alistair.cockburn.us/Characterizing+people+as+non- lin...](http://alistair.cockburn.us/Characterizing+people+as+non- linear,+first-order+components+in+software+development/v/slim)

<comment><USER5> The thing is, what is the alternative to a scrum process? I see so many shops with zero defined process constantly re-invent project management wheels that were solved a long time ago. Start from a known place like scrum and then adapt it to your team and organization.

We standardize around protocols, frameworks, programming languages, etc because adding constraints and processes make a problem much easier to solve.

If not scrum, what? Where do you start?

<comment><USER6> Kanban, gantt, unified process, extreme programming, trello, rfc.

There are plenty of methodologies and tools that can replace or complement Scrum.

<comment><USER7> Or even the engineering design process. Every ABET accredited engineering program teaches it, and while there are minor variations in the specifics it's always broadly the same. It's worked well in the engineering disciplines for decades & produces reliable products. There's no reason it can't work well for software, only an unfortunate case of "not invented here syndrome".

</comment></comment></comment></comment></comment></comment><comment><USER8> I agree 100%.

Thankfully I dont do agile any more, but I'm close to several teams that do. My fondest memories are:

No over-arching design (Implement feature after feature however the hell anyone likes) Once said features are implemented, taking the time to "refactor" (read: completely rewrite because the code was so bad) becomes a really hard sell.

Thus, new features get progressively harder to implement, as you touch a deeper cross-section of the code to try and fix stuff semi-covertly, without a formal refactor.

"Tech Debt" was done in sprint scheduled after phase of dev sprints. After, say, a year of development, lets fix all the problems in 3 weeks... When you're dealing with procedural php masquerading as OO, MVC with business logic everywhere it shouldnt be, and abuse of inheritance such that you cant throw an error in a command line because you're not a logged in browser user, who's had their language queried from a database, and doesnt fall back to default when the db isnt there... 3 weeks isnt gonna cut it!

Introducing peer review was supposed to sort that, but bad or inexperienced devs didnt know they were doing shoddy work (it met the criteria after all..), and good devs became impediments because so many stories needed redoing. Demoralising.

We were probably "doing agile wrong". But it's like a religion: open to interpretation. In my experience it's a tool used to extract maximum customer benefit at the expense of the developer's soul, under the pretence of "self managing team" \- ie. "You brought it on yourself".

<comment><USER5> > Once said features are implemented, taking the time to "refactor" (read: > completely rewrite because the code was so bad) becomes a really hard sell.

This should be a hard sell. The code in production works. Why does it in need a rewrite? The fact it needed a rewrite in the first place doesn't really reflect on scrum but on poor engineering and management practices.

<comment><USER8> "The code in production works"

This might be what I have the biggest problem with. To a customer, it works. The customer is happy, they pay their money, which makes management happy, and we all get paid. So the site takes 10 seconds to load on certain pages, who cares! It works, right?

Behind the scenes, there's a fleet of web servers burning CPU so add some more! A database that's overwhelmed, throw some more CPU/mem and faster disks at it! Maybe optimise some queries if you can get it into sprint. But a fundamental problem with the implementation itself cant be fixed, because "it works". Want to leverage some slave dbs for reads? Sorry, no time for that because unpicking the backend would take too long!

It's backwards. In my idealised view: Good design first = better code = less resource hungry = less cost for servers = support more users = more revenue = less time spent working around crap = more time to implement features! = more revenue = better wages. Everyone wins.

Imho, agile doesn't help make this happen.

<comment><USER9> Again, there's a ton of wrong here...

If you really have a fleet of web servers burning CPU and you arne't tracking the costs, then I guess "it works" until someone figures out there isn't any money left in the coffer.

There is a lot of value in working software, and unless your engineering infrastructure expenses seriously outweigh your engineering payroll costs (which does happen, but is hardly commonplace), CPU efficiency isn't the be- all to end-all and focusing on it may well prove to be counter productive. If no one actually cares about your page load times, it may very well be that it doesn't matter. You can spend a near infinite amount of time & resources trying to get optimal performance (talk to someone who does high-frequency trading to get a sense) well past the point where the costs pay off.

There is tremendous value in "it works" that engineers generally struggle to fully factor into their thinking (I come by this wisdom honestly). People have written about this extensively (e.g. [https://www.joelonsoftware.com/2000/04/06/things-you- should-...](https://www.joelonsoftware.com/2000/04/06/things-you-should-never- do-part-i/)). That said... the notion that you can't fix actually serious and counter-productive problems with the product because "it works" sounds not only counter to Scrum, but really counter to any software development methodology I've ever heard of.

<comment><USER8> > If you really have a fleet of web servers burning CPU and you aren't > tracking the costs, then I guess "it works" until someone figures out there > isn't any money left in the coffer.

What if the costs are fixed? (own servers, unmetered bandwidth) The problem shifts down the line when you want to add a new product and the first product is consuming all your resources. Refactoring then becomes a necessity, but there's no capacity for it because the company is focused on shiny product #2, while also adding shiny features to product #1. Now fire a few people to save money, leaving the remainder short handed, who get stressed and demoralised. But that's ok, because "it works!". Why cant we design first, lay down a good foundation, _then_ add features. The business makes more money, people keep their jobs, instead of spit-balling "user stories" at an application which becomes a giant spit-ball.

> CPU efficiency isn't the be-all to end-all and focusing on it may well prove > to be counter productive > You can spend a near infinite amount of time & > resources trying to get optimal performance

I used CPU as a broad example. What happened in my case was there was _no_ performance. At release it was unusable. What stuck in my side was I knew it was going to happen, and had been calling for refactors. But if you cant get them prioritised because you cant justify the customer benefit (it's not released yet, so nothing has fallen over yet) vs features! features! features! it then becomes a bodge job /after/ release. eg. Instead of "refactor this code to make it do fewer queries" it's "lets shove the results of these queries into a memory cache." This satisfies agile, you've iterated and made things "better" \- and it fit into a 2 week sprint! - but it feels backwards.

I was going to go on and talk about quantity vs quality, but a quick fact- check google revealed the evangelists with their "Agile parables" (it even sounds cultish), which are in no way perpetuating Agile to sell support tools, say I'm wrong.

I need to thank you for making me realise it's time for a career change. After all this time Agile has failed to convince me, I'm inclined to conclude it never will. But should the next methodology of the moment come along that emphasises quality over quantity, I reserve the right to shout "I told you so!"

<comment><USER9> > But should the next methodology of the moment come along that emphasises > quality over quantity, I reserve the right to shout "I told you so!"

Again, your problem isn't coming from the methodology. The priority on quality comes from the context, not the methodology. I have a friend who does presentations on agile all the time and his team prioritizes quality pretty much over anything simply because it allows them to develop faster.

<comment><USER10> The agile methodolgy claimed we needed to switch to it to increase quality.

Quality got worse.

In this scenario it's the fault of agile, as the reason for doing agile was to increase quality.

<comment><USER9> "The agile methodology" doesn't really make claims about what a specific group of people need to do.

It's a tool/methodology that can help you increase quality.

If quality isn't a priority, a methodology that helps to better align your work with your priorities isn't going to improve quality.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER11> Having been a manager, PM, and lead engineer this article really resonated with me. Scrum has a brief window of utility if a team isn't delivering at all, and has lost management trust. It also has a large window of dis-utility where everyone haggles over points, shows velocity as results, and leaves customers and businesses wondering what their engineers are doing. Trust your engineers to do the right thing on their own and they might just surprise you.

<comment><USER12> What does "trust your engineers to do the right thing on their own" look like to you? And how is that stopped by SCRUM?

For the way we do it, when a stakeholder wants our team to do something, they come to us with user stories and acceptance criteria that matter to them. Then we hash out the rest of it. I don't really see a useful way we could be trusted more. The Marketing department knows best what feature it is they want on the website, and why. So they specify that part. We estimate complexity and the business weighs the priority of that feature against other stuff in our backlog and it falls into an appropriate sprint based on that and other motivating factors. Then we do the work.

I don't see a lack of trust? So I'm curious where you see it and feel it should be done better?

<comment><USER13> Perhaps they meant when the engineers decide the the priority of the features and maybe even define some features themselves

<comment><USER12> If your company isn't tiny your engineers generally shouldn't be deciding priority. Unless your company is small enough that the engineers have a clear view of all the priorities of the business all we are capable of is saying "This seems really important to us." And then that has to be weighed by people who have the bigger picture.

But outside of a very small company to me it's a bigger crime to waste engineer time with all the meetings necessary to give them that full perspective. When I started at my current company I was the only developer and I worked directly with the CEO and our single marketing person. Back then I helped decide priority. Now the company is too big for that. I don't have time for all the manager and marketing and business planning meetings to be able to decide priority.

As far as defining features, we can propose them like anybody else but I think I already explained why usually it makes sense for them to come from whoever owns that piece of what you're doing. But this of course again depends on the structure of your company.

</comment></comment></comment></comment><comment><USER14> Meh... All of these items are more or less misinformed so I'm just going to bring up one.

> Because all product decision authority rests with the "Product Owner", Scrum > disallows engineers from making any product decisions and reduces them to > grovelling to product management for any level of inclusion in product > direction.

The product owner is part of the scrum team. She or he is responsible for the backlog but if she has trust in the engineers she can let the engineers add their own things to it.

I think OP just works in a bad place.

<comment><USER15> If OP worked in a "good" place where product managers & engineers trust each other to do those tasks, what value does Scrum bring?

The process is there to account for the places where the people fail. If a requirement of a process is unfailing people then it's not a valuable process.

<comment><USER16> _The process is there to account for the places where the people fail_

That's just wrong. It's there for lots of reasons – to help avoid failures and surprises, to deliver sustainable pace, to help make estimations, to ensure a common understanding of problems and challenges… the list goes on.

Scrum doesn't require infallible people – it's just a tool to help avoid failures, which happen regardless of the skill of your team.

<comment><USER15> I've not found that to be the case. In fact on at least 2 occasions in my career adding scrum practices to a product team essentially destroyed them.

I've seen instances of all of the items the article claims being problems in practice. That was across a wide variety of teams & skill levels.

I've also seen no evidence in the literature or research that backs up your assertions.

I'll concede some teams have benefited from scrum practices, but in the face of my anecdotal experience & the lack of data forgive me for being skeptical of a practice that seems largely around to keep process consultants in business.

I'm certainly not receptive to a defense that someone who criticizes it just works at the wrong place or hasn't seen "real" scrum.

<comment><USER16> _In fact on at least 2 occasions in my career adding scrum practices to a product team essentially destroyed them._

Why was Scrum added to these teams if they were already working? It's a tool to deal with problems. It's not something to use if another process is already working.

 _I've seen instances of all of the items the article claims being problems in practice.

I have found essentially the exact opposite of all the problems that are claimed to exist, and I've equally seen no research to confirm that they somehow destroy teams.

_my anecdotal experience & the lack of data forgive me for being skeptical of a practice that seems largely around to keep process consultants in business

My experience directly contradicts that. Every Scrum-ish team I've worked with has had a pretty steady pace of development and produced good software. Some other processes have worked too; the worst I've seen are fake-agile-actually- waterfall processes.

 _I'm certainly not receptive to a defense that someone who criticizes it just works at the wrong place or hasn't seen "real" scrum._

There's no such thing as 'real Scrum' so I won't use that defence. A good process is one that works for the team and company. Scrum is not a universal solution; for extremely high-performing teams it's probably overkill; for bureaucratic teams it will crush everything. It's just another good tool to use where appropriate.

<comment><USER15> Usually scrum seems to be added for the sake of 'predictability'

But nothing about the process fundamentally change the problems with software estimation. So in cases where teams are delivering rapidly at high quality but unpredictably, scrum acts as a place to hang paperwork & as a process to hide bad project managers. All while lying to management with charts.

<comment><USER9> > But nothing about the process fundamentally change the problems with > software estimation.

I'd argue quite the contrary.

> scrum acts as a place to hang paperwork & as a process to hide bad project > managers. All while lying to management with charts.

So weird. The "paperwork" tends to make bad project managers all too transparent.

<comment><USER15> You'd be arguing against research in that case. Software estimation is a widely studied subject and no estimation technique we've found has brought projects into the 'predictable' mode.

There are a few different estimation techniques that are better than others but scrum actively avoids those techniques (probably for the best as they are expensive and don't show huge gains over other forms of estimation).

Instead scrum attempts to track a made up velocity number by using any number of known to be inaccurate estimation techniques. It then gets hyper focused on breaking down tasks into small enough tasks that the velocity number stays constant, all while forgetting about the real desire, the quality software the business desires, delivered to paying customers. At that task, scrum has proven to be no more predictable than any other technique.

An enlightening exercise for any project manager is to go to a sales team and explain what you are delivering in a given sprint. Almost always, they won't care at all about that, and will instead ask for when some 'major epic' thing will be done, at which point you won't be able to tell them with any more certainty than if you'd just guessed.

Thats the best case. The worst case is that all that work you put into showing transparency around velocity ends up being used against the teams working on the hardest and most innovative projects in your organization. Their velocity will be all over the map while the maintenance teams will look good. You'll have convinced the leadership of the organization that velocity is a real number to track (cause you spend so much resources tracking it) and the incentive structures will reflect it. You just made it worse for good engineers to join the teams solving your hard problems.

<comment><USER17> > There are a few different estimation techniques that are better than others > but scrum actively avoids those techniques (probably for the best as they > are expensive and don't show huge gains over other forms of estimation).

What methods would you suggest for software estimation then?

<comment><USER15> I wouldn't do it. Prioritize your backlog, work on the most important things, reprioritize at your planning meetings.

Invest in going fast, reliability & figuring out priorities. There are lots of agile methodologies that abandoned the estimation step for the reasons I mention (fdd,rad,dsdm).

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER18> Respectfully, I'm not sure the author understands what he's talking about. He's arguing for the no-op process where engineers determine all their own tasks and priorities - and I mean, I'd like that too. But there's a fundamental difficulty in aligning each engineer's personal goals with those of the company, and some amount of management or organizational design has to go towards addressing it. Engineers won't just naturally align with the organization if nobody rewards us for doing so.

> Do managers or Product Owners track and estimate every task they engage in > with little or no say in what they work on?

> Are they required to present burn down charts that show that they are on > target to finish?

> Are they required to do bi-weekly sell-off meeting to justify their > activities?

These things are in fact the primary responsibilities of managers and product owners.

<comment><USER19> _Engineers won 't just naturally align with the organization if nobody rewards us for doing so._

Hoes does Scrum reward the engineer for such alignment?

edit: grammar

<comment><USER20> Theoretically, Scrum is a way to say 'work on this, because it's what aligns with the organization'. But, of course, whether it really does or not depends on who is implementing it and how.

<comment><USER19> Scrum telling you how to align with the organization is not rewarding the engineer in any way. Orthogonal concerns.

How does Scrum reward the engineer, in a way that it does it better, and more profoundly, than other methodologies?

<comment><USER18> When you let engineers run around doing our own thing, we never have to show that the work we're doing _is_ the most productive use of company time. We just have to show that it plausibly could be. Nobody will hesitate to reward the well-liked engineer with a cool sounding project, even if other things would really be more important.

As the author noted, Scrum solves this problem by making number of story points completed the primary tool for a team to measure its productivity. If the cool-sounding project isn't important enough to take other items out of the sprint, there's no way to offer a post-hoc justification for doing it anyway. It has no story points, so work on it is considered non-productive.

</comment></comment></comment></comment></comment><comment><USER21> I've found that "certificated scrum masters", "certificated project managers" and their ilk are the problem. Anyone who says we must follow a specific process because that is how agile development is done is missing the point.

The actual agile manifesto makes a lot of sense IMO.

[http://agilemanifesto.org/](http://agilemanifesto.org/)

<comment><USER19> Does it? E.g.

 _Welcome changing requirements, even late in development. Agile processes harness change for the customer 's competitive advantage._

Everyone has deadlines. Either customer imposed ones, or the market running against you. At some point, you'll have to meet them. When do you stop accepting changes and deliver? Can you welcome last minute disruptive changes? Sure. But the market won't wait for you to implement them.

 _Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale._

Some tasks require longer attention spans. This is the classic technical debt accumulation choke point. Now, iterations + deadlines make sense. But does it have to be a fixed 2/3 week period, always? Where the flexibility in that?

 _Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done._

To be fair, I've only seen Scrum. But this point is in direct contradiction. Scrum is about diluting the individual. Everyone is a replaceable resource.

 _Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely._

This is just wishful-thinking, the Agile Point. The only remotely close way of doing this is turning everyone into cogs in a machine. No, thanks. Weren't we valuing the individual?

 _Continuous attention to technical excellence and good design enhances agility._

And takes time. Ops, sprint's time is over. I guess that refactoring can wait.

 _The best architectures, requirements, and designs emerge from self- organizing teams._

Some of the most successful products and projects (Linux, Python, Apple) revolve around strong leadership.

There are definitely good ideas in this manifesto. Ideas that have been applied for years, before even the manifesto came to be. Some others are just wouldnt-it-be-nices.

<comment><USER16> Yes, it does.

 _Everyone has deadlines. Either customer imposed ones, or the market running against you. At some point, you 'll have to meet them. When do you stop accepting changes and deliver? Can you welcome last minute disruptive changes? Sure. But the market won't wait for you to implement them._

There is no point in delivering software which doesn't meet customer requirements. If changes to software are required because it doesn't meet requirements, pretending otherwise solves nothing. Agile processes make it easier to cope when these changes happen, and accept that if change is required then other constraints have to move – such as deadlines.

 _Some tasks require longer attention spans. This is the classic technical debt accumulation choke point. Now, iterations + deadlines make sense. But does it have to be a fixed 2 /3 week period, always? Where the flexibility in that?_

Most tasks do not require 'longer attention spans', whatever that means. Almost literally every task can be broken into smaller parts with minimal effort, helping to expose implementations to scrutiny at earlier stages.

And while Scrum traditionally has a fixed sprint length, there's no requirement to follow that to the letter. If your constraints are such that it doesn't work, then adjust the process to suit.

 _But this point is in direct contradiction. Scrum is about diluting the individual. Everyone is a replaceable resource._

No – Scrum is about the _team_ of individuals. Depending on a single individual is obviously stupid regardless of what process you use.

 _The only remotely close way of doing this is turning everyone into cogs in a machine._

Not at all true. A nice sustainable pace is reasonable for any team of skilled professionals. If you are not achieving it, your team is broken.

 _And takes time. Ops, sprint 's time is over. I guess that refactoring can wait._

And pretending otherwise does nothing. Make refactoring a requirement for completion, and you will avoid this problem.

</comment></comment></comment><comment><USER22> Don't tell me why Scrum sucks. That's really not useful to me.

Show me a better system instead.

<comment><USER6> Call it Kanban, it's exactly the same thing but without all the certifications and consulting services around it.

[https://thehftguy.com/2017/12/06/scrum-vs-kanban-arent- they-...](https://thehftguy.com/2017/12/06/scrum-vs-kanban-arent-they-the- same-thing/)

<comment><USER23> You're incorrect.

Scrum is a framework. Kanban is a method of implementing a system.

Here's Kanban creator David J. Andersen's own words:

[http://www.scrumcrazy.com/David+Andersen+-+There+is+no+kanba...](http://www.scrumcrazy.com/David+Andersen+-+There+is+no+kanban+process+for+software+development).

Also Kanban has certification:

[http://leankanban.com/team-kanban/](http://leankanban.com/team-kanban/)

And consulting services around it:

[http://leankanban.com/project/services/](http://leankanban.com/project/services/)

<comment><USER6> They're both a basic TODO list with a fancy commercial name.

</comment></comment></comment></comment><comment><USER24> One under-appreciated shortcoming of Scrum is that it doesn't deal well with dependencies on other orgs that have their own schedules and probably don't use Scrum themselves. We ran into this at Red Hat, where the other org is an external open-source community. You do your work quickly like Scrum forces you to, submit the work upstream, where people not operating under Scrum's artificial time pressure ignore or reject it. Hardly surprising, since quick often means dirty. In any case, you have no control over how long it takes that process to complete, let alone when the new code gets into an upstream release so you can pull it back in. What always ends up happening is that developers have to take on more work in progress while code works its way through someone else's process. If it's done officially it's no longer really Scrum. If it's done unofficially it's still no longer really Scrum, and even worse the time spent shepherding patches upstream is invisible to the Scrum planning process.

Maybe Scrum works when you're a passive consumer of the frameworks, libraries, etc. that you use, with no expectation that any significant time will be spent contributing back. I don't know; I haven't worked in that kind of environment for a very long time. That only seems like a tiny segment of how real development gets done, though.

<comment><USER12> I don't see this as really an issue. When your work is done it's done. If it's someone else's work that needs to be done now before you can do something else, those should be separate issues/stories/tickets that are blocked until that external work happens.

In my mind it's no different than waiting on a design or pricing sheet or API key or any other dependency that holds up work. Yeah you might have to context switch to something else for however long you are waiting but that's what happens.

Also why the "do your work fast like SCRUM forces you too"? SCRUM doesn't mean do your work shitty and fast. Maybe your organization wants it to but whether you prioritize speed or doing it the best you can or whatever is up to you, I don't see that as part of SCRUM.

<comment><USER24> > When your work is done it's done

Have you ever worked on open source? Getting code accepted upstream is not somebody else's work. It usually involves significant ongoing effort _by the author_ on top of what they did to implement and test the code in the first place. That work is usually very interrupt-driven too, responding to review comments etc. whenever someone upstream happens to wake up, and that makes it even worse. Your "separate issue" idea is exactly how Scrum fails to account for real work in progress when open source is involved.

<comment><USER12> If that work is non-development work like writing emails or getting in hangouts or Slack conversations or whatever then you're right it doesn't get tracked in SCRUM tickets/issues/stories (typically.) but that's fine. Because it should be reflected in your velocity automatically by the reduced development work you can accomplish.

If it does result in development work; like your pull request results in revisions. You have choices about how to account for that. If you feel you have confidence about how much extra work that will add based on the issue you're working on, you can account for that when pointing it. (Much like you'd account for writing tests or going through code review process within a team.)

If you have no handle on how much work it takes for whatever reason (contributing to multiple projects with wildly different expectations) then you can make new issues for each set of revisions. This will give you clear history that you can reference afterwards and learn from.

In any case; it's a poor craftsman who blames his tools. SCRUM can work for all these situations if you want it to. If you have a defeatist attitude or if you prefer to blame systems and tools for your problems instead of finding solutions, you can do that too.

Let me be clear; I'm not saying SCRUM is for everyone or the best system or any of that. I'm just saying these specific claimed problems don't hold water with me.

<comment><USER24> > it's a poor craftsman who blames his tools

It's an even worse craftsman who persists in using the wrong tool. If the tool does a poor job or requires more maintenance than the work it saves - as would be the case if your suggestions were followed - then it should be abandoned in favor of another. Which is what we did. Solutions found, nothing defeatist about it, and I notice you didn't answer the question about whether you've actually tried to do this.

<comment><USER12> I have contributed to open source occasionally. It's not a part of my job most of the time so it's rare.

But it's also not relevant at all. As I tried to spell out the situation you describe is not unique at all. It's the same thing every software dev encounters.

I'm glad you found tools that work for you, but this exchange has been unpleasant so I'm done with you.

<comment><USER24> > It's the same thing every software dev encounters

No, it really isn't. "Upstream first" development such as Red Hat does is _fundamentally_ different than developing in private, even if that includes throwing the occasional scrap back over the fence.

If you think this exchange has been unpleasant, consider that casually dismissing others' experience rarely leads to any other outcome. Did you do your part to make it pleasant for anyone else?

</comment></comment></comment></comment></comment></comment></comment><comment><USER25> Yeah this seems to be an excellent list on how not to Scrum. Or an what happens when scrum is used by people that don't understand the spirit list. I actually scrolled down to see if it was a joke list or had a deeper point.

Scrum is actually used to make sure the dev team is part of the decision process and there is no reason not to be innovative But of course the enterprise can kill all things good

</comment><comment><USER26> A lot of this article is a mix of a little bit of truth with a lot of what is just bad management.

But the first few and final example are good warnings that can be applied anywhere, Scrum or not. Paraphrasing / quoting the article:

"[If] all product decision authority rests with the "Product Owner" ... engineers [are disallowed] from making any product decisions and reduces them to grovelling to product management for any level of inclusion in product direction."

"[If] all the engineer's time [is accounted for] in a tightly managed fashion, [that] discourages innovation — which typically occurs spontaneously and outside of any schedule or system of good predictability."

"[You] encourage "least amount of work possible" solutions [when you expect engineers] to conform to ... strict predictability requirements."

"[If you] divide every task into small items that can theoretically be completed by anyone on the team .. [you] discourage engineers from taking pride in and/or ownership of their work. This lack of ownership results in ... Poor design [and] Lack of motivation ('It isn't my thing', 'It was broken when I start working on it')"

"[Don't] ignore the fact that any task that has been done before in software does not need to be redone because it can be easily copied and reused. So, by definition, new software tasks are truly new territory and therefore very hard to estimate."

</comment><comment><USER27> > Because all product decision authority rests with the "Product Owner", Scrum > disallows engineers from making any product decisions and reduces them to > groveling to product management for any level of inclusion in product > direction.

Only if your Product Owner sucks. Their job is to communicate with all stakeholders, which includes letting the engineering staff have their say. If the engineers feel left out, the product owner isn't doing their job.

> Scrum, in accounting for all the engineer's time in a tightly managed > fashion, discourages innovation — which typically occurs spontaneously and > outside of any schedule or system of good predictability.

It doesn't. That is why there is a 'focus factor' baked in, to allow for their time to not be tightly managed.

> Scrum encourages "least amount of work possible" solutions — to conform to > it's strict predictability requirements.

No, it doesn't. The scope of a task becomes a negotiation point for assigning stories into sprints. Sometimes you do something quicker to make the sprint work. But that shouldn't be the default answer. It should just be a talking point. Most of the time, the engineers dictate the effort required to complete a feature, and if they always pick the quickest easier way.... well, then that is a problem that needs to be resolved with the team.

I could go on for every point. But I'm not seeing a single shred of evidence that this author actually understands Scrum. They seem to have been exposed to poor scrum teams, focusing completely on processes and documents, not the communications, negotiations, and discussions that are truly the heart of scrum... admittedly put within a defined structure. I'm not saying Scrum is perfect. It isn't, but you definitely are going to hate it if you have never even seen it done well.

<comment><USER28> > > Scrum, in accounting for all the engineer's time in a tightly managed > fashion, discourages innovation — which typically occurs spontaneously and > outside of any schedule or system of good predictability.

> It doesn't. That is why there is a 'focus factor' baked in, to allow for > their time to not be tightly managed.

Can tap into my experience and say that it does discourage innovation and has nothing to do with focus.

While doing innovation and research, your path is fuzzy and unpredictable and does not fit into a predefined scope that the team has to commit on at the beginning of the sprint.

While doing research or innovating, you never know if you can deliver business value - your research may succeed... or may fail, which is often the case. Meanwhile, in the predefined sprint scope, everybody is clear what tangible business value it will bring, everything is clear and no room for wiggling and straying away.

Edit: I am not talking about occasional research tasks, which seem to fit well into Scrum structure. I was talking about the innovation as a project that requires a big chunk research to be done.

<comment><USER16> _While doing innovation and research, your path is fuzzy and unpredictable and does not fit into a predefined scope that the team has to commit on at the beginning of the sprint._

This is because _you are doing it wrong_.

Innovation and research is valuable. It has a business cost, and may not result in business value in all cases. That's totally fine! But it's still important to recognise that so that we can understand the costs and benefits that are being realised.

I pretty frequently engage in long-running research tasks within a Scrum team. The approach that works is to be clear about what the deliverable output is. Perhaps this takes the form of a plan of action, or documentation of the research. If the whole scope of that research project doesn't fit into a sprint, then that's a red flag – break it up.

I've had literally no problems with this approach and it's made the process of understanding the business costs of long-running, uncertain projects much clearer.

</comment></comment></comment><comment><USER29> We do scrum and this doesn't describe how it works for us at all. Our scrum master isn't our manager and neither is our product owner, for example. And we have gone some time with minimal direction from the product owner at all, when things were going well.

My main complaint about scrum was how much of my time was spent in meetings vs working.

</comment><comment><USER30> I just put my teams on scrum and they love it. Immature scrum that focuses on metrics and jira boards can be a very tough transition, but mature scrum that focuses on collective ownership and continuous improvement is heavenly.

</comment><comment><USER23> Another day and another post where someone who believes their companies incorrect adoption of the Scrum framework is evidence that Scrum itself is at fault and therefore creates a Strawman to attack.

Scrum is a victim of Semantic Diffusion. [https://martinfowler.com/bliki/SemanticDiffusion.html](https://martinfowler.com/bliki/SemanticDiffusion.html)

You know all of those things that you're doing at work when someone says its Scrum? Chances are they're not Scrum but practices that are additional to Scrum:

User Stories? Not Scrum

Story Points? Not Scrum

YAGNI? Not Scrum

Pair Programming? Not Scrum

Planning Poker? Not Scrum

The list goes on.

I recommend that anyone who currently hates Scrum to spend 30 minutes one lunch time and read the Scrum Guide: [http://www.scrumguides.org/scrum- guide.html](http://www.scrumguides.org/scrum-guide.html)

You may then realise how that consultancy that your company hired butchered it to sell their people to do transformation, or that old school Programme Manager changed it because he wanted more control, or that Scrum Master who joined a company who was already doing a butchered Scrum implementation and did a 2 day course and learned nothing else then espoused what they knew as Scrum when they joined a new company.

This article shows the author has strong opinions on something they don't understand - That's not a good trait to have.

</comment><comment><USER31> Having personally witnessed all of these symptoms of "agile" on teams I've been on, I was pleasantly surprised to discover when I read Jeff Sutherland's book that none of these problems have much to do with Scrum, which is more of a way of thinking about building (and tearing down) processes to optimize for the things only the team can identify, than a process itself.

I think the reason these sorts of bad practices crop up so often is because internalizing and applying the sort of ego-free principles of Scrum is very very hard, even for a small team (or individual).

Reading that book [0] (particularly the first half) was eye-opening for me, and I recommend it to anyone who works in an "agile" environment.

[0] [https://www.amazon.com/Scrum-Doing-Twice-Work- Half/dp/038534...](https://www.amazon.com/Scrum-Doing-Twice-Work- Half/dp/038534645X)

Edit: I would add that the linked article is pretty typical of things I had read online about Scrum before I read Jeff's book, and I believe are very misleading and unhelpful, as they abuse one way to solve the problems they complain about. Bad team dynamics didn't come from Scrum. Maybe Scrum failed, but that's a whole different discussion.

</comment><comment><USER32> > It assumes that engineers cannot conduct a meeting effectively without a > facilitator (Scrum Master)

Scrum isn't perfect but this is certainly not true. If the team is well- functioning there doesn't need to be a facilitator of any kind present. Sounds like OP is either in a bad team or with a bad Scrum master—or both.

<comment><USER33> _If the team is well-functioning there doesn 't need to be a facilitator of any kind present._

This is a tautology.

<comment><USER32> Only if you misunderstand me. ;) What I meant was that Scrum doesn't dictate that there _has_ to be a facilitator present but if your team isn't well- functioning it's probably a good idea to have one. I.e. if the Scrum master has done his job exceptionally well he's rarely needed.

</comment></comment></comment><comment><USER34> I think more people need to talk about best fit. People shoehorn scrum into every situation, when it is perfectly valid to say that it won't work sometimes, and others when it would work well. You wouldn't use JavaScript to build an operating system, and you wouldn't write your browser code in C. So why assume that one SDLC regime is right for every situation.

Scrum seems to work well when estimation really is possible and there is true ownership and flexibility on the team.

I have not seen Scrum work well with brand new products or situations where practically every task is an unknown and the team is defining and prioritizing features in the product as they move and discover. Which makes sense as Scrum does assume a high degree of uniformity and definition. There are situations where the product owner, temporarily, has to be the whole team.

</comment><comment><USER35> Funny, while in agile teams I made several product decisions and did innovate in some occasions.

You don't need everything to be "inside the project/inside the process" and even then, more things fit there than people might think.

</comment><comment><USER36> This is a list of things they are doing wrong not things wrong with Excel, Visual Studio, JIRA, The Scrum Methodology or any other tool they have poorly implemented.

They should seek external help in getting their usage of these simple tools back on track.

I've seen people create horrible abominations using Excel, that doesn't mean that the tool itself is broken or that all the effective usages of Excel are wrong. It's the same with Scrum. If you use it right it's awesome, if you use it wrong it's just a different name for the same old bad project management you always had.

</comment><comment><USER9> So much wrong here. I couldn't quite figure out the full nature of the problem (aside from working in a terrible environment), but then I saw this the author's most recent post: [https://medium.com/@ard_adam/the-fountainhead-and- software-e...](https://medium.com/@ard_adam/the-fountainhead-and-software- engineering-d991b269af2e)

Now it all makes sense.

</comment><comment><USER34> The biggest one for me is estimation. I grant that certain domains work on very predictable tasks, but what if you are working on a new product that is solving a lot of new problems? Practically everything should be a spike. I'm working on a new product right now and our estimates are worse than garbage as they end up just haunting us with management.

</comment><comment><USER37> Pretty good list of symptoms, side effects, phenomenon.

My assessment is somewhat more simple:

Scrum is a strategy to reach an unspecified goal thru incremental revelation. (1)

I'm old school. Raised on PMI and gantt charts. I prefer defined goals and critical paths. (2)

(1) Drunken sailor's walk thru the problem space.

(2) What we grey beards called "a plan".

</comment><comment><USER38> "Scrum is probably the worst way to build software, except for all the others."

<comment><USER39> Well having done RAD/DSDM (including projects presented at the IEE) some of the bizarre rules based things scrum gets up to seem sub optimal (to be kind).

I have even done very successful hybrid projects that used Waterfall for design and built the system using RAD in 12 weeks - including doing a physical delivery.

</comment></comment><comment><USER40> A lot of these items are process points. The whole point of scrum is that the team determines and refines the process over time. Scrum is not a process but a process creation framework.

I agree with most of the comments so far this is bad management.

</comment><comment><USER41> This list shouldn't be named "what scrum does wrong", it should be named "excuses made by engineers who don't want to take responsibility"

</comment><comment><USER42> > 7\. Scrum is very management heavy. Typical teams have Product Owners, Scrum > Masters, and Team Leads. Innovative, motivated teams operate better with > less management, not more.

> 8\. Scrum is typically implemented with HORRIBLE task management tools > (Jira, tfs, etc…) that enforce very bureaucratic interpretations of Scrum > that waste huge amounts of developer time. Additionally, they effectively > lock you into one mode of operation, no matter how ineffective.

Scrum is not just management heavy. It's micromanagement heavy. If someone asked me for an account of what I did for a whole six (assumed to be productive) hours yesterday and how many story points have been burned, and wanted this every single day, I can only imagine that the person has no experience with software development whatsoever. There are productive days when a lot of stuff gets done and there are unproductive days when almost nothing gets done because it's hard to focus or because of distractions. But the daily standup meeting that's enforced would make any unproductive days as something to get publicly shamed about.

On the tools, yes, whatever I've seen in Scrum dictates a lot of time spent updating the tools with estimated hours, hours spent, remaining hours, everyday. That data is rarely useful for any further estimations or to figure out what's going on.

Lastly, the "story points not related to effort but related to effort" conundrum confuses developers (especially the ones who are considered to follow instructions and code whatever the user story's tasks say). Add to this a really weird concept called velocity, which is not just a measure of how many story points are completed in a sprint, but is used as a range — too low and you're not working hard enough; too high and your estimates are wrong. The only way to satisfy the Scrum master in many cases is to lie and make the velocity conform to expectations.

I have no idea who was tying to prove what to whom when they came up with Scrum and Scrum certifications. The certified Scrum masters I've seen don't even know how to write a good user story or to break it into tasks.

Give me low process overhead iterative waterfall any day over these schemes. Repeatedly trying to turn software developers into predictable manufacturing style widget makers is not a good idea.

<comment><USER16> You have given an example of a shitty company using a shitty process. It's unfortunate that it's nominally 'Scrum', but that's kind of irrelevant.

 _If someone asked me for an account of what I did for a whole six (assumed to be productive) hours yesterday and how many story points have been burned, and wanted this every single day, I can only imagine that the person has no experience with software development whatsoever._

This is wrong. If this is happening, you are following a broken process.

 _On the tools, yes, whatever I 've seen in Scrum dictates a lot of time spent updating the tools with estimated hours, hours spent, remaining hours, everyday._

No it doesn't. This is wrong and broken.

 _Lastly, the "story points not related to effort but related to effort" conundrum confuses developers _

If a software engineer can't immediately grasp this abstraction then they are not good software developers.

 _too low and you 're not working hard enough; too high and your estimates are wrong_

Velocity should not be used as a stick. It's a measure of the amount of work being done which can be used for planning. If it fluctuates, that can indicate problems that need to be dealt with.

 _Give me low process overhead iterative waterfall any day over these schemes. Repeatedly trying to turn software developers into predictable manufacturing style widget makers is not a good idea._

"Low process iterative waterfall" is basically Scrum.

I work two-week sprints. There are a total of four hours of meetings for those two weeks. 5% overhead seems pretty reasonable.

<comment><USER42> The problem, as I see it, is having Scrum certifications and certified Scrum Masters who follow a rigid process with many conditions (which is antithetical to the agile mindset).

I know "low process overhead iterative waterfall" sounds agile, but somehow the word "Scrum" seems to make people want a certified Scrum Master (these people usually frown on waterfall-like processes even if those are better suited for delivery).

</comment></comment></comment><comment><USER16> This is a bad article. It conflates "bad management" with "bad process", and unfortunately pays too much attention to an idealised "official" version of Scrum. This is the first thing that anybody developing a Scrum process should discard.

Let's deal with these points step-by-step.

 _Because all product decision authority rests with the "Product Owner", Scrum disallows engineers from making any product decisions and reduces them to grovelling to product management for any level of inclusion in product direction._

This is a sign of a bad team. The product owner in a functioning Scrum team works with the engineers to establish the product direction, both at the micro and macro levels. My current product owner will involve the engineers in almost all product decisions; she is responsible for mediating between the different priorities set by different parts of the business. All product meetings are open to engineers who want to contribute. It works well, and Scrum has no embargo on this.

 _Scrum, in accounting for all the engineer's time in a tightly managed fashion, discourages innovation — which typically occurs spontaneously and outside of any schedule or system of good predictability._

Scrum should not involve 'accounting for time'. It's entirely possible to include innovation and research within a sprint – sprints should always be a little flexible and allow for some expansion or contraction of goals specifically to support this. Longer-term innovative or research tasks should be treated like any other work – and importantly, the process should be flexible enough to accept that priorities sometimes change, and that failing to meet a sprint target because the situation changed is okay.

 _3\. Scrum encourages "least amount of work possible" solutions — to conform to it's strict predictability requirements._

This is simply false. Uncertainty should be built into every prediction made. The goal is to _assist_ with predictability, not to _require_ it.

 _By dividing every task into small items that can theoretically be completed by anyone on the team, Scrum discourages engineers from taking pride in and /or ownership of their work._

Only if you have a poorly-skilled or unprofessional development team. Scrum isn't going to fix that problem.

 _5\. Scrum is highly intolerant to modification, and it's proponents typically espouse an all or nothing attitude in it's implementation._

Finally, a possible reasonable objection! The first thing one should learn to do when building a process is to ignore all dogma. Adapt Scrum for your particular requirements; it's still Scrum, more of less. Nobody has ever implemented Scrum precisely as described.

 _6\. Scrum's attitude of intolerance to self-examination is present in all of it's practices. Only processes that operate internally to Scrum's framework are open for modification— as for Scrum itself, it is seen as sacrosanct._

See above.

 _7\. Scrum is very management heavy. Typical teams have Product Owners, Scrum Masters, and Team Leads. Innovative, motivated teams operate better with less management, not more._

Scrum involves three roles – a product owner, a scrum master, and a development team. The product owner decides what to do; the scrum master looks after the process and removes roadblocks for the others; the development team do the work. These roles can be combined where required. Frankly I'm struggling to imagine a _lighter_ form of management.

 _Scrum is typically implemented with HORRIBLE task management tools (Jira, tfs, etc…) that enforce very bureaucratic interpretations of Scrum that waste huge amounts of developer time. Additionally, they effectively lock you into one mode of operation, no matter how ineffective._

You're entirely free to practice Scrum using whatever tools you want. Personally I have no problem with a simple Jira implementation. If it's been over-complicated, then you have implemented it badly. The whole point is to provide tools that make it easier to manage work. I use Jira, spend essentially no time using it beyond keeping track of what I'm doing and sharing knowledge about particular work. If this tool doesn't work, use something else.

 _9\. Scrum discourages bug fixing, reduction of technical debt, and risk taking, all because of its narrow, exclusive focus on only doing items that Product Owners would interpret as valuable._

The product owner must be a skilled professional who works with the development team to decide what the priorities are. If the development team believe that a particular bit of non-user-facing technical work needs to be done, then that should be taken into account by the product owner—who as a professional, will trust the development team's judgement—and appropriately prioritised.

No process will fix an overworked team, or compensate for a lazy product owner. Frankly, it's not Scrum's fault.

 _10\. Scrum is hypocritical. Do managers or Product Owners track and estimate every task they engage in with little or no say in what they work on? Are they required to present burn down charts that show that they are on target to finish? Are they required to do bi-weekly sell-off meeting to justify their activities?_

Product owners are accountable for their activities like anybody else. I think they'd benefit from a bit of Scrum in that! In fact, we've found that our process has worked well enough that other business units are beginning to roll out Jira to help teams understand what work they're doing.

As for the other points, I've never had to present a 'burn down chart' or otherwise justify my activities to anybody. Again, Scrum will not fix a micromanagement culture.

 _It assumes that engineers do not have task tracking systems that they already use to manage their time and therefore need time-management hand- holding._

Scrum does not involve time-management. Let me say this again: "SCRUM DOES NOT INVOLVE TIME-MANAGEMENT".

 _It assumes that engineers are not to be trusted with directing their own work._

It does not do this. I am trusted to direct my own work. I agree what that work is with other stakeholders. That's Scrum.

 _It assumes that engineers cannot align themselves with the best interest of the organization, without tight supervision._

It does not do this. I am not supervised; I use Scrum to agree with the rest of the organisation what is in its best interests.

 _It assumes that engineers cannot conduct a meeting effectively without a facilitator_

It does not do this. My scrum master (actually the head of development, acting in that role for multiple teams) takes care of the nitty-gritty of booking meeting rooms, setting calendar dates, preparing documentation, taking notes, finding availability, and that kind of thing. They are a helpful facilitator. If you have an alternative, that's awesome. The scrum master doesn't ned to be involved.

 _It assumes that you can plan every facet of a software task by merely talking about it in sprint planning /backlog grooming_

It does not. No ticket describes every aspect of a feature. Ideally, you can do this, but we all know that things can change. Roll with it and take the obvious step of dealing with unexpected changes like an adult.

 _It assumes that all engineers work the same way._

That's just flat-out wrong.

 _Scrum story points are supposedly meaningless, yet they are tracked, recorded and presented at many levels in an organization and often are the only metric by which a team's performance is represented (ie. Velocity)_

As far as I'm aware, nobody outside my team knows anything about our velocity. It's purely a method used to help us understand how much work we can commit to in a given period. If it is being reported, you are doing it wrong.

 _Scrum is designed to manage the weakest Engineers and consequently dis- empowers the better ones._

No.

 _Scrum is the opposite of many of the points set forth in the original agile manifesto:_

No justification is provided.

 _15\. Scrum ignores the fact that any task that has been done before in software does not need to be redone because it can be easily copied and reused. So, by definition, new software tasks are truly new territory and therefore very hard to estimate._

This is laughably wrong.

Basically, I disagree emphatically with _every single point_ made in this article. I have had an _excellent_ time as part of a Scrum team; I have a clear idea of:

\- What I'm doing \- What others are doing \- How we can help each other \- What the business priorities are \- When particular tasks take longer than expected \- How we can avoid surprises and failures

I honestly can't imagine working any other way.

<comment><USER43> Every criticism of Scrum or Agile evangelicism is met with these No True Scotsman arguments that if you were simply better, or tried harder, the process would save you.

I want a process that works for the messy, suboptimal world that is reality.

<comment><USER16> I'd argue that you can't 'solve' bad developers, bad managers, or bad culture with _any_ process.

</comment></comment></comment><comment><USER44> This seems like a coded endorsement of Agile processes.

</comment><comment><USER45> I'm disappointed that this throwaway list of unsubstantiated bullet points is being treated seriously, but seeing as it is, here's "A brief list of what this article gets wrong about Scrum":

1) The author makes the unfortunately all-too-common mistake of confusing agile development with software design. Agile says very little about software design, other than observing that it is incremental and iterative rather than revelatory and monolithic. Scrum, as an example of agile practice, is primarily concerned with implementation and delivery. The Product Owner can consult anyone they want in the course of designing the software, and of course that includes the engineering team. Scrum encourages the PO to seek the participation of all stakeholders in sprint planning and review, but other than that, design is left to the PO's discretion.

2\. Nothing in scrum discourages innovation, and agile certainly encourages innovation to a much greater degree than the detailed spec-driven alternative.

3\. There is actually a grain of truth to this one, but it confuses what happens within one sprint with the overall process of software evolution over many sprints. What the author is complaining about here is basically Scrum's version of YAGNI ("You Ain't Gonna Need It"). It's the principle of doing the simplest thing that could work first, and then elaborating on it. My 35 years of software development experience tell me that this is a sound approach. Others may disagree.

4\. Scrum does not require the "dividing every task into small items that can be completed by anyone on the team". It definitely encourages dividing work into meaningful pieces with tangible, testable results. But nothing prevents a team from matching work with the team members most suited to doing it. The author seems to be complaining about working on a team in general, where the credit for the product must be shared with others. Nothing about scrum encourages 'lack of ownership' to any greater degree than any other team-based development process.

5\. This is simply wrong. Scrum encourages modification and explicitly proves the flexibility for it by ensuring that you're never more than a sprint away from changing direction if it becomes clear that's necessary. And of course, if the team is _really_ blindsided by new information, the PO can cancel the current sprint and start a new one.

6\. Scrum explicitly encourages self-reflection through the retrospective that occurs every sprint. The author here is apparently ignorant of this aspect, so maybe it was not practiced in his company.

7\. Scrum requires minimal management. The Scrum Master is not intended as a manager, they are intended as a way to short-circuit bureaucracy so that any impediments to the team's progress can be removed. And I've never seen any software development process of any scale that doesn't have a Product Owner or a team lead, though the titles may change.

8\. There are lots of bad tools. Don't use them. Find good ones, if you need them. Scrum _requires_ very little, a whiteboard and some sticky notes will do.

9\. Scrum does not discourage (or encourage) bug fixes or refactoring. As the author notes, that's at the discretion of the Product Owner. Again, that's always true, whether you're using Scrum or some other software management system.

10\. The Product Owner is responsible for delivering the product on time. Of course they are accountable, and I guarantee that if they're at all competent, they're doing far more reporting and documentation for their superiors than the team is for them.

11\. Scrum assumes none of these things. Not a single one. Who has a Scrum Master at every engineering meeting, for instance? Ridiculous. The Scrum Master runs the daily scrum, which is a 15- or 20- minute daily sync up. They don't attend any other technical meetings unless someone wants to invite them for some reason.

12\. Of course scrum points aren't meaningless; why would anyone bother to track them if they were? They tell the team what it's velocity is, which is useful to the team for sprint planning, and useful to management for resource planning.

13\. Scrum disempowers the best developers from...what, exactly? Scrum is designed to allow devs to focus on delivering, so they don't have to guess at what's being requested, and so they get quick feedback on what they've implemented. At all times, they know how they're doing. There's nothing disempowering about scrum.

14\. The Manifesto doesn't say "no processes or tools". The scrum process is very light compared to the spec-driven process that it replaced. And as noted above, it doesn't require many tools. The fact that people feel like they need ten Atlassian services to do it isn't Scrum's fault, any more than the fact that you bought a Total Gym and a ThighMaster means that fitness is bunk.

15\. Any developer who truly believes that "any task that has been done before in software does not need to be redone because it can be easily copied and reused," and that any new task cannot be estimated, should really find another profession.

Honestly, I think the article is a troll. For the author's sake, I hope so. If not...well, he says he's a Programmer and Dog Owner. I hope he's a really good dog owner.

</comment><comment><USER46> Wow, this article is blatantly wrong on almost every point the author makes.

</comment><comment><USER47> Only a brief list?

</comment><comment><USER12> My team does SCRUM at work and almost none of these apply to us. Sounds like the author works in a bad company.

<comment><USER48> I work for a good company but the team I was on a few years ago was using scrum. It really does promote pushing debt down the line because the product owner only cares about what they can see or measure. The debt isn't part of that set so the developer has to fight to address it. After the first battle many will stop fighting because they are measured by how well the product owner thinks that developer is implementing their roadmap and on track with the schedule they got approved.

Products with heavy debt tend to get rewritten rather than fixed. So it makes sense to keep the schedule through shortcuts and push as many features as possible. Then throwaway the product and rewrite in something newer and more modern.

For developers the benefit is your resume will have the latest tech and you can write sloppy non-abstracted code and not worrying about having to support the product later. Management gets increased visibility into each task with an accurately followed schedule.

Not a surprise it has become so popular. If I could change one thing I would make the scrum master in charge of technical documentation. That one change would force the master into understanding the code at a lower level. That would make them the most knowledgable person on the project thus it would remove the need for daily standups because team members could go to the master at any point in the day with questions or to coordinate effort.

<comment><USER12> SCRUM does not push for bad, tech debt laden products any more than any other development system. Managers who want you to push code out the door ASAP will do it just as much no matter the system you're using.

The solution is not to blame whatever particular form of agile you're using; the solution is to replace the bad managers if you can't educate them on why that's short sighted.

</comment></comment></comment><comment><USER49> Mediocre developers will produce mediocre results. No methodology will pull great results from mediocre developers.

</comment><comment><USER50> The engineer here is protesting being turned into a factory worker, becoming alienated from his work, and being used towards the ends of management rather than his own. It is an indictment of capitalism's effects on workers, even highly skilled knowledge workers.

What he is expressing is the inkling of the desire for a better world; perhaps one where there is democratic control of the production process by workers.

A spectre is haunting software development. Developers of the world unite! You have nothing to lose but your chains.

</comment><comment><USER51> The Agile movement was all about dropping the process hoop jumping and focusing on solving problems efficiently, that's why it was considered extreme. Too extreme, as the one true implementation to rule them all is worse than what the agile movement was revolting against. This is how the game is played, over and over and over again; any movement that threatens the narrative is embraced, corrupted and ultimately used as a weapon against its core values.

</comment><comment><USER52> I am getting real tired of methologies and agile movements all together

</comment><comment><USER53> This post confuses many things but firstly it doesn't properly talk about Product Management. PM is customer centric and marketing heavy discipline and just knowing how to code and good intentions of devs may not work on competitive market. Secondly Scrum is project management framework and says nothing about software development practices and leaves them completely to the judgment of the team (including developers and PO because they collaborate heavily in Scrum).</comment>


Ask HN: How to Get Good at Sales? - <AUTHOR> In Sam Altman's recent blog post, "How To Be Successful", he talks about "Getting good at sales":
Self-belief alone is not sufficient—you also have to be able to convince other people of what you believe.
All great careers, to some degree, become sales jobs. You have to evangelize your plans to customers, prospective employees, the press, investors, etc...
http://blog.samaltman.com/how-to-be-successful
Other parts of the post resonated with me, and this one does too, as something I want to work towards as I build my company.
Looking online, all advice on "sales" is centered around actual sales scenarios, rather than what Sam is referring to. I was wondering if anyone came across any books etc. or had good advice on where to start with "getting good at sales". <comment><USER2> This is one of those things that HN may not be great at overall. Most answers here are brainy: "read this book" or "follow these principles" type suggestions, but this is really something that isn't solved by reading about it. Don't get me wrong it helps to have an intellectual basis, but in reality you just need to be embarrassed and rejected a lot to get good at sales.

Sales isn't about your product, it's about the person your speaking with and picking up on queues and verbiages that help you cater the conversation to them.

There isn't a magic algorithm here. Get out among people and learn how to hold an artificial conversation for longer than 1 minute with a complete stranger without making it feel artificial. Once you can do that and walk away _feeing_ good about it, you can start to figure out how to convert that artificial-ness into something that's hard to distinguish from comfortable conversation with someone you've known for 10 years. That's sales. It's being able to interact with people at a comfort level that enables them to feel relaxed and safe.

I push a lot of CS students to get jobs as servers at local restaurants and bars. The pure experience of interacting with a group of new strangers every 5-10 minutes is hugely beneficial to sales development. It's also easy to practice selling stuff (convince a bud light drinker to try a local microbrew, or up sell the nachos to the nachos grande because it's the freakin weekend and what's life without a little adventure). The bonus is that you can obtain a huge amount of experience with very little commitment as serving can be a 4-6 hour /week deal if you need it to be.

In the end it's not about sales. It's all about how comfortable you are in your own skin and how comfortable you make them. That takes a bit of time and discomfort to achieve and a book won't give you that by itself.

Go get experience.

<comment><USER3> Yep, if you wanted to learn to ride a bike, you wouldn't talk about riding bikes online or read a book by someone who has won the Tour de France. You'd go ride a bike.

<comment><USER4> I think the question is more like "I have ridden a bike before, but I'm not very good at it. How can I improve?" in which case you could definitely suggest reading a book or watching videos on proper form, training exercises, etc. because just riding a bike will not be good enough past a certain point, and even getting to that point takes a long time that can be shortened by targeted practice instead of just "riding".

</comment></comment></comment><comment><USER5> If your business is already running, take the time to take a sales course (I did Dale Carnegie many years ago). When I did this years ago I was in a class with people who sold chip mfg equipment (ASP in the tens of millions, 2+ year sales cycle), someone who sold ADT security systems, a couple of guys who started a T-shirt shack, and learned from all of them.

Then a few years later I was 30 with a wife who couldn't legally work, a mortgage, and two cats and sold on commission. I _had_ to execute or I couldn't make it.

This is how I learned.

</comment><comment><USER6> I have a program like this that my dad passed on to me, which I often re-start when I feel I'm loosing it:

0\. "How to win friends and influence others" by Carnergie

1\. "Zig Ziglar on Selling"

2\. "Unlimited Power" by Tony Robbins

3\. "Secrets of closing the sale" by Zig Ziglar

4\. "Influence psychology of persuasion" by Caldini

Really made the difference for me when feeding the kids became a challenge.

<comment><USER7> Zig Zigler's books helped me during college when I'd have to do cold sales, but the lessons were amazing outside of sales.

</comment></comment><comment><USER8> One of the most important aspects of sales is a great thing - connecting with people. If you want to build a company, work on a product, or anything in between your new job is: "Talk to everyone and anyone about everything and anything".

From there you will see points of commonalities with anyone and will one day a) enjoy speaking to strangers b) learn from others c) most likely get better at sales as a result because sales at the end of the day is people connecting to people.

Good luck Andrew!

</comment><comment><USER9> "Influence -- The Psychology of Persuasion" by Robert Cialdini is excellent background reading. Any reasonable bookshop has 100s of books on sales. Best to browse and pick one that resonates with you.

The best way to start learning is to watch and listen to a good salesperson doing their bit. For example, visit a prestige car dealership after you have read "Influence" and see how they apply the various aspects. Ideally get a job as a junior salesperson working for a great salesperson. Your learning will go much better under expert guidance. You just can't learn enough just be reading books, watching videos.

From your question you appear to have conflated marketing, public relations, negotiating, etc as being sales. They are all distinct functional areas that support sales, but are not "selling" as such.

<comment><USER10> I absolutely agree on "The Psychology of Persuosion". There are some really helpful principles in there.

</comment></comment><comment><USER11> Like most things, getting good at sales is about practicing, learning and practicing again.

Books and advice are great to get started but eventually there is no substitute to actually doing it yourself.

That being said, we are all actually "selling" in our day to day lives without formally defining it as sales. From convincing your parents to buy you a toy all the way to landing the first job involves similar techniques.

For a really simple sales weekend task, try buying a pack of bottled water and see how many you sell.

</comment><comment><USER12> My actual sales experience is limited to the one summer job of direct sales experience I had a couple of years back, so I'm not an expert. It was a very interesting experience, however.

If you can, it'd probably be pretty effective to get some "actual sales" experience and treat it as a sandbox for experimenting. The alternative seems to be vacuuming a set of sales training materials and then start applying them directly to other scenarios. Anecdote: A friend started reading up on sales and applying to his dating life and expressed positive surprise - but he recently started work as a door-to-door salesman, and has been talking about new sales-related observations at a higher frequency.

AFAIK (haven't read yet) "How to win friends and influence people" is good for the non-actual sales. Supposedly early editions are better than later, as later ones are written by committee? I can - on the basis of my tiny experience - recommend Zig Ziglar's books.

<comment><USER6> Zig Ziglar's books on sales are really great and can have fast effect, it made the difference for me back in the days I was 22 or so and had to wardrive by foot to get work done for customers that would pay me very few or not at all - to the point i had to choose between paying for child food or the internet bill.

I __highly __recommend Zig Ziglar books on sales and Dale Carnergie 's book "how to win friends" which should indeed probably be the first one to read for anybody - despite the phony title that will put most people off.

</comment></comment><comment><USER13> It's one thing to read material around sales and another to practice it. That being said, one book I'd recommend is Daniel Pink's "To Sell Is Human"

In general, sales is something you need to practice every day. Like Sam mentions, it's about being able to convince other people of what you believe and you have an opportunity to do this in your every day life, from convincing your kids to clean their rooms to convincing your reports to adopt a new process.

The first step is to look for opportunities in every interaction to practice sales. Sales starts by listening, so try to understand the other person's point of view and why it's different from yours. Really step into their shoes and see things from their lens.

Once you identify where the difference is, ask questions to learn more. Why do they think that way? Why do they prefer the current process? Why are they hesitant to change?

Again, they key here is to listen. Once they list the reasons why they believe differently, summarize what they said. Then start to work through each difference together.

This is important. You're not competing with them. You need to work together to arrive at a common solution. If they say adopting a new process is a waste of time, then calculate with them how much time it will take and then work to reduce that time by offering help in some area.

In the end, you should both walk away having achieved something together without one person browbeating the other into it.

</comment><comment><USER14> Here is my list of advice:

1\. Think from their point of view. What are the biggest pain points they can identify with? What are you solving for them?

2\. Show as much as you can upfront. Bring an app with their logo and name on it. Maybe mockups if you don't have app. Their "customizing and correcting" instict kicks in an the conversation becomes about what to change.

3\. Don't charge anything serious upfront, just take their credit card for a "retainer fee" and have them authorize charges as you go.

4\. Use a website for them to choose from predefined choices, like JS libraries used to let you choose what you wanted. Then they leave their email to get a quote.

5\. Use your website or app in order to set up a portal for them, including their choices and initial product, and invite others to manage this portal. Make it as easy as possible for them to invite MORE stakeholders in their organization. Build onboarding for the stakeholders where they get to see the work in progress, choices, video, until some stakeholde enters the credit card.

7\. Break things down into milestones and deliverables. Put as much as you can on a website to create a feeling that you have lots of customers vying for your tome so they don't feel they can haggle.

7\. Finally, reward your existing customers for adding testimonials, sharing good results, and bringing more customers, with some internal credit system, that can be used to reduce the amount they pay. Make onboarding process for inbound sales, which includes the social proof from the customers.

8\. Oh yeah, and consider doing PR and bringing people to your landing page from 7.

</comment><comment><USER15> I am an software engineer and an introvert. Have been sitting at my desk coding all my career. Once I got a job at a technology company, but the office I was sitting in had very few engineers and most of it was filled with sales and marketing personnel. I was surrounded by all sales and marketing people. The sales and marketing department at that company ran a one month programme open for everyone at the company to sell company products on weekends at multiple brick and mortar retail stores prior to Christmas season. I thought, hell why not I should participate and give it a go; what could go wrong? So I enlisted in the programme. On the first day I was sent back home from the entrance of one of the retail stores because I was wearing jeans pant which was against the retail store's policy. So I went back home and dressed accordingly and returned back. For the next 4 weekends over the month I spent selling company products at 4 different retail stores directly to consumers. What I experienced was that people started coming to me with their requirements and asking what product they should buy! I am not even a native english speaker and I was selling in an english speaking country. I went on to win an award for selling most products in that programme in that year.

So what did an introvert, non-english speaker with no experience of selling do to sell successfully and what did I learn? Here is what I learned, and it is really very simple:

The first rule of selling is don't sell; rather learn, inform and help i.e. genuinely learn about the customer's requirements/problems, genuinely inform the customers about the solution you have or anyone else who could provide the solution and genuinely help the customer with the decision making process. That's it. And your customers then become your recommender and help you "sell" more!

</comment><comment><USER16> Speak with the customer. Or in fact listen to your customer. If you can do that and your product is good, you will be fine.

Stay away from books/blogs that teach you into manipulating your customer to sell them something. That usually leads to them regretting the buy later and you not finding product market fit .

</comment><comment><USER17> Sam Alterman's advice is bad, people want to buy not to be sold, you will never convince them otherwise.

If you want to be good at sales you need to turn the question on its head. It's not how to sell but how do people buy?

There is a pain point that creates a want. Research is done into how to satisfy this want. Evaluate the possible solutions. Purchase.

Now you know what your customers will do regardless of you, you just funnel them to you at every step of their buying process. The earlier in the process the more work is required to get to conversion but the easier it is to build reputation with them.

Targeting before the pain point is a waste of time no one will spend money on a backup system until their system fails and they realise they needed it all along.

The information gathering point is the easiest place to target, the customer knows little and will look industry experts like you, to inform them what they should believe.

Don't sell to them, give them all the detailed unbiased information they need to get to the evaluation stage. The more information they get from you the more they will favour you at the evaluation stage as all they know is what you taught them. If you can control what some one hears and sees it stands to reason that you can control what they think and say.

At the evaluation stage, if you are not in their short list at this point you missed your chance. They will have already decided who to go with and are looking for reasons remove the rest from the list. If all their reasoning comes from your advice and you follow your own advice you have won. At this point they are already convinced they just need some reassurance from you to take the leap to purchase.

Purchase This is called the close, its easy Smile, Nod ask a few questions they will answer yes to, then ask them "Are you happy with that?" they will respond with a smile nod and say yes and think to them selves, you know what I am happy, let's do it. If they answer no ask them specifically why not, whats holding them back? Satisfy this concern.

</comment><comment><USER18> The actual good idea of learning anything / or achieving anything comes down to good amount of homework and experience with introspection and improvising. This seems like too repeated and conventional advise, but it works.

</comment><comment><USER19> When I was at university every week my roommates and I would invent a new student organisation and spend a few hours pitching it to passersby on campus. The organizations were ridiculous, things like "Students for the exploration of space" or "The Student Potato Advocate". Sometimes we would solicit money but always we would have a mailing list where you could sign up for more information.

We just did it for silly fun but in retrospect it was a great experience. Learning how to promote something, having the self-confidence to talk to strangers and sell something is really useful.

</comment><comment><USER20> Take improv acting. You learn two highly relevant things:

1\. Loosening up creatively(which helps you develop the pitch)

2\. Playing a character appropriate to the scene. e.g. during the job interview both parties can play characters that represent themselves/the company in their best light.

Playing a character isn't about lying - it's in the word: play. Every conversation involves some performative aspects, and these skills simply give you additional ways to conduct conversation in business and in life.

</comment><comment><USER21> > You have to evangelize your plans to customers, prospective employees, the > press, investors, etc...

Listening is the new prospecting.

On this subject, John Jantsch is masterful > [https://www.goodreads.com/book/show/21847226-duct-tape- selli...](https://www.goodreads.com/book/show/21847226-duct-tape-selling)

</comment><comment><USER22> There are surely many resources for sales theory. You can use these to _inform_ yourself.

To get good, you'd need to practice and train your mental and emotional intelligence to the task.

Sales is a very human process and carries a lot of discomfort which you need to learn to work with.

Sell 10 things and you'll get better. Sell a thousand things and you'll get good. No shortcut.

</comment><comment><USER23> I'm finding this "How To Sell" Startup School lecture by Tyler Bosmeny helpful: [https://itunes.apple.com/us/podcast/startup-school-by-y- comb...](https://itunes.apple.com/us/podcast/startup-school-by-y- combinator/id1436083034?mt=2&i=1000420506910)

</comment><comment><USER24> Fog Creek published some good articles before, but it looks like it's been affected by link-rot:

[http://blog.fogcreek.com/the-very-most-basic-things-your- com...](http://blog.fogcreek.com/the-very-most-basic-things-your-company- needs-to-know-about-sales-part-1-of-4/)

<comment><USER25> Here's a copy on Archive.org:

[https://web.archive.org/web/20161202094244/http://blog.fogcr...](https://web.archive.org/web/20161202094244/http://blog.fogcreek.com/the- very-most-basic-things-your-company-needs-to-know-about-sales-part-1-of-4/)

A snippet I liked:

 _" I used to work as a waiter, and we were supposed to up-sell various things like top-shelf margaritas and seasoned sour cream for the french fries. I sucked at it..._

 _One day the manager wanted to know what was up, and I said something like, "Man, if they want top-shelf margaritas they'll ask. I don't need to push it on them."_

 _My manager said, "That's true, they are likely to ask if they want something. But what if they don't know we have it?" "_

<comment><USER24> Thanks - that's the article I was thinking of.

Off Topic: I hope the whole Fog Creek blog hasn't gone away.

<comment><USER25> I think it has. Fog Creek renamed itself to Glitch [1], sold off FogBugz (which then rebranded as Manuscript, then rebranded back to FogBugz). The last Fog Creek blog post was Feb 14 2018 (about becoming Glitch), and it looks like the blog was turned off in November 2018.

It's a bit of a miracle that the Joel On Software forums [2] are still accessible.

[1] [https://glitch.com/about/fog-creek-is-now- glitch/](https://glitch.com/about/fog-creek-is-now-glitch/)

[2] [https://discuss.fogcreek.com/](https://discuss.fogcreek.com/)

<comment><USER26> We do still have the archives, and are thinking of how to bring back the pieces that are still relevant. A lot of the technical content rotted long before the links did, and the more human stuff was due for an update.

<comment><USER24> That's good to hear.

</comment></comment></comment></comment></comment></comment><comment><USER27> Depends on the type of selling. Face to face? Online? Direct? Narrow it down and go sell.

But how do you start? You just do. There is no tutorial. The one thing that helps is selling things you know about and can provide an educated opinion on the subject.

</comment><comment><USER28> Plenty of people have suggested books, etc., and have given you advice. Get the books. Test the advice.

If you want to get good at sales, go back and read Altman's post again ([http://blog.samaltman.com/how-to-be- successful](http://blog.samaltman.com/how-to-be-successful)). Start with the section you asked about:

4\. Get good at "sales"

Notice Altman puts the word "sales" in quotation marks. That means there are other words and terms that you could put in there to increase your understanding. Here are some that he uses: Convincing others, evangelizing, communicating, and believing in what you're selling. Can you come up with some more?

Now ask yourself, for example, "How can I get better at convincing others of what I believe?" What way could you practice convincing someone of something you believed? What would it feel like to convince someone of something you believed? Can you picture what it would look like to be in that situation? What would you need to hear from someone to know they were convinced? Is there any time in your life that you have convinced someone of something that you believed? (Imagine a small child convincing an adult that they believed someone they knew was in danger and you'll realize that a child in this situation knows everything they need to know about "selling.")

Repeat this process with each term. "How can I get better at evangelizing?" "How can I get better at communicating?" (Here he provides some more tips: "Is my thinking clear?" "Am I using plain, concise language?") "How can I get better at believing in what I'm selling?" (Would you buy what you're selling? Have you? Take your reward out of the picture, and find someone who needs what you are selling, and give it to them.) Try with some other terms that you come up with, e.g. connecting with others, understanding the customer's needs, serving the customer, etc..

Brainstorm every answer. The most important thing is that you take Altman's advice and "Show up in person." Test each idea in person, face to face. Engineer situations where you can test your ideas, collect data, and determine what works.

Your problem is not a lack of information. Reading another book is another way to avoid taking action. What you need is imagination, commitment, and a willingness to try everything until you find something that works.

Be patient with yourself. This is a process. It could be a lifetime journey. Enjoy it.

</comment><comment><USER7> Zig Zigler was one of the early sales gurus and he frames a lot of his sales training around being thoughtful, caring and kind. His books are worth reading for the non-salesman.

</comment><comment><USER29> There's a book called "The Accidental Salesperson" by Chris Lytle that is a very good read.

</comment><comment><USER30> I learned to code by coding. I guess I could learn to sell by selling.

</comment><comment><USER31> My reply is probably too late, but I'll post anyway for people referencing this later.

My own journey over the last 20 years has been a slow migration from a technical contributor (About 10-12 years of systems engineering, infosec consultant, pentester) to a full blown quota-carrying, territory-running sales guy. Surprisingly, I enjoy the work. My personal view of sales started negative based on my interactions with the last generation of salespeople, but I've seen a generational shift in Enterprise Sales recently, and there are a lot more people like me than 10-20 years ago when I started in the industry.

It turns out, sales and running a territory is like engineering to me. Like any good engineer, I enjoy building things. I built out a customer base that can contribute to local chapter events to be where I can't. The job is also highly measureable. I can't think of another role where performance is so easily measured day-to-day and forecasted into the future. It's also a critically important function of the company. Bringing in revenue is a top priority and receives a lot of benefits. One driving force that got me to where I am is that I always took steps of becoming more important.

Back to the question.. how to get good at sales? Easy. Take a sales job. A good place to start would be Sales Engineering or Sales Overlay (SME with sales responsibilities). I'd look for a field that is highly technical and complex. Something hard where real technical chops are required and respected. Customers value your output because they genuinely don't have the expertise that you offer. Nothing commoditized.. look for smaller, fast growing segments.

As for specific skills to succeed in sales in these environments, it's mostly about understanding the customer's business problems and objectives. Once you have a firm understanding and agreement with the customer on the desired business outcomes, then dig deeper into making the individuals at the customer successful. Make your customer a hero. Help them overachieve on their goals. Financial reward comes quickly after you reach this point.

Also important: good communication, systems-thinking (ability to navigate complex organizational decision making processes), and understanding people/empathizing with your customers. Over time you'll develop good instincts to know when to push or when to say no. So much of sales can be subjective, so try to use repeatable processes where possible. Your pricing strategy should be defensible and systematic. Don't make shit up.

To get the above to work for you, you must have strong communication skills. Sales is still about talking to other humans. You get small windows of time with influencers, decision makers, and buyers. You have to have good presentation skills and be able to convey value to a customer with clarity. To distill complex ideas down to simple, meaningful value and tie that to the customer's desired outcomes. The customer needs to be able to answer the question of "why choose these guys instead of those guys?" with confidence and expertise. Most of the real selling happens without you in the room, so you need to build them up to be your champion. When you are in the room, you need them to be your coach.. every meeting should be an open book test. Your coach should tell you in advance who cares about what so you can craft your messaging around things that matter to these decision makers or influencers.

The idea that there is some magical persuasion element in sales seems dated to me. Enterprise sales campaigns are complex. 6-18 month sales cycles with dozens of influencers, decision makers, users, buyers, and so on. You don't take someone out to a steak dinner and close a deal. Does charisma and charm help? Sure.. in a few marginal ways. But you don't have to be a cliche salesperson to be successful. You have to understand how the organization makes a decision, and then work backwards to provide the right information to the right people. Explain the technical value to the people who care about technical aspects. Explain how the license model scales to the person running the budget. Explain how your added services will help the guy in charge of operations scale up the program and over achieve on his goals.

Also, the best sales people pick great products in growing markets. That's where the money is. Mediocre products in stable markets do not attract talented sales people.</comment>


Ask HN: Stripe Bans Protonmail.com? - <AUTHOR> I have a protonmail.com email. Today I wanted to purchase something from a website that handles payments via Stripe. My purchases were declined. I contacted their support, and they responded that 'our payment provider is not accepting your email address'.<p>Is this a blanket ban from Stripe? <comment><USER2> I checked my Stripe (business) account, we have user with @protonmail.com email addresses, all fine. I have seen few Stripe errors like 'stolen credit card', 'insufficient balance' but never a decline due to email address.</comment>