We use Scrum at work and I have to say, I am pretty annoyed by it. I think it is fundamentally rooted in the idea that ideal software development is just a continuous production of small improvements to the code. And from this come all its micromanagement failure modes (which there are plenty).
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.
fxtentacle 1397 days ago [-]
I remember we had a discussion about 10x developers a while ago and how some developers are perceived as moody divas.
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.
js8 1397 days ago [-]
I am definitely a "moody diva", I think because daily standup in particular forces me to admit more failures than I would have to otherwise (you need to fail before you succeed). And it's ultimately pointless and more stressing for everyone, because lot of these failures get resolved the next day.
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.
toomanybeersies 1397 days ago [-]
Some standups, I feel like I'm back in primary school doing show and tell, as I get regaled with tales of whatever meeting someone had (even better when several people feel the need to bring up the meeting that literally the whole team attended), or their progress on a completely unrelated project/feature which may as well have been what they had for dinner last night, for all relevance it has to me.
They do have their benefits though, especially when well run. A team member may encounter something they're having difficulty with that another developer has encountered and solved in the past. You might want to share a problem you encountered or findings that are relevant to others.
I suppose that most of those things could just be done as a slack message. Sometimes I feel like a meeting helps ideas flow better though. There's been occasions where having an actual verbal conversation with the team has yielded better results than a slack conversation would've.
Either way, I've never had a huge issue with them, as long as standup is the start of my working day and not like 10 AM or something where I'm going to get interrupted.
eindiran 1396 days ago [-]
> A team member may encounter something they're having difficulty with that another developer has encountered and solved in the past. You might want to share a problem you encountered or findings that are relevant to others.
IME this has been the biggest boon of standups. If they are kept short, and further conversation is done outside the meeting, they are a good way of matching your problems to other people on your team who may have a solution.
> Sometimes I feel like a meeting helps ideas flow better though.
I generally prefer when protracted conversation/problem solving is taken up between the concerned parties after the meeting, as otherwise the meeting drags on for everyone else who doesn't really need to know about your particular issue. But I do definitely agree with your assessment that "actual verbal conversation[s]" are better for me with regard to figuring a problem out.
1397 days ago [-]
irrational 1397 days ago [-]
> and then these design decisions are vetted (and possibly changed) by everyone in an open discussion
But don’t you dare try to have an open discussion at a stand up meeting. The moment a useful discussion starts the scrum “master” will tell you to schedule a separate meeting to discuss it. Honestly, that just kills the flow of communication. I have never scheduled a separate meeting to continue the discussion. We just end standup, go back to our desks, and don’t talk to anyone.
mindcrime 1396 days ago [-]
The moment a useful discussion starts the scrum “master” will tell you to schedule a separate meeting to discuss it.
Have you considered that if this didn't happen, it would be one of your co-workers on this thread, instead of you, and they'd be complaining that:
"Our scrum standups are supposed to be 15 minutes long, but they always take an hour or more, because people start going down some rabbit hole that doesn't concern half the team, and the scrum master won't politely interrupt and ask them to schedule a separate meeting. So much time has been wasted by this that it's unbelievable."
I have never scheduled a separate meeting to continue the discussion.
Why not?
username90 1396 days ago [-]
If a useful discussion happens during a standup the people discussing can just leave and let the others continue the standup without them. There is no point in being strict with these things.
mindcrime 1396 days ago [-]
Agreed. I was just curious about why, specifically, the parent poster never schedules follow-ups. If the discussion in question was actually valuable, it seems like they would want to pick it up later (or use your approach of just forking off immediately. I look at those two things are being approximately equivalent).
cutemonster 1395 days ago [-]
> can just leave and let the others continue
That can be hard -- many / some people would be worried it'd be impolite to leave and in a way say "the things you're talking about aren't interesting to me".
And they'll stay and feel frustrated, in silence.
seer 1397 days ago [-]
That sounds overly harsh. What we do in our team is "postpone" those discussions. When people have went through their updates, anyone who wants to stay is free to do so and can continue that discussion, usually in the same channel. This way you're not forcing people who _don't_ want to listen to that discussion to sit through it twiddling their thumbs - best of both worlds :).
geochronology 1395 days ago [-]
This. When I structured the standups for our own team, I budgeted 15 minutes for updates and 15 minutes for open conversation.
The result has worked almost exactly as intended: there's breathing room to discuss issues or ideas that come up in the course of conversation, but discipline around keeping those conversations brief enough to stay on the rails.
IMO at previous companies getting told "this isn't the time for that discussion" really frustrated me. As the OP stated, these conversations never happened, and it's healthier to allow some time and space for people to talk off-script when they're all meeting together.
KSteffensen 1396 days ago [-]
Would moving the standup to sometime where you are naturally interrupted, e.g. just before or after lunch, work better for you or is it the nature of the standup itself that's the problem?
jariel 1397 days ago [-]
1) Communicating is part of the job
2) Don't think about it in terms of 'failure'. You're just doing work. Sometimes the route is direct, sometimes it's not.
3) 'Time boxing' really has to be done, because products are not made in a vacuum. Time is money and it's a huge constraint. So everything really does have to be boxed up and parameterized by 'time' in the most reasonable means possible that doesn't screw everything up.
brailsafe 1397 days ago [-]
1) They were disputing scrums, not necessarily communication. 2) It's hard to not think of something as failure, if it's treated as failure, which is often the case. This is like telling someone who's being mistreated in a relationship to not think of it as abuse, just think of it as your way of life.
3) Time boxing may be important if a number of different types of schedule conflicts may arise, but I think it can place an undue importance on the measurability of how something gets done, often at the cost of it actually getting done well.
jariel 1396 days ago [-]
1) Scrums are literally communicating.
2) Just because someone feels there is a failure does not mean other people perceive it that way. If you describe it as a step towards the finish, then it is.
3) Time-boxing is inevitable. If there is a side-step due to some other issue, then you describe why the time boxes must be moved.
WalterBright 1397 days ago [-]
You just gotta trust that your top guys know what they're doing and let them do it.
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.
ckastner 1397 days ago [-]
I'm not entirely convinced that Johnson's example generalizes well. He might just represent an instance of survivorship bias.
Some people can be brilliant at something while at the same time being toxic, with the toxicity ultimately winning. Kalanick at Uber might be an example.
WalterBright 1397 days ago [-]
Lots of companies have tried to establish a skunkworks, but with "improvements". None have done particularly well. (The "improvements" were taking away the autonomy of the skunkworks.)
I've also seen it fail the other way where the Skunkworks becomes the preserve of "high achievers" not producing a lot that's useful. Almost every 'Office of the CTO' I've seen has suffered that failure mode. Lot's of things get built but none are more than fluffy experiments and there's no path to actually putting any of those things into production. Once in a while they'll be forced through and the production team has to spend a lot of effort fixing and making the project actually work.
ricardobeat 1397 days ago [-]
Isn't that just a lack of clear goals? Skunkworks had extremely ambitious deliverables and was not a science lab, even though they helped develop a lot of new technology.
meheleventyone 1397 days ago [-]
I think that's a part of it but there's also the question of how they interface with everyone else. IME a lot of these teams end up working in isolation from everyone else. And the patronage of the team usually makes them somewhat untouchable or unquestionable.
ckastner 1397 days ago [-]
I'm not arguing against the autonomy part, on the contrary: I join you in arguing in favor of it, and also that such an autonomy requires a brilliant personality at the head of it.
However, while the combination of autonomy and brilliant personality might be a prerequisite of outstanding success, I'm not yet convinced that it's an overwhelming indicator of it. I believe that a brilliant but toxic personality with autonomy can lead to an ultimately fatal instability.
C1sc0cat 1397 days ago [-]
Which is not orthogonal from SCRUM done well
toomanybeersies 1397 days ago [-]
I definitely fit into the "moody diva 10x developer"
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.
rawoke083600 1397 days ago [-]
>that ideal software development is just a continuous production
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 !
xtracto 1396 days ago [-]
One think I havent read being mentioned on this thread is how Scrum discrete sprint units allow the dev team to focus in a task for some time.
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.
1396 days ago [-]
MattGaiser 1397 days ago [-]
> Of that, probably the formal estimation methods (replaced in Scrum by intuition for some reason)
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.
tragic 1397 days ago [-]
> Why are we being asked how long it will take to do work in sections of code we have never seen?
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.
js8 1397 days ago [-]
> One of the one hand, the development team getting to control the estimate helps to control the workload.
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.
MattGaiser 1397 days ago [-]
> In every other discipline, you would ask engineers for an estimate. It's insanity to do otherwise.
I studied engineering in university and profs had plenty of stories about bosses sending business analysts to look at similar projects, generating a time estimate from those projects, and then send that estimate to the engineers as their deadline for completing the project.
It being insane doesn't stop people.
Scarblac 1396 days ago [-]
That's a pet peeve of mine. A perfect estimate is one without bias. It can't be without variance because there is always uncertainty involved in what needs to be done exactly.
So if you take an estimate and turn it into a deadline, in the perfect case, the deadlines can only be made 50% of the time.
Of course, in practice there is bias, there are things you forgot to include in the estimate.
sergeykish 1397 days ago [-]
It is to inform Product Owner. Quickly estimate with "trivial", "small", "medium", "big" and move on. Wrong estimate should not hurt. Managers are not allowed.
jay_kyburz 1397 days ago [-]
>Planning could be far more accurate if we just got a proposed task list a day before planning.
Why don't you work that in to your process. It's called Agile for a reason.
js8 1397 days ago [-]
Why don't they put it into Agile books? They're called books for a reason.
Snark aside, that's the difficulty. The fix for everything in Agile is - instead of adopting some sensible practice (that could actually have been discussed in academic literature), have an argument about this with your team members, maybe they will get it.
It's a return to medieval times, where all the expertise was just the experience of the master.
Supermancho 1397 days ago [-]
> Why don't they put it into Agile books? They're called books for a reason.
Agile books are hilarious because they are trying to not be prescriptive about process, while being prescriptive about process. Within that dichotomy, is the assertion that you can create your own process. So, in fact, it is usually in those books that you can make your lists for your team.
In the end, Agile/Scrum are a bunch of hand-waving rituals, which is close to what ends up happening within every software development team everywhere anyway.
jay_kyburz 1397 days ago [-]
I think the value of Agile is that everybody is different, and every problem posses unique challenges. You don't want to just follow some process in a book and expect it to work with your unique group of developers and designers, or for the unique problem you are trying to solve.
You could start with something suggested in a book. But you need to be ready to adjust your process when you identify when something is not working.
mathw 1397 days ago [-]
If you have no idea what the task list is before the planning meeting I'd say you definitely need to get your process changed. That's astonishing.
Scarblac 1396 days ago [-]
I want to add that the tasks we get at the planning meeting are just titles of tickets, nothing more. Working out all the details is the responsibility of the dev working on the ticket during the sprint.
Still estimates are considered extremely important...
jasonbourne1901 1396 days ago [-]
Scrum is being applied like a shiny new hammer to everything that might have seen or heard of nail a once.
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.
C1sc0cat 1397 days ago [-]
I think the obsession with tickets /Jira as the be all and end all of SCRUM is the main problem.
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.
tragic 1397 days ago [-]
> P.S. I am tired of the YADIW excuse. Let's have a nice honest discussion about how it can be fixed.
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.
ricardobeat 1397 days ago [-]
Despite what every book says, despite having three agile coaches run workshops with the team, despite this issue being specifically addressed with everyone involved, and being acknowledged as wrong, it still becomes the purpose of the standup.
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.
cutemonster 1395 days ago [-]
> it still becomes the purpose of the standup.
Also, the meetings are a bit useless for the developers -- they can just chat directly instead, and look in Trello/sth to see what the others are doing.
So the for oneself most meaningful thing to do, during the meetings, is to impress the managers / others listening?
Since the meetings barely hello with getting real work done anyway
mindcrime 1396 days ago [-]
inherently dicatorial culture of corporate governance
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!
wirrbel 1397 days ago [-]
> Of that, probably the formal estimation methods (replaced in Scrum by intuition for some reason) are the biggest loss.
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?
js8 1396 days ago [-]
> I wonder whether any formal way of estimation actually works
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).
jay_kyburz 1397 days ago [-]
>idea that ideal software development is just a continuous production of small improvements to the code.
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.
js8 1396 days ago [-]
> Many of us do believe this. Absolutely.
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.
aliante 1397 days ago [-]
I am fine with the small improvements to code part, but I at least want an idea of where I am going. Small improvements to solve the problem? Sure. But I at least want an idea of what the entire problem is, not just the two weeks of problem shards I am given.
jay_kyburz 1397 days ago [-]
Absolutly agree, if you don't know where you are going, how can you possibly move towards it. At the end of every milestone its super important to take a step back and ask, are you on the write track.
If nobody can clearly tell you the end goal, your project management process is not the problem.
sergeykish 1397 days ago [-]
I have seen project made three turns based on users feedback until it found niche. SCRUM has not denied our vision but made it possible to continuously roll out to tighten feedback loop. Something else wrong in your case. In SCRUM you should be able to voice your concerns, to work with Product Owner.
KSteffensen 1396 days ago [-]
If Product Owner is not providing you with the bigger picture he is not doing his job. Product Owner should make sure the end result is crystal clear at all times.
dogecoinbase 1397 days ago [-]
> The smaller the steps you take, the smaller the risk you step in the wrong direction.
This is the route to local maxima.
someguyorother 1397 days ago [-]
>>idea that ideal software development is just a continuous production of small improvements to the code.
>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.
jay_kyburz 1397 days ago [-]
I'm not familiar with the story, but it sounds like he started with a solution, (the tests) and tried to find some code that would satisfy them. Perhaps Norvig started with the problem, then tried to find a solution.
someguyorother 1397 days ago [-]
As I understand it, TDD works by that you say what your problem is, find the smallest thing that will get you there, and then implement a test for it. The test will naturally fail, so you then write code to make it pass, and finally refactor. It's fundamentally iterative.
But Jeffries didn't know how to get to the solution, i.e. what mechanism to make use of to get the computer to automatically solve Sudokus. So he wrote a few tests for the obvious things (like I/O and data structure) and then got stuck.
In contrast, Norvig knew considerably more CS and so knew that the right way to implement a solver is to use constraint propagation. So he did so in about a screen of Python code, all at once, job done.
The lesson of the story, as I read it, is that you can't iterate yourself out of a problem if you don't know how to attack it. If you're making a symbolic calculus program to solve integrals, it's unlikely that you can start off by going "okay, the integral of x is 1/2 x^2..." and somehow, through a series of small steps, end up at the Risch algorithm.
Similar arguments could probably be made about design. The less CRUD-y your application is, the more careful thinking is required. You have to know enough about the domain to know where the pitfalls are, and what the proper tools are.
mindcrime 1396 days ago [-]
I think in reality, SW development done right is nothing like that.
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.
dragonwriter 1396 days ago [-]
> 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.
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.
seer 1397 days ago [-]
Maybe I've been lucky up to this point myself, a kind of survival bias or something, but a "lightened" version of Scrum has always made so much sense to me when it comes to developing software.
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.
greatgib 1397 days ago [-]
I agree with this point of view.
In my opinion, one of the greatest fallacy of Scrum and some agile methods is:
"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.
sergeykish 1397 days ago [-]
You know you've described the opposite of agile approach, right? "management", "file by file, function by function", "exchangeable and a commodity"... at least not what agile was ten years ago. Actually the points in favor of agile were:
* utilize persons strong points
* reduce management
* reduce burden
* improve working environment
greatgib 1396 days ago [-]
I agree also with your point.
The real agile as of the "Agile Manifesto" has the spirit of what is good dev in my previous message.
But was is used today as "agile", "agile in business", agile in real use, and especially Scrum is not what the Manifesto asked for, quite of the opposite in the end.
That is even why some of the creators of the agile manifesto backed off when they saw what it became.
In fact, at the moment a company or a people say "we will create an agile team here" (maybe with a specific process scrum/...), you know that it is failed.
It should be like "we have experienced software engineers, we trust them to be autonomous and smart enough to do it how they individually want to be the most efficient/adequate. Also they have responsibility and their opinion is taken into account for business decisions"
sergeykish 1396 days ago [-]
I've seen it in work. It was very emotional when our Scrum Master left, we've got another one and he was great, but it has not felt same. This may be the biggest Scrum issue.
I've seen unreal Product Owner, it was so much pleasure to work with. Ever since I've found a joy in filling this niche if it was empty.
Yes, Agile Manifesto, Scrum is just some tools. It is like blaming axe [0] in Armenian cartoon.
As a follow up, nothing in the Agile Manifesto says that the process is important to ensure that a "developers" is not essential and can easily be replaced:
"Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done."
sergeykish 1397 days ago [-]
Agile builds on the premise that developers like to build. That we self organize our teams and don't like slackers. Bring transparency for business so it can trust us. Give estimates and accept priorities. Ship from time to time so all can see that process works.
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.
etripe 1395 days ago [-]
> Bring transparency for business so it can trust us.
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.
KSteffensen 1396 days ago [-]
You'd think products shipped on time as agreed with the customer was a benefit for management.
sergeykish 1396 days ago [-]
I thought same. I fought for roll out in time, velocity and quality. Now I'm burned out. PM had his own agenda - introduced a men who, he was like 1/10x developer on senior position, promised to fire in a few month, have not happened in a year and a half, this destroyed velocity and as tech lead I was blamed. I stayed so long because our customers were awesome, could not leave them.
Managers are not friends. The moment I've said I'm leaving I become nothing. Time to learn.
AnimalMuppet 1396 days ago [-]
> P.S. I am tired of the YADIW excuse. Let's have a nice honest discussion about how it can be fixed.
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.
remontoire 1397 days ago [-]
what does YADIW mean?
usrusr 1397 days ago [-]
"You are doing it wrong", the first and last thing any scrum believer will say to someone for whom it does not work.
mindcrime 1396 days ago [-]
And in a great many cases, when you dig into the details, it turns out that they are - in fact - doing it wrong. Or at least blaming scrum for things that scrum does not actually entail. Or blaming "agile" for things that are 100% contrary to both the letter and spirit of the agile manifesto.
nnevala 1397 days ago [-]
I think it stands for You Are Doing It Wrong.
augustk 1397 days ago [-]
YADIW = You Are Doing It Wrong.
1397 days ago [-]
1397 days ago [-]
jariel 1397 days ago [-]
This is a very good point, but often for established code bases, many things are just incremental. If the architecture is in place and well understood, especially if it's more of a business app ... then it's not Math ... it's more like Carpentry.
1396 days ago [-]
kevsim 1397 days ago [-]
I interviewed a long time ago at a med tech company in Boston where Jeff Sutherland, one of the inventors of scrum, was the CTO (I believe). I had recently been through scrum master training at my current job and was quite keen to see how scrum was applied in the place where the guy who invented it was working. I asked my first interviewer how they used scrum on their team and his answer was that they didn't use scrum. I was pretty shocked. Then he explained that scrum didn't fit well with their team and the way they worked best together, whereas on some other teams they were really happy with scrum. Made me realize that's there's no one size fits all process for software teams. Some of these "pre-baked" processes can help teams depending on their composition and maturity, but teams/companies really need to find the way of working that works for them.
Areading314 1397 days ago [-]
If you read his book, you'll see that he repeatedly drives the point home, that Scrum is not a set of pre-baked processes, but a philosophy around measurement, prioritizing, and continuous improvement. The cargo cult meetings and processes are more a product of the "Agile movement" that is championed by mediocre middle managers.
danjac 1397 days ago [-]
That's the problem though: any philosophy that cannot be implemented by a "mediocre middle manager" (i.e. most managers in most companies) is doomed to fail. And if it requires an "amazing" manager to succeed, the question is whether it's down to the philosophy or the manager.
sergeykish 1397 days ago [-]
But there are no managers in SCRUM. It is doomed to fail once methodology is thrown out and replaced with manager. I've been on SCRUM presentation in 2007. They explicitly stated - we help forming the team and go away.
danjac 1397 days ago [-]
> there are no managers in SCRUM
A philosophy that hinges around some ideal of how the world should be, rather than dealing with the world as it really is, often ends up being implemented as the exact opposite of that ideal. I can think of some historical parallels...
sergeykish 1397 days ago [-]
Just don't call it SCRUM.
Call it "fraud SCRUM because it sells so well" or "lipstick SCRUM so we look cool" or "didn't read SCRUM but we have meetings and sprints". SCRUM works, maybe not for everyone but this denies us a chance.
danjac 1397 days ago [-]
No True Scrum again...
sergeykish 1396 days ago [-]
Look, I've had good experience with SCRUM team. Later I've been searching for work, "SCRUM", interesting, interview, what? PM? Another place, PM? Yet another... I have not found. They would not tell that it is not SCRUM before interview. And oh, they failed so miserably, I knew how it works but couldn't do anything. It is regress.
So often it is PM who destroys project. I've seen good PMs. Two. Great guys. Great managers protects project from upper management and helps to resolve teams disputes. Others... They are like third wheel - developers like to build, business knows what to build, managers - exercise control.
danjac 1396 days ago [-]
That's just it though: the fact that Scrum only works given this perfect "no management" ideal. It might work as a lightweight set of guide-rails in a self-motivated, experienced team which has 100% hands-off trust from management, but I'd argue that in that perfect-unicorn case Scrum is not the key to success but rather the fact that you have a good team and good management. In practice - as you are finding - this combination is very rare. Furthermore I'd argue that in the typical company with typical management, Scrum will lead to even greater micromanagement and overhead, and might actually be worse than, say, some version of ad-hoc Kanban-lite.
sergeykish 1396 days ago [-]
Yes, but not works but is. Scrum requires trust and autonomy. Otherwise it is a set of non applicable tools, jumping with parachute under water. I argue Scrum with PM is oxymoron, like round square. I know it is rare, earlier it was easier to find.
Why discussion is about Scrum, not Scrum tools application and awful project management? The language is subverted, why do you help it?
mpweiher 1396 days ago [-]
> So often it is PM who destroys project.
How true! In my 30 years in the industry, I haven't experienced a single PM who was a net-positive (though I've heard that some are awesome), and some that simply made no positive contribution whatsoever.
I had one program manager who was awesome, even though we certainly didn't need a program manager (~40 person startup) per se. But she realized what was going on and then kept the PM (and everyone else) off my back so I could get the job done.
First and AFAIK only time in that company's history that a software project was delivered on-time.
Of course, after we shipped, it was all "congrats, but now you must do things properly like the rest of the company".
Not sure whether that's "sigh" or "LOL" or ¯\_(ツ)_/¯
christophilus 1397 days ago [-]
Part of the scrum retrospective involves a process review. You look at what is and isn’t working, then evolve your process accordingly. Sounds like that team decided that scrum wasn’t working, which means they used the evolutionary aspect of scrum as it was meant to be used. That focus on improving processes is the best aspect of scrum in my opinion, and the least used in my experience. Today, I mostly work on my own and am self directed, and boy... I don’t miss working in those old structured environments.
leto_ii 1397 days ago [-]
This reminds me of the anecdote about Harry Markowitz, the originator of what is called modern portfolio theory (which supposedly tells you how to allocate your money efficiently). When asked if he applied his theory IRL he said something along the lines of: Hell no, I just put a third in stocks, a third in bonds and a third in cash.
I think a theory of any kind that is not applied IRL by its creator should be seen with great suspicion.
wodenokoto 1396 days ago [-]
So what did they use? Other than kanban I haven’t heard of anything other than scrum. And that is essentially scrum where you draw issues from the entire stack instead of biweekly choosing a subset of the stack to use.
Graham24 1397 days ago [-]
There is no silver bullet
PaulKeeble 1397 days ago [-]
In the one place I saw Scrum work really well it wasn't because of scrum we succeeded it was the amazingly talent team that groked their goals and understand how to build software well. The complete lack of an enforcer manager was a huge win, being connected directly into your customers and letting them drive what they needed and balancing it with the engineering, that worked really well. They executed well despite scrum and ultimately used Kanban with on need for the biweekly meetings since they were releasing many times a week.
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.
jariel 1397 days ago [-]
"being connected directly into your customers and letting them drive what they needed and balancing it with the engineering,"
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.
PaulKeeble 1397 days ago [-]
You need the right customers. We were really lucky the lady in charge of the business team learnt enough of how the development worked to sit in that middle ground between her team of experts and ours to guide the direction well. I would say she and our engineering principle were what made things work well. If you are working with generic customers out there in the world then its much harder to utilise customer focussed requirements.
sergeykish 1397 days ago [-]
That's the idea - allow people to take responsibilities, learn, grow, communicate. It takes effort and time. And sometimes right person. But when it works it is a joy. I've seen young developers in what was their first project. It is bad but that moment I felt envy.
So often people complain about specification. Here you craft them as they fit you (as long as they resolve customers need).
jyriand 1397 days ago [-]
What i don’t like most about scrum is the sprints. Doesn’t matter if it’s one or two weeks long, we never have a successful sprint, the velocity chart looks like random numbers, and we spend hours on debating what the story points really mean. Sprints are artificial deadlines that don’t really make any sense, developers don’t care, business people don’t care. A project i could complete in a month will take at least three months, because of the processes we have to follow. Instead of refactoring and thinking about overall design i have to worry about getting the task done by the end of the sprint.
woutr_be 1396 days ago [-]
The amount of hours our team has wasted on estimating, re-estimating, splitting up stories, simply to make our burn down chart look great is amazing. We would often be forced to split up stories the day before a sprint review, just so that the chart would look like things have progressed, while in reality nothing was completed.
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.
xtracto 1396 days ago [-]
I have suffered through those sprint sessions of hell.
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
woutr_be 1396 days ago [-]
Sadly because of the way our organisation works, the scrum master pretty much takes ownership of the whole process, he also sells agile to the business side. So if you go against what he says, the business will know that you’re a trouble maker, even if you had the best intentions.
Trust me, our team has tried, sadly the whole business wants to move to agile, and it’s shoved down your throat, wether you like it or not, or even regardless if it’s working for the team.
Eventually I gave up, the amount of energy wasted on these discussions is just not worth it. After a while you learn to say the right things, while also making sure you keep your technical freedom. Sometimes that meant not bringing up certain technical tasks, and overestimating others so that you have time for those other technical tasks.
mathw 1397 days ago [-]
I raised a similar idea with my team a while back and we stopped doing sprints as an experiment.
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.
sergeykish 1397 days ago [-]
SCRUM highlights project management problems. If everything works its only overflow is a two hours boring retrospective. Morning meetings is 5 minutes maximum (status ok), estimation - about an hour. Last sprint day is a lazy day - no new tasks allowed, refactor what you can, make presentations etc.
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
C1sc0cat 1397 days ago [-]
I have worked very successfully with one day sprints and an end of day catch up - though the was with RAD/DSDM.
donw 1397 days ago [-]
The problem with Scrum is that most practitioners have no idea why their tools exist in the first place, under what conditions those tools apply, and what to do when their tools fail.
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".
onion2k 1397 days ago [-]
Very productive individuals that don’t work as a team
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.
dbt00 1397 days ago [-]
This can flow both ways. I've had great engineers on my team that people were scared to approach because most of those conversations resulted in the questioner discovering they were wrong about something or missing some knowledge. Ideally people who are afraid of that are coached up to be happy to learn instead.
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.
keithnz 1397 days ago [-]
As long as they aren't toxic, if you can't get the best out of brilliant loners, then, you don't deserve them, or possibly don't really need them. My experience is if the team culture is good, then they can fit in and you can accommodate their working style
rawoke083600 1397 days ago [-]
Ja I've seen teams without them (10x, brilliant loner, call them what you want). The times the teams are without that sort of talent(just talking pure problem solving ability here)... was the times the teams, product and company was also just that. mediocre/not-inspiring/meh. And they weren't solving a hard problems !
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 !
onion2k 1397 days ago [-]
they weren't solving a hard problems
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.
mattmanser 1397 days ago [-]
What's with all the ellipses? Really makes it hard to understand what you're saying.
Almost all of them should be replaced with simple commas or full stops.
rawoke083600 1397 days ago [-]
agreed... and fixed
andi999 1397 days ago [-]
Actually the brilliant loner should be the norm (to have one), not the exception. If you believe in the 20:80 rule, that 20% of the people to 80% of the work. This rule doesnt sound so bad but actually (lets take these numbers as strict and not as a probability distribution). It means your top perfomer are 16 times more productive than the lower performers.
Lets say you have a team of 10 people doing 100 work units. So 2 do 80 work units which is 40 per person, and 8 do 20 units which is 2,5 units per person.
Of course you could say this principle does not apply to your team (good luck!)
jevgeni 1397 days ago [-]
I'd agree with that, but it doesn't require that productive people are "loners". Best programmers I know are brilliant in communicating with people, setting standards, and so forth. Even if they sometime crank out a library or two on their own over morning coffee.
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.
onion2k 1397 days ago [-]
In my experience having a brilliant loner on the team increases the amount of work the team needs to do by more than they contribute. Also, very often, what they contribute is clever solutions to problems that didn't need clever solutions. The few teams when I've had that sort of person on my team productivity has gone down, not up.
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.
brtkdotse 1397 days ago [-]
This is my experience as well. Give me a few medicore, but friendly and well-adjusted developers and we'll deliver a decent CRUD app within a standard deviation of budget and time.
Give me a team of superstars and we'll deliver a half-finished framework for solving the general class of CRUD problems one could have, along with a bad implementation of a gherkin dialect.
donw 1397 days ago [-]
Agreed.
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.
matsemann 1397 days ago [-]
Yup, I'm not fan of the 10x-programmer moniker. The true 10x-ers are those that multiply those around them by a small factor in some way. If you can help all the members of your team to be 10% more effective, that has a bigger impact than even working twice as fast.
Or find ways to reduce the workload. For instance by questioning if the feature really is worth making that complex.
Osiris 1397 days ago [-]
As a team lead, this is the approach I try to take. I spend most of my time tackling the problems that are blocking other team members from getting work done. It's not sexy but keeping 3 guys working is more valuable than me getting to work on feature work. Sometimes the things that are blockers are the more interesting challenges and sometimes it's just frustrating bugs, but either way it's satisfying to me when I see the team cranking through our assigned feature.
metalliqaz 1397 days ago [-]
It's a matter of management. Brilliant people can be very useful. Even team players may not work with all other team players. Gotta find the right fit.
alexashka 1397 days ago [-]
I hear you.
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.
onion2k 1397 days ago [-]
You're getting downvoted but I think you make a valid point. Brilliant loners can be really useful for a business. They're the visionaries. They're the ones who change industries.
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.
1397 days ago [-]
bcrosby95 1397 days ago [-]
Yeah, but now you're most likely leaving the field of software engineering and are going higher up the promotion ladder.
mattmanser 1397 days ago [-]
Beatles/music analogy rather backfires, no-one remembers Paul McCartney albums or Freddie Mercury solo projects.
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.
danjac 1397 days ago [-]
Counterexamples: John Lennon, Sting, Eric Clapton, Neil Young, Phil Collins, Lou Reed...
mattmanser 1396 days ago [-]
They're the exceptions to the rule, the converse happens far more often.
danjac 1396 days ago [-]
...George Michael, Paul Simon, Iggy Pop, Cher, Michael Jackson, Tina Turner, Diana Ross...
ponker 1397 days ago [-]
I've seen my FAANG division manager use brilliant loners quite effectively by requiring them to be remote. They don't join meetings or really check in with anyone but every six months they pop up and say "I re-architected System X and now it can handle 10,000x as much traffic" or something like that.
secondcoming 1397 days ago [-]
That sounds like a nightmare. How did they handle things like being on call? Was the loner responsible for their genius 24/7?
ponker 1397 days ago [-]
No, basically the group managers assigned the “architecture astronaut” tasks to these brilliant loners. They would figure out the answer and then be assigned to a team to onboard them basically, they’d come into the office for a week or two to do design reviews, go back to being remote to get the stuff into production, and then the full crew would own the service and the loner would go to the next thing.
secondcoming 1397 days ago [-]
Interesting. How did the team feel about being maintenance people? I think I'd have found it a bit demoralising if someone gets parachuted in to work on the - I assuming - interesting stuff.
ponker 1396 days ago [-]
The team didn't become maintenance people. Basically the architecture astronaut did the first 6 months of 2-3 year projects. And everyone knew that they were geniuses, maybe there was a little grumbling but people got on board.
tehlike 1397 days ago [-]
Brilliant loner can bring up 20x the improvement though. Especially in the creative business, productivity could mean very different things.
apabepa 1397 days ago [-]
Yes I agree for the general case and I have seen this problem many times where management refuse to see the problem with anti-social loners holding too much of the competence in a team.
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...
kevsim 1397 days ago [-]
I tend to agree, though as an engineering manager, the brilliant loner poses an interesting challenge. Can you actually work to turn that person into a team player, see the value of collaboration and transparency, etc. Sometimes there's some insecurity or simply lack of understand behind their behaviors, and a behavioral shift is actually possible.
That being said, I've tried this a number of times and most of the time it doesn't work out.
1397 days ago [-]
xtracto 1396 days ago [-]
I have had someone in my team with some autism (diagnosed). The dev comes up as a VERY shy person who would barely talk during standups. Still a great developer and I love her to be part of my team. Even if interaction is different.
1397 days ago [-]
waschl 1397 days ago [-]
I am in a big project which assembles 45 teams and all of them shall adopt Scrum (for various reasons). My observation is that all those teams which have a sustainable pace with regards to architecture, technology, quality, output, social behavior, etc have done so while adopting and embracing Scrum in a clean way since the beginning of their existence as a team. All teams severely struggling with their content of work, output and collaboration have also severe issues with regards to Scrum-adoption, and show anti-patterns similar to the Stackoverflow thread creator‘s. However I would say the root causes (which we discussed in maaaany meetings) are certainly neither caused by Scrum nor increased by it, but individual mindset, dysfunctional team dynamics, pressure, weird contracts, etc. and would be there under any other or no process framework.
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.
waschl 1397 days ago [-]
One more thing: In answer to Scrum advocates claiming its about doing it right I would disagree and replace it with understanding what is really (really REALLY) the purpose and idea behind it. Don’t worship the cult and don’t fight it because it’s the perfect target of rants, but see the motivation behind it and acknowledge that there may be reasons why it makes sense how it is to some degree. This doesn’t only apply to Scrum but to any other interaction of humans.
dboat 1397 days ago [-]
Could you explain what you mean by the real purpose and idea behind scrum?
waschl 1397 days ago [-]
Let me try: I think it’s about reflection and continuous improvement and providing a framework to enforce those. Scrum-haters in our group are also notorious for an attitude of negativity and resignation in many matters, while Scrum-friends want to improve all the time and find ways to do so, beyond what is obvious.
watwut 1397 days ago [-]
I think that Scrum leads to resignation for many people, because it takes away control out of individual and insists on everything being collective. So your personal options to improve or make decision becomes severely limited.
Some people like it, because it allowed them to push themselves on the rest of the team. But people who dont thrive in such constant dominance conflict end up resentful and helpless.
jjav 1397 days ago [-]
That's an insightful concise description of "agile" experience.
As an anecdote, I have an acquaintance who is a psychologist in silicon valley and he has mentioned he frequently works with patients suffering from mental health issues related to being subject to "agile" at work. I wish someone would do a proper study on this topic.
Personally, agile hasn't driven me to depression but it has made me target roles that avoid it at all cost. Life is too short and precious to suffer through a detailed status report meeting every.single.day.
watwut 1397 days ago [-]
I found that testers in particular find agile off putting and some avoid working at such companies if they can. I am not sure why testers specifically end up disliking that.
I think that agile ignores human psychology. First, in management theory, intrising motivation happen when one has autonomy, mastery and purpose. Imo, plus accountability. Agile removes that from individual, but has some rhetoric that places it on the "team". But team is not person, it is set of people.
Second, it kind of assumes that people are socially perfect and everyone is kinda the same and its answer to any social human problem is "that is team dynamic or bad individual". It does not help to deal with predictable human imperfections, emotions and conflicts.
ohmyliver 1396 days ago [-]
possibly because usually they get a fraction of a sprint to do a whole sprints worth of validation.
tumetab1 1397 days ago [-]
I think UX people should evaluate the different development processes. UX people because they have the concept of that something tasks take more mental effort while other less, e.g. searching for a button within 100 buttons has a cognitive load than searching for a button within 10 buttons.
My guess is that SCRUM has a greater cognitive load than waterfall.
riffraff 1397 days ago [-]
what control do you feel is taken away from individuals? I mean, you discuss tickets with the rest of your team, but that doesn't seem such a big loss of freedom.
perlgeek 1397 days ago [-]
Control what to work, on for example.
These days I sometimes decide not to work on the top priority issue right now, because I suspect it'll take a few hours of uninterrupted log file reading / debugging / thinking to fix, but the day already has three different meetings scheduled.
If that's the last issue in the open sprint, choosing to add another issue to the sprint while there's still an open one tends to be a no-go, or at least causes some discussion, especially if the sprint closes without the issue being closed.
Or sometimes I simply I don't feel like working on a particular issue right now. Maybe there's no rational reason for that. I have no problem overriding that impulse if I know somebody else (either a colleague or a customer) is blocked by the issue, but if it's a case of "we have happened to include issue A in the sprint, but not issue B", having to work on A instead of B against my preference causes unnecessary resentment.
watwut 1397 days ago [-]
All the control and all the autonomy I would say. There is nothing I would be responsible for where I can make own decision and have them right or wrong.
In the teams where I liked to work, I felt control over order in which I do tasks and general shape of something I was responsible for. So I could make my own decisions, decisions that would be really mine.
So when there was mess or something was late, it was my fault. I was not due to other people forcing me do things their way and I did not had to fight about every single detail, just because college happen to be anxious or control freak.
mindcrime 1396 days ago [-]
So what process are you advocating for over scrum, that would restore this control and autonomy to you?
watwut 1396 days ago [-]
Compared to scrum, pretty much any other, quite honestly. The majority of teams I was in did not used named process and for the most part I was alright. Usually there were bigger tasks assigned to people or smaller areas of responsibilities.
For the record, I did not liked when leader had micromanagement/dictatorship tendencies either.
eecc 1397 days ago [-]
In fact there’s no point in being “agile” in an organization that has no appetite for change (unless those are topdown, consultant-driven, marching orders).
When you’re given the false hope optimization is possible, only to bump into 2-3 layers of middle management and just as many half-broken, Confluence spaces about the “one way of work” for the org... you just content yourself with features and tune out.
In short I would say, applying ideas from the agile manifesto while providing cadence and some predictability. But that is a personal opinion.
watwut 1397 days ago [-]
My experience with scrum was that it makes issues around bad team dynamic, pressures and weird contracts worst. Basically, it makes it impossible for individual to react to them and defend against worst consequences.
When it is good, scrum powerlesness does not matter, maybe. But when it goes bad, it does.
waschl 1397 days ago [-]
I would agree that Scrum makes bad dynamics more transparent, yes. I would not agree that it generally makes bad dynamics significantly worse. This may happen and it’s certainly often claimed, but that is not what I can confirm from my experience.
watwut 1397 days ago [-]
I did not said more transparent. I said harder to deal with and harder to solve.
Those are fundamentally different things.
beaker52 1397 days ago [-]
The thing I personally see that corrupts Scrum the most are external stakeholders. They're usually applying time pressures and defining work items to be worked on. The team then has no ownership and no control, resulting in an unhappy and unmotivated team that's constantly disappointed with itself for not delivering and often isn't really invested in what's being asked of them.
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.
fergie 1397 days ago [-]
(The linked article is a piece of content marketing and not the reflections of an individual expert in the field.)
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.
jevgeni 1397 days ago [-]
It's a decent article.
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.
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.
xtracto 1396 days ago [-]
I disagree with this sentiment, well at least I disagree that it is SCRUM's fault. I think this is a problem that resides higher up.
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).
JoeAltmaier 1396 days ago [-]
Hm. That sounds like a process issue. Which is what SCRUM etc are part of. So its not process, but changing process will fix it? SCRUM + technical debt management is the cure? Then SCRUM was missing something.
I put the blame squarely on the process, whether its SCRUM or whatever.
mindcrime 1396 days ago [-]
Then SCRUM was missing something.
Scrum is missing a LOT of things, because it's very specifically intended to not be highly prescriptive. The whole idea is to iterate, use empirical feedback, and evolve your process to match your context.
Right near the beginning of the Scrum Guide it reads
Scrum is not a process, technique, or definitive method. Rather, it is a framework within which you can employ various processes and techniques. Scrum makes clear the relative efficacy of your product management and work techniques so that you can continuously improve the product, the team, and the working environment.
alexashka 1397 days ago [-]
The only right way to do 'great engineering' is by not having any middle management.
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.
danjac 1397 days ago [-]
While "middle manager" is often nowadays a negative term, having a good manager between yourself and the upper management/customer can be a godsend. They can act as a bullshit filter, they can deal with bureaucratic busywork, they can get you whatever resources you need, fight for more funding/people for your team, help out with HR stuff and so on. You need these people so you can get on with "great engineering".
amznthrowaway5 1396 days ago [-]
Those people should not be paid nearly as much as the actual value producers.
bickeringyokel 1397 days ago [-]
You'll have to define middle management, if you're including product management, then your statement would be pretty contradictory.
Can't know what you ought to build if to don't know what your customer wants.
alexashka 1397 days ago [-]
Everyone knows what the customers want, it's quite trivial.
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.
fjfaase 1397 days ago [-]
Great article, but it does not mention management attitude. If upper management does not have the right attitude towards Scrum, Scrum will fail. If upper management does not guard the role of the Scrum masters, select capable Scrum master and allow them to function correctly, Scrum will crumble into another tool for micro-management which frustrates developers and destroys productivity. I also have seen that often it are the more ambitions (and less technically talented) developers that opt for role of Scrum master as a stepping stone to a management role. These type of Scrum masters will starting act like top-down managers, who no longer fulfill the role of a Scrum master, namely provide a safe environment for the team to function optimally.
mindcrime 1396 days ago [-]
Great article, but it does not mention management attitude. If upper management does not have the right attitude towards Scrum, Scrum will fail. If upper management does not guard the role of the Scrum masters, select capable Scrum master and allow them to function correctly, Scrum will crumble into another tool for micro-management which frustrates developers and destroys productivity.
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."
AnimalMuppet 1396 days ago [-]
In fact, scrum is something the messed-up management has tried to use as a magic bullet, rather than actually fixing themselves.
mharroun 1397 days ago [-]
Scrum, Kanban, scrumban, tickets with predefined checkins... all can work.
"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.
gtirloni 1397 days ago [-]
I think it's similar to when someone switches jobs frequently and complains about every company they've worked at. At some point, you have to realize it's you not them.
To me it feels scrum is the person switching jobs constantly and saying people don't get it.
baq 1397 days ago [-]
Yeah, no. Scrum is a tool. You can implement it wrong or be very strict with it which kind of isn’t agile, but it’s always a people problem.
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.
supercanuck 1397 days ago [-]
No true scrum.
moksly 1397 days ago [-]
I work in the public sector of Denmark, and I’m involved with both developing and procuring solutions. We have quite a lot of them, around 300 for our 10.000 employees, and from a buyers perspective things like Scrum and agile rarely makes a lot of sense. It’s down to the old triangle of time, features, money, which agile and through it scrum mandates at least one has to be flexible. Only that’s now how you buy software. No one is going to give you an unlimited amount of money of time for an uncertain amount of features, and almost nobody has the time to act into your Scrum schedule to prioritise stuff. Because of this, it’s not really how you sell software either. As a result Scrum often becomes a wrapped in a business side that’s very much unified or waterfall process in companies pretending to be agile. I’m not saying it happens everywhere, but I don’t think I’ve ever been involved with a procurement or development process you could truly call agile.
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.
GordonS 1397 days ago [-]
> We have quite a lot of them, around 300 for our 10.000 employees, and from a buyers perspective things like Scrum and agile rarely makes a lot of sense
> 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 :)
leto_ii 1397 days ago [-]
> Build a team to do scrum, don’t expect scrum to build your team.
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.
samdwilson 1397 days ago [-]
I wish blog posts like this had examples of things they actually did. It would make it a lot more informative to learn from an example.
doctor_eval 1397 days ago [-]
In my company we hired a CSM (certified scrum master) and we definitely did Scrum by the book. But we didn’t do it right, in the sense that after 2 years our productivity was worse than when we started.
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.
Very few people care to read the official Scrum documentation. It is not a long read. Some posts on HN have more words than the Scrum Book.
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.
danjac 1397 days ago [-]
While there may be success stories out there (and usual arguments apply for No True Scotsman), a company that proudly states "we're a scrum shop" is at this point most likely shorthand/signal for "we love meetings and micromanagement" and is to be avoided if possible.
znpy 1397 days ago [-]
I work in systems engineering, automation, devops and that kind of stuff.
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.
sunstone 1396 days ago [-]
Scrum is a process for large companies to force some group consistency across their 1000's of developers. Think of it as the minimum viable group behaviour. Naturally talented and effective team oriented developers know what to do naturally and don't require the explicit framework.
richliss 1396 days ago [-]
99% of teams are doing Scrum wrong most likely.
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.
dragonwriter 1396 days ago [-]
> Scrum is not a process it’s process design framework
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.
richliss 1390 days ago [-]
Part of the reason for the Scrum Patterns movement which is helmed by Jeff Sutherland and Jim Coplien is that the Scrum Guide isn't all that great or clear. There's politics behind that and also attached to how it's changed/updated too.
"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".
mindcrime 1396 days ago [-]
Scrum as defined in The Scrums Guide is a very specifically defined process with a few degrees of freedom, not a process design framework.
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.
dragonwriter 1396 days ago [-]
> Nearly every other aspect of how work gets done is unspecified
No, it's not, the whole classic litany of scrum rituals (“scrume events” in the guide’s language) is prescribed in the Guide.
> Two week increments, for example. I've heard so many people complain about scrum mandating two week increments, when it doesn't actually.
That’s strictly true, but somewhat misleading, as while it doesn't mandate two-week sprints specifically, the guide does specify that sprints are not more than one month. (And that they have “consistent duration throughout a development effort”, which is probably a more problematic command. But the most problematic is using synchronized iterations rather than flow for dev work, and locking the time cycle for product iterations to the time cycle for process improvement.)
> Or people complain about "velocity", and "story points" which are likewise not part of scrum at all
Yeah, they are an attempt (and, used as designed, probable the best attempt yet) to deal with a well-documented hard problem un software development which Scrum just assumes is, and requires to be, solved without really commenting on directly. I have far less complaints about them (except that people cargo cult them badly) than Scrum, which, while also subject to bad cargo-culting, has a lot of it's problems baked into the fundamental spec.
JoeAltmaier 1396 days ago [-]
They are certainly part of Scrum-master training. They're a widespread practice. At this point, they can be grouped as 'part of Scrum' with fair confidence, in any implementation you can point to.
Resorting to definitions is not helpful, when you work in a dysfunctional organization, and instituting Scrum was the root of the disfunction.
mindcrime 1396 days ago [-]
They are certainly part of Scrum-master training.
I am certified as a Professional Scrummaster, and none of those things were taught as part of any training I went through, nor were they mentioned on the certification test.
Referring to definitions is useful, when many people are misunderstanding the definition. If anything, we should be screaming from the hilltops "For the love of FSM, go read the Scrum Guide, and the Agile Manifesto, and show your managers and shitty Scrummasters what they're doing wrong." If we, as developers, are not willing to draw a line in the sand and take a stand sometimes, then what right do we have to complain? And if management won't listen to us on this, they aren't going to listen to us on anything else and we're back to "toxic management is the problem, not scrum."
JoeAltmaier 1396 days ago [-]
Or, not do Scrum. Do another process, like having an experienced team that respects the other team members to plan their time and prioritize tasks, with good communications between members of the team.
Looking at 'scrum master certification test questions' online I don't see anything about technical debt, variable-length time boxes, re-prioritizing work during a sprint etc.
A real and reasonable criticism of Scrum or Agile is, the structure is not helpful to the actual work. Sure, making a list of tasks is quite useful. But the time-boxing and task atomizing can dissect the work to the point of dysfunction.
If nobody is doing Scrum right, we're right on the edge of a No True Scotsman argument.
mindcrime 1396 days ago [-]
Or, not do Scrum. Do another process, like having an experienced team that respects the other team members to plan their time and prioritize tasks, with good communications between members of the team.
That seems orthogonal to the question of how desirable (or not) scrum is. You can have scrum (or not), and/or have "an experienced team that respects the other team members to plan their time and prioritize tasks" and shitty management is still going to wreck things.
A real and reasonable criticism of Scrum or Agile is, the structure is not helpful to the actual work.
I 100% agree that there are times when the structure imposed on a team in the name of Scrum (whether it's actually prescribed by Scrum or not) is harmful. Don't mistake what I'm saying here as a massive endorsement of Scrum. It's not actually my preferred methodology. But I do think Scrum can be useful to very many teams in very many situations, and I feel like a lot of the criticisms directed at scrum are somewhat misplaced.
If nobody is doing Scrum right, we're right on the edge of a No True Scotsman argument.
I think I get what you mean by that, and I probably agree to a point. But I don't think it's quite "No True Scotsman", as Scrum has an actual definition, to an extent that "true Scotsman" does not. But I'll buy the suggestion that "if everybody is doing it wrong, then there's something fundamentally wrong with the whole situation".
kevsim 1397 days ago [-]
This is something I think a lot about because I'm working for a small startup [0] building an issue tracker and trying to take on the likes of Jira. We discuss a lot about exactly how much scrum we should support "natively" in the tool (sprints, story points, etc.) because we've seen scrum go wrong and turn into a mess of micromanagement and misaligned incentives a number of times. At the moment we've opted to make it very un-scrum and our early adopters aren't complaining. Teams need to work hard to find a process that actually works for them - tools and scrum master trainings can't dictate that for them.
Once there was great scrum master, no managers, felt like a team, no missed sprints.
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.
1397 days ago [-]
mrich 1397 days ago [-]
As a manager you should think hard about what aspects of scrum are important to you and where you can let loose. This will heavily depend on the makeup of your team - how many experienced developers are there who don't need hand holding? How many of them will still deliver without some oversight? How many of them can mentor? How many inexperienced people do you have, how many will be onboarded in the next year? Things like that determine and change your development process.
MattGaiser 1397 days ago [-]
> what aspects of scrum are important to you and where you can let loose.
Scrum explicitly does not permit that. A criticism that didn't make it into that answer.
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.
1397 days ago [-]
tomohawk 1396 days ago [-]
The main problem I've seen with scrum is that everything can get put into the backlog, and the backlog becomes infinite.
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.
Fire-Dragon-DoL 1396 days ago [-]
Scrum has its flaws, but even though is marked as a "process framework" and the guide states you should evolve the process to fit your company (it is part of the agile movement), it's considered a big red flag diverging from it even a little, which completely invalidates the "people over processes" part of the manifesto.
stx 1397 days ago [-]
In my experience it has been that people expect scrum to be a magic bullet. Things are not going well... it will be better when we change to the new orgs process. Only the real reason its not going well is because of lack of planning and poorly written stories. The how you fix that is much more complicated.
mem0r1 1397 days ago [-]
I almost can't believe that it's 2020 and people are still disscussing or even worse "utilizing" Scrum. Pretty much all good and excellent Software engineers I know who had to deal with it at various companies hated it.
loopz 1397 days ago [-]
Easy: Is the output great engineering because of scrum, or despite it?
1397 days ago [-]
Yhippa 1397 days ago [-]
How about letting developers pick or come up with their preferred way of working instead of mandating Scrum?
kitotik 1397 days ago [-]
The only potential result of a competently run scrum process is exactly that - a process that was designed by the team.
If you are stuck in some weird cargo cult that doesn’t allow the team to iteratively change the process, you should call bullshit.
rightbyte 1397 days ago [-]
If scrum is any process designed by the team the term is worthless.
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.
kitotik 1396 days ago [-]
> If scrum is any process designed by the team the term is worthless.
SCRUM is a handful of tactics that a team can start off with to design and implement the “right” process for a given team. For example, I’ve been on several teams where through the use of retrospectives, daily stand ups were abandoned and replaced with other means to keep the team in sync.
> Sadly, scrum as I have seen it has been consultants preaching to the commoners how their rigid process is going to make them agile.
That sucks, but sadly this is the most common case. Very few organizations actually want agility, as they are culturally and practically top-down hierarchies that require command-and-control structures to function. These consultants are generally brought in by middle-management who are grasping at straws without any real buy in from the c-suite.
> 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.
I couldn’t disagree more. For “routine” work that is predictable, what value does agility provide? It’s either done correctly or not. Agility is only useful in dynamic environments when outcomes are hard to predict and there is limited prior art to reference.
mindcrime 1396 days ago [-]
Scrum prescribes very little. What parts would you want to change?
C1sc0cat 1397 days ago [-]
No and Yes
bJGVygG7MQVF8c 1396 days ago [-]
As a vendor of thought leadership, it's 100% in my interest to treat as exogenous the likelihood that my framework / best practice / etc will be implemented as I intend it to under ideal circumstances.
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.
blargmaster33 1394 days ago [-]
It's ALL ABOUT THE BACKLOG!
A properly groomed backlog with clear requirements/acceptance criterias and guidelines from a software architect will make scrum teams highly efficient!
Having the SA an the PO beeing 2-5 sprints ahead of the team creating a backlog that is ready for the team is a wonderful thing to behold.
A competent SA will with input from the team leader be able to estimate on the feature level allowing reasonable time estimates to be given to the management.
Grooming the backlog is a FULL TIME job.
awinter-py 1397 days ago [-]
or both
Rendered at 00:30:29 GMT+0000 (Coordinated Universal Time) with Vercel.
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.
They do have their benefits though, especially when well run. A team member may encounter something they're having difficulty with that another developer has encountered and solved in the past. You might want to share a problem you encountered or findings that are relevant to others.
I suppose that most of those things could just be done as a slack message. Sometimes I feel like a meeting helps ideas flow better though. There's been occasions where having an actual verbal conversation with the team has yielded better results than a slack conversation would've.
Either way, I've never had a huge issue with them, as long as standup is the start of my working day and not like 10 AM or something where I'm going to get interrupted.
IME this has been the biggest boon of standups. If they are kept short, and further conversation is done outside the meeting, they are a good way of matching your problems to other people on your team who may have a solution.
> Sometimes I feel like a meeting helps ideas flow better though.
I generally prefer when protracted conversation/problem solving is taken up between the concerned parties after the meeting, as otherwise the meeting drags on for everyone else who doesn't really need to know about your particular issue. But I do definitely agree with your assessment that "actual verbal conversation[s]" are better for me with regard to figuring a problem out.
But don’t you dare try to have an open discussion at a stand up meeting. The moment a useful discussion starts the scrum “master” will tell you to schedule a separate meeting to discuss it. Honestly, that just kills the flow of communication. I have never scheduled a separate meeting to continue the discussion. We just end standup, go back to our desks, and don’t talk to anyone.
Have you considered that if this didn't happen, it would be one of your co-workers on this thread, instead of you, and they'd be complaining that:
"Our scrum standups are supposed to be 15 minutes long, but they always take an hour or more, because people start going down some rabbit hole that doesn't concern half the team, and the scrum master won't politely interrupt and ask them to schedule a separate meeting. So much time has been wasted by this that it's unbelievable."
I have never scheduled a separate meeting to continue the discussion.
Why not?
That can be hard -- many / some people would be worried it'd be impolite to leave and in a way say "the things you're talking about aren't interesting to me".
And they'll stay and feel frustrated, in silence.
The result has worked almost exactly as intended: there's breathing room to discuss issues or ideas that come up in the course of conversation, but discipline around keeping those conversations brief enough to stay on the rails.
IMO at previous companies getting told "this isn't the time for that discussion" really frustrated me. As the OP stated, these conversations never happened, and it's healthier to allow some time and space for people to talk off-script when they're all meeting together.
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.
Some people can be brilliant at something while at the same time being toxic, with the toxicity ultimately winning. Kalanick at Uber might be an example.
https://en.wikipedia.org/wiki/Skunkworks_project
However, while the combination of autonomy and brilliant personality might be a prerequisite of outstanding success, I'm not yet convinced that it's an overwhelming indicator of it. I believe that a brilliant but toxic personality with autonomy can lead to an ultimately fatal instability.
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.
I studied engineering in university and profs had plenty of stories about bosses sending business analysts to look at similar projects, generating a time estimate from those projects, and then send that estimate to the engineers as their deadline for completing the project.
It being insane doesn't stop people.
So if you take an estimate and turn it into a deadline, in the perfect case, the deadlines can only be made 50% of the time.
Of course, in practice there is bias, there are things you forgot to include in the estimate.
Why don't you work that in to your process. It's called Agile for a reason.
Snark aside, that's the difficulty. The fix for everything in Agile is - instead of adopting some sensible practice (that could actually have been discussed in academic literature), have an argument about this with your team members, maybe they will get it.
It's a return to medieval times, where all the expertise was just the experience of the master.
Agile books are hilarious because they are trying to not be prescriptive about process, while being prescriptive about process. Within that dichotomy, is the assertion that you can create your own process. So, in fact, it is usually in those books that you can make your lists for your team.
In the end, Agile/Scrum are a bunch of hand-waving rituals, which is close to what ends up happening within every software development team everywhere anyway.
You could start with something suggested in a book. But you need to be ready to adjust your process when you identify when something is not working.
Still estimates are considered extremely important...
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.
Also, the meetings are a bit useless for the developers -- they can just chat directly instead, and look in Trello/sth to see what the others are doing.
So the for oneself most meaningful thing to do, during the meetings, is to impress the managers / others listening?
Since the meetings barely hello with getting real work done anyway
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.
If nobody can clearly tell you the end goal, your project management process is not the problem.
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.
But Jeffries didn't know how to get to the solution, i.e. what mechanism to make use of to get the computer to automatically solve Sudokus. So he wrote a few tests for the obvious things (like I/O and data structure) and then got stuck.
In contrast, Norvig knew considerably more CS and so knew that the right way to implement a solver is to use constraint propagation. So he did so in about a screen of Python code, all at once, job done.
The lesson of the story, as I read it, is that you can't iterate yourself out of a problem if you don't know how to attack it. If you're making a symbolic calculus program to solve integrals, it's unlikely that you can start off by going "okay, the integral of x is 1/2 x^2..." and somehow, through a series of small steps, end up at the Risch algorithm.
Similar arguments could probably be made about design. The less CRUD-y your application is, the more careful thinking is required. You have to know enough about the domain to know where the pitfalls are, and what the proper tools are.
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
But was is used today as "agile", "agile in business", agile in real use, and especially Scrum is not what the Manifesto asked for, quite of the opposite in the end.
That is even why some of the creators of the agile manifesto backed off when they saw what it became.
In fact, at the moment a company or a people say "we will create an agile team here" (maybe with a specific process scrum/...), you know that it is failed. It should be like "we have experienced software engineers, we trust them to be autonomous and smart enough to do it how they individually want to be the most efficient/adequate. Also they have responsibility and their opinion is taken into account for business decisions"
I've seen unreal Product Owner, it was so much pleasure to work with. Ever since I've found a joy in filling this niche if it was empty.
Yes, Agile Manifesto, Scrum is just some tools. It is like blaming axe [0] in Armenian cartoon.
[0] The Axe (1994), no speech https://www.youtube.com/watch?v=mA7H5KnyzJk
"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.
Managers are not friends. The moment I've said I'm leaving I become nothing. Time to learn.
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.
A philosophy that hinges around some ideal of how the world should be, rather than dealing with the world as it really is, often ends up being implemented as the exact opposite of that ideal. I can think of some historical parallels...
Call it "fraud SCRUM because it sells so well" or "lipstick SCRUM so we look cool" or "didn't read SCRUM but we have meetings and sprints". SCRUM works, maybe not for everyone but this denies us a chance.
So often it is PM who destroys project. I've seen good PMs. Two. Great guys. Great managers protects project from upper management and helps to resolve teams disputes. Others... They are like third wheel - developers like to build, business knows what to build, managers - exercise control.
Why discussion is about Scrum, not Scrum tools application and awful project management? The language is subverted, why do you help it?
How true! In my 30 years in the industry, I haven't experienced a single PM who was a net-positive (though I've heard that some are awesome), and some that simply made no positive contribution whatsoever.
I had one program manager who was awesome, even though we certainly didn't need a program manager (~40 person startup) per se. But she realized what was going on and then kept the PM (and everyone else) off my back so I could get the job done.
First and AFAIK only time in that company's history that a software project was delivered on-time.
Of course, after we shipped, it was all "congrats, but now you must do things properly like the rest of the company".
Not sure whether that's "sigh" or "LOL" or ¯\_(ツ)_/¯
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
Trust me, our team has tried, sadly the whole business wants to move to agile, and it’s shoved down your throat, wether you like it or not, or even regardless if it’s working for the team.
Eventually I gave up, the amount of energy wasted on these discussions is just not worth it. After a while you learn to say the right things, while also making sure you keep your technical freedom. Sometimes that meant not bringing up certain technical tasks, and overestimating others so that you have time for those other technical tasks.
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.
Give me a team of superstars and we'll deliver a half-finished framework for solving the general class of CRUD problems one could have, along with a bad implementation of a gherkin dialect.
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.
Some people like it, because it allowed them to push themselves on the rest of the team. But people who dont thrive in such constant dominance conflict end up resentful and helpless.
As an anecdote, I have an acquaintance who is a psychologist in silicon valley and he has mentioned he frequently works with patients suffering from mental health issues related to being subject to "agile" at work. I wish someone would do a proper study on this topic.
Personally, agile hasn't driven me to depression but it has made me target roles that avoid it at all cost. Life is too short and precious to suffer through a detailed status report meeting every.single.day.
I think that agile ignores human psychology. First, in management theory, intrising motivation happen when one has autonomy, mastery and purpose. Imo, plus accountability. Agile removes that from individual, but has some rhetoric that places it on the "team". But team is not person, it is set of people.
Second, it kind of assumes that people are socially perfect and everyone is kinda the same and its answer to any social human problem is "that is team dynamic or bad individual". It does not help to deal with predictable human imperfections, emotions and conflicts.
My guess is that SCRUM has a greater cognitive load than waterfall.
These days I sometimes decide not to work on the top priority issue right now, because I suspect it'll take a few hours of uninterrupted log file reading / debugging / thinking to fix, but the day already has three different meetings scheduled.
If that's the last issue in the open sprint, choosing to add another issue to the sprint while there's still an open one tends to be a no-go, or at least causes some discussion, especially if the sprint closes without the issue being closed.
Or sometimes I simply I don't feel like working on a particular issue right now. Maybe there's no rational reason for that. I have no problem overriding that impulse if I know somebody else (either a colleague or a customer) is blocked by the issue, but if it's a case of "we have happened to include issue A in the sprint, but not issue B", having to work on A instead of B against my preference causes unnecessary resentment.
In the teams where I liked to work, I felt control over order in which I do tasks and general shape of something I was responsible for. So I could make my own decisions, decisions that would be really mine.
So when there was mess or something was late, it was my fault. I was not due to other people forcing me do things their way and I did not had to fight about every single detail, just because college happen to be anxious or control freak.
For the record, I did not liked when leader had micromanagement/dictatorship tendencies either.
When you’re given the false hope optimization is possible, only to bump into 2-3 layers of middle management and just as many half-broken, Confluence spaces about the “one way of work” for the org... you just content yourself with features and tune out.
https://www.youtube.com/watch?v=hG4LH6P8Syk
When it is good, scrum powerlesness does not matter, maybe. But when it goes bad, it does.
Those are fundamentally different things.
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.
Scrum is missing a LOT of things, because it's very specifically intended to not be highly prescriptive. The whole idea is to iterate, use empirical feedback, and evolve your process to match your context.
Right near the beginning of the Scrum Guide it reads
Scrum is not a process, technique, or definitive method. Rather, it is a framework within which you can employ various processes and techniques. Scrum makes clear the relative efficacy of your product management and work techniques so that you can continuously improve the product, the team, and the working environment.
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.
[0] https://agilemanifesto.org/
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.
No, it's not, the whole classic litany of scrum rituals (“scrume events” in the guide’s language) is prescribed in the Guide.
> Two week increments, for example. I've heard so many people complain about scrum mandating two week increments, when it doesn't actually.
That’s strictly true, but somewhat misleading, as while it doesn't mandate two-week sprints specifically, the guide does specify that sprints are not more than one month. (And that they have “consistent duration throughout a development effort”, which is probably a more problematic command. But the most problematic is using synchronized iterations rather than flow for dev work, and locking the time cycle for product iterations to the time cycle for process improvement.)
> Or people complain about "velocity", and "story points" which are likewise not part of scrum at all
Yeah, they are an attempt (and, used as designed, probable the best attempt yet) to deal with a well-documented hard problem un software development which Scrum just assumes is, and requires to be, solved without really commenting on directly. I have far less complaints about them (except that people cargo cult them badly) than Scrum, which, while also subject to bad cargo-culting, has a lot of it's problems baked into the fundamental spec.
Resorting to definitions is not helpful, when you work in a dysfunctional organization, and instituting Scrum was the root of the disfunction.
I am certified as a Professional Scrummaster, and none of those things were taught as part of any training I went through, nor were they mentioned on the certification test.
Referring to definitions is useful, when many people are misunderstanding the definition. If anything, we should be screaming from the hilltops "For the love of FSM, go read the Scrum Guide, and the Agile Manifesto, and show your managers and shitty Scrummasters what they're doing wrong." If we, as developers, are not willing to draw a line in the sand and take a stand sometimes, then what right do we have to complain? And if management won't listen to us on this, they aren't going to listen to us on anything else and we're back to "toxic management is the problem, not scrum."
Looking at 'scrum master certification test questions' online I don't see anything about technical debt, variable-length time boxes, re-prioritizing work during a sprint etc.
A real and reasonable criticism of Scrum or Agile is, the structure is not helpful to the actual work. Sure, making a list of tasks is quite useful. But the time-boxing and task atomizing can dissect the work to the point of dysfunction.
If nobody is doing Scrum right, we're right on the edge of a No True Scotsman argument.
That seems orthogonal to the question of how desirable (or not) scrum is. You can have scrum (or not), and/or have "an experienced team that respects the other team members to plan their time and prioritize tasks" and shitty management is still going to wreck things.
A real and reasonable criticism of Scrum or Agile is, the structure is not helpful to the actual work.
I 100% agree that there are times when the structure imposed on a team in the name of Scrum (whether it's actually prescribed by Scrum or not) is harmful. Don't mistake what I'm saying here as a massive endorsement of Scrum. It's not actually my preferred methodology. But I do think Scrum can be useful to very many teams in very many situations, and I feel like a lot of the criticisms directed at scrum are somewhat misplaced.
If nobody is doing Scrum right, we're right on the edge of a No True Scotsman argument.
I think I get what you mean by that, and I probably agree to a point. But I don't think it's quite "No True Scotsman", as Scrum has an actual definition, to an extent that "true Scotsman" does not. But I'll buy the suggestion that "if everybody is doing it wrong, then there's something fundamentally wrong with the whole situation".
0: https://kitemaker.co
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.
SCRUM is a handful of tactics that a team can start off with to design and implement the “right” process for a given team. For example, I’ve been on several teams where through the use of retrospectives, daily stand ups were abandoned and replaced with other means to keep the team in sync.
> Sadly, scrum as I have seen it has been consultants preaching to the commoners how their rigid process is going to make them agile.
That sucks, but sadly this is the most common case. Very few organizations actually want agility, as they are culturally and practically top-down hierarchies that require command-and-control structures to function. These consultants are generally brought in by middle-management who are grasping at straws without any real buy in from the c-suite.
> 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.
I couldn’t disagree more. For “routine” work that is predictable, what value does agility provide? It’s either done correctly or not. Agility is only useful in dynamic environments when outcomes are hard to predict and there is limited prior art to reference.
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.
A properly groomed backlog with clear requirements/acceptance criterias and guidelines from a software architect will make scrum teams highly efficient!
Having the SA an the PO beeing 2-5 sprints ahead of the team creating a backlog that is ready for the team is a wonderful thing to behold.
A competent SA will with input from the team leader be able to estimate on the feature level allowing reasonable time estimates to be given to the management.
Grooming the backlog is a FULL TIME job.