I think in reality, SW development done right is nothing like that. It is highly discrete when it comes to output, because it takes time and experimentation to come up with the correct way to approach a problem, but if you do it right, you save yourself an incredible amount of time. It's more like mathematics, where it takes time to discover that things are actually rather easy (this quote comes to mind https://micromath.wordpress.com/2011/11/06/andrew-wiles-on-d...).
Of course, if you look at the project from the longer time perspective, it can appear as continuous production of improvements. But it has a kind of quantum nature, if you decrease the scale of time, you will see less continuity and more discrete bursts of code production. There is something like uncertainty principle that on certain scale, it's pointless to try to predict things, because making the correct prediction (which is needed at least to define thing DONE) will take as long as doing the thing in the first place.
I don't consider myself special, but it is possible that Scrum ruins great minds because they seek conceptual clarity (we sometimes humbly call it "lack of technical debt"). I am not sure how to make that work with Scrum. Perhaps if everything was done three times, punctuated by a team discussion, each time with shorter code.
Second thing that I dislike the most about Scrum is that it threw away (or at least "conveniently" renamed) pretty much everything that was ever known about project management. Of that, probably the formal estimation methods (replaced in Scrum by intuition for some reason) are the biggest loss. (I think it comes from the fact they actually realized the quantum nature of development is a problem.) To me, that is a huge red flag that it is, in fact, a snake oil.
P.S. I am tired of the YADIW excuse. Let's have a nice honest discussion about how it can be fixed.
My guess would be that the 10x-ers have are independent enough from any given employer that they can reject Scrum even if everyone else has to follow it. And later on, their ability to work on their own terms is what then makes them 10x more productive than the poor scrummers.
In some sense, standup is a nocebo, a mood killer for me. I am there, in the morning, ready for work, my mind firing up, geared towards working the problem, but no, I have talk and listen about something unrelated. It's like going to a movie and having to suffer the trailers for other movies first.
(There was also this funny psychological research that showed that when you tell someone you will do something, you're less likely (less motivated) to do it. Not sure if true, but if it is then standups alone have caused billions of loses in productivity.)
In any case, I think the discussion about individual productivity is somewhat sidetracking the core issues. What I wrote applies to the whole team as well. In my experience, the best design decisions come from individuals working alone, understanding the problem, and then these design decisions are vetted (and possibly changed) by everyone in an open discussion. This cycle can happen on almost any timescale, depending on the nature of the problem. So one doesn't need to be in an ivory tower for this to work.
Timeboxing as such is not a bad idea. But I think conflating it with "being done" is just wrong.
It's how Lockheed let Kelly Johnson run the Skunkworks however he wanted to. Johnson delivered the impossible again and again, and Lockheed was smart enough to not interfere.
I've given up trying to estimate how long a task will take and more or less just pick an arbitrary (usually comfortably large) number of points.
The thing is, it isn't even about estimating the scope of work, which is often unknown until it's complete, especially if I'm battling technical debt. A given task might take me an afternoon on a good day, or half a week on a bad week. Case in point, I got more work done on Monday than all of last week. That's the joy of having ADHD I suppose.
At least my manager is very understanding, and recognises that on a macro scale I get a lot of high quality work done. I think that's the key to being a good manager, understanding that your subordinates have different working styles and managing them with that in mind. I'm sure there are "10x developers" out there who work in a more consistent manner, or benefit from more hands-on management than I do.
This ! Can't agree more... Scrum always made me feel like a production-line-worker making shoes... No craft nor space to discovery/explore problem solving. Urg and all those damn meetings and pulling numbers out of thin air ! What a waste of time those meetings were !
I have been in both "sides" of scrum (dev and manager) and it is good not to have objectives changed every days. As a manager I even have had to split a scrum team in two (scrum and kanban) to maintain devs sanity.
Kanban is my preferred PMing process but only if there are defined "cutout" periods to perform releases or a CI/CD cycle.
This has benefits and downsides. One of the one hand, the development team getting to control the estimate helps to control the workload.
On the other, I agree. Why are we pulling estimates of effort out of thin air? Why are we being asked how long it will take to do work in sections of code we have never seen?
Planning could be far more accurate if we just got a proposed task list a day before planning.
It is common enough for those packs of estimation cards to include one with a question mark on it, to denote the "I can't estimate this sight unseen" scenario. The reason it's common is because often people are presented with stuff that isn't well-understood enough, and it's a very good idea not to pull a number out of one's rear in those situations. Don't be afraid to use that card (or do the equivalent and just say so).
If you are afraid because you will be marked as 'not a team player' or whatever, you have management culture problems that neither Scrum nor any other imaginable software development process will fix on its own. They will all end up feeding an idiotic garbage in/garbage out cycle of overpromising, crunch, burnout and general misery, with the superficial appearance of whatever process it was supposed to be.
I think that's a kind of waterfall strawman. In every other discipline, you would ask engineers for an estimate. It's insanity to do otherwise.
Why don't you work that in to your process. It's called Agile for a reason.
The primary reason scrum should be used for software development is when iterating closely with a knowledgeable customer. The pattern basically outsources the discovery of what to build onto the customer - and if the customer can tell what good looks like, shazam! scrum is downright magical!
Guess what, most software teams are isolated from the customer, or the customer/product owner doesn't know what good looks like, so no wonder scrum is getting a bad name as teams struggle to get value out of scrum activities.
There is a reason why teams need to have flexibility to modify their R&D patterns and processes. Without that flexibility you get to do scrum and the results make you wonder if you are doing it wrong.
What is lacking in a lot of cases is an overall vison and plan for the desired end state -
I have seen doing a classic waterfall design stage with a RAD/AGILE/DSDM/SCRUM development stage right at the end work well.
If somebody complains that Scrum is bad because e.g. every day you have to update management at stand-up (as mentioned in TFA), but the Scrum Guide, every book ever written on scrum, the websites of the Scrum Alliance and scrum.org, and more or less every advocate of scrum great and small, states explicitly that this is not the purpose of the stand-up but instead to highlight obstructions and opportunities for collaboration, then I don't see what more there is to say than "you're doing it wrong" - because you are doing it wrong, in letter and in spirit. It may not be your fault that you're doing it wrong (it's my guess that the widespread perception that scrum is management-heavy is a function of scrum's market penetration combined with the inherently dicatorial culture of corporate governance). But doing it wrong you most certainly are.
This is not one of your complaints of course, but you do complain about estimation, which - as a sibling comment mentions - is simply 'out of scope' for Scrum, which is a smaller package than people think. (Plenty of scrum thought-leadery types are part of the 'No Estimates' thing, for example.) It does, however, mandate that you occasionally meet for the explicit purpose of working out how to improve processes that are not working properly (such as estimation) - in other words, that the team takes seriously as a collective all the things that scrum does not talk about in itself.
No amount of "this is not the purpose of a standup" and "you're doing it wrong" can fix human nature. Management is mostly interested in progress and timelines, and will give unintentional (or not) feedback, even through body language, whenever a task is delayed or impacted in any way. They have some authority over team members' performance eval. Hence people will end up reporting to them no matter how hard you try. The only possible fix is to remove management or product from the standup, which is how it was originally supposed to be - but that seems unthinkable in the "agile at scale' format most companies have adopted today.
Exactly. There's no point in blaming scrum for problems that are ultimately rooted in your corporate culture.... because those problems are going to (re)-appear no matter what methodology you adopt!
Curious about that point because for many engineering tasks the variance in the estimates is so big that I wonder whether any formal way of estimation actually works. I did some analyses on the correlation between estimate and actual development time in a project I worked in and the correlation wasn't really there. Sure, there was a difference for the very large work items and the very small one but overall the estimates were fairly useless, especially when it came to anything that touched operations. I just googled formal methods for estimation in order to see what you might mean by that and nothing appeared to be something I'd assume to be more powerful (a priori) due to my lack of confidence in workload estimation overall.
Note, btw. that the Scrum Guide doesn't make any mention of estimation at all, neither prescribes it nor disallows it, just says that the team should plan a sprint (roughly speaking). Even the typical "story point estimation" stuff that people think is attached with Scrum, its more of an XP practice that has been carried over.
Personally I think that Scrum took a weird turn in its lifetime with Sprints becoming shorter and shorter to the point where there can be no meaningful work (with customer benefit / demoable in the sprint review) be completed within a Scrum. Maybe its possible to ship a couple of CRUD-website-features within 2 weeks, but for the B2B software I am working on a feature is too complex for 2 week cycles. And if your tasks are small enough to fit into two week cycles, why aren't you doing Kanban?
I agree that it is a legitimate concern, I certainly do not advocate a position that software cannot be estimated or planned at all. I think it can be, but only up to certain time granularity, where the attempt to gain understanding for a sensible estimate (and describing what needs to be done) becomes essentially comparable to writing the code in the first place.
I actually have an underdeveloped idea how we could have a completely formal approach to tackle uncertainty in SW development, but it is purely theoretical so far (using a combination of functional programming and information theory).
Many of us do believe this. Absolutely.
>It is highly discrete when it comes to output, because it takes time and experimentation to come up with the correct way to approach a problem, but if you do it right, you save yourself an incredible amount of time.
But on the flip side, if you get it wrong you waste an incredible amount of time.
The smaller the steps you take, the smaller the risk you step in the wrong direction.
I can't really comment on the rest of your comment because as far as I'm aware SCRUM means something different everywhere. I have no idea, for example, why a scrum team would not use formal estimation methods and rely on intuition.
Agile project management should mean you can examine your process and improve it. If your intuitive estimates are not accurate, you should be able to suggest a different method and see if you get better estimates.
I think it is empirically not true, if you look at your Github history for example, sometimes you produce less change and sometimes a lot more. It corresponds to the fact (or at least a feeling) that some things are clear and can be easily done while some require some thinking or experimentation before they can be done.
And it's even less true if you restrict the requirement to only functional changes to the code (not just refactorings or productivity improvements or code reduction with preservation of the functionality). These things have to be mentally planned even more and that requires even longer periods of apparent inactivity.
> The smaller the steps you take, the smaller the risk you step in the wrong direction.
I don't think that's how it works. Risks are risks, whether you're taking small steps or not. If you don't know if your DB will break at 1000 users, it's a risk regardless how small steps you take to introduce the DB to your code.
Personally, I prefer to attack the biggest known risks first (for example, make prototype, measure it). But that flies in the face of other Scrum requirements, like getting some feature completely done in smaller chunks.
This is the route to local maxima.
>Many of us do believe this. Absolutely.
Isn't Jeffries' attempt to do Sudoku with TDD pretty much the prime example that it's not always so?
Jeffries tried to write a Sudoku solver by starting from tests and incremental improvement, and got nowhere. Norvig knew about constraint propagation and did it in one go.
I would argue that it's more correct to say something like "Not all software development done right is like that." Or in other words, some software development is closer to that model.
Some teams are doing work that involves real "invention", things that require using cutting edge C.S. research, implementing algorithms from papers, or using just-released open source libraries, etc. Other teams are building the nth iteration of some CRUD application that amounts to a database, some REST API's built using Spring Boot, and a UI built in React, where today's work isn't (usually) that different from yesteday's work.
Depending on which end of that spectrum your project falls on, it would make sense that the details of the methodology you use would need to vary.
I've also long thought that the details of your development methodology need to vary throughout the lifecycle of the project. Early on, there may be less clarity, and more "unknown unknowns", so it makes sense to focus more on experimentation and learning. Later on you (hopefully) start to converge towards a deep understanding of what you're doing, and can move more into the "gradual refinement" mode of work.
Unfortunately, I have found that few shops take either of these factors into account.
I think this is basically true but incomplete; early and late are misleading a bit, because it can be early in the life of a product that is in a well-explored space and it will look “late”, while a product can experience change in requirements or external context which makes it look “early”. A product should expect to move between modes multiple times if it is long-lived.
Our requirements change, they often change daily, from forces outside of our control. Fickle clients are one thing, but even things as predictable as implementing protocols can be uncertain. Many times you'll design and implement the perfect solution to the problem at hand, and then hit a nasty bug mid way of some tool / lib you're relying on that would make you rethink your whole approach. This can drive you into a rabbit whole in itself. Its always nice to consult with your team at that point to see if its actually worth it.
As far as I understand "Scrum" is just a collection of practices that helps us actually ship something in a reasonable amount of time. Each standup can be a "battle plan meets the enemy" kind of moment. And as we know, "no battle plan survives first contact with the enemy". Yes its uncomfortable sometimes, but it should force us to deal with reality a bit more often and I think that's a good thing.
And scrum and it mutations has survived to this day for a reason. Teams that employ it are much faster to adopt to changing conditions, and thus "outevlove" the competition. I really hope that we can codify a more humane way of dealing with those problems, but at its heart, I think scrum is better suited for software development than its predecessors. We need time (and willingness) to "evolve" it as well.
"Another note on breaking down tasks into chunks"
This is the management trick of "divide and conquer".
But for real good dev, that is not a good development process.
Imagine you are an experienced dev and you need to refactor a 20 files low level code to change the way errors are returned:
If you were in an agile/scrum setup, it would be asked to do that file by file, function by function, problem/code change type by type code change. And possibly not break the rest so that there is something 'runnable' at least every week or some other people can work on another file/function.
But that does not make any sense for a great dev. What you would do if you were experienced is to know the overall direction but rework the code line by line progressively, fixing side things on the way and maybe regularly fixing in other files/functions pattern that are similars. And maybe at some point decide to change again something you did until the point where you achieve your goal.
In my mind, it works more like a path searching algorithm in action.
The scrum concept is probably good for the devops/web script kiddy devs, where you just change hundreds of individual small items without too much interdependance. For example, change the style of button, reorder blocks on a page, change the icons, increase the font size.
Also, something that makes great dev become average is this concept that every dev should be exchangeable and a commodity. Dev become workers on a factory production line where they have no value than to follow process and apply patterns.
They say "what if something happen to your autonomous great dev?" but this argument is not used for the rest of the intellectual society: you don't see 2 doctors at a time, 2 lawyers for your case, 2 CEO in the company, 2 main architects. This thinking is just applied to low level replaceable workers.
Normally, if you lose a great dev and you find another great dev, the new one should be able to understand the problem and the code in a short time and be operational quite fast.
One example we can easily see of efficient dev are the great open source projects. Most of them were not created and led by an army of dev clones but by a few efficient ones: linux, python, php ... In these cases, most of the time we don't consider people to be interchangeable. Some people are keys to topics/code/features and that leads to great dev. But in case of problem, there is almost always someone smart capable to take over after a short time.
* utilize persons strong points
* reduce management
* reduce burden
* improve working environment
"Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done."
It is really easy to screw. I've seen far to many broken versions. Community building is harder than management. And for management there is no benefit beside budge. So they say SCRUM and change nothing but cosmetics. It sells.
The problem is no methodology can make them trust us. Software development is one of the few professions where to the business it's simultaneously "magic" and they think we - as experts - don't know what we're doing. Management is supposed to empower employees and remove obstacles, not disempower and introduce them.
At the same time, there's this illusion that as long as we developers change the way we operate, the rest of the enterprise will magically be affected. A cultural shift without management buy-in won't work.
Well, I think that Scrum (or, more widely, agile) can in fact be done "right" - done in a way that works well. So in one sense, "you aren't doing it right" is in fact a correct statement.
But then you look around, and you see how often it isn't done "right". If something is almost impossible to do "right", then yes, there may in fact be a problem.
I think a theory of any kind that is not applied IRL by its creator should be seen with great suspicion.
Scrum was a small part of a package of process, the important bit that made that possible was the engineering processes not the task management ones. The business needed to work out what matter most to it and the developers certainly helped more as their expertise in the subject matter grew but what made it all slick was the automation and engineering. Engineering is where the time goes on a software project and doing that well is what matters. As an industry we focus so much on something that is a few hours of effort a week on planning and tracking and yet the big time goes into the actual work. If you spend a lot of time doing planning and tracking and not producing software you are doing it wrong regardless of whatever process you say you are using. Scrum is not remotely sufficient, it ignores all the important bits.
Lucky you however, letting 'raw' Engineers interface with customers is usually a disaster. Engineers build tech, the company builds products, and they are very, very different things. A lot of pieces in there - support, training, docs, price, risk, leverage, IP, know-how, relationship management, legality, confidentiality.
Experienced Engineers who have a lot of exposure to Product, Sales etc. can do this, there's usually a role there for a highly technical person to support sales.
If it were only a matter of 'the customer saying we need XYZ and Engineers doing that' then great, but it's almost never that.
So often people complain about specification. Here you craft them as they fit you (as long as they resolve customers need).
Our sprint planning sessions were a FULL DAY, yes, an entire 8 hours of planning. Because our scrum master wanted a detailed plan of what every engineer would be working on, on every day of the week.
I still remember a certain even where we were forced to adjust our story points, so that we could make a detail a month in the future. Yes, our “agile” team, had a hard deadline that we had to try and make work. This was the business decided that we’ll launch in a month, so now we’ll use our agile methodology to somehow make it magically work. During a full day session to plan for this, I suggested we should drop our scrum board and instead revert to kanban. The scrum master threw me a dirty look and told the business about this, pretty sure that’s why I was moved to another team.
What has worked for me is the following:
- let the most sr tech person ("the architect ") refine the stories maybe with the PM. Then, the same person will point the stories. - The sprint planning is only for presenting the stories to devs and giving some minor adjustments to the points if necessary - The architect may deep dive with a dev for a certain task while pointing it. - That way we have a standard complexity measure. We know different devs will perform different amount of points per sprint . We dont lose time in pointless neverending discussions - it also works well in Mexico where people are not so vocal so the standard poker planning doesn't go well
We haven't restarted. It has been mentioned a small number of times, but the consensus is always that we don't think it will help. For our team, for what we do, how our work arrives and the nature of the systems we're maintaining and developing, sprints were just artificial lines in the sand.
Never heard of successful one week sprints, two weeks looks optimal. Sprint purpose is to show there is no hidden debt ("almost done, oh, no, three weeks more"). Roll out is a bonus.
Failed sprint should be an exception. It as marker, to resolve it you have to resolve real issues:
* team got to much points to implement properly
* no need to fight on story points, ±1 should not matter much
* you can't have two week story, commit something
Nearly every -- but not all! -- "Agile" environment I have worked in was pure cargo cult, with none of the requisite cultural infrastructure required to actually make any of it work, and often with a very strong centralization of control that made local iteration... unpossible[1].
Or they do the opposite, and go full "Lord of the Flies", providing no structure at all.
Both approaches yield poor results. You want to provide structure, but then grant autonomy over that structure to those beholden to its results.
If you want to "be Agile", your organization needs to push a great deal of control and trust fairly far down in the corporate hierarchy. Doing this successfully requires that organizations build the structures required for both appropriate oversight and cultural promulgation, and few companies even recognize the need for this, much less have the tools to do so.
[1] I am hereby defining this as "Possible on paper, but not in reality".
I refuse to have those people on my team. One person who's twice as productive as everyone else sounds great, but if that person's work doesn't fit well and makes everyone else's work harder it always been a net loss in my experience. I'd prefer my team works well together than have some "brilliant loner" join it.
That only works if the great engineer is also excited to learn and help. If they call people stupid or fail to listen to all the details because they prejudge the situation, then they're more of the "brilliant jerk" archetype -- but they often aren't as brilliant as they think they are.
If we were to take this to the extreme. Where do you slot in someone like Jeff Dean ? Are you going to sit there and make someone like Jeff Dean, play poker-scrum about how long the next "big research jump/product" will take ? Granted not everyone will have a Jeff Dean. But I would never wan't to work in place that is as boring as a place without someone like him.
Yea in my experience, scrum sucks for innovation !
That's absolutely true. I work on web apps for startups - most of the problems are quite simple. Jeff Dean would be bored out of his mind by the problems I solve.
Almost all of them should be replaced with simple commas or full stops.
Of course you could say this principle does not apply to your team (good luck!)
What is way more toxic, are people who consider themselves brilliant loners, because they've just implemented a web server using only Python's list comprehensions. And that is surely evidence of their unbridled genius. You know, people who are decent enough programmers, but are so egocentric in their work, that it borders on being inconsiderate.
For example, I used to work in a team where we wrote a lot of Python. We were three and one guy out of us considered himself above PEP-8 (he was good on the SW subject matter and was tight with the manager, so that went on unchecked). For example, all indents were done with 2 spaces. Meaning when some of us had to fix or change his code we had to fight our editors/IDEs. We ended up autopeping his files by default and ignoring any complaints.
Regarding the point you make about 20% of the people doing 80% of the work, that's half true. I find that 20% of the people do 80% of the work, but for any given period of time it's not always the same 20% of the people. One iteration might have a couple of back-end devs doing most of the stories, and the next iteration will find those two doing less while 80% of the stories are done by a DBA and a UX researcher. I've never had a team where one person consistently does most of the work. If that was the case I would be concerned about the make up of the team - clearly I'd need more people who do the sort of work that person is doing and less of the other team members.
Obviously my experience is not universal, so your experience may be very different.
What happens when the genius leaves? Can other people extend or maintain their work? Is there a lasting benefit to the organization? Does their work enhance the capabilities of other contributors?
From my experience in working with "very productive individuals that don’t work as a team", the answer to these questions is "no".
The reality is that a large chunk of generating economic value stems from being able to get along with other people.
The richest blacksmith in the Old West wasn't the one that was the most brilliant artisan. They were the one that knew the value of a customer, how to cultivate a long-term relationship with one, and how to get more.
Or find ways to reduce the workload. For instance by questioning if the feature really is worth making that complex.
When Michael Jordan was an asshole to everybody, I hear they refused to have him on The Bulls and won multiple championships without him.
Remember how The Beatles decided it's not worth it and didn't make any music? What a great decision by them, nobody would remember them long after they're gone anyway.
When I look at giant corps with their HR departments and filtering out of anyone who isn't a 'team player' - I am inspired. When Microsoft announces another ground breaking product - I forget all about the mediocre music and art created by small groups of difficult people.
When I compare Steve Jobs and his lunatic behaviour to Tim Cook, I am reminded that getting along clearly leads to better outcomes.
It is corporate culture of getting along that inspires me. It is people who think like you.
But imagine having Steve Jobs on your team, and trying to get the best out of him within the constraints of a project. It'd be impossible. Brilliant people like the ones you've listed need to be the ones leading. That's why I don't want them on my team.
I could spend years listing bands that have split up, the lead singer or guitarist tries to go solo, utterly fails, band goes for reunion tour 10 years later. It's a known band cliché.
A large software project is a lot of hard work of basically a bunch of people trying to write a story together. It's different to sport. One asshole pulling in a completely different direction is enough to drag everyone down.
It can also depends on what kind of software you are working on. Some parts might require a 'brilliant mind' to push through a spike solution for certain areas. This individual should not really be in a "normal-happy-scrum-team" though, that would be a punishment both for the team and the individual...
That being said, I've tried this a number of times and most of the time it doesn't work out.
I am no Scrum fanboy (I think), but this experience and also from former projects make me quite sure to not blame Scrum in the first place when I see struggling teams, but trying to understand the underlying problems and solve those.
When it is good, scrum powerlesness does not matter, maybe. But when it goes bad, it does.
If you want teams to care, they need to own it. When teams care, things happen faster. The catch is that you can't make them care about what you want done. You need to treat the team like the "10x rogue developer" giving them freedom to pursue what they want to pursue, steered by the product owner, shielded from external stakeholders. A product owner that mandates as _part_ of a team "we need to do X by y because Bob from marketing wants it" has a losing battle on their hands.
I really think the best person to be prioritising is the leader of the moment. Sometimes it's the strongest Dev, sometimes it'll be the product owner, sometimes it'll be the scrum master, sometimes it'll be a UX designer. It could be anyone, that everyone believes in. The next week/month/quarter it'll naturally be someone different, or maybe it's still that same person, if everyone is on board then there's no issue, right? That's not to say there's should be bitter infighting either, only that everyone should follow the herd. This way, the majority of people believe they're working on the right thing, and social pressures get others pushing in the same direction too.
Typically for this type of article the merits of "Scrum" are debated without Scrum first being defined, thereby making any reasonable appraisal impossible, and inviting a "your doing it wrong" conclusion.
At this point I am genuinely unsure whether this is some sort of master-level content-marketing trolling which is expertly crafted to goad engagement from senior engineers, or whether it is just sloppy, misguided, business-school nonsense.
Defining "scrum" in a debate-club fashion here is meaningless and is actually a valid strategy to discredit any criticism of it.
1. Scrum being a "philosophy" itself isn't clearly defined.
2. Different orgs practice Scrum differently, hence the more specifically you define Scrum, the less of the practice falls under that definition.
3. Best definition in this context is "set of practices most orgs call Scrum", which might as well be omitted.
And all of that has no bearing on the fact, that if team leadership busts out Scrum boards and Jira tickets more often than discussing problems, teaching/promoting knowledge and figuring out the best product design, then it's probably a mediocre shitshow.
Features over robust code
An effect is "birth defects are forever". An early design mistake is very difficult to correct in a scrum-like "agile" process. The incremental nature of the process favors patching around it.
This is OK for webcrap, but not OK for systems that have strong internal consistency or time constraints.
I have been in teams that to take the time to solve technical debt and even generate technical wealth. The best approach that has worked for me is to divide the development available time per sprint in: 33% new product features, 33% existing product maintenance, 30% Solve Technical debt (or 20% tech debt, 20% product debt with a 30-30-20-20 split).
With this I try to show that the problem of development teams NOT fixing their crap i not an issue of the Agile/SCRUM process (or any other process), it is an issue of management that prefers to ignore the mounting technical debt (until it explodes and you have the Github downtime, or LinkedIn leaks or the fact that changes become slower and slower due to codebase complexity).
I put the blame squarely on the process, whether its SCRUM or whatever.
The only right way to do great engineering, is by first asking what we ought to be engineering, not re-implementing the same shit over and over again, like we do web frameworks in every new language.
Great engineering is completely unrelated to scrum. It is only in the delusional mind of a middle manager that his existence and thoughts are at all relevant to the success or failure of any project on this planet.
Can't know what you ought to build if to don't know what your customer wants.
Most problems people try to solve using technology/engineering, are actually an attempt to bypass dealing with the real issues, which are almost always political.
One trivial example of this is children starving to death or dying of diseases we have medicine for. I'm sure there'll be another 'app' created for yet another charity or foundation.
Another trivial example of this is all the middle management and technical bullshit mobile development sweatshops go through, hiring separate developers for iOS and Android, getting them to coordinate and sync their work, working out the peculiarities of the two platforms, etc, etc.
All of these problems are solved at the political level of mandating that all mobile platforms have to support a shared set of protocols, libraries and frameworks.
All this 'fin tech' investment bullshit - it's a political problem, not a technical problem.
It's an endless list of insanity - 99% of IT work is useless trash, as are almost all other forms of work done in office buildings. It'd take a trivial amount of investment (less than a trillion) to automate away most office jobs worldwide but we don't do it, because we're stuck with a political decision to continue wage slavery. Again, political problem, not technical.
BINGO. The "problem with scrum" isn't usually scrum itself, but the management and culture of the company. And bad management and toxic culture will, in my experience, lead to the same results no matter what process / methodology you nominally employ.
To me, most criticisms of scrum reduce to a (legitimate) claim that "scrum isn't a magic bullet that will fix the fucked up management and toxic culture at this shitty company."
"Formal scrum" only exists to sell books, certs, classes; but more importantly to give justification or a "fix" to failed project managers and leaders.
A process will not fix a team that has bad teamwork, is not productive, and/or has bad communication/leadership/management.
To me it feels scrum is the person switching jobs constantly and saying people don't get it.
Scrum tells you 1) to analyze the way your team works, 2) make improvements, 3) talk to each other. If that sounds reasonable, it’s probably because it is. The mythology of scrum being evil is misguided, I wonder how much of it is caused by engineers forced to use JIRA configured by somebody who doesn’t work with the team.
That doesn’t mean you can use scrum, but it does mean that you should be careful about how you do so. If you have a bunch of guys working on different CRUD web-applications, does it really make sense to have them do a stand up every morning? Probably not. But maybe the kanban board still works well. Based on my own experiences you have to be careful and “agile” about how you build your processes to suit your changing needs, but going full strict scrum, is probably never going to work unless you’re a major tech company.
> No one is going to give you an unlimited amount of money of time for an uncertain amount of features
In a customer project I worked on recently, the consultancy I work at had a contract based on the number of story points - something like, "we will deliver 200 story points in phase 1". Now, because a story point is a relatively nebulous thing, there is of course a lot of room on both sides to fiddle things, but actually the customer was pretty happy with it.
The actual scrum teams were completely miserable, but that's a separate point altogether :)
This is a very important takeaway I think. A development methodology can work to organize the processes of an already (relatively) well working group. Expecting process standardization to fix dysfunctional human interaction is just putting the cart before the horse. Scrum will not build trust between coworkers or between workers and management. It will not allow non-technical management to suddenly develop an understanding an appreciation for technical difficulties.
In my experience, Scrum can easily become a series of little waterfalls, rather than bring a flexible and needs based approach to building complex products. This lead me to see that Scrum is not really Agile, where by “Agile” I mean [0]. Scrum is a process and Agile is a mindset. Some teams are able to hold both ideas in their head at the same time. But in my experience across multiple large customers and projects, teams think that by doing Scrum they are being Agile, and this is not the case at all.
Scrum is no more a solution to the social and political problems of a project than is waterfall or the spiral model (which Scrum mimics IMO) or anything else. A good team will succeed regardless of the project management methodology and a bad team will most likely fail.
Scrum is not the problem nor the solution. It’s management’s job to ensure that the teams are working well, that people have room to succeed and fail, and that the project management methodology suits the needs of the project. That’s certainly where I failed my business for a few years, until I worked it out.
As a result of not reading the documentation, not many understand what Scrum is and what they're criticizing. I have been in that situation myself at some point. One day, I found myself so frustrated that I read the Scrum book over and over again until I could complete the certification assessment with passing score, just to understand if Scrum was to blame for the problems I perceived.
What I learned in the process was that scrum does not recognize the role of a project manager and it does not make distinctions between development team members. The development team is defined as self-organizing and empowered to make decisions to a very reasonable extent.
The problems described here often start when some the self-organization and autonomy of the development team is taken away. This can take many forms, like adding roles like project managers or by redefining existing roles, such as making the scrum master role absorb responsibilities from the development team.
Those adjustments are suboptimal and almost inevitably result in an imbalance of power between product and engineering, and that's a really bad idea that will often result in engineering disasters.
Some companies create engineering holidays such as hackathons, where engineers can take the time to work on neglected aspects of projects. But then, in many companies, product people have started to intervene those events as well, perpetuating engineering frustration.
I've seen colleagues in development at other companies do this daily standups and all this scrum thing.
From the outside it really looks like somebody constantly asking "are you done yet?" And pressuring people into delivering. It really looks like something invented to serve companies and management more than developers.
Scrum has been ruined by many different groups (large consultancies, certification bodies, the misinformed, bloggers etc.) and there is a movement called the Scrum Pattens movement trying to fix the damage and to make it more explicit. If you want to do Scrum properly read “A Scrum Book”.
Scrum is not a process it’s process design framework- you start with Scrum as a framework to then, through inspecting and adapting, add what works for that team (and no other team) and discard/replace what doesn’t through experiments and retrospectives.
Does that sound like it’s liberating for engineers or something that ruins them?
Note: Kanban is also not a process but a system for continuous improvement. 99% of teams doing that are doing it wrong too most likely.
Scrum as defined in The Scrums Guide is a very specifically defined process with a few degrees of freedom, not a process design framework.
Now, if your approach was actually Agile (unlike the many groups that do Scrum, either as defined in the Guide or some variation they've cobbled together from other sources and still call “Scrum”, and think that by doing so they are therefore Agile), any canned process will be at most a starting point and input into what works for your team. But that is very much not Scrum as it has been propounded from the beginning, including by it's creators.
> Kanban is also not a process but a system for continuous improvement
Kanban is a very specific process element related to flow visibility and management.
"Scrum is a framework" immediately follows the "What is Scrum?" heading on https://www.scrumguides.org/ also Jim Coplien directly told me the point of the Scrum framework is to design your own process.
Regarding Kanban - I'm talking about the Kanban used in software development as defined by David J. Anderson and not the token used in manufacturing by Toyota and DJA himself previously wrote "Kanban is not a software development lifecycle methodology or an approach to project management. It requires that some process is already in place so that Kanban can be applied to incrementally change the underlying process." and "Kanban is a change-management technique that requires making alterations to an existing process".
Scrum as defined in the Scrum Guide prescribes very little. It's not much more than "Have a development team, a scrum master, and a product owner, have a product backlog, have developers plan their work, and work in time-boxed increments." Nearly every other aspect of how work gets done is unspecified and can (and should) be evolved by the team based on empirical observation.
My observation is that people have a tendency to adopt a version of scrum that is based on certain "default settings" that everybody sort of assumes are required, when they aren't actually. Two week increments, for example. I've heard so many people complain about scrum mandating two week increments, when it doesn't actually.
Or people complain about "velocity", and "story points" which are likewise not part of scrum at all.
Once there were no managers, team crumbled in internal politics but was bearable.
Once there was micromanagement, all fails to developers, all prizes for management, each sprint failed, that was hell.
Scrum explicitly does not permit that. A criticism that didn't make it into that answer.
https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum...
1. There's a lot of stuff that is often thought of as "part of Scrum" that really isn't. To the extent that the parent post you're replying to is referring to these things, then he/she is spot on. Things like Jira tickets, story points, planning poker, velocity, two week sprints, yadda yadda yadda.
2. Scrum™ doesn't permit you to do certain things... while truly saying you are doing Scrum™. But nobody has any real authority to mandate that you do Scrum™ to the letter, as opposed to an in-house "little-s scrum" version. And if that is what works better for you, you should do it. The goal is delivering working software, not adherence to the Scrum Guide for its own sake.
Then, development becomes ticket driven instead of engineered.
I have seen scrum used successfully where an engineering process was placed in front of the backlog ala Feature Driven Development.
There is a ticketing system, but it is kept separate from the work planning system.
If you are stuck in some weird cargo cult that doesn’t allow the team to iteratively change the process, you should call bullshit.
Sadly, scrum as I have seen it has been consultants preaching to the commoners how their rigid process is going to make them agile.
Scrum is just flawed from the foundations for anything but very routine work where you can somewhat estimate subtasks duration with any accuracy. But if your job is that easy you hardly need any fancy process anyway.
As a consumer of thought leadership — a sensible and responsible one, that is — I'm compelled to treat such concerns as endogenous to the framework / best practice / etc, and predict outcomes accordingly.
"You're doing it wrong" doesn't explain anything. At best it's the start of a conversation, at worst it's intentionally used to elide the costs of whatever it is you're selling.
