Story points are not what agile is about. Agile has a plain-English meaning, but a lot of grifters and consultants are “slideware agilists” and miss the point.
Here’s the thing: process heavy agile is an antipattern. If you’re ducking around with Jira all day, that’s an antipattern.
The key question is: are you releasing working software regularly, are your incidents / bugs down or flat, and — the key! — are you responsive to your business needs?
Put another way, would the budget holders say “tech just ducks around” or say “our tech team is 👍”?
Someone will moan at this point, “this doesn’t work in regulated institutions”. Yes it does. There are plenty of case studies. It should be noted that every industry needs a certain amount of documentation. But overdoing it is a problem.
Personally I just track teams’ DORA metrics, especially the “big 2”, releases (normalized per 10 people) and bugs.
I don’t even care what the numbers are at a point in time. What I want to see is positive jaws: releases up and bugs down over time (or flat if the team is already performing near industry highs).
I’ve found this to be a great way to sniff out BS and “slideware agile”. It’s not even super secret or anything, Jez Humble and the Poppendiecks have spoken about this for ages. The biggest issue in this is getting budget-holder buy in.
Bugs? Don't you mean missed requirements with points 🤔
The regulation in my company to release anything to production requires multiple days of emails, forms, confluence release page, jira fix version, jira release story, approvals, bribing a sysadmin to what is ultimately just changing a version on kubernetes customization yaml and it auto deploys. Then we get to do that 5+ times a week since we have 30 apps to manage for one team.
Lots of orgs are like this, its definitely not great.
This is why the positive jaws (releases up, bugs down) is so powerful. They can be gamed all right, but gaming them over time and ensuring they travel in the right direction is much harder.
It’s actually interesting to see IT managers’ reactions when they realise they’ll be measured with these metrics *over time*. Huge cultural shift.
In order to achieve a measure of the complexity of the task that is presented to you, you ask questions and clarify, schedule exploratory work in order to prepare the ticket and be sure you understand the whole picture. This is an exercise that is not a slow down but a good push forward as those questions would have to be cleared during the production phase. In which you would answer one question then find another one then find another one. Making the whole process go further in time.
This is just preparation so you know how hard it'll be (not saying you are fully right in that but the more people, the closer to reality).
> you ask questions and clarify, schedule exploratory work in order to prepare the ticket and be sure you understand the whole picture
But you'd do the same steps if you were simply assigned the task, no? This is talking about doing 20-30% of the work and then putting the item back on the backlog.
That might be the right thing to do, but it probably would be right only if priorities had shifted around (i.e. other priorities are now higher, or the improved understanding of this task makes it lower priority).
That said I do think it's good to break work up into smaller discrete units (to a point), but that's usually always good, you wouldn't do that only to improve estimates.
> but the more people, the closer to reality
I do think this levels off quickly after the first few people you ask. So continuing to add more people, especially in a meeting setting, will add so much time that it becomes counterproductive quickly.
One the first point:
As a senior/staff/lead, yes I will, even without estimates. But estimates are a side effect that is helping maintain the relationship with management. For some obscur (;)) reasons, people tend to want to manage resources and costs. As such, they like to budget projects and to have a ratio on business value vs costs... Having these estimates on the complexity of a task is helping the business prioritize the work so the salaries are less at risk. It's not really beneficial for the task to do, it is for the business that requires the task to do. As you do this in your process you standardize the process of refining the work to do while keeping business in the loop. Win-win. Estimating a ticket when everything is clear is taking like 2 minutes. And getting used to the scale of points is generally done in less than 3 or 4 sessions (about 2h).
As a junior/intermediate, this isn't an easy task to do. And taking the habit to break down your ticket isn't something easy. Also because of the lack of experience. So, the point would be to use the process to get the dev hooked up on the refinement.
Now all that is in an ideal situation: business is benevolent. If the intention of the business is to be healthy, there is no problem with what I said above. But if the company's intents are to overwhelm the devs, everything will go sh*t anyway.
On your second point: yes totally. I like teams to be 5 to 6 devs at most. You generally cap the benefits of the number at 4-5.
Also it blinds managers and teams on the real way to make work. You can do all the ceremony, if you never hone your craft and solve important design questions.. then your app will just be shit.
It's like the adeptus mechanicus in 40k. They perform the rituals, and some of them might actually work, but they don't understand why it works or why the rituals were developed in the first place.
sounds like it, are they also evangelists about the whole thing ? because I've seen people get sour or angry that you don't want to praise their new version of the agile process (meanwhile bugs are accumulating faster than we can fix them but that's not the goal right ?)
And then assign some of those to someone else who doesn't know anything about that functionality, and thus block the other dev that's working the other tickets.
This has turned a legacy interface rewrite I've been assigned into a multiple month fiasco. The other dev has no experience in the legacy code language, and is barely proficient in the target one. Given the easiest tasks, told what to do, how to do it, still can't deliver anything on time. Ok now I'm just venting....
“Would you say this task is closer to building a bike or building an airplane?”
“uhhh, I’m defining content models using qualitative input translated from stakeholders’ feelings, not solving a math-based engineering problem.”
I’m surprised product gives engineering that much credit at your company.
At my company it’s “here’s the design. I moved the pixels on the screen with ease. You can get this done in a week right?”
Answer is simple: don't estimate. Count stories instead. In retrospectives, identify stories that took longer than you'd have liked and ask how you could have split or derisked them. Turns out counting stories is just as good at predicting how long work will take as estimating sizes, because people are bad at foreseeing complexity.
Yeah, a team I had that used Scrum moved pretty quickly to replace story points with T-shirt sizing after a couple of retros, followed a few retros later by just not assigning complexity scores at all. Instead we broke up stories that seemed too large.
If you can't make do with "this is what we should focus on this week, and this is some stuff that's also available if we run out", you're doing something wrong.
This is how we did work when I worked in a biotech lab. We are going to culture 6 batches of cells and run 15 assays for quality. This did not take the entire week because we knew something would break and require rework or if that did not happen, we could use the time for maintenance on equipment or ordering supplies.
We also had weekly Operations (Sprint) planning and Lessons Learned meetings, as well as daily what am I doing today meetings. Who knew we were agile! We used white/chalk boards for managing the tasks, but that was before the availability of Jire/GitLab, but these tools would have been great.
> Modern “agile” has seemingly almost nothing in common with the original Manifesto for Agile Software Development
That's because of the fundamental struggle of "control" between management and developers.
A manager, sensibly, wants predictable timelines, well prepared plans that are followed without unexpected deviation, and an IT department that builds the solutions they ask for.
A developer, on the other hand, knows that much of the work is fundamentally unpredictable (if i knew how long investigating and fixing this bug would take that would imply i already know how to fix it. And if i knew this bug was going to happen i would've taken steps to avoid it), that requirements can and will change, and that sometimes what is asked for is a few orders of magnitude more difficult than a similar but slightly different solution.
The ideal solution is for the manager and the team to work closely together and communicate the difficulties and solve problems together. But whenever this isn't the case, the natural response from management is to want more control, rather than more cooperation and freedom.
Agile is saying "give all control away to the developer team, and you will learn to trust them to do what's right". But without the trust there in the first place, no manager is going to agree to cede control. Leading to the all-to-familiar sight of managers implementing every part of agile/scrum **except** for the fundamental part of ceding control.
This actually goes both ways if done right. The developers have to cede control to management on the priority of identified work items, weather they are known entities, or a vague story (i.e. upgrading to the newest version of .Net). But all parties have to agree on the priority of the work items for the next cycle. Getting everyone to agree on a numbered list of work items is a pain. People like to make "buckets" but that never works. In the end though the pain of actually numbering each work item in terms of priority will make everyone argue the work for the next work cycle and that's what you want, a compromise with hearing arguments ;)
Trust is a two-way street if your developers trust management (and requirements, test and operations teams) and you have good communication then you can build software incrementally that is easy to test and deploy as well as does what the user wants. Whatever framework you use Scrum, Kanban, Extreme or Rapid will work.
If you do not have trust, developers will build shadow schedules (the actual schedule developers use), and management will blame the developers for being lazy. Development, Test, Operations, System Analysts (requirements) and Management will all blame one or more of the other for failed schedules and software that does not meet the needs of the users, whatever Agile/Agilefall framework is used.
I would disagree that a manager sensibly wants predictable timeliness, as if that is there fundamental need. The fundamental need is to create the most business value as possible, as quickly as possible. That being difficult, and also management usually having their incentives poorly aligned with the business, management opts instead to maximize other things, such as control and stability, but these substituted goals are quite often counterproductive to the real goal of creating business value.
A bit of a dramatic comparison there. I don't think you can compare a social organisation theory, that has killed millions to a software development process that has annoyed a few devs.
The only issue I've had with it is when it's used as time instead of complexity. It's hard to explain to less technical management why a 3 point task didn't take exactly 3 days.
> The only issue I've had with it is when it's used as time instead of complexity.
Everytime I read this, I'll post this article from one of the people who started this whole "story points" thing:
> In XP, stories were originally estimated in time: the time it would take to implement the story. We quickly went to what we called “Ideal Days”, which was informally described as how long it would take a pair to do it if the bastards would just leave you alone. We multiplied Ideal Days by a “load factor” to convert to actual implementation time. Load factor tended to be about three: three real days to get an Ideal Day’s work done.
https://ronjeffries.com/articles/019-01ff/story-points/Index.html
SPs *are* a measurement of time, always have been. This whole "complexity, not time" fairy tale has (in my opinion) been invented for two reasons:
1. Because people (quite rightly) caught on to the ruse and started treating SPs proportional to time, so a new layer of obfuscation was needed.
2. The bigger the story, the more uncertainty will creep in (generally). But "uncertainty" sounds bad, so people started saying "complexity" to make it sound more professional.
But it's all smoke and mirrors. If devs could just be honest, they'd say, “look, we don't really know, can we build something smaller first?” But it seems that's often seen as losing face, hence the culture of obfuscation.
That's why I much prefer the 1/TFB/NFC scale (if you can create the required culture of honesty):
1. 1 Story Point
2. Too Fucking Big
3. No Fucking Clue
(https://estimation.lunarlogic.io/ has a nice overview (while also trying to sell you the card deck …))
I would add the Developers have the right to refuse to take on the task if there is not enough information for the necessary estimate of time/complexity. Also, if a task changes or an unknown/undocumented component (e.g., the data is not available in the database, so we have to create it and add it) appears during development the task is pushed back on the backlog instead of working over the weekend because someone promised something that did not have sufficient investigation.
If you have good tasks you literally do not need any estimation points, sizes or hours. Just measure velocity by tasks done per time period and will be pretty accurate over time for your planning needs.
But you need to be disciplined to have good tasks then and no 'too fucking big but don't worry' bullshit.
That is interesting, and I like the honesty scale lol
>But it's all smoke and mirrors. If devs could just be honest, they'd say, “look, we don't really know, can we build something smaller first?” But it seems that's often seen as losing face, hence the culture of obfuscation.
I would love to be able to try that. I guess it makes sense that it was originally a measurement of time, but I'm glad I'm not alone in not being able to see the future. I've been driving my managers crazy for years because the best time estimate I can give them is "probably not long" and "probably not short".
I did pull off a miracle once though. I estimated 3 days on a task and when I was asked why it was 5 days to deliver I said I put in 3 days of work across those 5 days. But that's because I have a lot of other responsibilities at work and also around that time in particular we had too many meetings. In any case, I gave an accurate estimate.
We talked about it and were about to switch to shirt sizes but then for some reason we were steered back to points. I said clearly that as long as we are describing complexity that's ok
The only useful thing to learn is that if we had unions we could actually have some authority to manager ourselves correctly.
Oh maybe that plus time-and-a-half for any on-call duties or when your working hours go beyond 50.
>Oh maybe that plus time-and-a-half for any on-call duties or when your working hours go beyond 50.
I'm on-call in an EU member country and we already have this. I think the US is sorely behind on worker rights.
That said, in my humble opinion US tech companies would first outsource all of their labor before allowing the work-obsessed mentality to change. We're already seeing it with the way H1B1 visas are abused by some big companies.
actually thats also why we do the retros. Being able to grief and receive empathy from coworkers improves mood by 10% (number made up but proof is somewhere in the morivational interviewing books)
Sadly I'm currently under a lead that thinks his job is to be PM he hasn't touched code in over a year by now I think, I honestly got really pissed when the PM asked me if the lead approved the new programmer to do a PR, let's ignore how she makes missions unintuitive to follow through and often forgets to get critical requirements written, I have been giving the points on the missions for even before the new lead was put over us, he doesn't do PRs he doesn't rain management back on anything, he's away atm and we had a long meeting about a mission that could take weeks and he wasn't even mentioned so what exactly does that tell us.
So no retro isn't a place to share our grief anymore because the lead is against us so it's just shit "the testing have been delayed for 3 days cause the PM couldn't decide about letting a mission upload or not I think that's a problem"
I hope I stay in the industry long enough to see us all re-learn the reason for why communication-heavy paradigms like Agile were invented to begin with. Quasi-Kanban can seem like a breath of fresh air for IC productivity - No meetings! Just do your work! - until you realize that your team regularly produces monster PRs because nobody ever refined tasks or management is unaware of potential dev rebellions against the product ecosystem and its constraints because nobody talks to one another.
None of those things are addressed by sprint meetings where managers ask pointless questions about story points for an hour straight.
If you're suffering from a communication breakdown, set up communication channels, not jira boards.
Never fails that somebody will inject strawman arguments based on a bad place they work at. If you're suffering from bloviating workers, set up cadence standards.
Yeah, that person just has a fucked up organization to think you had to work in agile to make productive software. Acting as if consultants loudly shoving how they work down our throats means it applies to every industry (hint it doesn't).
Companies have been working on complex products that require multiple technical teams to work in conjunction since the late 1800s at least.
These problems aren't new (capital dictating how labor works).
When a measure becomes a Target, it ceases to become a good measure.
If you come up with some new project management system called FLIP-FLOP, very quickly whatever advantages it provides are going to be eaten up by the weekly meetings to discuss how many flips you plan to execute during this cycle and your annual performance review will be based on those numbers.
This is not a problem with the system itself, except in so far as it fails to understand the motivations and pressures of the organization running the system.
Hey, we heard about this flip-flop system of yours, are you willing to provide a paid mandatory consultancy services on how to use it efficiently in our company?
Sorry, /u/amakai. HR jumping in here. We can't hire /u/Coffee_Ops to implement our FLIP-FLOP system because as of this morning all candidates for new positions must have at least 3-5 years experience working in Flip flop driven environments.
Sorry, but we've just read an article about how Flip-Flop is highly inflexible and very outdated, and are looking into Flip-Flop Scrum variety instead.
A flop is defined as slang for a failure.
So, what if we flip a flop?
Introducing: **FLOP-FLIP**, the answer to flip flop’s failures. My team and I believe that by taking a **top down** approach on flops, we’re able to produce **synergy** between the flippity flips in order to maximize team productivity and leading to a better success rate. Many believe that **flip flop is dead** the truth is, in today’s Data and AI-Driven Web Applications and Dynamic Systems (**DADWADS** for short) flip flopping doesn’t cut it anymore. Instead of holding to your flops, join us in our upcoming seminar where we teach you how to flip the flops and get you back on track to meet your goals.
Hi can you tell me more about FLIP FLOP. Someone mentioned it when we were playing golf. It isn't on the current Gartner Quadrant???? Can I pay you `LARGE_INTEGER` money to help me tell my arse from my elbow????
Agile is just like communism. If it doesn’t work it’s because it wasn’t done correctly.
It can’t possibly be that the idea is fundamentally flawed due to an idealized assumption of how human beings interact with each other……
It feels like Agile has become a cult. We must worship the good word of Agile... praise to thee!
No seriously we spend more time talking about Agile than just doing the damn work.
Ever since I've started working in an Agile organization, I feel my brain slowly rotting away. Story. Story.... Story? Yep Story.
I miss the days of just working on a damn project from beginning to end for months without interruption, dsu, retro, planning,... oh worked on this small piece of this small component? Gosh you probably sure would like to see jt through huh? Well... someone else picked up the next Story so... go do something else insignificantly small for 2 days... then you know... pick up a new story.
Yup, 90 percent of companies I have been with just do waterfall but worse wasting everyone’s time with points, retros, planning, standouts which daily go over an hour, etc.
I try to avoid orgs that do "agile" these days. It generally means a low trust environment and managers who can't or won't understand that metrics are different from real work.
Agile seems to be a game that's played so that managers, executives and developers all feel vaguely in control of their common endeavour. But it's just a distraction.
Nobody will ever give you the best work of your career wrapped up as a "user story".
The headline fooled me at first but this is a really good article that goes into how Agile has been frequently mis-applied by many people from the beginning.
90 Comments
pxm7@reddit
Sqirril@reddit
pxm7@reddit
cheezballs@reddit
HolyPommeDeTerre@reddit
mpyne@reddit
HolyPommeDeTerre@reddit
agumonkey@reddit
Hargbarglin@reddit
agumonkey@reddit
yojimbo_beta@reddit
FrozenOx@reddit
kroboz@reddit
Equivalent_Air8717@reddit
hippydipster@reddit
bobaduk@reddit
mpyne@reddit
bobaduk@reddit
tofagerl@reddit
Groundbreaking-Fish6@reddit
mpyne@reddit
asphias@reddit
dcoolidge@reddit
Groundbreaking-Fish6@reddit
hippydipster@reddit
tofagerl@reddit
awood20@reddit
-grok@reddit
awood20@reddit
anzu_embroidery@reddit
alternatex0@reddit
TomWithTime@reddit
wldmr@reddit
Groundbreaking-Fish6@reddit
46516481168158431985@reddit
hippydipster@reddit
TomWithTime@reddit
pjmlp@reddit
hippydipster@reddit
46516481168158431985@reddit
TomWithTime@reddit
alternatex0@reddit
teslas_love_pigeon@reddit
alternatex0@reddit
GoTheFuckToBed@reddit
gilady089@reddit
SKabanov@reddit
funciton@reddit
SKabanov@reddit
funciton@reddit
teslas_love_pigeon@reddit
programming-ModTeam@reddit
Coffee_Ops@reddit
amakai@reddit
sponge62@reddit
amakai@reddit
0x53r3n17y@reddit
amakai@reddit
cimeran@reddit
rhavenn@reddit
dcoolidge@reddit
hans_l@reddit
amakai@reddit
estecoza@reddit
Worth_Trust_3825@reddit
narcisd@reddit
agumonkey@reddit
yojimbo_beta@reddit
amp108@reddit
hippydipster@reddit
CactusOnFire@reddit
savage_slurpie@reddit
Icy-Coconut9385@reddit
Ok_Biscotti4586@reddit
BlueGoliath@reddit
RChrisCoble@reddit
Abject-Kitchen3198@reddit
RChrisCoble@reddit
khnorgaard@reddit
RChrisCoble@reddit
khnorgaard@reddit
RChrisCoble@reddit
Liru@reddit
dasdull@reddit
khnorgaard@reddit
Big_Combination9890@reddit
gimmeslack12@reddit
rashnull@reddit
yojimbo_beta@reddit
mpyne@reddit