> This is not to say Agile itself is bad - it takes effort and skill to use it effectively but managers seem to be taking the easy way out to create a factory line kind of setup where random requirements keep getting thrown and every two weeks you are supposed to roll out _a_ solution.
Scrum has outmarketed "Agile", and swallowed it up wholesale. Agile was about putting people before process, Scrum is all process, no-wonder the people feel downtrodden.
> Scrum has outmarketed "Agile", and swallowed it up wholesale. Agile was about putting people before process, Scrum is all process, no-wonder the people feel downtrodden.
This.
I understand that some managers want graphs, points, velocity, etc. Those things makes it easy to point at something and tell the team to improve. A good (imo) manager on the other hand, would just ask the team how the sprint went and what problems needs solving.
I usually come back to my “products vs projects” division.
Projects are discrete work efforts with a specific business objective and an end date. They’re effectively waterfall, and managing a whole program with multiple work streams is at least possible via scrum (if you have the right feedback loops into the product team and execs). I suspect this is the kind of work people really hate. This is the kind of work consulting companies generally do.
Product development should be much more free form. The product manager should own P&L for the product (or at least some proxy) because it aligns incentives. The dev team need not be 100% utilized all the time as their ability to quickly and effectively develop functionality is valued above cost efficiency (because again, product owns P&L so no business case has to be made). You can then use the “extra” time to deal with tech debt or take on special projects.
The companies that really suck to work for are the ones that confuse the two. They are two different mindsets — one requires a developer who thrives on tight deadlines and can turn around functioning code and toss it over the fence, the other requires a more deliberate approach where doing things right preserves the ability to do things quickly. Put a project developer on a product they’ll be lost without the structure; put a product developer on a project team and they’ll quit within 6 months because they hate being micromanaged.
Yes I tell everyone who ll listen this distinction too. I've arrived in a project based financial institution. It boggles my mind the software mind set: get project "done" toss / handover to some poor bastard to struggle with. Repeat. I actually think handovers should be banned. They don't work.
I used to lament “they’re doing it wrong” but I’ve come around to the fact that sometimes, that op model really is best for the size and way the company operates. If they don’t have technology product management as a skill in-house, it’s a seriously hard capability to build. In those cases, being able to work with an experienced vendor is great — but usually requires either time-boxed T&M or a deliverable-based contract (which is effectively timeboxed to protect the consultant’s margin). So you need to do handovers as your MSP / internal IT may not have the expertise to execute every project, and those (expensive, specialized) resources need to go away after the project is done.
I understand what you are saying, but this is all internally built stuff. The slopey shouldered mentally breeds a "don't give a fuck" mentality around code, testability, ease of new releases etc. I'm used to eat your own dog food.
This crystallizes for me that I’ve been a product developer mostly living in a project world (even when nominally building products).
> the other requires a more deliberate approach where doing things right preserves the ability to do things quickly
Yes. There is a surprising nonlinearity of benefits to doing something properly.
It’s not about over-engineering to “best practices” or being a “cowboy coder” tuned only to your own preferences. These two are the Scylla and Charybdis of pursuing quality in software.
To me, Scrum is a sad story about how the road to hell is paved with good intentions.
Scrum does have a lot of processes and artifacts and things to measure. They all had a decent purpose: to give the product and project managers (Product Owner and Scrum Manager in Scrum parlance) information that allowed them to do their jobs more effectively. Story points and velocity estimates were supposed to drive decisions about what to build and when by giving the product manager some sort of signal they could use to decide things like, "Let's skip this feature; it's going to cost more than it's worth," or, "Let's push this bit a few weeks forward in the schedule, because it's looking like it's bigger and more likely to go quagmire on us than I had been hoping."
There was supposed to be an understanding that generating this signal would reduce the speed at which the development team could churn out features. (Of course it would; that time spent playing planning poker had to be taken from somewhere.) But this was understood to be worthwhile in the long run, in a, "Work smarter, not harder," sort of way.
On paper, it seems like a pretty good idea. The critical flaw, I think, is that, when you take a system that produces all those numbers, and even do something boneheaded like name one of them "velocity", and then drop that in the middle of a crowd of people who went to business school and have had heavily indoctrinated into Taylorist ways of thinking, well, it's like a will-o-the-wisp to them. They'll see something that looks bright and shiny, and follow it straight into deepest part of the swamp. And, since they're the manager, they'll be able to drag the whole team, or even the whole company, along with them when they do.
Years ago, I had an interesting "A Tale of Two Scrums" experience. I was on a product team that had been doing Scrum as their own internal thing for years. Quite successfully, too, everyone was happy, it was possibly the highest morale team I've ever been on. But then senior management decided they wanted the company to go Agile. So they brought in $FAMOUS_AGILE_CONSULTANT to deliver a week of workshops which was mandatory for all the developers and skipped by all the managers, including product managers. And then we had this very top-down, Taylorist, how-much-blood-can-we-squeeze-from-this-stone brand of Scrum rammed down our throats from above. Half the team left the company within 2 years. I found later that, not too long after I left, the company had subsequently divested of the product I worked on. While I was there, it was the market leader and cash cow.
Long story short, there's Scrum, and then there's Scrum. I can't tell you how much I loved doing Scrum, but I also can't tell you how much I hated doing Scrum.
I guess the real question is why the fuck are management courses still founded in Taylorism?
Taylorism was known to only work on short interventions at the time it was created, and it's known to create all sorts of problems (one being absolutely demotivating everybody).
You know that high you get when your software finally works, with all the little cogs churning away and producing something much bigger than any one of them as a system effect? That, but with people. Feeling powerful feels good.
> I guess the real question is why the fuck are management courses still founded in Taylorism?
im not sure if its just management courses, ive been under technical managers that think the same way... they like numbers and measurables... maybe to them its like code coverage and performance metrics... but with people...
The desire for metrics is also a major driver of surveillance capitalism and why every web site and app is now larded up with telemetry.
Some of surveillance capitalism is indeed about making the user the product, but a decent chunk of it is about people having metrics to show to people higher up the chain.
People who sell advertising need metrics to sell it. Managers need metrics to show the value of feature X or Y or the application in general. Companies need metrics to woo and placate investors. Investors need metrics to show to their investors/LPs. It goes all the way up the chain.
I'd say there is a general lust for metrics on the part of everyone who answers to anyone. Markets are not DAGs, but undirected graphs of power relationships, so everyone has a boss somewhere and thus everyone wants metrics.
In the late 90’s, one of my clients was an ultrasound company in Seattle. I was on a small software team of five or six competent engineers. We gelled as a team, embraced Kent Beck’s Extreme Programming (XP) philosophy, and really kicked ass.
We were also writing code in C++ to run on an ARM 7TDMI core embedded in a custom ASIC. We used the Metaware C++ compiler and JTAG based debug hardware from a German company whose name I’ve forgotten.
Good times. The client company was successful and was sold to Fujifilm about 20 years later for $950M.
Spot on - In my mind I use Agile and Scrum interchangeably because Scrum is what I see being used everywhere and it sure has swallowed Agile up it up like you said! It's too easy to throw scrum in - who doesn't like ready made processes that take minimal effort to overlay instead of integrate? Agile without scrum would require a deeper level of effort as it would first and foremost involve people. Much harder to think from people first standpoint than process first standpoint.
Scrum in of itself is not so much a deal, if it just provides a light framework/training wheels for companies transitioning to Agile. Start with 15 minute daily standups and 2 week sprints, for example, but if you work better with a twice-weekly standup and a 6 week sprint, fine.
Where it becomes a problem is where it's used to enforce underlying pathologies like micromanagement. But if your shop has a micromanagement problem, you'll be miserable, Scrum or no Scrum.
The reason people are hating scrum isn't because the simple scrum statement is simple, it's because a whole industry has been formed around advocating "true scrum" with consultants that fly in and give big meetings about how you can turn scrum into a tool for micromanagement.
Corporate suits eat that shit up. The value add of scrum, to them, is everything devs hate. They love the burn down charts, the timelines for features, the resource allocation, the ability to fly in and say "You are working on polish? WTH value add does that bring to the company? Dump it and do feature 123 instead!"
And, unfortunately, corporate suits tend to pay the bills.
I'm sure there are companies out there that don't fall into micromanagement shit, but I'm convinced it's an inevitability that any successful company will eventually turn into a feature factory hell hole.
Agree. Also tickets being units of work that you can assign "effort" points to and measure "velocity" with is the biggest load of shit I've ever come across. I'm surprised any developers buy it. I've been told "oh no effort is not time" me : "but you always says what's that in days?"
"No but we don't measure velocity like that"
Me internally "oh fuck right off"
Scrum doesn’t have velocity and burn-down charts. Those are add-on Agile extras. Scrum is simple, but it’s so annoying how people make everything so complicated. When I start working on something, we may have an idea of how much effort it is, but often you dig into the code and find gnarly tangles, or the model has more gotchas than people realize and the person doing the work is the one person who has the entire model loaded into their head at the moment. Yes, a manager might need to verify people are actually working, but if the manager is capable it shouldn’t require burn-down charts which can be full of inaccuracies. It often takes actual thinking to get real work done and micromanagers hovering about do not help with producing thoughtful work. Scrum just says to get some help from friends when you need it, communicate about what could make your job better in the next few weeks, and are we breaking things down into bite-size pieces or do people have unrealistic expectations?
Yeah that semantic debate about what exactly the story points mean, is my least favorite recurring stupid conversation, right after that angry debate of what exactly constitutes a "true" unit test, lol
We just had a talk from our master about how points are not days. Every developer ignored him and treated it as days because that was the signal. Management just made it official. Jira Align is rolled out and points are days. The master just threw up his hands and took his promotion under great duress.
Before that the master really tried to have meaningful retros. Now we type some things in a doc, everyone is silent, and the master has dropped any mention of follow up or takeaways.
...and this is a company with a good culture! I have done this dance at places where the culture was not good. As a person renowned in my circle for technical ability and productivity this was the only place where I couldn't get anything done and was removed from the account by the manager. Relief.
Scrum is a tool. It even has a tool built in to take care of these things, the retro. If you have someone on the team who is counting every point and dogmatically sitting on every metric that should be brought up in the retro as 'something that is not going well'. These tools are a way for devs to say 'here is how I am going to break this up and you have a limited amount of time so pick what you want'. The metrics are to help you realize you are doing an anti pattern. But if you force everyone to be good at them they will hide what is wrong.
One group I was in everything was a #1 priority. I had to sit the manager down in his office for a couple of hours and make him pick the priorities. It turns out he did not know what he really wanted, yet he wanted to micromanage everything. I had to show him that you have 4 devs and they can not work on 15 things at the same time 200% of the time. They have lives outside of work and you will get nothing done if they are jumping around at every whim you come up with. After that the team worked much better. I would at the start of each sprint make him pick what order he wants things in then the devs could come in and fix it up correctly.
Team management is totally on the table of 'things to work on' in scrum yet many PM's seem to forget that.
My new team has 3 15-30 min calls a day. I just joined this team so I am watching for now for a couple of sprints. But you can bet money on the fact I am bringing that up in a retro. You are distracting everyone at regular intervals and they can not get into anything because they are always prepping for your status meetings. You are leaving them basically 30% of their day to actually do anything related to the things you want status on.
A good PM who 'gets it' is great. One who strictly follows the metrics... yeah
If everything is a number one priority, nothing is.
I’ve literally told our internal users “if you can’t tell me which of these two things is more important to you, my team will work on them in whichever order is best for us.”
“If you could only have one and then the other, which would you pick to go first?” “But we have to have them both.” “Are they related/linked?” “No.” “Then which would you want first?” “I want them both.” “Thank you; I don’t need any more information from you.”
I get that. I have used that exact way of handling it. I was just tired of the 'everything is first' and got pissed off. To prove that they were being silly I picked something I knew for a fact would be a low priority and said 'this is going first. 'oh well not that' 'ahhhh you do know what order this is in compared to the others lets write that down'. I made it painful meeting wise for them to do that to me. Think in one meeting I walked in with a quarter and just started flipping for what went first. They did not like that either. Again 'ahhh you do know lets write that down'. The confusion comes from 'i want it done' to 'which one first'. Those are not the same thing. Something will go first. Either you pick it or I do. If I pick you may not like the answer.
Ah yes, that conversation. Here's the list of things on the road map. Which ones do you want to bump to next quarter/year in order to do this new priority? "None" is only an option if you can somehow retroactively hire another dev 90 days ago.
in my team we don't micromanage, however I agree that some scrum events can be adjusted a bit. For example the sprint reviews don't make much sense if you can deliver any time you want, and we do. It's probably just a way to wrap a bunch of work we did and show it to keep everyone on the same page about what's happening.
Daily also don't make sense, because the team has several major tracks in parallel and I can't really contribute to what others are doing, unless I decide to put my work aside and/or overwork.
Why this? My guess is that it's more convenient for a manager to have a more consistent view of what's happening. On the other hands there are team members that like to hear what's happening besides their own work, and such meetings give them that opportunity.
The luck we have are the retrospective meetings: one of the most efficient ways to actually make actionable things. This meetung I would never cancel, because it has nothing to do with the sprint but with the teamwork, workload, etc.
The issue with all "things" is the ability of people to be able to adapt it to the own workflow. It takes balls and experience.
> ...provides a light framework/training wheels... Start with 15 minute daily standups and 2 week sprints, for example, but if you work better with a twice-weekly standup and a 6 week sprint, fine.
training wheels are the perfect word for it, because people and management get used to it, and now cant ride without them, so now you have entire orgs running in training wheels smh
Daily standups, weekly retros and weekly 1-on-1:s. Those are the ones that bother me the most, the micromanagement around planning, I can deal with. But the creepiness of these other vague "Hey, I'm your friend, we can just talk" type of meetings are too much for me. And this trap of "giving feedback" and whenever you do, you get punished and marked for no promotion, immediately, it's just loyalty checks masked as something else "this meeting is for you" uhmm, can I just go back to work please?
Stand-ups can be a drag. My last stand-ups were literally 3-5 minutes, which I attribute to everyone working on long-running project where we all either knew what "Today I'll be fooing the bar" meant or knew it wasn't important to know. And we were very good about mentioning but not discussing problems during that meeting; they'd be dealt with "off-line" (so to speak).
Retrospectives can also be good when they're focused on how to improve processes (including Agile's). If it's just a venting session, that can become demoralizing, even caustic. There's also value in not having certain people in the room, so they can't get defensive or cause people to clam up.
This is almost certainly due to poor facilitation. That is to say, whoever is facilitating this meeting is either afraid to push back or else thinks that this is how it should be.
Convince the 6 developers that they don't need more than 30s each during the "tech only" standup. Get the facilitator to aggressively chop long discussions (clarifying questions can be fine; discussions and debates are not). At least, move long discussions to the end of the standup so that people who aren't relevant and who don't care can leave.
Initially, my team's standups (I think 4 devs at the time) would be 15-20 minutes; we're now (6 devs) down to 10-15 minutes, probably 10s more than 15s.
I can't imagine there being much value from a daily, 30-minute, whole-team meeting with multiple stakeholders. Developers should perhaps talk to specific stakeholders... but those conversations should be focused on specific stories and probably should be done in much smaller groups. Heck, it would be fine to have 30 minutes of scheduled "office hours" time where specific developers can talk to specific stakeholders about specific stories.
Bring this up in retrospective. Point out that (nominally) 12.5% of every day (and likely more than that) is being spent on these meetings. Ask about what value people see in these long meetings and if there's a better way to achieve that value. Brainstorm other approaches and get the team to commit to experimentation.
Try, you know, actually standing up. On your feet. That's where the name comes from and it's to encourage people to be brief.
The central evil is letting anyone control the standup that isn't directly participating in the work output of the team.
Because then it's easy for that person to forget that stand-ups have no independent value -- their only value is in making the other work go faster. And should be calibrated to maximize that.
Which is why you get the "We standup because we have to standup" shops.
I knew one company where the standups were getting so bad, the managers solution was to have everybody in a plank position for the meeting. Meeting time got short real fast.
Dont go. Seriously. When they ask why just say 'I do not contribute and am in the way there'. One place I worked it took them 4 months to realize I was not in the 1-2 hour meeting every other day. It took them another year to realize most of the people on that call should not be there. The managers are confusing their status meetings with yours and now they are one in the same. That is why they are long and disorganized.
I knew a particular self-important PM that had follow up point-poker meetings that easily went into the three hour range. She was very useless, but it was almost like going to her own little tea-party with her little dolls that she fed fake tea.
Apologies for the gender connotations, but I have no better analogy. It was a little girl playing with her little dolls.
Oh man I feel for you. At the startup I'm currently at, it's all remote and we have daily stand-ups that are only 15 mins but usually they finish in 2. Not sure if it's useful or not since you could probably express the same info in a message but it's nice to see people I suppose.
I'm in a distributed team where the daily standups are optional. Almost everyone join every day and say it is good to see the others at least for a short while every day
I despised daily stands in person, but love them on a remote team.
We've decide to drop the status updates from standups to focus solely on discussing things of interest to the team - blockers, processes, issues, announcements, icebreakers, etc.
I'm going to be that guy: They say it is good to see others or they say what is expected of them? Is like the conversation yesterday about leaving interviews. You don't say Person was is shit and an asshole but you say a better opportunity came up. Heck, even during job interviews, you don't answer 'why work here' with 'money' but 'looking for a new challenge, or interesting work or whatnot'
As someone who enjoys sharing a similar sense of humour and outlook as the people I work with, I'm personally more than happy to spend 15 minutes goofing around before a day of knuckling down and getting shit done. YMMV
Yeah, and that feeling of someone oversharing something both irrelevant and boring, while you already have an overfull short term memory from your own work, AND being forced to pretend to pay attention, it's just so painful.
In my team, we have a fairly strict process, it's been refined over time by the team. We change little things every sprint.
We have checklists/agendas for what to discuss and we go through them fast. We update the agendas when we need to. We don't tolerate diversions from the meeting topic for more than a couple of exchanges and anyone can ask to move the meeting on/back on-topic at any time with a funny "safe word". Our stand-ups focus on "what needs to be organised, who needs to talk to whom, what work/bugs have come in from other teams?" not "what has everyone done". Our planning is split into two or three (so it's more meetings, but they're shorter - one focuses just on bugs and is only for a subset of the team). Our sprint review is open to the entire product and engineering teams and we go to theirs. They're actual demos; the last one we did was interactive.
In my opinion, Scrum can work. It takes time to find the combination of people, agenda items and venues to get the best work done in each "ritual". If you didn't have Scrum, you'd still have to create _some_ proces to follow; you'd do most if not all the meeting functions, but perhaps at a different rhythm. The scrum system is pretty minimal and under-describe exactly because you can mould its it to fit your team. If your Scrum implementation isn't working for your team, make your Scrum master change it or take on that role. Any other mindset will cause the process to fail.
It's probably not the right process for systems which include hardware or other long-lifecycle subsystems. It's best when the whole team can focus on specific goals, and a small number of goals.
If you have multiple concurrent work streams (e.g. "epics", and you try to give chunks of work from each epic to individual developers, you'll fall into the trap of "feature farming". It's much more effective and interesting when the team is focused on a single feature and works together on it.
The backlog needs to be about the _product_ not "work to be done by the team". If you have multiple work streams/epics consider making specific, short-lived, smaller teams and splitting their stand-ups and retros out.
Keep changing it to suit your product needs and fit the teams around that.
Scrum has outmarketed "Agile", and swallowed it up wholesale. Agile was about putting people before process, Scrum is all process, no-wonder the people feel downtrodden.