https://agilemanifesto.org/principles.html
It's common in corporate implementations of Agile (tm) but it isn't actually some commandment or prescribed feature of Agile itself. It's actually prescribed by Scrum:
> The Daily Scrum is a 15-minute event for the Developers of the Scrum Team
The business doesn't actually need a daily update. They think they do because they dont want to give you the ability to deliver anything.
Business demands process for people in functions to follow. Scrum outlines meetings for programmers to attend, and specific process outputs like user stories to produce and close. Scrum is agile in business because business cannot do agile.
I personally prefer Kanban. The sprint is not a useful deadline for me so I want to ignore it.
Personally I find it more useful to organize things around useful product milestones that are actually usable and demo-able. Those might take a week, or three weeks, but probably not two months because that's a long time to go without a demo and getting feedback. Sticking to a rigid 2-week sprint with an expectation of demo-able progress after each sprint doesn't feel particularly realistic or useful to me.
The business needs to know when something will be done as they need to make promises to customers. The business also needs to know when things will be done as that is a proxy for cost - they need to make sure they are not spending more creating a thing than it will deliver (this is a hard problem as some sales will not happen until it is done and there is typically a competitor customers could go with). That is nearly impossible to say how long engineering will take doesn't mean we don't need to know how long it will take!
We could also get into the theory of whether it is actually possible to say how long software will take at all. Business might bevroutineky asking for the impossible using the wrong methodology for what they think they want
Trying to estimate when software is finished is tantamount to asking when the last light will be turned off forever in the warehouse.
I keep trying to tell PMs that around the release date is when developers are the most busy, including afterwards. It's not some magic deadline after which developers are no longer needed.
There isn't really any such thing as "doing Agile", it isn't a prescribed process to follow.
And saying that you use Agile instead of Scrum but dislike the invasive status meetings isn't actually congruent with the actual definitions of Agile or Scrum.
On daily standups, from he manifesto:
> Business people and developers must work together daily throughout the project.
> The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
The "standup" theatrical part isn't in it, but that begs for daily meetings in the same physical place really.
Also...no. Verbal communication isn't effective or efficient. It's fast and natural, and perhaps comfortable to many.
In our current corporate environment, effectiveness (providing the right info in the right form) and efficiency (minimizing back and forth) will probably be better achieved with documents and open chat with all the parties involved, even if (in particular if?) it means slower throughput and more deliberate communication.
This is all there is to Scrum, if it's not here it's not part of it: https://scrumguides.org/scrum-guide.html
It's like calling the electoral college part of democracy. Than just a choice one place made, it's not intrinsic.
I find it very useful for allowing everyone on the team to have a general idea what everyone else is working on. You can call out to ask for help at any time [1]. But having a 15 minute meeting each day to make sure everyone has a view of all the pieces in movement is handy.
[1] Though the standup does give a place for people that aren't comfortable calling out when they're having issues.. to do so because it's expected there.
In my experience, standups are the worst places for such people. If they aren't comfortable calling out when they're having issues, they're even less comfortable calling out that they're having issues in front of the entire class.
What would you prefer besides agile?
I had a conversation with a young devTM who was arguing that estimating is hard and always inaccurate so we shouldn’t estimate. Everyone should just work on things until they are done. He argued this earnestly and didn’t recognize that there are opportunity costs and conflicting priorities and the need to choose what to do. He earnestly argued that every single user story should be worked on in order of entry until it was completed. It would have been precious how clueless this suggestion was if he didn’t spent 20-40 minutes a week arguing this as an explanation for why his items weren’t done and why he was civil disobediencing to refuse to estimate or report time on tasks.
Plenty of learned people have made defenses for having no estimates. If you want to make the opposite claim, you don't need to use a junior dev as a strawman.
For simple activities you can get by with no estimates but with dependencies estimates become more and more necessary.
Beyond that, you’re metagaming and that is going to end up either not being worth the energy invested or a net negative. I say energy not time because there are only so many niggling arguments you can have with coworkers before they push you into traffic. Each petty little argument that could have been about something more important just runs down the clock.
I don’t think you need precise estimation down to the hour, but knowing if someone can do 4 things in a sprint or just 1 is really important because people have interdependencies.
I don’t think I’ve ever had arguments about estimates and it’s usually a really quick exercise of “I think this is a couple days” and others saying “ok.”
A big difference for what?
Usually, when someone insists on getting estimates, that's my way to make sure that they really need it. besides, it also helps making an estimate that won't be useless in the context of the decision to be made.
The lesson I learned from asking that is 1) many people ask for estimates without a clue about what they'll do with the info, and 2) when a decision actually needs to be made, the actual question is never "will it take 1 or 10 days", but rather "will that project be done by regulatory limit", or "will it cost 50k or 5 millions". And for the 2nd point, sizing every small task and adding up usually compounds uncertainty in unpredictable ways.
For projects it’s almost always a budget issue “how much money and time does it need?” And that’s important because, like money is hard to get and $1 is different than $2M. I think the time is usually related to money due to revenue and costs and whatnot.
My example was about estimating “how long to add a revert button to 5 pages” and that requires “db crud to revert stuff” so how long the latter takes affects when the former can start and if they can both make it into the same sprint. Etc etc
I've never been in a situation where adding db crud was its own user story. Usually, we group this and the button (and the metrics necessary to trask feature use) in a single item, and pair people so it can be shipped in one go.
And on a larger team, a lot of these little things that need to be done could just be tasks rolled up into a maintenance story.
Of course when I was on a team doing Kanban none of this bullshit mattered. You just put it at the top of the backlog and it got done. Quick win, instant gratification, next story please.
And that right there is one of the biggest reasons Scrum is showing its age. It came into a world where quarterly milestones were the only time you found out how fucked the project is, and only then if you had a good bullshit detector. Otherwise it would be next quarter when you figured it out. It pushed that world down to two week resolution, one month to see past the BS. But it struggles to make good on reducing past 2 weeks. One week has more overhead, and forget about anything shorter than that.
Also I've never encountered anyone who followed Ken's advice to run sprints from Wednesday to Wednesday, so we always get the worst version of Scrum.
I have personally only ever had success with estimates that were "is this a project, or is this a task that belongs to a project". Perhaps stretching to t-shirt sizing of S, M and L. Anything beyond that, say, comparing two projects to be able to prioritize and see the opportunity cost etc etc is a fool's errand.
From The Black Swan by Nassim Taleb:
[Critics say that] the maps we had were better than having no maps. [...] This is the strangest of errors.
I know few people who would board a plane heading for La Guardia airport in New York City with a pilot who was using a map of Atlanta’s airport “because there is nothing else.”
I’m a fan of Taleb, but also a fan of using good maps. Note that Taleb isn’t advocating no maps at all, just that it’s stupid to use the wrong map just because it exists.
I agree that I’d rather have no estimate than a bad estimate, but it’s not like those are the only two options. I want a good estimate or at least a useful estimate over nothing or bad.
It is, however, possible to provide more information than "whatever" about how long it will take to achieve a goal. I have had goals I've worked on that were summarized with things like
- Could take anywhere between 2 days and 2 weeks, depending on factors
- Has an external dependency on X, and we don't have any insight into when X will be available
- May have other external dependencies, but we won't know until we're a few days into the work
- Not sure yet what the complexity of using <this API we need> is, so we'll need to check back in with more information once we have some time to experiment with it
- Expectation is about 5 days, on this, but it could be as short as 1.5, and could be as long as 3 weeks, depending on some factors
All of those things are more information than you had before, and allow the people that make decisions (which may be you and your team, or may be someone higher up the chain) to make _better_ decisions (or at least, better informed decisions)
And if you're working on something that you literally have no information on what's required for it, what the complexities might be, what the unknowns might be, etc... then perhaps the task you should be working on is "Identifying the work required to achieve <goal>", not "<goal>".
Unless you are working on ChatGPT-6, i assure you, you can definitely estimate how long things will take. your estimates will not be perfect, but they will be good approximations for guiding development.
Even OpenAI by now probably is pretty good at estimating how long the next ChatGPT version will take to develop, since they've done it 4-5 times already.
Alway always distrust someone who says "we are doing things that have never been done before". At the very bleeding edge (OpenAI, SpaceX), you are iterating on something that has been done many times before, but with a small innovation.
If it is not the first time, then you already have the code and hence the time it takes is 0.
There are cases where code is similar to code you've written before or you cannot just copy the old one due to licensing constraints. In this case estimation is easy, somewhere between an hour to a day or two.
Anything larger can be broken down to hour to day or two chunks since it has been done before.
All great, except this last case simply doesn't exist for the type of work that I do. And that is true for many people, software is extremely unpredictable because the stuff you need to build on top of might as well be quicksand.
"never done before" in my experience usually translates to "this combination of things doesn't have precedence internally [to the team or company], so I have to figure out how to glue all of these parts I don't understand together".
Like, the constant micromanagement and process lawyers pushing you down makes me misarable.
At least with classic project processes you'd have some oversight plan to follow.