In my opinion standups are mood killers.
If you need something, you ask for it anyway. Anything else would be ridiculous, you have a job to do and you need something from somebody so you ask. This is collaboration 101.
Yeah sure, there is some tiny possibility that person A happens to mention his approach to some task and person B happens to know a better way, but really that is such a motivation killer for several psychological reasons, but even more than that: How likely is that? It never happens anyway and if you know your colleagues, you likely already know if they probably can help you with something and you ask them for some pointers. If you don't do that, a standup isn't going to help you because you don't want help.
So for who's benefit are standups and "agile" in general?
It's for the benefit of managers who by their nature don't have insight into what's going on in general and they want the most superficial general overview of what everyone is doing.
For developers, I don't see any added value whatsoever. This applies to all pillars of agile, I could go on and on about this. Agile is only pseudo-beneficial for managers.
Everybody knows everything and then everybody(=nobody) is responsible when code breaks, giving the manager peace of mind but the developer couldn't care less: It's not like it was his baby.
On the other hand, its very common for a team member to get blocked and not know how to get unblocked. A (occasional) standup can get them past that. And one blocked team member can quickly become the long pole on the tent.
Standups and agile are quite useful, especially for new teams or teams of greener developers. Which, in our growth industry, is 'most teams everywhere'.
If you're part of a team that's worked well for months or years, then the utility is greatly diminished. I think standups can gracefully fade away after some months.
> On the other hand, its very common for a team member to get blocked and not know how to get unblocked
Yes of course that can happen and I said so, which means that he should ask whoever is blocking him how to proceed. If he doesn't know who it is, he asks the manager and he will direct him to the right person. If there is literally no way to proceed, he will work on another issue in the meantime and inform the manager that he's blocked on the more important stuff. If there is some way to speed it along together with multiple other people, it will come up when he talks to that first guy. Obviously waiting for the next standup tomorrow is a ridiculous proposition, so standups solve a problem for 1 time of the day requiring by definition more people than should be required because everyone is in it instead of pulling the people in that need to be pulled in for that specific block or feature.
I don't even know how people defend standups, they usually say something like "hey yeah, I know it's mostly useless but it's just for 10min a day". Absolutely unacceptable. Now I get to the last line of your post, and it's such a relief: "I think standups can gracefully fade away after some months."
Well you should tell the other proponents of standups because I can guarantee you that this never happens.
Standups might be a good idea in the starting phase of a projects but frankly even then it's debatable and then you would just call them meetings.
Green developers can not know who to ask (they're new, right?) or not know when or how to ask. They can be quite tentative. We're talking Engineers, not Sales guys.
Some folks don't think they need standups, ok. But in reality, many folks benefit from them.
I agree, even experienced developers can get stuck barking up the wrong tree.
There are at least one or two exchanges like this every week in my team:
Dev A: - I'm working on X, and will just need to fix the code for Y to handle it. It's a bit messy but I'm probably done tomorrow.
Dev B: - Eh... I think you need to do something to the Z code, we can take a look after the meeting.
Dev A: - Sure.
> its very common for a team member to get blocked and not know how to get unblocked.
Is it? I haven't seen this very often and only with very junior engineers. Anybody with even a modicum of experience knows to ask for help when they're stuck. On the other hand, what I have seen all too often is an experienced dev blocking everybody else because of poor scheduling by the manager. Oftentimes, there's no way others can help with this. The dev knows what needs to happen, but it takes time and the dev just needs to do it. This makes every standup a humiliation. 'Is Joe still blocking Ted and Tara? Can you speed it up, Joe?'
That is exactly how I see and have experienced it as well. It's part of why I called it a motivation killer but I didn't go into more detail.
Not only because of the accusatory thing but also I actually like to surprise my colleagues with cool features and issues I solve, surprising them with my speed even. If I attend a standup, I need to report that I'm working on these things so the surprise is gone. All my motivation to get them done asap is gone. Likewise, I can't do my own "secret" time planning anymore. I like to finish some mandatory feature fast so I can squeeze in a little extra cool thing I wanted to do for a long time. If I have to explain and justify this stuff, the manager will step in and urge me to do other mandatory things instead. It's such a mindkiller.
When I manage teams, I love having productive and self-motivated people like yourself on the team. As long as you are able to complete the scheduled and required tasks, if by being light-touch with process, you are motivated to contribute above and beyond, the whole team reaps dividends. I have seen such members contribute great tooling upgrades, features to reduce administrative overhead, automation mechanisms, and even delightful user-facing features.
In my opinion, processes are designed to resolve or prevent dysfunction. An extra-productive team member that completes assigned tasks and adds in some of their own creativity on top is generally not a source of dysfunction, so I prefer to encumber such people with as little process as feasible. I for one love engaged productive developers who deliver bonus features of the sort I mentioned above and I find over-processing curtails those bonuses.
This is exactly why you should be in a standup. "Secret" time planning and developing "cool" features. Someone has taken the time to carefully plan the features required for a project and make projections of how long that will take and how much it will cost. There may have been customer feedback on what features are required, or possibly even a customer is paying the costs of certain development work. And you think it's your job to just secretly decide that you don't want to do that, you'd rather spend time working on something cooler that the customers might not even want or perhaps conflicts with other project plans.
I'm all for devs being involved in the process, but devs absolutely should not be making secret solo decisions on what features to build without consultation.
The last thing I want is to be surprised by a new feature just showing up unplanned in a project.
I dunno, perhaps you work on internal software for a small group of specific known users who sit a few desks away from you and that's acceptable to them, but for any team building a customer facing product that attitude would be a nightmare to manage.
> I'm all for devs being involved in the process, but devs absolutely should not be making secret solo decisions on what features to build without consultation.
When the managers stop doing this, we'll stop doing this. This adversity between engineers and management is one of the biggest reasons I hate the agile process as it is commonly practiced. It benefits management at the expense of engineering, thus creating animosity between two groups who are supposed to be working together.
Blocked beginners usually know how to ask their way out of blockers without standups.
Another bigger problem with beginners though is the "creative" beginner. For those a stand up is a good place to catch "I just started writing a parser for X to solve problem Y" when there already is a company standard X-parser that the beginner doesn't know about.
I'm probably biased because I have for decades simultaneously worn both IC and manager hats, but I think you are overlooking the importance of passive awareness. It's not simply a matter of everyone knowing what to do and asking for help when they get blocked, there is serendipity and ad-hoc collaboration involved too.
If you are small and everyone is sitting close together at the same times, then maybe you have enough chemistry and passive awareness already and things can just flow naturally. That's amazing when it happens.
But there's lots of reasons it doesn't happen. Could be whether there are remote team members, or some team members are shy, or there is a general vibe discouraging interruptions and creating a chilling effect. In those cases, taking a couple minutes to share can be very helpful to keep people on the same page. Granted, every single day is probably excessive for this use case. Traditionally I've had best luck with once or twice a week.
As to capital-A Agile, I think it's even worse than you say: it ends up being used by consultants to justify their bloated bills. I would encourage you to go back and re-read The Agile Manifesto though, and realize that this is just what happens when good ideas are cargo culted and productized by the snake oil salesmen.
More generally though, I want to challenge the idea that something which only benefits managers is a waste of time. Good managers spend all their time doing things to help their reports, so why wouldn't developers want to take a chunk of time to help the manager do their job? As a developer it's nice to have your task and be able to focus 100%, but that will not be possible or effective if there is no coordination with an eye towards the end result. It can definitely work, but it requires ICs taking on managerial duties (even if they don't label them that way), and it is rarely as effective as having a good project manager once you reach a certain scale.
I don't think that I'm underestimating the passive awareness effect, I think it's very negligably useful. Not only that, it should obviously be solved by a great wiki-type solution that doesn't exist yet. It would be some kind of addon to jira or maybe one of those corporate facebooks that never quite took off or solved the problem that they were supposed to solve.
Solving this problem by forcing people to talk to each other in standups is just about the least scalable, least enjoyable solution possible .. especially for people who probably became programmers not because they like talking to people.
Inter-departement standups could work in theory but then you realize not everybody can attend because it would be too big of a group.
Then you end up with 1 guy of each team having to explain what the other teams are doing to their team.
I'm also not knocking managers at all. I'm more than thankful for when they deal with clients and project management and solve inter-team issues and and and. That is real value that they are creating.
I already conceded that daily standups are probably overkill, but you are going to great lengths to overestimate the cost of a standup. It's not unreasonable to spend 20 minutes a couple times a week to let your colleagues know what you're doing.
Using some a wiki is emphatically not the right tool for the job. If the personalities are such that you really don't want to have to talk to a group, you could use something like StandupMail.
Also as a single developer, it's entirely possible that you don't know what you don't know, and thus your estimate of value is dubious. As someone who built a product from 0 to 7M users and took a team from 3 people in a room to a team of 50, I can tell you that once we passed the 7 or 8 engineer mark but before we had bi-weekly standups, there was steady drumbeat of cases where the right hand didn't know what the left hand was doing. One way to manage this would have been for the PM to micromanage everyone, but given that the team was built of entpreneurial full-stack hacker types, it worked a hell of a let better for people just sync up as a group periodically.
Obviously you are entitled to your opinion, but also consider that the corner of the dev world that you inhabit is not representative of the universe of software development, and just because sometimes there is a cargo cult mentality doesn't mean that there aren't good reasons for some overdone practices.
I came to the same conclusion - standups are placebo for managers and nocebo for (at least some) engineers. Meaning, they have no observable effect whatsoever, they only make managers feel better and engineers feel worse.
Unfortunately, SCRUM (and many other methodologies) is not based on scientific method. If it was, then all placebos and nocebos would be weeded out during empirical testing.
I'm a senior lead on a team that had massive turnover and now has all new people. We support many large and complex web stacks. As a result the guys on my team don't always know how we do things. Many will agree to commitments they can't fill.
A 15 minute standup means our team leader and I do not have to wonder what they might be doing or creating. They say what they are working on and we guide them. Daily we catch issues where they overly complicating something, or scared to ask for help, or doing any number of crazy things.
We are very laid back and don't have huge timelines. If someone doesn't show up or have much to say we don't even talk about it. We know they work hard when they do and standup is never about finding out if they are working or not. In a large enterprise the team leader has meetings all day and can't know what is going on when they have 10-15 people under them. The standup solves that issue.
It works great for us and no one has any issues. I'd much rather talk about what I work on for a few minutes each day than be micro-managed.
I don't understand why you cannot ask your newbie members casually each day, what they are doing and if they have any problems? That way you can actually dig deeper than you can in standup - because standup is not to resolve technical issues.
Aren't you basically advocating for the dreaded shoulder-tap? As bad as a standup might be, I'd still rather attend something at a scheduled time than have someone randomly hovering at my desk for "quick sync up".
Yes. If they are beginners they shouldn't mind that. You can schedule a regular 1:1 meeting with them, why not, I just think that shoulder tap (or maybe a wink in the hallway) is easier.
I should add: Maybe they will even appreciate it. Maybe they are not sure if they should talk to you because they worry they will rob you of your time.
My point was that what to do really depends on person.
There are 10 of them and some work remote often. It's easier to get everyone in one place than to try and track down 10 people. I'm very busy getting work done myself as I'm not the actual boss of anyone, just a lead.
Because it is helpful for the new members to hear about what everyone else is working on as well.
I started on a new team a couple months ago and if it wasn't for the daily stand-up I would have no idea what was going on outside of the limited scope I've had a chance to work on.
Engineers in general probably know what they're about to do when they're about to begin things. Why not just have them habitually send updates on completed work and intended direction as things change, and intervene/help immediately when appropriate?
I want to agree, but there's no way to apply the scientific method to this case. Experiments would take at least several months to run, because it's not till several months that you know whether your business is going to fail solely due to the dev team. And at that point it's hard to run another experiment.
More importantly, the scientific method relies on an oracle (nature) to tell us whether we're right or wrong. It's not so easy to apply when there's no conclusive way to know you're mistaken.
That said, I completely agree that standups are for managers. Someone once said that standups are to re-affirm that everyone reports to the manager, and pretty much nothing else.
"Experiments would take at least several months to run, because it's not till several months that you know whether your business is going to fail solely due to the dev team."
If you use the rather stodgy and formulaic scientific method, sure. But if you approach this as a multi-arm bandit problem, and instead look at the question as "how much information do I need to collect with how much statistical power before I am justified in selecting an outcome?", it becomes quite tractable for a team to just try it out.
It also helps if instead of using merely "productivity" as your one and only goal that you also consider team happiness as a real and going concern. Then "Nobody likes it and it's demoralizing the engineers" becomes a perfectly valid form of feedback to use in the decision about whether to do it.
I also tend to use the metric that the brain is really, really, really good at figuring out what's important, sometimes perhaps even too good, so if we start a stand-up meeting plan, and it just sort of peters out, then I let it go. (Seems like somebody wants to try it every 2 or 3 years or so, I generally just let it happen and then evaluate.) Everybody's brains are coming to the conclusion that it's not important. Rather than fighting it, roll with it. There are some things in life where your rational forebrain must override the deeper instinctive algorithms about what is important, but that's quite cognitively expensive, and I've never seen any reason to believe that stand-up meetings are bringing enough value to justify that.
I emphasize the "I've never seen any reason". I hypothesize that in many ways, the work the teams I've been on have been doing is almost maximally pathologically bad for a stand-up meeting. Almost everyone is working on something independent of everybody else, so blockers are only rarely even possible. If your team is, on the other hand, chock-a-block full of blocking potential it may be useful to you.
Anyways, there's more ways to find out the truth of things that trying to split the universe into two precisely equal parts, make a change in only one of them, and come back ten years later to see what happened, only for someone to complain that a sample size of one isn't enough and we really need to do this a thousand more times to have a valid result.
So what would the scientific method have you do here? Take, say, 100 projects. On half of them, do standups. On the other half, don't. Measure the outcomes. Do statistics.
The problem is, you'd have to find 100 projects where they care more about the scientific rigor of the experiment than they do about the results of the project. Good luck finding that with real-world projects.
jerf's approach gives you data that is less certain than you would get from a real scientific experiment. But it gives you data that is better than nothing, gathered in the real world. And you can actually run the experiment (at least in some environments) without getting fired, which is more than is likely true with a pure "scientific method" approach.
jerf's approach gives you data that is less certain than you would get from a real scientific experiment. But it gives you data that is better than nothing, gathered in the real world.
The "better than nothing" is precisely where this logic goes awry.
It's usually better to admit what you're actually doing: Going with your gut instincts. Pretending you're doing science adds fake legitimacy to your words and makes it easy to fool people. Unfortunately, the person you have to be concerned about fooling is yourself.
> It's usually better to admit what you're actually doing: Going with your gut instincts.
Not at all. If you're doing standups, try not doing them for the next month. If you're paying attention, you'll know if things got worse or better. Yes, that's anecdote rather than data. Yes, it's not statistically significant. Yes, it may be different outside your specific circumstances. But no, it's not just gut instincts - not if you're any good as a manager.
A gut instinct is an instinctive feeling, as opposed to an opinion based on facts.
If you're paying attention, you'll know if things got worse or better.
Define "worse." In fact, define "better."
These are not qualities that can be measured until the company is either doing better or doing worse. And then you still have to figure out if the company is doing worse solely because of no standup meetings. Hence my original argument.
I'm not saying it's worthless to do that. I'm saying at least admit that it's not evidence-based science.
You can tell (even measure) how much of the time people are waiting for stuff from other people. That's the main thing standups are supposed to fix.
Now, you can still have confounding factors, because the project didn't stand still. You could have everybody waiting on a big deliverable from another team, for instance, in which case everybody's blocked, but the lack of standups has nothing to do with it. So you have to think about the results some, rather than just blindly accepting them. Still, it's better than just gut instinct, because it actually is an opinion based on facts.
I disagree. First of all, I am sure there are scientific ways to analyze things like this, scientists deal with phenomena like this all the time.
But the main problem is - if people don't actually know if the standup meeting helps, they shouldn't recommend it as a part of SCRUM (or other methodology).
I know that in Agile, it's popular to say "if you think it doesn't work, change it". It's a first step towards scientific approach, but also very naive step - it can easily cause you to create rituals with no effects, just based on anecdotal coincidences.
It is kind of disconcerting. On one hand, I applaud the excitement of Agile fans for critical thinking and scientific method, but at least they could study it a little - to find out that there is a little more to it than just "if it doesn't work change it". And that they shouldn't propose things that are not properly justified.
Meetings are velocity roadblocks. They rob energy and momentum.
Stop the meeting and instead of asking what people are missing, watch velocity.
The test of a productive team is spontaneous meetings, whiteboard sessions, and conversations. If people on your team are not getting up and talking, you don't have a team, you have independent contractors.
>"So for who's benefit are standups and "agile" in general?"
I've worked in a couple of shops where the company hired "Agile Coaches" and then assigned teams a dedicated Agile Coach. The Agile Coaches sole responsibility seemed to be to write up the sticky notes and do the physical moving of them to different swim lanes on the board.
It really felt we were having the standups solely for that person's benefit. I couldn't figure out what that person did outside of the 15 minute morning standup.
I could bet that was one of those coaches with 5 Agile Certifications and no proven track record. Good thing is not all Coaches are like this, but the good ones are actually hard to find.
We (the developers) took control over our standups. We went back to basics and talked about _why_ are we doing kanban boards standups, and found two reasons.
1) We do need better awareness of what others around us are doing, especially across the dev/ops divide.
2) Communication, kanban is there to show interested non-devs how projects are progressing.
We update the kanban before the meeting and let one person per day read through the entire board for today/ongoing/blocked. If there are any tasks that person doesn't understand – this is the time to ask.
The process takes often less than 10 mins per day.
Any issues raised will be discussed in loosely formed groups afterwards to not waste everyone's time.
I think what I learned is that you mustn't let process be shoved on you by middle management. Take control to make these things productive for you.
We have a slack channel. You write what you did yesterday, what you are going to do today. If you are blocked, what is blocking you. When you expect to deliver what. Everyone does it. As a reader, you skip the stuff you don't care much for. Pretty interesting though. Maybe ask someone for further clarification. Works great. I like to do it just before I leave for work. The only issue is some skill-less turkey with a title 'coach' can't make a buck, but I am sure he would pipe in and tell us we are doing it all wrong.
In fact we write plan for today on Slack and later modify me message to change what actually gets done.
It is great because:
1. Most of the time you skim the list, but sometimes want to follow up and collaborate. It helps ppl keep on same page and avoid redoing the same stuff.
2. Async, written as first thing when you come to work.
3. Writing todos and sharing them helps ppl to get focused and make them productive.
In one team I was coaching, we also experienced that standups improved when we switched to a kanban board and enumerating tasks on the board: We would not ask people "What did you do today", but pick a task and ask: "Who contributed to that task? Who thinks they can contribute?"
This made a huge difference (although there still were people that did not like the daily stand up - but less than before).
This. As an agile coach it absolutely boils my blood when non-programmers take over these activities with their own agenda. Who is actually doing the work here? The programmers, let them talk about what they need to in order to get their work done best.
> The process takes often less than 10 mins per day.
Yikes. That's worth pointing out and celebrating? The most crucial part of "standups" is in the name - a meeting so short you don't need to sit down.
Here's the thing with 'agile' and stand ups. Do whatever's best for your team. Do whatever helps you be productive as possible. Don't just throw the baby out with the bathwater.
However, in my experience, the IT industry is overflowing with pointless process meetings initiated by middle management.
My point was more to give a concrete example on how some (dev driven) initiative can give productive results which was sort of in line with the OP article.
"When it gets cancelled because a certain person is not there, you are doing the meeting for that person"
This rang true with my current team. It isn't that the meeting doesn't happen but it is extremely fast. No round robin, just a simple 'has anyone got any issues'. Nope, ok carry on. We still get high value from those discussions.
My personal observation is that when this senior person is there, they are using the stand-up as a project management meeting. This should really be 'taken offline' and this person should be working with team leads away from the stand-up.
Luckily I'm working closely with one of the team leads in an isolated area and I excuse myself from the meeting and let him talk on my behalf but I shouldn't be at that point where I'm trying to avoid them.
The other day 8 people did a stand-up for 27minutes. That's a crazy loss of time.
The other day 8 people did a stand-up for 27minutes. That's a crazy loss of time.
It's not necessarily a loss of time though.
The mindset "any time spent doing things other than writing code is a waste" rarely produces great products - you need to talk about things. No one knows everything about a project once it gets to a even moderately large size. Working in isolation from the rest of your team means you're not influencing, or being influenced by, the knowledge and discoveries that other people are making as they work. That means you're very likely to be working with an out-of-date model of the problem you're trying to solve.
Clearly a meeting where nothing happens is a waste of time, but the solution to that problem shouldn't be "no more meetings", but "better meetings with real outcomes".
It's more than a loss of time - there's also the context switch and attendant energy expenditure to restore the "head space" after escaping the meeting.
If the discussion can add more value than those costs, then go for it.
We did stand-ups at my previous employer and for some reason they happened early in the morning. That's my most productive time. I always thought we should move them to after lunch or maybe later in the day. In that office, productivity and energy definitely dropped as the day wore on and it seemed foolish to spend some of the best time in discussions.
I had the opposite problem, but it was a morning problem also. First thing in the morning, I am very foggy, and remember very little from yesterday. It is not until I've worked for an hour or two that everything comes back. Paged in from disk, so to speak.
So I often had to make things up on the spot to sound busy when I had no idea what happened yesterday at the crack of dawn. What a waste of energy.
>It's more than a loss of time - there's also the context switch and attendant energy expenditure to restore the "head space" after escaping the meeting.
Sorry - same thing. When GP is talking about "loss of time", he's not referring to "Oh, I lost X minutes of my life I'll never get back!" He's talking about lost productivity, just as you are.
And if a simple 5-15 minute meeting once a day saps your productivity so much, then what the GP is saying does apply to you: That you feel your job is just to sit on the computer and do software development.
And if you can't organize your work around that 5-15 minute meeting, you have other problems. You never take breaks during the day? This is just another "break", except it has a prescribed time. Plan around it! This isn't a "surprise interrupt" that occurs while you are working. It's not an interrupt, any more than your sleep is, or eating lunch is. It's a predefined part of your job.
Sorry, I'm not even saying standups are good. I'm not an advocate for them. But this attitude is silly.
If you are not getting value from the standup, improve the standup! Don't complain about context switching.
Context switching isn't free, so you shouldn't pretend like it is. You mention lunch, but that's a facile comparison: humans need calories, and if a person is in a flow they can take lunch solo and continue the thought process.
We shouldn't completely ban interruptions, but we shouldn't ignore the cost of them, either.
>and if a person is in a flow they can take lunch solo and continue the thought process.
And my question is: If you know there is a scheduled meeting at a given time, why are you trying to get in flow around that time? Sorry, that's just poor planning.
>We shouldn't completely ban interruptions, but we shouldn't ignore the cost of them, either.
No one's disagreeing with you there. No one is saying you should randomly take up lots and lots of meetings.
But I'd be worried if a developer - whether a colleague or one under me - said that a 15 minute meeting at a predefined time once a day is significantly impacting his productivity. That's usually a sign of him trying to solve the wrong problem - or a sign that he is not thinking the problem through.
I wish I could find the quote, but there's a famous quote from a SW manager saying that it's often cheaper for him to pay people not to code than it is to let them code a lot. Someone who is coding all the time (unless it is boilerplate work) is creating a lot of technical debt. Unless it is a cutthroat market, he should not be doing that.
If I were a manager, I would rather my SW developers:
1. Spend more time talking to the customer and refining their requirements (yes, I advocate more meetings than most people like) (part of solving the "right" problem).
2. Spend more time improving the infrastructure (automated builds, whatever).
3. Spend more time writing documentation.
I could keep adding to the list. If they are spending the majority of their time in "flow" mode, they are doing too little of the above, and in the long run, creating headaches for many people.
Frankly, writing code is a last resort. Almost all our code is to solve a problem, and a lot of code is an attempt to solve a social problem using technology. If my developer can solve the original problem without writing code, he deserves a bonus - not the guy who came up with a fantastic algorithm to solve it.
I'll grant there are niche roles where it is really beneficial to be in flow mode most of the day. But over 90% of the folks who want to be in that mode are not occupying one of those niche roles.
If you see flow as being time when someone is hammering away on a keyboard you completely misunderstand the concept. Flow is how developers avoid writing code.
That can be mitigated somewhat by having the stand up meeting first thing before people have started other tasks, but really that rarely works if people are interested in their work enough to get to the office early. You just have to take the hit, and readily accept that people will skip the meeting if they're deep in to something else.
The other time to hold it is just before lunchtime. This has the dual benefit of encouraging people to be brief (hunger is a powerful motivator ;-) and breaking at a time when people would have to break anyways. I also like holding it midday rather than the very start or end of the day because those times encourage staying late or coming in early to resolve an issue before standup. Lunchtime is also usually a time when everyone (apart from remote team members) is in the office no matter what schedule they keep.
Unless those eight people work on very closely related problems, there is little value in having all of them in the same room talking for half an hour. Communication doesn't have to happen with the whole team if different parts of the team work on different parts of the software.
What do you mean by "details"? The level of detail is highly context dependent. I'd argue that if there isn't a level of detail that all members of the team agree they should be interested in, then either the team is not composed properly or there is a misconception about the level of detail that is appropriate.
> The other day 8 people did a stand-up for 27minutes. That's a crazy loss of time.
But the whole point of a stand-up meeting is to keep it short. If you're talking for more than 5 minutes, the scrum leader or whatever you're calling them needs to reign it in. If you hit 10 minutes you're doing it wrong.
What I started doing after a couple of years of managing teams was to ask for average salaries per work function for my team, which has consistently surprised people when I ask (that this is surprising surprised and shocked me), and then send a weekly report to my boss - whether they wanted it or not - enumerating costs broken down by task.
Several times I've had managers that were confused why I'd send them this, or even insist it was a waste of time at first. Never once have I had a boss ask for this kind of breakdown themselves.
Then they'd see the result, and inevitably I'd get questions about how it could be right that e.g. (to take a number out of thin air) $5k worth of developer time every week was spent on meetings.
Or why that "tiny little change" that someone insisted on adding without proper scoping because it was so minor ended up costing $20k.
Pretty quickly those reports they initially didn't care about became mandatory, and it to some degree changed how people thought about resource allocation.
It doesn't need to be precise tracking either - you need to get the costs to about the right magnitude, and treat them accordingly depending on how you collect the data.
I agree with 'bad_user' here, to some extent. That is enough to give a manager a pause, but not to immediately dismiss it as a bad idea.
Most professionals will agree that it's unrealistic to believe that developer-typing-code-time has 100% efficiency. The time spent 'decompressing', which can sometimes manifest itself as spending time reading/doing unrelated stuff, does sometimes produce a solution faster than just banging away coding.
Management work is different from coding in that everything is hard and noisy to measure, so to some extent heuristics are relied upon, simply because it's the state of the art in this area.
So, even if half an hour meeting with 8 developers takes 4 developer-hours (which is a rather large number), it does not mean those hours are wasted. If one of those meetings a day stops someone spending one week chasing a dead-end known to others at least once in a while, on average the team moves faster, not slower.
BTW, I actually agree that 8 developers is too much, and that half an hour is too long for a daily. Just going off a tangent here.
The point is not that it is actually bad. Even 8 developers for half an hour could be justified.
The point is that it should give a manager sufficient pause to actually think through whether or not that cost is justified by what that meeting provides.
Surprisingly few teams account for the cost of the way they spend their time, and one outcome is that it's very easy for time sinks like meetings to go unchallenged because people don't think about how the costs multiply with the number of people involved. It's "only 30 minutes".
Costs which would require budget approval if it was scheduled as a project suddenly become ok because no single person spends much time on it per meeting and the time spent never gets recorded and reported on anywhere.
> The other day 8 people did a stand-up for 27minutes. That's a crazy loss of time.
What i see here is a team that let it happen.
A 'scum master' (or whoever) that oversaw the conversation and carried on with it. Developers (or team members) who talked for that long, and other people who _let_ it go on for that long and didn't put their foot down.
Man, where I work if a standup started going for half that time, people would just start walking away from it.
When the person who calls the meeting is sufficiently senior, walking away isn't always an option, unless you're prepared to also walk away from the job.
I'm seeing a lot of comments about how terrible different people's standup meetings are at their particular companies, and I can't help but think the problem isn't with standup itself, it's with these companies.
At my job, we meet for standup via video chat as early as we can. That's about 9am for some of us and 10am or 11am for others depending on timezones. We each say what we worked on yesterday and what we're working on now, which only takes about 5 to 10 minutes, then we enter what we call "parking lot." We call it "parking lot" because if this were an in-person meeting, this is bit where we would be talking in the parking lot on our way out to lunch. No one is expected to stick around unless there's something urgent related to what your working on that needs to be discussed. Anyone is free to hop off the call at this point.
During parking lot, we discuss impediments, anything that's going to keep someone from getting work done that day. If the problem is something complicated that's difficult to describe via text, we chat about it face to face and work out a solution together. If the problem is simple, we just agree to talk it out in either a public or private channel on Slack depending the kind of problem.
The purpose of the meeting isn't to build a big report of who's working on what or to guilt us into working harder. It's just to guarantee that we're all online at a given time each day to help each other out. Working across several timezones, we all have wildly different hours, and without standup, we would probably be waiting for days to hear back from each other about any issues we run into.
Maybe standup is a problem for other people or other companies, but for my team at least, we couldn't work without it.
Couldn't agree more with what you are saying here. Daily stand ups, if done right are very helpful especially for remote teams. I did daily stand ups at my previous company and they took on average an hour and were unfocused, meandering and generally pointless. I dreaded them and the whole team felt the same. By contrast, my current team is much larger but keeps the daily stand up to 15 minutes. It's focused and everyone is on page about tabling longer discussions for post stand up with the relevant stakeholders. While I won't ever say I'm looking forward to it, I see the tangible benefits. We are a remote team across multiple time zones and are able to effectively work together with ease. The daily stand up is a big part of that.
> I can't help but think the problem isn't with standup itself, it's with these companies.
I agree too.
Daily standup meetings help me to focus on my goals for the day. Communicating the same status in consecutive meetings makes me realize that I need to put more effort into progressing with a task so that I can report something new for the next standup. Standup meetings that go for more than 5 minutes per person are not ideal and the organizer needs to buckle up
The effort to say something about yesterday and about today is an obsolete overhead. Sometimes one is just stuck for couple of days with bloated and partially obsolete Java setup, sometimes one has done nothing and needs a break instead of daily confessions. Saying these might be perceived arrogant or disrespectful. I perceive standups as an immature way to discipline developers.
I really don't see why it has to be that way, and if people feel like that, there's something weird going on.
If you've been given a large feature that involves, say, analytics, there is surely nothing wrong with your standup contribution being:
"Yesterday, analytics. Today, analytics. Yes, I said the same yesterday, it's a big job, but it's going fine. Anyone can come over and ask me about analytics if they like! No blockers. Thanks."
It tells people what you're doing and that it's broadly going ok. If you're five days into something that was supposed to take three days and you're actively embarrassed about this, then that's a problem - but it's a problem that should be discussed at the end of the third day with the stakeholders, not in the standup.
[edit] Reporting on a high level ("yesterday - analytics, today - analytics") is fine only up to a point. This statement only works when team members are 1) mature (to admit problems) and 2) very self-aware (to accurately assess if they are making progress).
Unfortunately, huge percentage of people in software houses I've seen are young and therefore both immature and not very self-aware. They have a hard time recognizing the upcoming issues, and will not admit they made a mistake or are unsure if they can succeed on time.
The results? People claim they are on track, then they fail, goals aren't achieved. This happens over and over.
Eventually Project Manager or senior developers start probing more and more, dividing the work more, creating smaller (shorter) tasks to cater for less independent employees, adding short iterations, daily checkups and ...
This is why I regularly advise new hires, both senior and right out of college, that communicating when you're blocked or stuck is not optional. The quickest way to get me to recommend a performance improvement plan isn't if you can't hack it on a particular task, it's if you aren't clear that you don't have what you need (voodoo to get tools working, training, experience) to get the job done. Being stuck and not speaking up is a cardinal sin in knowledge work.
"This task needs to be broken up into manageable pieces badly."
This seems to be a sentiment I see a lot, but I don't think it applies equally to all people.
Maybe it depends whether the person doing the task is a mature worker (in the sense of doing independent work).
When you break things down, you make it easier for less experienced workers to complete work. It helps the managers with tracking progress.
However, increased breakdown is very costly on many levels. You need extra time to break things down (senior dev), extra effort to track it in project management tools, extra time to deal with it all every day. It's costly.
Moreover, dividing work that way is harder and less efficient for more experienced workers. They often dislike being micromanaged and probed multiple times a week (or day) about their progress. Give them space and they excel, but ask them to explain what they do, what's next, how much time is left, etc. and they get annoyed.
Mature workers generally know who needs to be informed of issues, recognize them early on, and proactively resolve those. "Process" is what you typically need when you don't have many mature workers. It's fine, but perhaps it's best to be careful who we apply it to.
> When you break things down, you make it easier for less experienced workers to complete work.
Actually you make it easier for everyone. The point of breaking down a task is to start removing assumptions, and make it so others can also lend a hand.
> However, increased breakdown is very costly on many levels. You need extra time to break things down (senior dev), extra effort to track it in project management tools, extra time to deal with it all every day. It's costly.
Time and again I have heard this reasoning, but in my experience the real costs comes when not breaking down tasks. There is an unknown unknown problem with large tasks, that is often solved by breaking them down with the stake holder instead of finding the issues during acceptance.
I do agree though that the right level to break down tasks is an art that ends up being team specific.
It's also so you can get the jump on risks as early as possible. Consider two projects, both roughly a week long. Project A is broken down into day-long tasks, and project B isn't. On day two, the guy doing project A reports he wasn't able to get milestone 1 completely done yesterday. Others can now step in and help if needed, after only a day. The guy doing project B, who reports "analytics yesterday, analytics today" needs to subjectively assess whether or not he's behind, and depending on how experienced he is at this, nobody will know until the sprint is blown that he was unrecoverably behind.
Personally, I find the "tasks must be tiny teeny as you can not manage task larger then few hours autonomly" management insulting - it feels like babysitting. Ok if one was irresponsible in the past or is too junior to work normally, but not ok if I was working alright.
The goal in small tasks, to me, is to encourage collaboration more than to micromanage. Sometimes you can get three free devs working on one story and turn it around in a day or two, but if it was all one "get the feature done" task, there are no opportunities there.
Fine grained efforts to "encourage collaboration" in places where it's not clearly needed is micromanagement. In fact, from an introvert's point of view, it could be the very worst form of micromanagement.
Agile only works for certain kinds of developers. In particular, it works well for people who are team oriented and communicate well, able to talk to the rest of the team to coordinate for at least 10 minutes a day, and responsible enough that they push themselves to deliver and get what they need from the rest of the team. If someone's an introvert who wants to be left alone to code, or to rely on a manager for all discipline, they need to be in a different environment, perhaps an old-school waterfall company where the manager hands out assignments and badgers people until they are done. I've done many agile transformations, and some developers just don't fit in agile, and are perfectly happy in waterfall, and that's fine. Though it might mean needing to find a new job.
I am ok having to talk with people for three hours or more a day. I am ok having to coordinate and having to respect other people's needs.
I am not ok with being micromanaged on hourly basis. I am not ok when I loose all autonomy and have no responsibility. The whole 10 minutes of talk you put in is nonsense - you won't be able to split large tasks into microtasks in those 10 minuteš a day.
Last point - waterfall vs agile is false dichotomy. So is the strawman of evil badgering management who stands against pack of developers who have all awesome social skills and are natural born benevolent leaders.
> The problem is you feel like you need to justify working on one thing for two days:
The problem is that the Agile industry caters to the fast world of write-only web site and app producers where the most complex thing is usually the decision whether a IAP purchase should be 0.49 USD or 0.99 USD.
The fact that there might exist some actual real-world problems that map to features that take weeks to month to implement and are not trivially decomposable is completely foreign to them.
It may be foreign to the "Agile Industry" but I've worked on a complex re-implementation of a dynamic language and supporting libraries on the JVM which involved a lot of quite complex problems and various agile techniques served us extremely well.
Having said that the team should be the ones driving this sort of thing - we switched between scrum and kanban several times depend on the nature of the work, and we kept looking at what we were doing to see if it was helping us, and when it wasn't we stopped doing it or changed it.
> but I've worked on a complex re-implementation of a dynamic language and supporting libraries on the JVM which involved a lot of quite complex problems and various agile techniques served us extremely well.
Any specifics? I would have imagined this to be a case with very strict up front requirements with a relatively heavy toll on changing the design during the project.
Actually, agile was first invented for writing mission critical enterprise software more effectively - thus the emphasis on test-drive-development and a very tight confirmation loop with the users. The fact that it also works well for web sites is great, of course, but it's not where it started.
This task needs to be broken up into manageable pieces badly.
This would also be my immediate thought as well. "Yesterday I setup integration with the analytics service. Today, I'm going to audit the places where we currently send analytics and see if it would be possible to centralise it – I'll share the results later".
It's hard to track progress and estimate if your tickets are huge multi-week affairs.
> It's hard to track progress and estimate if your tickets are huge multi-week affairs.
So what you are saying is that the standup really _is_ for project tracking. I don't disagree. In my experience that has been the main point to the meeting, but it's not really how it's supposed to be done according to agile doctrine.
The point of the meeting is often (A) let management/outsiders assess progress across devs with minimal time investment on the manager's part, and (B) put subtle pressure on the devs via the daily confession.
No, standups should not be for project tracking, it's a quick synch up and opportunity to raise issues. (e.g. My task is blocked until X is done). Then you resolve the blockage outside of the standup, in a longer, deeper discussion with fewer people.
Project tracking should be in a Kanban board (or digital equivalent, such as Jira or TFS). This should be used by the dev's so that they know what work is queued up, what work is in process and who's working on it, and what is completed, so that they can do their jobs. In an agile team most of the management is externalized onto a Kanban board - the team manages itself most of the time, using the Kanban board to have a shared understanding of what's going on. A secondary benefit is that outsiders can look at the Kanban board to assess progress, without consuming any dev time.
The "subtle pressure" on the dev to deliver is a great point. In fact, when status is completely transparent, developers put a great deal of pressure on themselves to deliver, because they want to honor their commitments, and there's a social pressure not to be "that guy" that blows the sprint.
While I don't mind daily meeting as such, if communication between ream members works at least half well, you should not need special occasion to raise the issues. You raise them wherever you see other team members are not focused on something.
As for second paragraph, I prefer management style that accepts that things sometimes take longer then estimated. I don't want to stay longer because made up deadline.
So what you are saying is that the standup really _is_ for project tracking
Only in the sense that the team needs to know itself how work is progressing, in order to understand what they can realistically achieve, or to estimate more accurately, or to identify pain points that need to be resolved. Not tracking in the 'report to an external agency how much is being done every day', which I agree is awful.
The point of the meeting is often…
I maintain that is this happens, you are in a bad environment.
> Only in the sense that the team needs to know itself how work is progressing
That's what retrospectives, demos, and stories are for.
If there is concern about individual performance, managers could create dashboard of their teams' git commits, allowing them to jump around and see peoples' work passively without disrupting the entire team.
When developers pull tasks, their name goes on it. If one dev keeps pulling tasks that don't get done, or take far too long, that becomes obvious to the whole team quite rapidly. That doesn't "disrupt" the team at all.
You don't need whole team to see that. You need to go to that one developer and ask him why tasks are not finished. I case he has solvable problem, you get the chance to fix that solvable problem. In case he does not, you need to watch him more and maybe eventually fire him.
The team knowing about whole thing won't make your job for you. It will just make them lash at each other unpredictably.
Right. The point is you don't really need them to stand up every day to say "still working on tasks A, B, and C". You'd just look at the board and say, "Hey, you have four things assigned to you. Are they blocked? Otherwise, please do one thing at a time."
I think some organisations have deeper problems [than developer communication] which SCRUM and Agile are simply not equipped to cope with.
Here’s one example:
* Moving functionality from a legacy^2 to legacy (mainframe to client-server)
* Target system groaning under 15 years of neglect, developer outsourcing, technical debt and band-aids. Source system simply untouched for nearly 20 years.
* Source and target systems inherently un- unit testable
* Mediocre developers with no intrinsic sense of craftsmanship nor any desire to acquire some
* Developers with no experience of legacy codebase so completely unqualified to estimate cost of stories
* Culture of fear reinforced by performance reviews, stack ranking and PIPs
* Locked down QA systems and silo’d resources
Any one of these would be a project killer but my last employer suffered from all of them in the same project and showed no inclination to address any of them because they were deemed to be out of scope. But it was totally fine to tie up 10 people for 15 minutes every day to enable the PM to derive a magical velocity curve to feed back to the stakeholders so that the company could demonstrate how effective this SCRUM process was going to be.
A thousand man-years of effort? Sounds like a very large project.
Just for contrast: I've been working for a medium size software house for the past 4 years. Typical project size is somewhere around 500 to 1000 man days. On that scale, individual days matter.
Still, I also have the impression that they matter because Clients demand certainty and precision in reporting rather than focusing on actual value delivered, but the management doesn't always see it that way.
Is it really important to track progress on a day to day basis?
It depends on the team.
We find it useful specifically because we want to make sure we are estimating relatively accurately. Since we work in essentially 10-working-day periods, it's great to know when a piece of work we thought we could easily achieve is actually a blocker, or much more complex than we thought.
Daily standups aren't for tracking progress, they're for keeping the team in sync, and in particular are a forum for raising blockers/dependencies so that they an be addressed.
Tracking progress goes on a Kanban board (or digital equivalent).
> The Development Team uses the Daily Scrum to inspect progress toward the Sprint Goal and to inspect how progress is trending toward completing the work in the Sprint Backlog.
Thanks one and all for the responses to my comment, which was written in some haste but seems to have generated useful discussion nonetheless.
Just responding to this one, I would say that it really depends. If your task is implementing analytics and no one else on the team has anything much to do with it, then maybe it's best not to trouble them with the specifics. Your summary is much better, and only a few extra words, but if no one really cares about the analytics except to know that it's cheerfully in progress, maybe it's not all that necessary to go into more detail. This is definitely something you need to be wary of in a multi-disciplinary team.
Also, I didn't mean "Anyone can come over and ask me about analytics if they like!" to sound defensive - it was actually more tongue-in-cheek! Here's another attempt: "I can't imagine why you would want to bore yourself with my analytics implementation, but please come over and ask me about it if you're having trouble sleeping at night." (I will freely admit that I am a confident person and would have no trouble saying something like that in front of a dozen people.)
> "Yesterday, analytics. Today, analytics. Yes, I said the same yesterday, it's a big job, but it's going fine. Anyone can come over and ask me about analytics if they like! No blockers. Thanks."
"You're not transparent enough. It feels you are blocked and you're not communicating. The task is too big, we will divide them more next sprint"
Basically this. If you're working on a large decoupled task, no-one else (other than team lead) has to know or care what you're doing other than that you're not waiting on anyone else. The moment your work has to interact with someone else's work, then you need to know what each other are doing.
As in a high-bus-number way? Not necessarily. We're talking about a few days here, not someone going off in a silo for months on end. If your standards for documentation, testing, etc. are reasonable then the results of their work should be maintainable by any team member after they're done.
Saying these might be perceived arrogant or disrespectful. I perceive standups as an immature way to discipline developers.
If this is what's happening in a team, then there is something more broken than unnecessary stand-ups.
It should be perfectly acceptable to talk openly an honestly about the things that you have or have not been able to do. If you're in a situation where you have to 'hide' the work you have been doing, then your team atmosphere is poisonous and avoiding stand-ups is not going to fix that.
If you're in a situation where you have to 'hide' the work you have been doing, then your team atmosphere is poisonous and avoiding stand-ups is not going to fix that.
Unfortunate office reality is that it's sometimes beneficial to withdraw by "hiding" your work or by not contributing openly to a discussion. The benefit is in avoiding (negative) spotlight, avoiding additional work or pressure, or similar consequences. This can happen even in an otherwise happy and supportive environment. If you're not pushed too hard by anyone, you can become complacent and settle on doing less. You can argue this is poisonous, but I'm not sure many people would call those "low ambition" or "low stress" or "hands off management" environments poisonous.
> Sometimes one is just stuck for couple of days with bloated and partially obsolete Java setup
That's the whole point of the standup. If I was stuck with something like some "Java setup", whatever that is, I'd let others know. Maybe someone will pipe up and say, "Oh yeah, I've seen that before, just do x", or "Let's get together after the standup and try to figure it out together."
Sometimes that's the right answer, sometimes it's better to just hit your head against it for a while.
(This can be an individual thing, I'm definitely a learn-by-doing type and need to be "spinning my wheels" sometimes. Others benefit from talking things through).
It would be nice to be trusted to make this call rather than having a ritual to force the talk-things-through option every time.
Yes. Exactly. 99% of the standup is allowing people to help each other and dynamically set their agenda for the day. If it's a status report or just a bunch of people trying to make up cool-sounding stuff they did? You're doing it wrong.
Team-oriented software development has become somewhat infantilized, and it's a worrying trend that keeps showing up in our society, in general.
We need to stop approaching team development with the expectation that one or more team members will need checking up on because they're goofing off too much or not working on what they're supposed to be working on. Professional software development is a career, and we should be able to start all employer <-> employee relationships with the expectation that a) we're all adults, and will treat each other accordingly, and b) we're all, ultimately, responsible for our own work and the work of the team. If someone repeatedly demonstrates that they can't execute in this fashion, then they're gone. There's simply too much to do, and dragging the entire team down to the level of the least-responsible member is ridiculous. You're better off just distributing the extra work among existing team members.
For example: want the team to bond and communicate ? Ditch the daily meetings, and every Friday take the team out for a meandering late work lunch where everyone talks about the week, what they're working on, the overall project, etc. Any other time, everyone knows where the other team members are working - if there's something that you need, you ask in the least-intrusive way possible, depending upon how busy the other team member is and the importance of your task.
I disagree with the basic premise of this: "When it gets cancelled because a certain person is not there, you are doing the meeting for that person".
One person being the driving force behind making something happen doesn't imply that all the benefit accrues to them at all.
"Just make sure everyone is actually recording what they are missing!"
Except they have no way of recording the opportunity cost - they don't know what they haven't been told; they could be missing something huge, but without a venue for communication they don't find out.
I have to say, I don't think this is great advice.
"Except they have no way of recording the opportunity cost"
This is a very good point. I have to think about it more.
Still, as an independent consultant, I have seen some teams who get close to 0 value from their dailies (while others got tremendous value). And just trying to change some small things about the dailies will probably lead to no results.
"One person being the driving force behind making something happen doesn't imply that all the benefit accrues to them at all."
Well, if nobody goes to the daily just because a single person is missing, you have a problem. Right? Even if that problem is only that the others do not recognize the value they are getting...
This isn't great advice because this isn't advice. It isn't advice because there's nothing actionable here. The only thing I'll say you can do if you're in a team like this is try to find your way out. Your "team" is already doomed and beyond saving.
I do some contracting from time to time with a devshop that has gone "full agile" - I love these people, and have a lot of respect for the work they do, but OH. MY. GOD. save me from the fucking standups. What a totally useless waste of everybodies' time. I refuse to attend most of them in any case, which harms my standing with the project managers, but I seriously don't care - most standups as well as the majority of other project management activities they practice appear to be designed to keep the project managers happy, and contribute little to the overall quality or speed of delivery of the project at hand, and are a massive distraction to everyone involved. Daily $project_management_ritual should die.
Daily standup is a scam just like the "open office".
Most of the time it turns into a beating stick for incompetent managers to feel good.
They are both defended by people for various superficial theoretical reasons that never come to fruition.
Like they try to defend open office because "it's good for collaboration" but in reality it's only to cut down office costs and to let employees watch each other.
If giving people private offices was much cheaper you'd never in a million years see a company accept the increased cost of an open office just because "it's good for collaboration".
This is a pattern that you can notice easily in business. Anything undesirable that is not good for you will be applied a lip-stick of colorful language in order to "sell" it to you and it goes right into the echo chamber.
You can put people in boxes that stack on top of each other and then say "Our beautiful stacked-box office promotes a culture of deep thinking and solitude where you can re-gain your focus and stay away from constant distractions.".
If giving people private offices was much cheaper you'd never in a million years see a company accept the increased cost of an open office just because "it's good for collaboration".
Were this testable, I'd absolutely take the other side of this bet. (Some) managers get too much satisfaction out of seeing their "doers" lined up and visibly working. And/or believe that watching one another makes people work harder. Open offices would happen, even at a premium.
Edit: actually, it kind-of is testable. If office costs were the biggest factor in how workers were deployed, we'd see far more remote work.
You can put people in boxes that stack on top of each other and then say "Our beautiful stacked-box office promotes a culture of deep thinking and solitude where you can re-gain your focus and stay away from constant distractions.".
Please tell me when you open one of these, I might be after a job!
I've been at my current job for 5 years and spent my previous 15 at 7 different jobs combined. It's not an accident that I've stayed at this one but left all of the others. This is the one where people are allowed to be responsible for their own productivity without overhead like standups, project managers, status reports, task tracking software, etc. It couldn't work for all people or all companies, but it means enough to me to manage my career around finding the environments like this one that make me enjoy coming to work so much more.
In the aspect of scrum the daily is good defined, I don't think you need to experiment about what needs to be talked about.
It is a one time a day meeting where everyone gives a glimpse over what he has done and how this may affect others and what he is going to achieve until the next meeting. Committing to a goal motivates me to get things done. A third aspect is to give the scrum master feedback about impediments which do prevent me from achieving my goals.
And yes this does not mean that nobody is talking to each other through the day. But even if you are a team it is important to get everyone up to date. Most discussion through the day happen between 2 or 3 persons, and not with everyone (4-6 people).
I agree with author... instead of doing "Scrum", how about we act like adults, and speak with people when we need to, in respect to their time, schedule accordingly, and not clown and parade around with scrum and poker cards.
There are a whole bunch of legitimate reasons that aspects of Scrum are useful to some teams. Like the planning poker thing –I work with a team of talented, experienced and professional developers, and we still have misconceptions about complexity that are revealed by the planning poker approach.
The idea that 'if everyone just programmed it would be fine' is totally asinine.
that's not how I meant it. Sure, plan it, however it suits you and the team. If planning poker works for you, great. But do you need to coat it under "Scrum", having special moderators such as Scrummaster and consultations every year how you are not doing scrum "enough". I don't advocate programming anarchy, but I don't like when managers treat programmers like some woodchoppers that they need to wrap fine grained process around, instead of having the team work the way it fits them best.
I completely agree that 'agile' without being agile is just buzzword bingo, and I've been through it myself. Ultimately, plan however works for your team. But I do get the impression generally that there can be a lot of unjustified resistance to any kind of organisation among certain groups of developers; it pays to be open-minded about techniques that can work.
I think the resistance is not unjustified - mostly programmers are fed up with "these" things, since they always get misused against them (i.e. - estimations - you and me know how it works, that it's well, estimation - but in back there is manager who translates it in his excel to $$$ and time, and the second your 8point story is now day overdue you are being pushed to zones which only further damage the project down the road (costs which you will have to pay by overtimes, not the guy behind his excel). Does that mean estimation is bad? No. It's non-programmers who misuse it. Would team be better without estimation? Probably, since it wouldn't be misused by external elements, and we could just do our damn job).
Perhaps the original agile was meant correctly, but as of today most organisations just use it to justify and coat (perhaps) same things agile was to be against.
For me today Agile has so way too many faces. If it doesn't work, answer is always "you're not doing agile/scrum correctly). There are always reasons how you're not being agile enough, no matter how many times you fine-tune your "agile" on retrospectives, if there are managers and people misusing it against you, you could as well be better without it.
What an incomprehensive piece of text I wrote. Sorry. I'm not native English speaker.
If you're lucky non of this applies though, but you have to be lucky enough to work with lots of (prehaps we might say all) smart people across whole "chain of command".
Any links to those studies? Although don't think we're interested in scrum vs waterfall. We all agree that iterative development is better than waterfall.
Yes, but if everyone speaks to you whenever they need to, you might be interrupted in your work very frequently which can be stressful. If only people could communicate all of these issues say once a day or so...
Yes. And at that point, you will suggest, like an adult, to speak when it fits both time. I wonder how people who don't use Scrum solve this problem!
Here's little experiment. 10mins after standup is over, ask some people what did they learn in standup. I mean specifics. Noone will know or care or remember. Sure, people get broad picture, which they could just as well by looking onto jira or whatever.
I've worked at one of these "no software process" utopias, where programmers just sat in their own world programming away and guess what? Software barely got released, it was always late, low quality, and nobody from management to individual contributors had any big picture visibility whatsoever. It was a total circus. They didn't even use source control or have a bug tracker. Absolutely 0/12 on the Joel test. I was brought in to provide some adult supervision and you better believe I layered on the process.
We made a little progress, but unfortunately, you can add process but changing culture is much harder. At the end of the day I got quality and release cadence under control, got a roadmap and a spec together, got basic "table stakes" software infra and tools up, but boy were those first few months a nightmare. I can't imagine any business getting anything done with just "programmers programming".
I mean this in the nicest possible way. Your experience counts for nothing. It's a one-off. Literally.
> I was brought in to provide some adult supervision
> I can't imagine any business getting anything done with just "programmers programming".
Your attitude and your arrogance will definitely limit your ability to lead engineering teams. Talented developers are not going to work with someone like you as long as they have a choice. I do recommend taking a coding bootcamp type course and delivering a project to gain a better understanding of how software projects work.
So for who's benefit are standups and "agile" in general? It's for the benefit of managers who by their nature don't have insight into what's going on in general and they want the most superficial general overview of what everyone is doing. For developers, I don't see any added value whatsoever. This applies to all pillars of agile, I could go on and on about this. Agile is only pseudo-beneficial for managers. Everybody knows everything and then everybody(=nobody) is responsible when code breaks, giving the manager peace of mind but the developer couldn't care less: It's not like it was his baby.