Eight points for one team is two points for another team
lloydatkinson.net
lloydatkinson.net
What I can confidently state is that you must work the people and then the process to improve anything.
We need to stop adopting things just because other teams use them or because they are an "industry norm".
If we just truly kept true to the original agile manifesto, there would be amazing results everywhere.
Sadly most EMs have the training of a scrum master and never want to work to actually improve their process/discipline. The solution of getting rid of everything is a sound one because at least you can focus on the core agile ideas that make shipping software successful.
Upper management think Scrum is the only way to do software engineering. It’s a management cult.
If you're hiring someone who can...somehow make up enough content for 20 minutes about stalling binary search implementation your org is literally gonna turn into places that has tens of engineers and gets nothing done.
It essentially claims that "good agile" is Kanban, and Kanban is essentially abolishing of any forecasting in favor of actually doing the tasks, like the CPUs do when executing programs.
CPUs can only execute, what the instructions tell them to do—like a production line—and not solve / create something (new).
In Agile, "points" are just an abstraction around work to try to normalize it in the same way that every burger+fries combo should be roughly equivalent.
Kanban doesn't "fix" this -- it just changes the frame through which deadline-buzzards get to look at it.
If it reduces friction (as suggested) for both sides and everyone spends less time managing ceremonies as a result, then its a net win.
It’s certainly possible to estimate to a rough-order-of-magnitude but the problem is that the ROM quickly becomes a target, and then a commitment.
I have a couple of positions that I take.
First, the old adage still applies: “better, faster, cheaper - choose two”. If you set a deadline then you have to be willing to drop features or quality, because Brooks already demonstrated you can’t add resources after you start.
Second, if you do need to set a deadline then prioritise it, stick to it and celebrate it. Too many times deadlines are used as a whip, and my or my team have wiped themselves out to meet it, only to be told it wasn’t really needed. This is insanely demoralising and strongly affects productivity in the long term.
My personal (and unpopular) preference is to prioritise completion of stand-alone features rather than building to deadlines, which means you can release a product at almost any time with fewer, but better quality features. This approach has a demonstrable positive impact on the ROI but because it’s more complex and provides less short term certainty, it’s frowned upon.
And it’s well established that a rewrite is dangerous. The second system effect suggests that rewrites will always take much longer.
BTW, one indication that Scrum is bad is that nobody is doing its analogue (syncing everybody once a day?) in computing. Sane project management practices should be universal, and should also work for operating system schedulers.
In a recent previous thread here on HN I was roundly criticised for saying that due-date driven management is not effective, but that’s what scrum has become, and todays thread is exactly what I was thinking about.
My experience in a few businesses is that Scrum as it is generally practiced in industry has been an absolute disaster for productivity. Kanban is awesome because it doesn’t force us to spend hours and hours every week on ceremonies which don’t change the outcome one whit.
In my own business, after 2+ years of scrum - including hiring a CSM - I tossed out our entire process, and replaced it with backlog management and kanban boards. The only thing we kept was the (short) daily standup.
Productivity went through the roof for a number of reasons, not least of which was that because we could now spend the ceremony time working on actual code.
The killer is that if you try to tell people this, they think you’re inexperienced or did scrum wrong or you don’t know what you’re talking about. But to me Scrum is a two year black hole of stagnant product development that I will never get back.
Do you have any recommendations for scenarios where there are due dates? I work in a field that is largely focused around dates that aren't really negotiable; the school year ends and starts and school budgeting decisions have to be made at a certain time, so if we're rolling out certain features, they really do need to be available in, e.g., August when school starts.
I've been using a backlog-driven, priority-based approach in my own practice for the last 5+ years, which has been extremely successful at delivering products, but remarkably less successful politically. Non-technical management seems to have come to the conclusion that we ought to be able to accurately estimate the time it will take to build stuff, despite decades of evidence to the contrary. Loads of people argue that this is the "only way" but the processes commonly implemented are more about making management feel good than about actually getting work done. Unfortunately, I've found that making management feel good is often more important than actually doing the work.
All of that said, what I suggest is very boring: instead of spending the (significant) time estimating the effort required to implement each task, instead you should spend the time working with the client on prioritising the features, and internally spend time prioritising the decomposed tasks. What features/tasks absolutely must be ready by the deadline, and what can they live without? Can some features be shipped "incomplete" from your perspective? For example, can you deliver a veneer over a manual process on launch day, and automate the process later? If, upon inspection, a feature turns out to be extremely complex and time consuming, can it be re-prioritised? Can you spend time working on reducing the total amount of actual effort that's on the "critical path" to the deadline? Obviously some things just need to be done, but when you drill down you often find that a lot of time is spend on features and tasks that are not critical (by whatever definition you choose to use).
The idea is simply to make sure that the important stuff gets done first, so that you are in a position to launch as soon as possible. You can and should continue to work on the project after the launch day. This approach has many well-known carry-over benefits like the ability to start user and automated testing very early. Unfortunately, as mentioned, this can be very tricky to pull off politically, which I think is why it's not more common.
Once you get to this point then reporting upwards should be about features delivered, features we're working on now, and features that have not yet started. Somewhere in that list is a red line that says "we can launch now". You can directly measure velocity in terms of how many features are left until you are in the green.
I want to be clear that I think rough-order-of-magnitude estimates on work-in-progress and future work are perfectly fine and reasonable for internal use. What I am against is the use of deadlines and dates to manage the project as a whole. The goal is to deploy features, and that will take as long as it takes, and no amount of stomping of feet is going to change that, assuming you have a good team.
Ultimately what everyone wants is for the project to launch successfully. Software is very complex, and history (and theory) suggests that it is impossible to estimate accurately. The more time we spend on estimating, the less time we spend on working, and the more likely we are to miss our deadlines.
One final note. If you use JIRA, the backlog sucks (or at least it did when I abandoned it a few years ago). You need something that you can manipulate, that you can create different views, and that can collect information that helps you manage and prioritise it, since the backlog is orders of magnitude larger than the in-progress work and in my opinion is the actual problem that needs to be solved. I've personally used ProductBoard for many years but AirTable and even a spreadsheet is good.
I am keen to hear criticism and other ideas. My key thing is that saying "this feature should be finished by THIS DATE" is an absolute killer of productivity because of the amount of effort required to determine "THIS DATE" and the fact that the date is always wrong anyway.
This isn't even remotely true. Kanban establishes specific measures, including throughput, that, combined with statistical modeling, specifically allow for forecasting to be done.
Do you really think the car industry, where Kanban originates, doesn't care how many cars they're going to produce in a quarter, or whether they're ahead, behind, or on track on hitting their targets?
Come on.
The idea that "forecasting" and "agile" are somehow at odds with one another is a gross misunderstanding of both.
Edit: As an aside, that article's use of Google as somehow the paragon of software development superiority really dates it. Google is notorious, at this point, for being an unreliable software development organization. They fail to listen to their users by building features people don't want, canceling projects that vocal users do want, and shipping incredibly buggy products (Android 12, anyone?) All of this is, at least in part, caused by many of the problems the blog post highlights but claims have been resolved, including a lack of strategic cohesiveness and issues with building and maintaining staffing for projects that are no longer sexy.
That's interesting to me as I hadn't heard that about Kanban before. Do you have a particular reference in mind that you think describes this well?
Then you can measure throughput (number of stories per unit of time) and cycle time (amount of time a story takes from start to finish).
Using those measures you can forecast, with monte carlo simulation as a common method. Here's a book on the topic:
https://www.amazon.ca/Forecasting-Simulating-Software-Develo...
There's plenty of other resources about this if you bust out your google-fu.
This means understanding and adapting the process to your needs. Agree on your definition of done. Set boundaries for pointing. Prevent confusing or unfinished stories from being point. Communicate how you work to the greater org, and get buy in. Use retros to constantly iterate and improve your process.
Management needs to skill up.
Personally, I've found retros to be most important area for a manager to focus. They can be a wonderful source of discussion and improvement for the team, or one of the most boring hours of your week.
You didn't say exactly that, but that's kind of the undertone of what you wrote.
If you live in the US and you demand your right to a fair trial, well good on you. But if you live somewhere perhaps less committed to such a thing, making the demand doesn't mean anything other than you're naive and foolish.
So it goes in some companies as well. If they don't have the values the demand isn't you being courageous. It's you painting a target on your back.
Let's get one elephant out of the room out right away. Many in the #NoEstimates camp are speaking from the position of some enterprise context where the business technically has already built the right thing, they have revenue, aren't innovating much (by design), and as long as they keep the ship afloat and don't make too much of a mess of things, they're fine - or at least engineering isn't going to be the deal breaker.
Estimates or no-estimates in these context-- who cares. Literally anything you do on the engineering side means nothing to the upside of the specific product line you're working on, and if you look around you in these contexts, you'll find gross and massive inefficiencies abound and none will have anything to do with your dev process, agile, estimates, no estimates, what-have-you.
For the rest of us, you live and die by execution, which includes your ability to prioritize what you're delivering, all of which means nothing if you're not estimating - however indirectly or directly you are estimating.
It also means nothing if all your estimates are so totally wrong and not based in reality, as I mentioned a few times in the bullet points.
Being able to estimate, being able to market, being able to code — these are all competencies.
Once I got over the initial horror it actually worked out pretty well. I would keep a stack of trivial work on standby for any time I needed to show some board progress and then used the majority of my time to dig into whatever work looked most interesting.
Story points are only the beginning. They are an estimate which must be updated during the planning meeting. Our planning meetings for a team of fewer than 10 people took the better part of an entire workday -- 8 hours.
What we did during those meetings was pick apart the user stories into small developer tasks until there was no task larger than 3 story points on the board, ideally all of them one-pointers, with one point being an estimated 1 hour of work.
We also spent most of an entire day for each retro meeting.
Edit: Our definition of done was signed off by the QA Engineer.
I hesitate to play the "you're just using them wrong/misunderstanding them" card, but it's worth at least alluding to its existence. Like any other tool, story points are powerful and helpful in the hands of people who want to and know how to use them to improve things, and difficult or even destructive otherwise.
Here the thing: two teams may operate at completely different rates: One team (more experience devs with more mature technology) are going to be faster than a new team with new tech, even if they have the same number of devs. You can't just assume that both of them can do 25 story points of work every sprint. The teams can only go as fast as they can go. It's analogous to the fact that two different people have different rates of walking or running. You can't make them the same unless you are willing to lose efficiency of your fastest walkers/runners.
The fact that one team expresses the quantity of work they do (i.e., English vs. Metric) isn't important as long as they actually hit their estimates most of the time, and improve their estimation accuracy.
I.e., split and gather work so that you don't need to score them. Then you can still get some rough feel for capacity without the bother of sizing.
And if you do this, you shouldn't split hairs and be dogmatic.
If the people who started the computing revolution last century knew that their descendants would be attending daily standups and debating "story points", they'd never have done it--in fact, they'd have blocked it from happening in the first place.
But...Agile doesn't involve that. Even when the same words are used, they don't have the same meaning, often, and the substantive processes even within vaguely Scrum-ish methodologies vary widely.
There are exceptions, but in far too many companies AGILE has become a religion that slows the workforce down with high priests who insist that their ritualistic practices be followed and their tithes be paid =[
We should be fighting against the standardization of the industry because it allows more competition for wages.
On the other hand, damn near every company seems to only want to hire 'senior' developers who can deliver working software in spite of process, which I assume is somehow related to all the nonobvious process skills being commoditized.
Has it changed? The Manifesto[1] is still there, unmodified, to provide thoughts on what you need to consider if you are going to run a software project without managers.
> Fuck user stories, fuck sprints, fuck Jira, and fuck product management
That does not sound like Aglie, especially given that you specifically call out managers, which are incongruent with Agile. The top-down organization where process flows down from management at the top to the developers at the bottom that you speak of is what is colloquially known as 'Waterfall'. This 'Waterfall' organization structure is what many believe the Manifesto was written to counteract, so it is interesting that you’re now calling it Agile.
- The Agile Prayer
Agile is more like a checklist of things to remember if you're going to operate without managers. Like, stay in touch with the business people, keep your work available for other developers to see, work with people who can be motivated without a manager hovering over them, etc. All obvious when you think about what role managers fill and what you need to do if they're gone, but still a decent reminder if you're serious about going down that road.
It's not something you do, rather something you can think about if you've decided managers aren't the right fit for your project.
Ah, but you could say, "That's not Agile's fault that people don't live up to it," but in a sense, it is, because Agile did not bother to anticipate that people would fall off of the path. Agile has no orthodoxy. Agile does not suggest punishment for bringing up deadlines. This has allowed people to pick-and-choose.
"Not living up to Agile" is one of its principals: "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly." That's not what we're talking about, though.
> Agile did not bother to anticipate that people would fall off of the path.
This isn't a case of falling off the path, it's a case of not even being on the same planet. Agile is written about the things you need to think about if developers don't have managers overseeing a project. The OP was talking about what managers are doing. They are at completely different ends of the spectrum.
If you want to use a religious analogy, this is like there being a religious leader preaching about God and a group of people who believe God doesn't exist. Logically, you wouldn't lump them together. They would be seen as distinct groups with opposing thoughts. Exactly how we treat this situation in a religious context: For example, Christianity and atheism.
So, in the corporate world, pretty much Agile==Scrumfall (and SAFe). Executive management wouldn't have seen any benefit to Agile otherwise. The only reason why companies adopt Agile is because of the fine-grained measurement and control promised by Agile consultants.
Now get back to work on the stories planned for this sprint. You have sprint commitments to meet, and others in the release train are depending on those deliverables.
Probably not coincidentally, this was the only place I've worked where KPIs were truly a useful way of framing our place within the organization.
Product managers are often hired to be a cat's paw for an unsustainable and/or ineffective way of getting technical work done. This is what many businesses want when they hire into product, because this is a more convenient explanation for why things aren't better than any alternative (such as you're doing too much stuff, you're building the wrong things, etc.).
This selects for people with the skill and temperament to thrive in this role. Being a bullshit artist is a great fit. Being a pushover and repeating everything your stakeholders say is easy. Asking difficult questions and being a skeptic is hard and doesn't make you popular.
Now people get certifications in scrum dogma and claim we have to follow the one true way. Now it's entirely about managing people instead of about satisfying customers. That's why a bunch of folks left years ago to work on development as craft.
> managing people instead of about satisfying customers.
I wrote another article that somewhat alludes to this, it's linked at the start of this one. If I'm not helping people, either customers, or developers by making their jobs easier, then what exactly am I doing as a professional?
We can't say with a straight face that we expected IBM or Accenture like conpanies to move to an "agile" process.
And smal and/or smart conpanies were already doing "agile" without making manifesto and boasting it at every occasion. What's left is the middle ground wh
'll blindly follow any trend and get certifications to proudly have the buzzwords on their company site, and "agile" weren't for them either.
Technical excellence doesn't pay the bills.
Curious - what products do you pay for due to their technical excellence of their backend instead of the value they provide you directly?
I've started to form a belief[0] that large software projects in general are A Bad Idea. Whatever it is, if it requires more than a handful of people to build, it's probably for the greater good of everyone--the workers involved, the users, humanity in general, anyone-not-identifying-as-shareholders--that it not be done.
Software is the only thing I can think of where the input effort of creating it is completely divorced from the output work it can churn through. The right program at the right time, written in 10 minutes by just the right person, can save hundreds of years of otherwise manual labor.
There's a sort of sense that arithmetic got us out of the stone age, calculus fed the world, computer programming gave us the stars. That sort of power is far too important to imbue into corporations.
When you get a large group of people together, they start to think of themselves as Important. And when people think of themselves as Important, they start to think the work they do is Hard. And when they think the work they do is Hard, they start to think the software to help them do their work should be Complex. And none of it comes out of anything other than "we have a large group of people together."
Like, microkernel operating systems have a reputation for being slow based on early experiments with them from the 1980s. There are modern microkernel systems that are perfectly fast and efficient and yet people still think "monolith go brrrrrr" and not "all my software lives here" is the reason Linux is any good.
Like, I've seen people pitching blockchain-based solutions for municipal information and issue-reporting services, like anything beyond the most basic, not-completely-incompetent, traditional RDBMS is really necessary for such a project.
Like, there's a serious cohort of economists that think that the best way to handle social safety benefits is to just give them to everyone who asks, no questions asked, because otherwise the management of welfare benefits gets to be so expensive that it eclipses any potential savings against "fraud". And I'm inclined to believe them.
I see people talk about "there's no such thing as a 10x programmer". I think these people have been stuck in ossified institutions so long that they have no idea what it looks like to see a person fly. Cut away 90% of the currently employed software developers. Dissolve the Googles and Facebooks of the world. Don't replace them with anything. Leave us with the 10% of crafstpeople who can actually work through a problem on their own. And make them report directly to the C-suite. No more middle managers. No more grunt work of CRUD forms. If it can be done on paper than it's a waste of time to write software to do it.
[0] AKA this is a feeling, not something I've created a double-blind randomized trial to study, dear pedantic HN reader.
Setting aside the Linux kernel, this is how Unix itself works, and one of the reasons it was successful.
I don’t agree that we should shut down all the “1x” developers though. I think everyone deserves to love their work and people will excel when given the chance. But throwing them against a massive monolith that takes years to understand is dead certain to make them feel stupid and go slow.
Author here, this was one of the motivations for writing this and the other article linked at the start. I've seen agile actively harming maintenance and quality more times than I've seen it ever help maintenance or quality.
You know things are fucked up when you need to put technical debt, refactors, library updates, etc down as "stories" (erm hello, where is the customer story in "fix that giant performance TODO") instead of just doing them. Sure, we can just carry them out to avoid the wrath of the scrum master and co, but then you have to balance time between doing the stories, and fixing bugs.
I worked at a company where the scrum master told us that a story point had to be a fibonacci number. Has anyone heard of this?
The original Agile Manifesto demonstrates the collective wisdom of people who have written a lot of software. Note that the Agile Manifesto doesn't mention a certified scrum master, or any role similar to it. It says that business people and developers should work together. It does not say that a certified scrum master should leave the stand-up meeting every morning to spend an hour giving a status report to the CTO.It removes a lot of the granularity of pointing, and forces the larger points to grow very fast. You still have some nuance between 2, 3, and 5 pointers, but once you start getting past that the numbers jump to 8, 13, 21, very fast. You don't need to spend time with your team debating whether something is a 5, 6, 7, or 8 pointer, it's closer to a 5, or its closer to an 8, if it's higher than an 8 it jumps up to 13. Less time spent circling around an exact number and quicker to get to a "is big" "is medium" "is small" "is trivial" decision.
I would agree that in practice all of those anti-patterns related to story estimating/pointing can work against the values of the Agile Manifesto.
Anything else is "Fugayzi, fugazi. It's a whazy. It's a woozie. It's fairy dust."
If the only problem is deciding between a 1 or a 2 though, I'd just remove "1" from the list of options.
(My planning poker algorithm is:
1. Vote without discussion.
2. If the votes all agree, that's the number of story points. If the votes are within 1 of each other (1, 1, 2; 2, 3, 3; 8, 8, 13) then it's the highest (2, 3, 13).
3. If there isn't that much consensus, then someone with the lowest vote and highest vote complete the sentence "To do this task..."
4. GOTO 1)
This is unbounded, of course, and sometimes no consensus can be reached. That usually means more definition is needed, and you can take on a task to do that definition for the next planning meeting. When there is disagreement, it isn't always bad. Sometimes an old hat will say something is a 1, and the new person that just joined the team will say that it's a 13, and the senior person will say "To do this task, edit foo.yaml and commit it." and the junior person will say "To do this task, I need to set up my workstation, then build a test environment, then read all those getting started instructions, then get access to production, ..." and you'll realize "Oh shit we never had the setup onboarding meeting" and you can just do that. Whereas if you just said it was a 13 and assigned it to the junior engineer, they still wouldn't be onboarded after struggling through all of that on their own.
I don't want to sound like an agile advocate or anything, in fact I'm pretty disillusioned by agile, but I've used this before and don't have a big problem with it. Looking at story points over a period of time is good for taking on the right amount of work in any given cycle; if someone says "we need to launch this next week" and your team does 15 story points of work per week, and the project is 1000 story points, then you know that that can't happen. Numbers to prove it! Someone can work on reducing the scope in the meantime. I think people try to get way too much out of agile, like on day 1 setting launch dates for features a year out, and that will never happen. That is why people are disillusioned, "I set up a 6 hour sprint planning meeting and bought a JIRA license, and we still aren't launching 3 new features a month!" Yeah, the actual work is still time-consuming; moreso on a larger team with changing opinions and changing markets. So it goes!
That's enough.
I for reference, have multiple agile certifications and just don't understand.
Complexity points has value since they can be used in aggregate to estimate what a team is capable off, assuming the estimations on average are consistent between cycles.
If I'm going to be "held to account" based on my estimates, I will optimize for producing work that matches my (naive, uninformed, up-front) estimate, rather than producing the _right_ work. This will last for a few months, at which point I will realize I'm burned out, working inefficiently, and writing bad code, and I'll find a new job on a different team that doesn't treat its employees like train conductors.
And points do not stop anyone from holding you to account, if that is what they want to do.
Steady and accelerating are the good cases, slowing down leads to questions. "Why did we slow down?" "Oh, that task we gave a 1? Turned out it was actually huge because it involved X which none of us noticed or was more broken than we realized. Took up the entire time." Or "We brought two new people onboard and were spinning them up. They aren't productive yet and our experienced people were spending the time bringing them up to speed. We should get back to the normal flow in a few weeks." Or "We have no idea" which drives more questions. Or "We brought on two new people and spun them up, but now their estimate inputs are changing how our tasks are scored so it will take a bit to figure out our new baseline."
All of that assumes the team tries to be consistent in their scoring and is reasonably stable in its composition. If you're changing out team members frequently, then there is no value from points (because they won't be stable). If your team decides to fuck with it by rolling a die and using that for each one, then there is no value either.
When you change your processes in some way (and assuming a stable team and scoring), then you can also use the velocity over a series of sprints to evaluate the effectiveness of the change. If it hurts, you'll see a long term decline, and if it helps you'll probably see an initial decline (learning) and then improvement.