"Then build it, however long it takes." (from the referenced article)
This is always my favorite fantasy. No one would have issues with "Agile" if you had unlimited time and money...but that's not how the world works. Hence why you break everything up into smaller chunks. It gives you clearly defined guardrails so that projects don't spiral out of control. EDIT: AND the people funding said projects know where there money is going. That's important.
The best effects I've seen from agile practices have been getting everyone to frequently think about deadline/feature trade-offs, reducing the occurrence of surprise bad news. I'm sure this is possible without "agile", but it's a thing I've seen it aid with.
The worst is probably standups-gone-wrong. There's little more demoralizing than a 20-person 3-team standup where you couldn't possibly care about what anyone says (because it's irrelevant to you) except three or four people, and you already know what they're going to say because you all, you know, talk, and then also having to turn yesterday's work into some epic (LOL) tale of adventure and adversity because your manager's in the meeting and that's the kind of dumb-shit tone they've set for it ("now—justify why I should continue paying you" with pointed, bordering-on-hostile follow-up questions to anyone without a sufficiently-convincing theatrical performance) and you'd like to keep your job. Starting every day with a half-hour of that shit. JFC.
But, I'm pretty sure, overall, agile is one of those things where most places that it works, any halfway-reasonable system would have worked just as well, and places where it doesn't, no system was going to work.
> and then also having to turn yesterday's work into some epic (LOL) tale of adventure and adversity because your manager's in the meeting
I find myself going over what I’m going to say in my head so it sounds good when it gets to my turn. I then end up not paying any attention to what anyone else is saying.
Yeah I wish more people would just say "I'm working on the same thing I was yesterday, no blockers, just need a few more days" and legitimize that if that's what's actually happening
I’m not sure why weekly status meetings lost favor.
Meet for 1hr every week as a team, and go over what everyone is working on and see how we’re progressing, and forecast where you should be by the next week.
The moment a developer feels they may not be able to deliver what was expected by next week’s status meeting, they share that with the team in whatever asynchronous communication tool your team uses, whether it’s chat, email, etc.
Regular problems and communications are raised in the same group chat/group email.
It doesn’t matter how small the daily standup is. It could be 5 minutes. But it’s a daily context switching exercise. I think it’s far better to have a single weekly, but longer meeting, so there’s only 1 context switch in the entire week.
At most places I’ve worked, long standups turn into “watch somebody else use Jira” meetings that all participants ignore until they hear their names. Not a great use of anybody’s time.
2. Those participants are not good employees then and should be told to pay attention or face further action. Meetings are for everyone to get on the same page, I’ve had too many engineers who think they have better things to do then implement things wrong or ask questions we covered in the meeting. Not something I’ll deal with anymore.
If one of ten employees isn't paying attention in a meeting, good chance it's the employee's fault. If most of the employees in a meeting aren't paying attention, it's probably the manager's/meeting-runner's fault. In between those, it might take some digging to figure out who needs to adjust to fix the problem.
When I’ve experienced this, I’ve availed myself of my personal favorite cargo cult rule: if you’re not getting value out of a meeting, you can leave.
Cargo culted from Urban Airship, and almost all of their meeting rules have been well received several places I’ve introduced them. Although admittedly in my experience this particular rule is best invoked with some extra social subtlety.
The best daily standups I ever had went like this:
Everybody is physically standing up, in a place where there are no computers.
Going around the circle, everybody answers three questions:
1. What did you do yesterday?
2. What will do you today?
3. Any blockers?
Any long discussions were tabled until the standup was finished. It took about 5 minutes to get through a team of 6, and was a great way to kick off the workday. On Zoom, you can't get quite the same kind of effect. But you could still keep it short, and you could leave your ticket-board out of the meeting.
I find that the no-Jira standup is better, because it makes people more honest about what they've actually been doing. They don't feel the pressure to fit some kind of Jira narrative, and will instead just talk freely about whatever's on their mind. Much better from a team collaboration perspective.
“Good standup” also surfaces what people are working on because it might be important for the rest of the team to know for innumerable good reasons. It can serve as an opportunity for many-birds-one-stone, or even as an opportunity to interrupt work that doesn’t need to be done because it’s redundant to other efforts or because other efforts made it moot.
But yeah, you won’t get that from standups where people aren’t invested in what others say they’re working on. That’s just people blabbing for a (hopefully short) ritual time.
Because everyone may not be available all the time except standup when all hands are on the deck. Or maybe the discussion is better done face to face. Or maybe the issue happened just before standup and the timings aligned with standup. Or any of the myriad reasons. The example also doesn't preclude raising issues outside of standup.
In the few cases those need some synchronisation, further discussion and knowledge-sharing across everyone in the team, it's a time set for that to happen.
Anything else can be discussed asynchronous, when the need for some synchronisation happens the stand-up is a good way to tackle it in a iterative way. Everyone knows what to expect.
By the way I'm not disagreeing with you, my current team (and the best teams I've worked with) don't need a daily stand-up, just a recurring time slot available for a synch time when people feel the need. People can show up when they want.
"Anything to bring up on those blockers, any help needed? No, ok, next: anything you want to bring up in the work in progress? Ok. Any further topics? By the way, if these topics are not relevant to you, you're free to go".
> I’m not sure why weekly status meetings lost favor.
Likely because, at least in my experience, they suffer the same problem as daily meetings: They provide no value. If you aren't already in the know about status before the meeting comes around, you didn't care about it in the first place and won't magically start to care when the meeting is in progress.
Those who have meetings for the sake of process adhere to daily status meetings because that is what the process literature suggested to them. Anyone who questions that further questions what is to be gained by having them at all, leaving little in the way of middle ground.
I've seen 1hr 11am weekly status meetings turn into "does anyone have a 1pm?" as Sr managers drill into every developer over the minutia of their status reports. Single handedly the most unbearable meeting series I've ever attended.
At least standups have structure and they are "supposed to be short", which helps a lot in keeping managers nitpicking at a minimum. Open ended 'status meetings' are horrible. A weekly 1 hr "standup" with a "no managers are allowed to speak", "stick to what you did, what you'll do, what are you stuck on and need help", isn't that bad, but you have to have structure.
Plus, if you are doing "Scrum", in a retro you should be able to suggest just having a "mid point" sprint review and change the process. I realize that's easier said then done, but its a good smell test on your org's attitude towards their process. Just make the suggestion and from the reaction you can tell if you can change the process like you are "supposed to".
As far as I know, there's no such role as "manager" in a Scrum team.
The Scrum way of working is a joy, which I have gotten to experience in my career just once. Practically it also seems very difficult for an organization to support, at least many have failed.
Scrum teams need to be autonomous, or the process becomes torture. Scrum as a process is rather simple, but the context is exactly a team working on their own. SAFe and such seem more like consultant slideware to me .
> Meet for 1hr every week as a team, and go over what everyone is working on and see how we’re progressing, and forecast where you should be by the next week.
So you're spending longer and getting less accurate results?
> The moment a developer feels they may not be able to deliver what was expected by next week’s status meeting, they share that with the team in whatever asynchronous communication tool your team uses, whether it’s chat, email, etc.
What prods them to think about that though? Often there's no clear threshold, and if you're supposed to keep it on your mind continuously then that's taking away from your capacity to think about what you're building. Having that daily sync point to take stock is very useful.
> It doesn’t matter how small the daily standup is. It could be 5 minutes. But it’s a daily context switching exercise. I think it’s far better to have a single weekly, but longer meeting, so there’s only 1 context switch in the entire week.
I mean hopefully you're switching out of work context when you go home or go to lunch. It's a tradeoff, but a few minutes a day isn't so intrusive IME.
Weekly isn't terrible, but I'd look at it from the other side: how long is it ok to be blocked for before you want to make sure you remember to raise things? A day works best IME. Maybe even twice daily would be better.
> I mean hopefully you're switching out of work context when you go home or go to lunch. It's a tradeoff, but a few minutes a day isn't so intrusive IME.
I don't think that is what was meant by context switch persay. It's like reading a fiction book, the context is the story. If you put that down, you might have to come back and re-read the last few pages to remember where you were exactly.
Worse yet for meetings, personally, about 15 minutes before I have to stop doing mostly anything so that I'm not too into it to then be late. About 5 minutes before I literally do stop everything otherwise I'll get into something and look back at the clock and it'll be 3 minutes past the hour.
A productivity hack I'm trying is to set an alarm for a few minutes before a meeting so I can do this more reliably without so much of a context switch.
All in all, given about 10 minutes before the meeting it is intentionally doing little so you can click that button on time, and then there is the time needed to get back into your work (most literature says it takes about 20 minutes to regain programming context), any meeting costs about 30 minutes of context switch overhead. It's a lot of time given a 8 hour work day.
You don’t wait for the meeting to raise things. You raise them when they happen. We have enough async communication tools that you can raise issues without having to wait for a meeting, and yet without disturbing someone who may be focused on something specific.
Really easy to thrash at something for days though thinking you are ‘almost there’. And someone else on the team might be able to help either directly or help you think of the solution if you just spoke out loud with the team sharing information.
You hit the nail on the head here. The whole standup process is extremely degrading. I don't think I'd ever work at another company that does a daily standup, the most I can take is 3x/week - and ideally as short as possible.
I suspect it depends a lot on the standup. My favorite place I worked had a great one. 10-15 minutes every morning, a brisk and helpful way to get focused, line up the help you needed, and kick off the day. I miss it deeply.
Conversely, I did a project once where we had not a single stand-up in 9 months. CEO would come up with some designs, I'd asynchronously comment on them with questions or concerns, then slice the designs into tickets that'd I'd pump good amounts of context and detail into, estimate and prioritize, then chuck my engineering team at them. We'd all asynchronously work on them. If they had questions, they'd slack me. This across five timezones.
Once or twice we'd have a miss on a ticket probably because I didn't define it well enough, but I'd just point out the issues in code review and they'd rewrite as needed. Oh well.
Meanwhile we all have a phenomenal quality of life because our entire day schedule is set on our terms. And we delivered a whole ass SaaS product from scratch in like 9 months for around 2,500 engineering hours if my brief math is right so the founders were happy.
2500 hours in 9 months could be two developers logging hours on the project. The project may have had stretches when dependencies limited the amount of work that could be done, and often one assumes at least an hour of non-billable time lost to miscellaneous business shit, per IC, per day.
The rest of the team (not logging engineering hours) may have included a (probably part-time) designer and likely some kind of project manager (likely also part-time—that is, managing 2+ projects at once for different clients).
7 (billable, on average) hours * 47 weeks (assuming 25 weekdays lost to holidays, sick days, and vacation, over a year) * 5 weekdays only yields 1,645 hours per worker per year, anyway. Divide by four, times three, to get ~9 months, and 2500 hours just looks like two full-timers on the project, really, if we're talking billable hours, but that's also (it reads like) not counting support roles and non-dev contributors like design or PM or maybe testers. Or it might be one full-time and two half-time devs, or whatever. I'd guess not more than four developers contributing significant time, anyway, based on the numbers and with fairly pessimistic assumptions for how many hours could be logged a week, and maybe as few as two.
I'm rough on the math cause I don't have the billing sheets in front of me, but the other person was pretty close.
The team I managed was me, functioning as frontend lead / architect / engineering manager as well as individual contributor. I then had three junior / early mid-level frontend engineers working with me.
I was pulling 40-60 hour weeks (contract so I didn't mind, just meant more money), the other devs were between 10-40 depending on how much work I could lay out in a sprint. Timezones were Taiwan, somewhere in Europe can't exactly recall, NYC, and California iirc.
That accounts for the frontend. There was a data system that was mostly built when I showed up, by one full time engineer at the startup. So that would be another 40 x 4 x 9 engineering hours on whatever he was working on in the meantime.
Then there was an API that would middleman requests to the data system and build out models and handle customer accounts and shopping carts and other data adjacent requests. That was one full time backend engineer over whom I didn't have responsibility, so add another 40 x 4 x 9 for that.
Finally, the designer was just the CEO. He would draw things up on figma and I'd slice them into frontend tickets. Now that I think about it I think the API engineer was consulting the same designs as he built out the API, I'm not remembering exactly.
So technically my original estimate is just for the frontend, it cost more when considering the whole system.
We "released" every merge into the main branch, internally. The CEO would constantly be giving feedback. It caused some friction occasionally, the classic "right the alignment is slightly off but what do you think about the actual interaction" type shoulder bumps, nothing major. Good feedback loop that basically daily aligned where I should be directing frontend priority.
There was a major customer facing release where a couple core customers were brought off the no code platform onto the new system, that cooked for about two weeks while we collected feedback and engineered against it, then another major release where I took advantage of the respite to do a major rewrite of the naively implemented request management system and fixed up some auth stuff, then another big release and then everyone else is brought over.
I still work a couple hours a week on the projecy but no longer as a leader. Looks like releases are still just kinda whenever, which I think is fine. There are "sprints" and have been the entire time but always quite informal.
I think a lot of this is just personality driven. I don't find meetings to be a way to get focused or a way to "kick off the day"; indeed, I always need a break afterward. Yes, this applies to a good 10-15 minute standup. And I don't really know what people mean when they say things like "line up the help you need". Why would I wait until a meeting the next morning to reach out to relevant people for help?
However, I recognize that lots of people don't feel the way I feel about any of this.
> Why would I wait until a meeting the next morning to reach out to relevant people for help?
It's hard to notice you're stuck when you're stuck. For a lot of programming problems putting your head down and ploughing through is the right approach - but you do need to come up for air occasionally. And if you need help then it can be hard to ask without feeling like you're interrupting someone else's work, so having a regular point where everyone's already not going to be in the middle of deep work is useful.
Again, I recognize that this is a "to each their own" situation, but I don't relate to this at all. I know when I'm stuck and I know who to ask (or who to ask who I should ask) and I have good asynchronous communication tools where I can ask people things without immediately interrupting them.
A lot of people believe they know the optimal time to reach out. But with my manager hat on, it's also true that a lot of people wait well beyond what's optimal for the organization. Things that can get in the way include pride, anxiety, laziness, a tendency to procrastinate, underestimating the resources available, and overestimating the cost of interruption, and underestimating the cost of delay. Maybe you are the rare sort of person who is perfectly calibrated. But if so, know that it's rare.
No, I'm not that rare sort of person. But it also isn't in the organization's best interest to force everyone into a single style of work, rather than supporting people in their own preferred style of work. That's why management is hard! If it were as easy as "having a status update meeting every morning is the optimal process for everyone", we could pay managers a lot less :)
I think there's conflict between "own preferred style of work" and what's effective for a given team. If there's a team of people who are, say, doing fine communicating only via pull request, then I wouldn't mess with them. But if somebody of those habits wanted to join a team that was into pairing and a faster release cycle, then I would suggest that new person look elsewhere. So although I don't think it's in the best interests for a large org to force everybody to work similarly, I do think it's in an org's interests to support teams finding an effective joint work style, even if that means a given individual might not find it optimum or might even have to find something else to do.
For what it's worth, treating my social anxiety made a big difference for me in this. A bad meeting is still draining, but good ones can be positive and energizing.
> Why would I wait until a meeting the next morning to reach out to relevant people for help?
Having a specific time for it makes it easier for people to do. It normalizes it, so it lowers the bar to ask for help. Also, note that this comes after a discussion of what people are working on for the day. So it's natural to say "Looks like I'll be getting into the foobar system today; who worked on that most recently?" And it's also natural for people offer help without being asked, so that lowers the help bar futher.
See, I used to think like this, that I have social anxiety. But as I've grown older and participated in more kinds of social situations over the years, I've learned that I don't, actually, have social anxiety problems; I love socializing, I think even more than average (the pandemic social starvation taught me this lesson).
What I have is a personality, which means that I have a set of preferences for my interactions, just like everyone else. It's fine that some people prefer group meetings, and it's fine that I prefer documents, chats, and 1:1s. We're just different people with different personalities. What I don't like is the group-meeting-preferrers seeming to believe that their preference is normal and my preference is aberrant. I find that condescending. I'm happy to accommodate other peoples' preferences, but I don't need to change my own preferences to align with theirs in order to do so.
> Having a specific time for it makes it easier for people to do.
Again, I don't relate to this. I agree with you that it makes it easier for some people to do, but I'm not in that group of people. My point in this thread is that people are different.
> So it's natural to say "Looks like I'll be getting into the foobar system today; who worked on that most recently?"
It is much more natural for me to say "`git log`, what have people been up to in this system recently?". I prefer to read text than listen to verbal explanation. I also don't usually want to be offered help without being asked, I just want to go read and work.
Again, I'm not at all saying this is the one true way, but please believe me that I just have different preferences that make status meetings less interesting to me (and I think a lot of other people) than they seem to be to you (and many others).
I believe that you have different preferences. And I'm happy to take your word that you don't have social anxiety. However, loving socializing doesn't prove it. I loved it and also often got anxious. Now I love it as much but am not as anxious, which has made the social parts of collaborative work easier for me.
As to the second bit, I'm sorry to be contradictory, but having a specific, in-person time where asking for help is normal and expected lowers the barriers for literally everybody, because the particular barriers being lowered include costs like "figuring out how to contact the person", "being concerned about catching them at the right time", "contacting the person", and "delay in receiving a reply".
If you have a different approach you like better, that's great! The way a team works should match the needs of the people on the team, and of the team culture. There are plenty of teams out there, and good work gets done lots of different ways. I hope everybody ends up on one that works for them.
That said, "personality" is not an immutable set of characteristics, and not all of the way people express their personalities are equally good for collaborative work. As an introvert who also wants to get things done at the scale only a team can provide, I'm just always going to have to stretch myself.
I may also decide that I can only stretch myself so far, and so my limits may mean that there are kinds of work I'm just not well suited for. E.g., large companies demand too much of what I think of as "political" behaviors for me to find the work sustainable. So although I think we should generally try to honor each other's preferences, we must also be honest about the fact that not all preferences are equally suitable for every kind of work.
I disagree with your (in my view) far too prescriptive certainty that a lot of synchronous communication is universally best for collaboration. It is a common view (especially among managers) that I believe is simply wrong, and based on vibes rather than empiricism.
It's not universally wrong though. All I'm saying is that it isn't universally right. It just isn't universally anything. A good manager or lead should be able to look around on some teams and realize, hmmm, we aren't getting much value out of all these synchronous touch points, and on other teams they should realize, hmmm, we could use some more frequent synchronization here. But a manager or lead coming in with their own prescriptive preference for daily synchronous meetings, and failing to notice if they aren't valuable, is not doing their best work, IMO.
I have been on both kinds of teams. Indeed, right now I'm on a team for which I think daily morning meetings are working really great, regardless of my own personal preferences. But I've also been on teams where they are working terribly and only the manager is happy with the situation, and that's bad.
For me it's based on a pretty simple feedback-loops model. The length of the feedback loops limits all sorts of important things, especially external responsiveness, adaptation, learning, and error correction. Collaboration requires co-laboring.
There are circumstances where collaboration isn't particularly necessary, of course, so maybe that's what you're looking for.
I agree of course that there are plenty of ways to have bad collaboration even with short feedback loops, as in your last example. It's not a panacea. Nothing is.
We talk for a full hour every day, but there are only usually 5 or 6 of us, and we are all invested in every feature, so the meetings end up being a fairly detailed review and feedback on everybody work.
I got pushed to a team that did this. I decided to try to extend the meetings for as long as possible with the goal of eating so much time nothing got done anyday. The daily stopped shortly after
My current employer doesn't do any stand ups at all. I've been there four months and not a single all-devs meeting. Sure we avoid degrading. But I've never been part of a team that's more dysfunction than this one.
I wiah. But it's not even on the radar. In fact, I'd be marginalized more than I already am. I said to someone on the leadership team, "How can we have a team without a single team meeting?" I got no reply. I'm not even sure they heard me.
The major problem facing the industry is doing agile just because everyone is doing it, not because it is the right tool for the job. No matter how much money or people you throw at it, it's not going to work.
> The major problem facing the industry is doing agile just because everyone is doing it, not because it is the right tool for the job. No matter how much money or people you throw at it, it's not going to work.
I recently started a role running an Engineering org at a startup. The first two questions I asked everyone are why are they doing scrum and what do they want out of the engineering process. Answers to the first question were all over the map, and answers to the second were almost identical.
> you already know what they're going to say because you all, you know, talk
Standups are a pet peeve of mine especially. If the team isn't communicating regularly, then there's a larger issue that standups won't solve. If it is, then standups are a complete waste of time.
This is where a decent Scrum Master or Agile Coach makes such a massive difference... I've seen what you're describing so many times and it's a simple fix to get people to stop focusing on what they've done and to instead focus on what the team needs to do (ie focus on work not yet complete for the team and not what on the individual has done/will do)
In practice, any standup format where developers show up and basically perform to some standards set by a “master” or “coach” is kind of doomed to feel a little bit like a circus show.
The problem is the existence of someone else running the show in these meetings. The best standup I’ve had were those run by the engineers themselves. Adding a “coach” or “master” just makes everything worse unless the team is really bad at communicating with each other, in which case you have bigger problems.
Lord knows what people are calling coaching these days. But if they're actually coaching, then yes, getting the team to run the meeting was exactly my goal when I did that kind of work.
But that can be tricky. The biggest issue is to train managers to not make it about the manager. For that, an external coach is especially helpful, because it's the rare engineer who can sit their boss down and say, "Look, you're destroying this meeting. How about you not show up for the next two weeks, and then optionally show up but never speak for a month after that?"
But even once you've created a space where power doesn't distort everything, there are a lot of things that can go wrong. People who talk too much or too little. People are unkind, rude, cutting, or outright mean. People who talk about the wrong things. People who don't even know what to do if there isn't a manager around to try to please.
The truth is that for most people in the industry, their median meeting is bad. People with shorter careers may never have experienced a good meeting. So expecting them to just figure out how to have an excellent meeting every day is asking a lot. Especially a stand-up, which has pretty sharp constraints. If a team already knows or quickly figures it out, great. But a coach can really help.
> whenever agile project fail, agile shaman say "you didn't do agile right!" grug note this awfully convenient for agile shaman, ask more shiney rock better agile train young grugs on agile, danger!
I know you're being somewhat flippant but if agile shaman blame team for not doing agile right team should throw agile shaman off nearest cliff and find somebody who's not doing that job as some kind of dodge... too many self declared agile coaches and scrum masters out there who have no idea what they're doing - it usually starts because the organisation gets their first feed of them and agile through a consultancy who just tells them what they want to hear rather than they reality, and the senior management usually can't get out of that headspace.
pure marxism has never tried! if only we try the pure version it will work better! Marx had some good idea, communism stinks. Agile manifesto has good ideas Agile stinks. Maybe not as bad, but let's move on
I've found a direct correlation that the more closely a workplace conformed to the Agile manifesto, the better it was to work in. It absolutely does work in practice, and where it doesn't work I have always found specific, actionable places where they were doing it wrong. At some point you do have to actually spend 5 minutes to try to understand and follow the methodology - I don't think there's any methodology that claims you can ignore everything it tells you, do the oppsite of what it says half the time, and it will still improve your organisation.
(Unfortunately I haven't found any correlation between how much an employer talks about Agile and how closely they actually follow it)
All those people do is make me disgruntled knowing it's someone's _job_ to run this bullshit circus. Automate the lot of it away, don't make it someone's career.
People care and should care about what they get rewarded for. If promotions/raises/bonuses are based on the manager's view of your personal work, as is the case at most companies, then that is exactly what a sane person should focus on. Removing the manager from the standup or adding another layer of a Scrum Master won't change that but merely change how they get that same information. Standup at least provides an equal opportunity for everyone to sell themselves in those cases.
As the other comment said I'm simply noting the unfortunately reality that what matters is rarely actual delivery. Trying to avoid that reality won't make things more tied to delivery but simply more opaque as to what they're tied to.
There's exceptions but in my experience those teams don't bother with these types of deep discussions on process. The process is somewhat irrelevant since the expectations are fairly clear and what they will be measured on is also fairly clear.
lol, this is exactly the team I'm on that I got moved to because I hate scrum and they thought they were doing me a favor after a product focused reorg.
just...hours of useless status meetings.
It didn't start like that, but they overhired, and the time not in status meetings is split between a dozen slack channels. bleh.
> getting everyone to frequently think about deadline/feature trade-offs
I never let anyone else impose a deadline and a list of features on my schedule.
If the features are mandatory, I will provide the deadline. If the deadline cannot be missed, I will accept a sorted list of features (by priority). In both cases, I'll do my best to cram the most value possible in the next release, but the sooner I need to commit to its content, the poorer it will be.
If the deadline and the list of features are both set in stone, then it's not my problem.
> break everything up into smaller chunks. It gives you clearly defined guardrails
This is only true if management respects the estimates. In my experience, they do not understand why Fibonacci or t-shirt sizing, etc. are used. They mentally convert the points to some "X days" and then beat you in the head with it. They want to micromanage and they do not understand they are building software. You can't break certain tasks down further and you can't parallelize many tasks. You can bring up Fred Brooks but it's a hopeless cause. They will never get it. Then as you inch towards their arbitrary deadline (that they tell no one, by the way, because it's better the developers don't know about deadlines until the last fucking minute because "agile" and not "waterfall") they suddenly act shocked that 9 women really can't make a baby in one month.
They mentally convert the points to some "X days" and then beat you in the
head with it.
That's actually why I really dislike Fibonacci estimation. If we just estimated days or hours, then I could say, "Okay, this is going to take me until Wednesday," my manager would reply with, "Wednesday? It's going to take that long?" and then we could have a discussion about why it's going to take so long. Or, worst case, manager says, "quanticle, I really need this to be done by Tuesday," and I know I'm going to be staying late until it's done.
But with Fibonacci numbers, it's like, I estimate a 3, manager nods and agrees that this task is a 3, and then it turns out that when I said 3, I meant that it'd take until Wednesday, but manager thought that a 3 point task would be done by Tuesday, and now manager is mad at me, and I don't know why.
The old way sucked, but at least it sucked in an up-front and transparent way.
> and I know I'm going to be staying late until it's done.
I cant tell you how many times I spent long days, 16 hours at a time, sometimes over the weekend etc. Only to have the manager stroll in monday talking about how great their weekend was, and barely acknowledge the item was completed. And then I find out the customer that "needed this so bad" didn't touch it for the next month. Or were never told it was deployed etc.
So many deadlines are fake that it's hard to trust any deadline.
Fake or not, at least you were told what the deadline was. The agile approach to this dysfunction is for you to be pulled aside at some point and told, "You're not delivering enough points," with the manager remaining extremely vague about how many points is "enough".
I think you illustrated the point of the deadline well. How else were they going to get you to work 16 hours days? No way to make someone eat the cost of estimation error by pretending there is no error and making job performance and team esteem dependent on "not failing the sprint".
For me the most absurd conversation around Fibonacci estimation is the burndown (etc) charts and group estimates.. you can't add non-linear values and expect the sum to mean anything!
I've had managers fight over how the upcoming sprint is doable because it has around as many total points as the last, ignoring that they've defined the individual five-pointers as being significantly more effort than five individual one-pointers. And they either fail to grasp the issue or deflect when it's pointed out.
That brings to mind the other issue I have with fibonacci estimation: it makes improvement impossible.
In any high-performance organization, there is periodic self-reflection and self-improvement. Professional sports teams will, for example, sit down and "watch the tape", reviewing video of their most recent game(s) to see what they've been doing well and what they've been doing poorly, drilling down into specific areas where they need further practice.
Agile pays lip-service to this practice with its end-of-sprint retrospectives, but I've never seen an agile team do anything approaching a ticket-by-ticket breakdown, going over why the estimate was wrong, and what could be done to improve estimation in the future. One of the reasons that teams don't do this is because Fibonacci estimation makes it impossible to do this sort of thing. If I estimate that a task was a "3", and it took me two days to finish, did I estimate correctly? How could I have estimated better? These questions don't even make sense without a common baseline for what these numbers mean.
That's what I find most frustrating about Agile, as it is practiced. It's not the fact that the estimates are wrong. It's the fact that the estimates are so meaningless that they're not-even-wrong, in a way that makes it impossible to find and adjust for biases.
> manager says, "quanticle, I really need this to be done by Tuesday," and I know I'm going to be staying late until it's done.
At some point you have to grow a pair and create the workplace you want. (Or, y'know, unionize). Tell them to fuck off.
> But with Fibonacci numbers, it's like, I estimate a 3, manager nods and agrees that this task is a 3, and then it turns out that when I said 3, I meant that it'd take until Wednesday, but manager thought that a 3 point task would be done by Tuesday, and now manager is mad at me
They're explicitly not allowed to do that. If they're claiming to follow Scrum then that's a promise not to do that. At some point all I can suggest is "don't work for a liar". Of course that may be easier said than done.
> The old way sucked, but at least it sucked in an up-front and transparent way.
I agree that pretending to follow good practices while following bad practices can be worse than honestly folowing bad practices. But that doesn't mean that good practices are worse than bad practices!
At some point all I can suggest is "don't work for a liar". Of course that
may be easier said than done.
The point of my anecdote was to illustrate how Agile makes it easier to lie, and makes it difficult for honest people to call out liars. If a manager tells me that the deadline is Wednesday, and the deadline passes without anything bad happening, then he or she looks bad. If a manger estimates a "3", and I estimate a "3", and then it turns out that our definitions of what a "3" is differ, then I look bad, regardless of whether the work was, in reality a "3", a "5", or a "3.1415926".
But that doesn't mean that good practices are worse than bad practices!
The worst practice of all is a bad practice that masquerades as a good practice. I'd much rather that people be honest and up-front about the deadline (even if it is BS) than try to hide behind some overly complicated poker-game kabuki.
> The point of my anecdote was to illustrate how Agile makes it easier to lie, and makes it difficult for honest people to call out liars. If a manager tells me that the deadline is Wednesday, and the deadline passes without anything bad happening, then he or she looks bad. If a manger estimates a "3", and I estimate a "3", and then it turns out that our definitions of what a "3" is differ, then I look bad.
If your manager says they're following agile/scrum and says you took too long on that "3", they're lying and you should call them out; you don't look bad, they do.
> I'd much rather that people be honest and up-front about the deadline (even if it is BS) than try to hide behind some overly complicated poker-game kabuki.
If you've got a real deadline then be honest about it. But most everyday tasks don't need a deadline; agile isn't about pretending the deadline isn't a deadline, it's about actually not having a deadline.
I think that's the crux of our disagreement. I think most everyday tasks do indeed have a deadline. Even if that task specifically doesn't have a deadline, it's often in service of a broader task which does. The premise that all agile methodologies are built on is that customers are going to be more willing to drop features rather than add days to the schedule. I think experimental evidence has proven that premise false.
And frankly, it was kind of a ridiculous premise to begin with. Can you imagine if other professions adopted "agile" methodologies? Can you imagine your auto mechanic telling you, "Okay, well, putting the dashboard back on is going to take me until tomorrow, actually, but, if I only attach half the bolts and leave the speedometer disconnected, I can get it to you by the end of the day. Would that be all right?" Or a home-builder saying, "Okay, well, the drain pipes are proving trickier than anticipated to install, but I can give you the bathroom without the drain pipes, and install those in the "version 2.0" release. Would that be okay?"
> Can you imagine if other professions adopted "agile" methodologies? Can you imagine your auto mechanic telling you, "Okay, well, putting the dashboard back on is going to take me until tomorrow, actually, but, if I only attach half the bolts and leave the speedometer disconnected, I can get it to you by the end of the day. Would that be all right?" Or a home-builder saying, "Okay, well, the drain pipes are proving trickier than anticipated to install, but I can give you the bathroom without the drain pipes, and install those in the "version 2.0" release. Would that be okay?"
You're talking about stuff that's a regression from the previous state of things, which is rather different. Where I live it's totally normal for a dentist to say "ok, I only had time to fill two teeth today, come back next week for the others". Or a tutor to say "ok, we'll stop there for today and finish the chapter next week". Or a cleaner to say "well I've got time to do the balcony or the fridge but not both, let me know which you want today and I'll do the other next week".
I prefer 1 or 0, do or do not. The rest of the sequence is meaningless. If you are truly in a position where two different features will bring the company £5mil of revenue and one is a 3 and one is a 13, just do both, no need to prioritise the 3.
At the end, those complexity number end up representing some time estimates anyway.
Cause you will get the velocity graph, showing how much points have been completed this sprint and how it compares to previous sprints. The graph is expected to stay somewhat level or increase as the team efficiency increases. It will decrease when members are away on holiday.
If your team capacity stays equal and last sprint your team completed 20 story points, it’s kinda expected the next sprint another ~20 story points are completed. So in that case 20 story points will represent about 2 weeks of work for the full team.
I also think for many people complexity translates into time needed to finish work. A more complex task will naturally take more time to complete than a simple task.
So from my point of view, it’s fair (if after a couple of sprints) a product owner might get an idea that 1 point is equal to -say- half a day of work.
PS: I am not a product owner and not a big fan of ”Agile”. I think daily stand-ups might be overkill in many situations (in my current remote team it’s more like a weekly stand-up) and I generally hate retrospectives. I just want to get shit done (which is luckily the practice we have in my current team). We do have a task board, but we don’t do the whole assigning points stuff. And I am mostly free to pick-up any task I feel like working on. This is much more agile to me than “Agile”.
That’s generally true for that specific team in that configuration, but as soon as you start plucking people off, and adding other people to the team everything is up in the air again.
Yeah, my last gig had high turnover (not a coincidence with the dysfunction) and it made it particularly apparent that the estimates were a waste of time, but we kept on trucking.
Okay, but I could equally say, "No one would have issues with 'Agile' if developers could get infinite work done in a week... but that's not how the world works."
The fact is, there's a limited amount of work that can be done in a limited amount of time with a limited amount of money. Developers want the time and money to be unlimited, while customers want the work to be unlimited. But none of that is how this works: all three of these things are finite.
The point of "Customer collaboration over contract negotiation" is that the customer is involved enough in the process to see that you're producing close to optimally with the time and money they're giving you.
Committing to an amount of work in a sprint doesn't work, because it always ends up with customers trying to get more work into the sprint--more production than ultimately is possible. And, it's worth noting, setting boundaries around that and guarding to prevent that, starts to just look like "contract negotiation" with a shorter contract. Sprints aren't agile, they're Agile: a marketable idea that doesn't work.
Part of the problem is that customers see it as their job to get more work for less time and money, so they try to set aside what developers are telling them, the "work is limited" part of the trifecta. They see developers as their subordinates, so they think their desired outcome, where time and money are limited but ability to produce is unlimited, is reality. If developers and customers are seen as equals, both bringing needed value to the table, then this doesn't happen, because everyone agrees on the limitations of the situation. But as soon as you start treating customers as superiors, their view of the limitations becomes dominant, with predictable negative outcomes.
I am really struggling with this currently, I have agiled myself into a spiral of never being done. I am wishing I took a more waterfall approach so there was a fixed endpoint.
For personal projects in the future I will adopt a more rigid design phase as you don't have designers and managers enforcing deadlines and sanity checking whatever tangents you go off on.
You also have an agile option: release early and often! Use the feedback you get from users/customers to decide what to do next and when to stop.
The problem with waterfall approaches to "fixed" endpoints is that at the beginning of a project you know the least. It can be comforting to imagine that you can fix an endpoint up front. But most projects worth doing result in a lot of learning along the way. I have heard of very few projects that did their 1.0 release and were so successful that they just stuck with that release forever.
It’s hard to have this conversation given the countless definitions of “Agile” but I think the majority of what I’ve experienced does not help with the concerns you raise.
Proper project management to enumerate concrete goals with well-defined timelines is what you need, which is obviously not a novel part of any Agile interpretation.
Often the desire for Agile comes from not knowing how to manage a project and reaching for the popular thing that people think will magically solve their lack of expertise.
> Often the desire for Agile comes from not knowing how to manage a project
Corporate Agile takes thr worst of Waterfall and Agile and combines them.
It frees the management from budgeting for discovery and research, which are nessesary in waterfall. They can come unprepared.
Then they demand all the things they expect from waterfall - hard deadlines, no surprises. Then thry change scope on the fly because 'its agile, right'.
Agile does more to excuse poor managment than it does to enable developers.
I think this mostly nails how Agile is largely practiced. Being prepared with a clear, concise, well-communicated vision of what you want to build is essential to developing quality software, regardless of the adopted process.
Agilists frequently argued investing time and energy into crafting requirements is an “anti-pattern”, so being unprepared became the Right Way To Work TM. This is 100% dead-ass wrong.
Yah. You run into a different issue even if you've got that. There's a lot of example of scifi/fant sagas where, as the author gains fame and (so it is assumed) gains more ability to say "no" to their editor(s), the series goes down in overall quality. AFAIK you can also see this is military R&D.
(IMHO, you can see the flipside of that in a lot of web fiction with 1/wk+ release schedules)
I'm pretty sure I'd never want to try touching a codebase built with unlimited time and money - I'd expect waaay too much code, mostly.
IMHO, even if you have (functionally) unlimited time and money, spending unlimited time and money is still a bad idea.
(Balance comes from opposing forces. If you don't have an opposing force, you can't be in balance. Budget and shipping can be treated as opposing forces.)
You can do this if you hire the right people. The only “process” that always works is “hire right people and the F out of the way.”
The problem of course is that there are waaaaay too many software developers and roughly 93% are terrible at their job (this is just simple math, take anything and put millions of people to do it there will only be 5-7% that are actually good at it).
FWIW, the early '70s paper the DOD misunderstood as suggesting 'waterfall' had already said the right way was to build one to throw away -- but use the prototype to derive the usability, requirements, and design docs first.
If you had unlimited time and money, then you wouldn't need Agile. There's no intrinsic value in having 50% of the system working at 40% of the deadline.
> There's no intrinsic value in having 50% of the system working at 40% of the deadline.
In practice that's usually more valuable than having 100% of the system working at 100% of the deadline. Almost all deadlines are fake, and most requirements are too.
This is always my favorite fantasy. No one would have issues with "Agile" if you had unlimited time and money...but that's not how the world works. Hence why you break everything up into smaller chunks. It gives you clearly defined guardrails so that projects don't spiral out of control. EDIT: AND the people funding said projects know where there money is going. That's important.