I always upvote these things, not because they're right. Because they show common misunderstandings about Agile. Agile is so simple and easy that the development community continues to screw it up. It's important to understand how.
According to the author, standups are something companies require developers to do to report about what they're doing. Many times they can take more than a half hour.
That may be true, but the purpose of standups is that the team requires one another to get together and talk about how to move the project forward. It's not about what you did. That's a status report. It's about how you can help one another.
If you can self-organize, effectively communicate, and help one another as-needed without standups? Don't do them. Easy. There's no magic requirement that you have to. What we've found over the years is that if you give it a name and a time, at least you have a way to talk about whether it's working or not. Other people can drop by to help out. But if that's too formal for you and you don't need it? Stop!
Standups remind me of brushing your teeth. When they're working well, it looks like nothing of value is happening. Five minutes and people tell jokes and leave. It's when they're misunderstood as something else that they become useless and painful. Had to throw a SM out of his own team room once because he kept using standups as an opportunity to play "What's your status?". Nobody cares about your status. We care about how the entire team is working. Have some down time? Tell us you're free and then go play tennis the rest of the day or something. It's not a management, outside-in meeting. Just the opposite, in fact.
I love these articles because they remind us that the goal is what's important, not the ritual. Unfortunately, people get the two conflated, usually due to a lack of multiple-team/org experiences.
That is just bullshit though. I don't find value in anything that agile offers, can I just throw it out entirely by your argument?
Standups - You can simply claim that, hey you don't want to do standups, don't do standups but if you take a concrete implementation of Agile, say scrum for instance, it specifically asks each person in the team to answer:
"What did I do yesterday that helped the development team meet the sprint goal?
What will I do today to help the development team meet the sprint goal?
Do I see any impediment that prevents me or the development team from meeting the sprint goal?"
These questions are effectively a way lay out a very clear path for management to basically micro-manage developers and they add pressure on developers to come up with some contrived explanation to make it sound like their day was productive. Hardly builds any trust when your work is being supervised and judged by a team every single day even if the goal of the meeting is not to do so specifically.
I can go deeper into each individual process that agile variants impose and take each of them apart. I have nothing but spite for this godforsaken process, the only thing it's good for is to give management an illusion of control on software development process.
If you read the agile manifesto and then you look at scrum, it feels as if scrum has nothing to do with agile. It seems to breaks every rule.
Scrum is processes and tools over individuals and interactions, by its very nature.
Scrum is comprehensive documentation over working software, because you have to map everything out.
Scrum is contract negotiation over customer collaboration, by allowing management to effectively rule scrum, scrum masters are always management or reporting to management, so devolve into contract negotiation by proxy.
Scrum is following a plan over responding to change, again, by its very nature.
It's the most odd thing I've ever seen, that somehow scrum came out of agile and literally got it all backwards. There's even certifications on how to do scrum, which is utterly stupid when you read the 12 principles, some choice scrum oxymorons:
trust them to get the job done - nope, we don't trust you, follow these scrum rules you oiks
simplicity is essential - but we've got all these formal rules for you to follow
working software is the primary measure of progress - no, actually, how many sprints have been successfully completed?
the best architectures, requirements, and designs emerge from self-organizing teams - but we're not going to let you self organize, you must follow these scrum rules
Scrum is all about implementing a system and then adapting it over time to fit your needs. It's all about having the team figure out for itself how to organize. It's not a rigid set of requirements. It's a set of suggestions about how to begin implementing the system, and then trusting the team to figure out what to adapt and what to cut.
All about what has to be done, with a formal role of scrum master.
Phrases like these brook no adaptability:
On each day of the sprint, all team members should attend a daily Scrum meeting, including the ScrumMaster and the product owner
on the first day of a sprint and during the planning meeting
Another activity in Scrum project management is the sprint retrospective at the end of each sprint. The whole team participates in this meeting
Management take Scrum as a set of rules to follow and then use it to micro-manage everyone. Scrum masters end up as middle managers. Daily stand-ups turn in to daily justify your worth.
> These questions are effectively a way lay out a very clear path for management to basically micro-manage developers
Well, they would if there was manager in the daily scrum.
Which is why there isn't.
(Not that I think the scrum formula here is ideal; if you've got a shared status display—kanban-like—the only question you should really need in the standup is the barriers one; the standup shouldn't be a status/progress check, it should be a venue for shared progress on breaking barriers.)
If it's not a dev manager, it can be a product manager / owner / scrum master / whomever is in charge of roadmap and high-level backlog items.
They take control because they've made promises to other people, higher up in the org and possibly outside the company, and they need to find out if scope is expanding too much, if something is taking too long to implement and scope needs to shrink as a result, or people who've been promised something need to be let down.
As a developer, this interaction feels a lot like micro-management.
> If it's not a dev manager, it can be a product manager / owner / scrum master / whomever is in charge of roadmap and high-level backlog items.
In by-the-book Scrum, that's the Product Owner, who isn't a participant in the daily scrum. Neither is the Scrum Master, whose only roles with regard to the daily scrum are: (1) teaching the Dev Team to keep it within a 15-minute time box, and (2) ensuring that it occurs, (3) ensuring that if people other than the Dev team are present, they do not disrupt the scrum.
(I do think that both having the status questions and leaving the door open for the P.O. to be present even if not supposedly participating is a thing that creates the temptation to turn the scrum into a managing meeting, which is very explicitly not the intent.)
I really don't get this "management can micro-manage developers". Sounds like you work at a very shitty company / unhealthy environment. Dailies are for the actual working team, so they work better together and not a tool for team externals to shit all over the process.
I really can imagine your scenario - do you really have your CEO standing there on your daily meeting? Or are you bothered by your Team Lead?
I'm a CTO and I've never been on a daily. I don't care about daily tasks. I care about shit breaking. It can be our tech, our infra, our people, etc.. That's what I need to solve. I don't get it why in the god's name I would attend a daily. What value would I get out of that?
If on the other hand, I see shit going down, I dig in right away and talk with the Lead and/or Team if shit got real.
Without scrum, if a CTO wanted to ask how an individual developer is doing, they could ask their line manager. With scrum, a CTO could just dig in to some of the many dubious reports that scrum generates. They could look at an individuals burn-down on tasks, and compare them across developers/teams. No matter how stupid this sounds, I've seen this exact thing being done by company Directors.
Decisions are made. Developers are moved to different projects, or given shitty bonuses, or constantly hassled to make their scrum metrics look better.
Just because you don't go to a stand up doesn't mean your not micromanaging, or enabling micromanagement as it is usually the line manager using scrum as an excuse to account for every hour in the day. Sometimes that is due to pressure from up high for various metrics to improve, etc. Other times they are just douchebag managers that don't know what they are doing...
You're basically arguing that CTOs mostly cause damage and it's better to hide various vanity metrics from them with the purpose of them not meddling in the process.
My view is that looking at scrum metrics will provide you with additional insight into the development process. I understand that shitty managers will simply take those and decide on top of that. Proper managers would look at the numbers and go ask the line manager what is going on.
I can give you a very practical example - before we had scrum and burndown charts our team leads had limited tooling to detect problems and even quantify problems in the development process. Now we can use that to improve our process with the purpose of us being more efficient and making the development process less stressful.
I never look at burndown charts - I'm the CTO and my purpose is strategic. VP of Eng might look at them, but only if issues are detected, while team leads need to use them daily to help them improve how they work.
> I don't find value in anything that agile offers, can I just throw it out entirely by your argument?
Yes, of course?
But I think you might be confused about what agile is, going by your remark about processes that agile imposes. There are none. Agile is about certain values, and people have come up with various processes that try to incorporate those values. This fails sometimes, mostly because different teams require different things in their process.
But ultimately, since it is about values, if those values are not shared by a company (or at least your division) and management it's going to turn into process for process sake. You're screwed, but it's not agile that screwed you.
Then it becomes completely meaningless - It's the equivalent to saying to someone - "Be good" without defining anything about what good-ness involves.
Once you start defining specifically what you mean by good, if your initial premise falls apart and there's no practical way to be good, then what's the point of saying be good?
>Because they show common misunderstandings about Agile
I agree with most of what you're saying. I've found this to be the biggest barrier to the process actually working.
People don't understand the purpose of what is being achieved with X meeting/process and so will actively try to subvert it. Sometimes as engineers we're too smart for our own good, and sometimes we don't listen to what we're being told.
I went through the SM training and really brought into it, however, it's a difficult job to do well. Sometimes being the bad guy and telling your product owner no, or yes but here are the consequences can make you hated (literally a former co-worker and Po/PM of mine won't say more than Hi to me)
>If you can self-organize, effectively communicate, and help one another as-needed without standups
Another anecdote I have is this happening only to find out over approximately a 4 month period that we weren't good communicators, that we did need frequent structured communication to get things done right (right being the keyword). Even though this was the `smartest`, highest paid, most experienced team I've ever worked with, there was still re-work and production outages because of a lack of good coms. This probably could've been avoided if planning meetings were being attended.
Bottom line, agile processes are written in blood that you don't need to shed. Convincing a team of engineers this is the hard part.
I'm Old Expert Programmer Dude now, so I get to tell stories.
1. Worked with a team of outside experts once. We were brought in to stand up an internal team of coaches. The first week there, the four of us got together. I asked "Do we want to do standups?"
Another coach said nope, we're professionals! What do we need standups for?
The rest of us met every morning for breakfast. No standing up, no meeting. But we knew what we had to cover in between shooting the crap.
We did well. He did not.
2. Worked with another team once who were doing some gnarly embedded work. The lead, a super-smart C++ guy, announced that he wasn't going to do standups because he was a professional (see a pattern here?) and could communicate just fine without tossing a football around.
He finally came. Every morning the team would have fun with the nerf ball (which is just something fun to toss around. Who cares if you have one or not?) When it was his turn, everybody stopped smiling and somebody put the little football on the ground at his feet. Then he spoke. He never did touch the nerf ball.
I was trying to help them do mocks and rapid hardware prototyping, but he wasn't getting it. Finally one day, just after the standup, somebody said something like "You know John, if we did this thing like this, we could work a lot faster"
He said he hadn't thought of that (even though multiple people had suggested it. It just wasn't phrased the right way for some reason) and agreed to start right away.
I smiled as he left and asked him "Wasn't that a great standup!"
"Nope. Could've had that conversation just the same without the stupid meeting"
Yes, you could have. But you didn't. Communication is weird. There are no big, flashing red lights when you fuck it up. And when it works, it doesn't feel like anything has happened.
So when people want to do things differently, I always encourage it. If they focus on the goal, they'll come back to these lessons. If they focus on the ritual, however, it'll never ever make any sense to them. (And they very well may end up making life miserable on everybody around them)
> The rest of us met every morning for breakfast. No standing up, no meeting. But we knew what we had to cover in between shooting the crap. We did well. He did not.
Basically, since the other guy did not wanted standup you intentionally left him out of loop and communicated only among yourself during breakfast. If there was ever ugly politics, it is this one.
> He finally came. Every morning the team would have fun with the nerf ball (which is just something fun to toss around. Who cares if you have one or not?) When it was his turn, everybody stopped smiling and somebody put the little football on the ground at his feet. Then he spoke. He never did touch the nerf ball.
Frankly, I really don't want to work in environment you and your friends are creating. Regardless of whether I enjoy the process you are pushing for, I don't want to work with people who intentionally sabotage people they disagree with - and then brag about it. If there is something called inability to work with different people, this right here is it.
The pattern I see here is that your colleges are intentionally toxic to those who don't share their preferences and then blame victims. You refused to communicate like adults resorting to passive aggression, not your opposition.
Maybe they were being toxic, but it simply seems like they took a little time in the morning to go over things and he chose not to join them. So what should they have done, each staged separate little talks with him to go over everything that was discussed in their morning meetings? Compile meeting notes and send them to him?
It doesn't sound so much like sabotage as it does that he chose to put his head down and eschew the meeting and struggled because of it.
No, of course not. "We are having coordination meeting at <insert reasinable time and place>" announcement is already fine. Just starting standup when everyone is in office even if he disagree is fine too.
The time and place here seem juuuuust coincide with time and place he is least likely to be at. Standups are not supposed to be passive aggresive way to enforce early coming to work either (most coders have flexible time, your process should honor that) nor are they supposed to prevent you to have breakfast with familly or alone in home.
And yes, if collegue does nor know info he needs for work, I would tell it to him even if he clearly missed it by his own mistake. I would also tell him that he don't know info because he ignores meetings he should be at. Transparency and open discussion, basically.
Otherwise said, you solve it like any other disagreement over something that requires coordination.
>And when it works, it doesn't feel like anything has happened
Exactly, which is why it's so hard to keep people on board when all is going well. The meetings start seeming like a waste of time and then you end up falling into cyclic relearning traps.
Good chat though, I'm sure most people who have been SMs will have similar stories.
"agile" is great. "Agile" has been fucked to death by consultants and execs who just heard "wait you can make developers completely fungible and i can get something in 2 weeks rather than waiting for 2 years?" and never bothered to listen to anything else.
That is how I view it:
- "big A" Agile has books and approved tools and coaches from outside the company holding week-long all-day workshops.
- "little a" agile has devs/QA/etc. suggesting ways to make the process of building and shipping software smoother.
I'm currently working on a "little a" agile team. Upper management doesn't really care what our process is, as long as they get their quarterly release with (most) of their priorities.
I'm becoming increasingly convinced that, to be successful, a team's agile practice needs to largely fly under the radar of upper management.
As soon as upper management catches wind, you'll need to justify every little process flow change to them, or they'll start demanding regular reports with burndown charts and plots of velocity over time and crap like that. At which point, you're done. Things officially suck forever.
That isn't to say that I think Scrum coaches and whatever have no value to offer. I've done a 1-week Agile training course, and I thought it presented some really great ideas. But their potential value is severely undercut by the fact that there's no way to bring one in without attracting the attention of the mothership.
I had that once, the bit where management wanted to see the burndowns and velocity, then fixated over same. The only way to move past it was to stop producing them. I did, as the Lead/SM/Dev Manager, have the clout to say no, so that was lucky. I explained it's the working software you need but I don't think they were happy.
> As soon as upper management catches wind, you'll need to justify every little process flow change to them, or they'll start demanding regular reports with burndown charts and plots of velocity over time and crap like that.
I think that's a management problem you'll run into with any development methodology you use. There are a lot of management types that slavishly focus on metrics whether or not they make any sense, and they can do tremendous
damage to any organization.
Give those people a tool and they'll find a way to misapply it, whether it's velocity, or performance reviews, or LOC, or whatever.
Prime example of this was stack ranking at Microsoft. How much productivity was lost due to the political maneuvering and backbiting caused by their misunderstanding of bell curves?
That's a strange reading of Agile to me. Agile is not about making developers fungible, it's about building high performing teams of people. That takes time, and it is set back any time you have to replace someone. There's plenty of Agile literature that points out the hit to velocity when there's turnover.
As for 'i can get something in 2 weeks rather than waiting for 2 years', that's about not waiting 2 years to find out that you've been building the wrong thing or that the software sucks. Maybe as you deliver features you'll find out that the application is good enough in 18 months. Maybe you'll find out after several months of sprints that the product owner is bad at getting requirements and you need to do something different. Or maybe you'll find out that it is taking longer than original estimated to deliver functionality so important dates need to be adjusted accordingly.
In the old waterfall model, all that bad news may not come out until 2 years later when the software is released. And in the old model the customer is not getting useful software until 2 years out, rather than much sooner with a minimally viable product.
Agile is not a panacea and any methodology will fail if attempted by dysfunctional/incompetent groups of people. But if there's one benefit of Agile, is that everyone should find out much sooner that things are going awry.
I've worked in waterfall and agile for 15 years, and the key lesson from Scrum is that it effectively exposes bad news early on. The scrum ceremonies do just that and nothing more. Once you get the bad news open and dealt with a lot of other work is made more worthwhile.
It's so true. So many people think "Agile is bad because my company does ineffective standups". That's not what Agile is! Agile is about continuous improvement.
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
It's pretty simple but somehow people confuse this and Scrum (with bad scrummasters) and blame Agile for what's actually ineffective leadership
In my experience, at least at bigger companies, standups are there to justify the project manager’s job. It’s for them to tally that everyone is doing their work. Simply, they see that the team wishes to meet for development purposes and it gets co-opted into a status meeting.
I find that small business gets it right more often because there is simply less bureaucracy and developers are much more trusted.
Feel free to send them this way. I’m currently working at a startup where the CEO is the product owner/manager, as well as doing all the CEO duties. A good PM would be a dream come true right now.
PMs have a role, no doubt. They should help facilitate discussion and help protect the team and communicate upward, and provide guidance where necessary. I have worked with some that did this well. I have also worked with some who cared so much about status that it negatively affected the team because they wanted five or more meetings a week (even stand-ups took an hour each). This type of disruption isn't limited to PMs, of course, it's just something I've found in my experience -- more-so than any other role.
Can you articulate an example of a good versus a bad standup? Because your response is pretty vague. I've been on a lot of teams, read a lot about Agile and SCRUM, and just about every single one communicates stand-ups as a status update, not what you are indicating at all. If this was an isolated thing, I would agree with you, but when almost everyone is doing it this "wrong" way, as you say, I think the problem is with "agile," as loaded as that term is these days.
I don't even understand how you can get together to "move the project forward" and it be under 5 or even 15 minutes. What does that even mean in practical terms? That kind of open-ended question usually devolves into many different unfocused discussions and then pretty soon everyone clearly wants to leave.
Yes! This is right on the money. So many people forget that "being Agile" is an active undertaking, something that takes reflection and iterative improvement of not just the things you're building, but also the process you're using (in search of a way that works specifically for you and your team). One easy step is rethinking the classic standup questions, in a way to address the overall question "what do you need?".
The only useful result of standups that I ever saw consistently was when people spoke up about tasks they were blocked on, and cross-team collaboration allowed a pathway towards a solution to be established more quickly and smoothly than if the exchange had occurred over email or Slack.
Aside from that, the only purpose of a stand up that I experienced was to posture ones self and otherwise waste company time.
I think most times, the individual developers are not the ones that choose to do Agile (or which flavor of Agile), and in many cases, they have no agency to change anything. So when you're in a situation with "hour long standups," you're not really able to do anything about it, due to the business people who are really in charge not wanting to change.
If this is the case, than that's a sad state of affairs for the team. Instead the Team should have retrospectives to freely talk about, what processes/ceremonies work and add to the teams efficiency at getting things done and which do not or are even detrimental.
With each iteration of a retro the Team should slowly but surely progress towards a local optimum, where they shaped their work environment such that they can work best.
> due to the business people who are really in charge not wanting to change.
Stand-ups should be only for the team and SM. Sometimes a domain expert/PO can be added to the mix, if issues need clarification. But never should managers or stake holders bother the team during internal coordination of the work (as others said, standups are no status-report).
"If this is the case, than that's a sad state of affairs for the team. Instead the Team should have retrospectives to freely talk about, what processes/ceremonies work and add to the teams efficiency at getting things done and which do not or are even detrimental."
I mean, that sounds great, but in many of these situations, which are quite sad, the biggest problems they face are management that doesn't completely buy in, but still wants to tout that they're "Agile". So no getting rid of any ceremonies.
"With each iteration of a retro the Team should slowly but surely progress towards a local optimum, where they shaped their work environment such that they can work best."
Again, not all the issues are ones that the Team directly can address.
"Stand-ups should be only for the team and SM."
Should. Should is the operative word there. And I understand what you're trying to say in your comment, but it just completely ignores what reality is like at some places.
I famously got outraged at my team the day after our planning meetings + interviews the whole team was on.
"Yesterday we had meetings"
because while that's helpful in retro finding out where time went; it doesn't update or encourage more thought on the current work. I pushed my team to think about things that others would ask questions about and how it affected their work.
But they likely haven't actually started anything. I think that's the worst part about standups is they require everyone to get up and say something. If you've got nothing to say, then you end up saying idiotic stuff like "yesterday was meetings". (I do also think that having everyone take a turn at speaking is one of the good things about them, because otherwise it's really easy for one or two people to take the whole time talking about their thing, and a shyer person might not be able to get in a word that they otherwise really would have wanted/needed to.)
You are right, of course, in an abstract sense. But in the real world, this reminds me of the "we never had communism!" argument (because somehow, all those who implemented it, got it "wrong" and failed the principles). I mean, the principles behind communism might be noble and great, but if they ignore the human nature and the realities of the world, then, what good are they? If communism always seems to lead to murderous regimes, maybe it's better to avoid it than to attempt to "implement it right, this time"?
Of course, the parallels between "communism" and "agile" are imperfect. But the same way that various forms of "real communism" might work in small communities but fail spectacularly in large organizations, maybe "agile" is in fact actively harmful in corporations? Just a thought.... because I've never seen it implemented right. OTOH, I can't say I've seem good software practices in any large corporations (small pockets of excellence, yes, but they often work "against the system", not because of it).
This seems like some application of "no true scottsman" combined with complex human interactions in a theoretically "simple" system. I guess the perfectly rational consumer fits in somehow too.
You describe a better way of doing standups than simply status reports, but I'm finding it hard to distil into a couple of sentences. Could you help me understand what a better standup would look like?
Talking about team communication in the abstract is difficult. I wrote a book about it. [1]
The problem is that you are looking for the maximum amount of valuable communication with the minimum amount of overhead. That is almost impossible to reliably quantify, however, because each team develops their own communication and language style. This is the tension we face: outside folks who mean well want to standardize things so that teams have a better chance of succeeding. But the only thing they accomplish by doing this is creating a lot of friction, waste, and overhead. It does not matter if your TPS report has a cover sheet or whether your standup is at noon or not. Nor does it matter whether you're using Trello or crayons. You're focusing on the wrong thing.
If we limit our discussion to teams located in one place using a physical board, I have noticed that standups that focus on the board, the work, happen with better teams. (They don't make teams better. Good teams tend to do it that way). A few useful tokens of testable work on the wall that people can point at and talk about how those goals are going tends to focus the conversation around value.
On the other end of the spectrum, large spreadsheets or online tools where each person reports on what they're doing usually show a completely waste of time and a death march. I worked with a VP once of a major corporation that kept a 100-300 line spreadsheet with "promises" he received from all his teams. We spent every Monday morning for hours reviewing each promise and talking about how we had failed the clan and dishonored ourselves. Oof. It was horrible.
Do you have any advice for someone in a senior IC role to actually get people setting the processes to shift their thinking from optimizing general metrics and making everything more homogenous, into a model where everything is contextualized (like your examples) and then we draw out higher-level patterns by analyzing the common traits that organically arise as a result of contextual solutions?
Ping me. I'm happy to provide any free advice I can over the phone as long as it has a chance of helping developers. HN isn't the place for this, however, as whatever I say is just going to open up a religious war. (Disclaimer: I am currently looking for new clients)
You hire a guy like me because they have a broad and long record of seeing various things work and fail. The first thing you learn is that it takes a lot of examples to start seeing patterns. The worse folks you can deal with are the enthusiasts who have only seen things rock-and-roll a few times. Skeptics are great. Let's go see what works or not. True believers are another thing entirely. Humility is critical here.
There are some things I've seen that work. There are also some things I've read from others that I trust. I've always been a huge believer in success by failure avoidance: it might not matter what you do as much as it matters that you're actively trying to avoid screwing up.
No matter what your mix of strategies, it's a personal call that involves risk and not a kind of conversation you want to have in a room with ten thousand people in it. It's something to think about for a while.
According to the author, standups are something companies require developers to do to report about what they're doing. Many times they can take more than a half hour.
That may be true, but the purpose of standups is that the team requires one another to get together and talk about how to move the project forward. It's not about what you did. That's a status report. It's about how you can help one another.
If you can self-organize, effectively communicate, and help one another as-needed without standups? Don't do them. Easy. There's no magic requirement that you have to. What we've found over the years is that if you give it a name and a time, at least you have a way to talk about whether it's working or not. Other people can drop by to help out. But if that's too formal for you and you don't need it? Stop!
Standups remind me of brushing your teeth. When they're working well, it looks like nothing of value is happening. Five minutes and people tell jokes and leave. It's when they're misunderstood as something else that they become useless and painful. Had to throw a SM out of his own team room once because he kept using standups as an opportunity to play "What's your status?". Nobody cares about your status. We care about how the entire team is working. Have some down time? Tell us you're free and then go play tennis the rest of the day or something. It's not a management, outside-in meeting. Just the opposite, in fact.
I love these articles because they remind us that the goal is what's important, not the ritual. Unfortunately, people get the two conflated, usually due to a lack of multiple-team/org experiences.