A brief list of what Scrum gets wrong
medium.com
medium.com
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.
There isn't enough evidence-based science on what produces the best software -- but Scrum can be measured against other software practices, and should be.
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.
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...
Using only few features might slow development a little in the small, and you might even make more errors in the small while developping. But you can FIX them.
I realize this is not hard science, and I have no motivation to do any on it, like collecting and bending statistics. But as long as all people have to say "XY is not good or bad", "things will get better", "XY has just a very steep learning curve", "you just didn't dance the right dance" and all evidence seems to suggest otherwise, then you've just lost the argument. End of story.
When you need partial updates to state in the case of an error, then you're in trouble. When you have multiple transactions to coordinate, but no distributed transaction coordinator, you're in trouble (but you are anyway whether you use exceptions or not). The more state you need to preserve in an error case, the worse exceptions are for your use case. Ideally, exceptions are never caught except at the topmost loop: server request dispatcher, UI event handler, or command line driver. When execution must continue with recovery, exceptions are an inferior tool.
And not just simple programs and short scripts; very complex programs, as long as they keep state in a transactional store, and a request has approximately the same lifetime as the transaction.
Which likely doesn't even try to handle any errors, and may actually be a bad, faulty program - the edge cases just don't matter that much for businesses. Maybe an e-mail will be sent out twice in a few circumstances, etc: nobody cares.
Transaction management is implemented in the database server, and very likely that doesn't employ exceptions. And more complexity is implemented by the OS (the "process server" if you will) - if your program dies it specifies how to handle the condition, etc. Another part of complexity is dealt with by the language runtime, for example garbage collection - no exceptions to be seen there.
The thing that serves responses to requests is a program. And it's not just a "simple, dirty request handler script," it's often enormously complex. Entire companies exist with their product exposed via HTTP APIs.
The reason you don't see exceptions in databases, operating systems, etc is because they're often written in C++, which has notoriously wonky semantics around exceptions, or C, which doesn't have exceptions at all.
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?
There are plenty of methodologies and tools that can replace or complement Scrum.
>This paper outlines the work I reviewed that made it clear to me that ‘people’ really are a first-order, and not incidental, project success driver, the characteristics I currently use as predictors.
My personal experience is similar - methodologies can make things incrementally better for a team, but cannot do anything with the ‘people’ factor.
Oh please. Dogmatists make the worst software developers. The "objectively better" criteria is highly situational and not nearly as clear cut as it looks most of the time.
There are plenty of methods and techniques in software that work well for some goals and absolutely suck in others and it's very often not obvious that something that is working well or badly for you is doing so mostly because of your situation.
My favorite example of this is microservices - which apparently worked really well for Martin Fowler once or twice (and I'm 90% sure he didn't understand why) and then when he promoted it, it got applied dogmatically by teams all over the world in situations where it was manifestly an idiotic idea.
The same goes for most hot-button issues - type systems, functional programming, nosql, etc.
And so it is with most other hyped technologies. The complexity and loss of control is very rarely worth it. I'm not a dogmatist, but have seriously tried many different approaches. And that's why I do mostly C (well, not for web applications, which I try to avoid as well :>) with only very simple data structures, and I love it, and it works, and it's maintainable, modular, and very performant. Although I know that C has flaws - I have been trying to find ways to improve (and failed so far).
woosh
They work really well in large organizational environments where inter-team coordination costs are very high and language flexibility is valuable. Where these benefits outweigh the additional infrastructure headaches it works very well.
I've likewise worked in environments where they were a terrible idea (e.g. startup team of six).
Like you, I used to be dogmatically anti-microservice. I was wrong.
It’s ok to only want to do certain kinds of work (for example C code that runs close to the metal and that is performant and easy to reason about). Other people in the world though enjoy doing different kinds of work and going about it in different ways.
My advice to you is to be humble and watch people as if they had something to teach you. Whether they are doing scrum, waterfall, using this or that language or architecture, there’s always a ton of things you can learn by watching how someone works.
If you pay closer attention, you will see value in what other people are doing and be able to benefit from what they have discovered.
I'd still be suspicious of people who start out saying they're going to implement a microservice architecture (especially greenfield) without having an understanding of why, though.
I've almost always found that the earlier on in the process I made hard-to-reverse architectural decisions, the worse the architecture ended up being. The more the architecture came about as a series of gradual, iterative refactors that took in to account the various trade offs that became evident, the better it ended up being.
But that's just a fucking picture. A plan. That usually does not survive contact with the changing requirements and implementation reality.
Anyone incapable of admitting that there will be changes should be taken upstate to a nice farm, then shot behind the barn. Usually these people are on the client's team. :(
The thing about any agile methodology is that they are meant to be adapted to the situation at hand, not to be a fixed set of rules that you can just apply to get consistently good results. But many are trying to turn scrum into that - a fixed set of rules that allows micromanagement. I would say that that is definitely bad, but, is that really scrum?
I think you need to get out more.
Exceptions are actually pretty standard in the database world. ScyllaDB, arguably the top dog in terms of DB performance, has the "throw" keyword strewn throughout its code base. Oracle PL/SQL's error handling is done entirely through exceptions...
Is this about the database engine itself? Or just the query parser? Or even just exceptions in the query language itself?
FWIW, Scylla is not an RDBMS. I don't know about its architecture and am not interested in digging more. And that thing works reliably? I don't know - not my cup of tea. Why am I reminded of Node.js? Not cherry-picking here...
future<file> sstable::open_file(component_type type, open_flags flags, file_open_options opts) {
auto f = new_sstable_component_file(_read_error_handler, filename(type), flags, opts);
if ((type != component_type::Data && type != component_type::Index)
|| get_config().extensions().sstable_file_io_extensions().empty()) {
return f;
}
return f.then([this, type, flags](file f) {
return do_with(std::move(f), [this, type, flags](file& f) {
auto ext_range = get_config().extensions().sstable_file_io_extensions();
return do_for_each(ext_range.begin(), ext_range.end(), [this, &f, type, flags](auto& ext) {
// note: we're potentially wrapping more than once. extension mechanism
// is responsible for order being sane.
f = open_file_or_schedule(filepath);
read_or_schedule(f, buf, size);BTW, Exceptions and OOP are used conceptually in most kernels, RDBMS, and any bigger piece of software, it just doesn't make sense to use languages which force their use if a project has too many edge cases.
It's not the company. This inflexibility is a reflection of scrum's culture. I've seen this inflexibility on multiple teams across the world - what you've experienced is very much the exception and what the OP described is basically the norm.
>We also made changes to the "core" of scrum after our retrospectives when we decided it was stuff that did not work for us.
This is great and it's exactly how I'd want to work but I think almost every single scrum consultancy not only advocate strongly against doing this, they would likely blame anything that went wrong on your "rash" decision to not adhere to core scrum principles.
They literally invented a whole new phrase to emphasize just how much they look down on what you do: https://www.scrum.org/resources/what-scrumbut
>We added bugfixing sprints after we observed the bugs piling up.
This is actually something I've heard explicitly called out by consultancies.
>Instead of complaining about scrum, I suggest the OP either try changing the culture
I don't agree. I suggest slagging scrum off until it dies, because the inflexibility which you decry is so deeply embedded in its culture and will only die when scrum does.
Sure, what you did worked great - it just wasn't "scrum".
Well, it's either good, bad or ho-hum. If it's bad or ho-hum we shouldn't be doing it. If it's good we should be doing more of it.
Now, it's true that a technique can be good but people practice it badly.
But first we need to know positively that the technique is good -- before we insist people follow it more carefully.
So saying "X isn't food or bad, it's the way you use it" don't help.
Saying "X is good, but you're using it wrong" would indeed be helpful (if true).
Engineers are as responsible as any other actor for poor Scrum implementations.
Scrum, or any agile method, isn't a silver bullet. It doesn't compensate for bad teams. It's something that teams can use to deal with some common software development issues. It's also not the only tool that can be used for that purpose. Developers pouring ire on "scrum" when they aren't practicing it in the first place are attacking the wrong target.
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".
Feeding that back through the process is pointless when it inflates the complexity of future stories, because they are less likely to be prioritised, and the rot festers.
Peer review is a good way to improve the quality of peers, either though the natural education/knowledge sharing, or simply the transparency that helps you remove low quality peers and find better ones. It's not a cure all, but it's hard to imagine a successful team that wouldn't benefit form it.
Some turn up in the morning, however, work on their task for the day and go home. If they reimplement a chunk of the codebase somewhere else, because they feel they need to be writing more code to complete their task, fine, the story still passes. "I didn't know that was there" is not an excuse, it was probably covered in planning but they forgot. It's not going to get refactored, because it works! Peer review in this case goes one of two ways:
1. Bad quality peer sees criteria are satisfied and approves 2. Good quality peer sees all the duplication, some other bad practice thrown in for good measure and disapproves
In 2. say the story has already carried, pushing more work back, and hard deadlines are looming. They will be forced to begrudgingly approve the work, knowing they've just allowed a good chunk of cruft to enter the codebase. They will try and educate (assuming they've not lost the will to live - this might be the 100th time for eg), to prevent it happening again. But it will still happen, because bad developer is bad.
Forgetting the looming hard deadline: If the story carries over so what? We'll retro and add some bloat to the process to try and avoid it happening again.
What isn't explicitly said is "this dev is committing crap and the competent people are getting demoralised", it's the process that gets "refined" not the people. Agile is papering over the cracks and nurturing the codemonkey's behaviour.
But none of this matters, as the deliverable has been delivered. Now on to the next story!
But the organisation is slowly carving our monolith into microservices (Because buzzwords will save the day! <sigh>). I do feel microservices lend themselves better to agile, as the programmatical boundaries a good dev should naturally code within become rigidly defined. And people can effectively do their own thing within their "box".
IMHO it shifts the problems to the layer above, papering over the cracks. (Badly written code performing badly? Whack it behind a gateway and spin up some more containers!)
Even with microservices you're gonna have to define that API at some point (and now we can have as many as we like behind the scenes!), why not at the start with a holistic view... like, a design!
"As a user I can see a login page" - ok here's a static html page with two input boxes and a submit button. "As a user I can log in" - implement that slice of the backend, all in one hit with no eye on what other things might need from it (Dont get me started on YAGNI... YMNI, imho and you'll miss it when it isn't there! Especially when there's "no time" because it's not a feature with perceived customer benefit which take priority) And it goes from there. What I would prefer is more like "before we can even think about showing a login page to a user we should have..." which is more bottom up, and doesn't look good to a customer (or management).
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.
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.
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-...). 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.
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!"
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.
Quality got worse.
In this scenario it's the fault of agile, as the reason for doing agile was to increase quality.
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.
Can I ask why do you deliver stories before refactoring, if that's what you're saying? We'd tend to do necessary refactors as part of features or bugs when we touch related code and rarely have pure refactor chores.
Also, why do you have to _sell_ code quality? At least where I work there is a pretty strong divide between what to build and how to build it. There is two-way trust between the product manager and engineers that they know their domain and when they say "this is important right now", it's probably the right thing. After that it's just a matter of communication and prioritisation between the the two sides.
I could easily see how this might fall apart if either side was not trusted or not doing a great job, but I guess it would probably fall apart no matter what development process you followed if that were true.
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?
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.
> Trust your engineers to do the right thing on their own and they might just surprise you.
Yes, they might surprise you. That's potentially quite terrible because there's a whole ton of other people & roles involved in the success of a product... and of course that's assuming that the project is what the customer wants, requires no marketing message for the customer to understand, and sells itself.
I mean - trust but verify. While I largely agree with you it's always demotivating for the team to realize one dev is doing no actual work and getting away with it. Obviously not good for the business either.
> 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.
Or to give a much more serious response : this article seems to be very unprofessional, about trying to defend unprofessional behaviour as "normal".
The scrum guide talks about roughly 1hour/week for the scrum team to show stakeholders (such as upper managers and customers) what has been done. Any engineer can at any time reach out to people in the company to demo what has been created, if there's interest.
So I'm not sure what point you're trying to make with starting your own company if you want visibility outside the team.
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.
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.
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.
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.
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.
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.
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.
What methods would you suggest for software estimation then?
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).
If you don't know what values scrum brings over for example traditional waterfall, then the scrum handbook is a good place to start to learn.
If the process is just as often implemented incorrectly as correctly, that is a failing of the process. And in this case that is the most damning thing you can say about scrum. More often than not, people do it wrong. I'm tired of that excuse.
The companies I have worked on who claim to use scrum does not suffer from the issues OP brought up. So I question your statement. I also have >20 years experience.
> If the process is just as often implemented incorrectly as correctly, that is a failing of the process.
That's bs. That would be like putting a tractor driver in a Cessna and when the plane crash clamr that Cessnas are inherently unsafe to use. Yes, scrum requires buy in and some basic level of competence. If one or both of these are missing in an organization and they still say they use scrum then that can hardly be blamed on scrum.
Nailed it.
My team's product owner is as much part of the team as any of the engineers. Her role includes balancing the need to deliver products with the need to build reliable and scalable software, and to make those arguments to other parts of the company on the team's behalf. Since we're all skilled professionals, we're able to trust each other to make good decisions, and if I say "we cannot proceed until we have done <necessary technical work>" then that is taken seriously and work is prioritised as required.
I'm baffled by the awful environments that people apparently work in where this is not the case.
Either give the product owner a reason and a way to work towards what they want, or an alternative that (hopefully) is just as good.
Even if that didn't happen you're never going to win, because the b.a.'s have no other job than playing this verbal judo, while you also have to spend your time getting conplex technical things to work. You're like someone who goes to a karate class twice a werk fighting against someone who's life is dedicated to training.
A well-functioning team is composed of skilled professionals. If you are being asked to do something, it is because someone else has a problem that needs to be solved. "No" is an especially unhelpful response to that scenario. Other approaches can work:
- "No, but how about this alternative idea?"
- "No, this prerequisite is required. How can we make that happen?"
- "Not without causing these other problems – let's decide if it's worth the tradeoff"
- "No, that idea is fundamentally impossible. Here's why."
If you work in an environment where engineers are never listened to, then it's a bad environment. But similarly, engineering requirements are not the only ones, and it's important to realise that quite often an engineer doesn't have all of the required information to make the correct long-term decision.
I've never been in an environment where you could say no to the b.a.'s under agile either. And I've tried being more articulate as well and that just results in the same claims to your manager as "no" does that you're not being cooperative, a team player, etc.
I'm pretty sure after working several places that did agile that most of these "worked great for me" stories are made up.
I've never met another dev in real life who did something other than agile and preferred agile.
> 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.
Hoes does Scrum reward the engineer for such alignment?
edit: grammar
How does Scrum reward the engineer, in a way that it does it better, and more profoundly, than other methodologies?
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.
The actual agile manifesto makes a lot of sense IMO.
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.
What’s the point in delivering something both you and the customer know is wrong, when you can turn around and fix it instead? The point is delivering something of value instead of delivering something you agreed upon half a year ago.
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?
The text says "couple of weeks to a couple of months", not 2/3 weeks. If a task requires a longer attention span than two months, you should probably break it down and deliver something of value earler on. As you say yourself: "the market won’t wait for you to implement them".
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.
What a nice way of motivating people. Every person in a good team is of big value, and cannot easily be replaced by anyone else. Creating a good team requires thought and planning. If Scrum is about diluting the individual, then Scrum is far more wrong than I originally thought.
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?
When you motivate people, and give them tasks they like, they tend to perform their best. Turning people into cogs in a machine, as Scrum seems to like, is not a good way of motivating them. As the manifesto says: value the individual and motivate them, and they will get the job done.
And takes time. Ops, sprint's time is over. I guess that refactoring can wait.
And that is why you don’t care about sprints. You do one task, preferably as small as possible, and deliver it when it is done. That’s it. I have never understood why I should spend loads of time planning what I should do the next N weeks, when I can just do it instead.
Some of the most successful products and projects (Linux, Python, Apple) revolve around strong leadership.
Having strong leaders around a self organizing team is not necessarily problematic. Self organizing teams are more about giving the team freedom to work the way they want. A manager or leader can then contribute by removing obstacles and ensure the team has everything it needs instead of micromanaging everything.
The most important part of The Agile Manifesto, in my opinion, is "Individuals and interactions over processes and tools". If you care more about the process than you do of the people in the team, you are doing it wrong.
EDIT: formatting.
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.
If the best argument they can come up with for the process is "because that's how agile development is done" it's because they don't actually understand the process but that doesn't necessarily have anything to do with them being certified or not.
That's my point. They paid money to get "certificated", get jobs as project managers or scrum masters but have no idea how development or agile actually works. I've have come across a lot of these types of people.
(And, in case you're interested, "certified" is the standard term. In case you're not interested, my apologies for bringing it up.)
Show me a better system instead.
This is the story that keeps unfolding again and again in front my own eyes at my work, alas.
https://thehftguy.com/2017/12/06/scrum-vs-kanban-arent-they-...
We work by having an engineering manager work out requirements with a product owner, and my manager just comes and asks me how things are going and when they're going to be done. Often times, my estimations are off, but some of that is just expected. Honestly, I'm very happy with it and I've never felt like I was doing better work.
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....
Also Kanban has certification:
http://leankanban.com/team-kanban/
And consulting services around it:
This is: https://en.wikipedia.org/wiki/Kanban_(development)
Since 2005ish.
About 10 years after Scrum was formalised at OOPSLA 95'
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.
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.
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.
You can only get folks to commit stuff they have responsibility over. External dependencies are not really part of Scrum per se; they are part of the the larger project management part of managing every team.
We assigned an LOE task to me to shepherd/beg/nag my bits through. I (nor anyone else dealing with an outside party) couldn't commit to getting it done, but I can commit to helping it along.
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.
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.
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.
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?
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
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."
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.
> 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.
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.
My main complaint about scrum was how much of my time was spent in meetings vs working.
Scrum is a victim of Semantic Diffusion. 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
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.
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...
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.
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.
This is a tautology.
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.
You don't need everything to be "inside the project/inside the process" and even then, more things fit there than people might think.
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.
Now it all makes sense.
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".
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.
I agree with most of the comments so far this is bad management.
> 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.
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.
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).
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.
I want a process that works for the messy, suboptimal world that is reality.
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.
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.
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.
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.