You work. You do your job. If you're unsure about what task to do, you speak to your manager. You know, how offices have worked for the previous hundred years.
That's okay, if your team works in this fashion. You shouldn't cargo-cult stand-ups or any other aspect of Scrum.
It's important to realise that they are a tool, like any other form of meeting or organisational strategy. For example, if you find that your team are sometimes stepping on each other's toes, then a daily stand-up might be able to help with that. If you don't need them, then don't have them.
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 am just trying to say that you do not necessarily need a daily meeting to achieve these goals. And that you might get all the value from the daily scrum with something that better suits your team.
Provided only work that's in the issue tracker is worked on (thus avoiding work being done more than once by different people), I've never found 2. useful.
That is, the information has never been actionable for me, so it really doesn't matter what people did.
People SHOULD flag stuff they encountered that others should know about, but to me that's part of the 3. "what you need/can help on" category (essentially "anything you want to flag?" be it gotchas, blockers, offers of help etc)
Even 1. I find usually not useful, provided you do regular planning meetings (I like them to be weekly personally) where people are roughly assigned to areas and then just work off the backlog, although it can vary I suppose.
I buy into the peopleware model personally: status meetings are a distraction, other meetings need an agenda (with a clearly defined "end point") and be time boxed. Aligning people and sharing knowledge should be accomplished through informal "coffee morning" conference-breaks-hallway-conversation style events. Ideally an hour set aside once a week, purely for this. That largely covers the cases of people overhearing what you're doing and saying they can help.
In my experience, my team works so closely anyway that the standups don't add much, if anything, and the people who could benefit are not at the meeting (other teams basically). I've tried text updates in slack and that had the great side effect that other teams could see them and offer advice or help, but the downside is they're boring and people often don't read them. Informal coffee morning chats largely solve that in my opinion.
Besides peoplewares suggestions on meetings, I also really like the GROWS Method model of agile.
Having just finished a 5 week agile project with daily stand-ups I found:
1. I'm already aware of what everyone is doing which is relevant to my own work outside the daily meeting. Everything else is just noise.
2. I don't want to know what someone else did since the last meeting unless it was relevant to my stream of work, in which case I already know about it.
3. See above.
Needless to say I found the daily stand-ups a complete waste of time.
I'm intrigued by 2 - granted, it doesn't have to be part of a daily meeting, but surely learning about other workstreams is still a net positive? In theory it's still about the direction of the same organisation which is important, no?
I absolutely agree- I should have clarified I don't want to know about it as part of a daily ritual that is the stand-up. I'd challenge anyone to summarize what other people talked about during the stand-up right after the stand-up. I bet they don't know- because they were thinking about their own work they wanted to get on with after the stand-up. The only thing I remember from the 5 weeks stand up is when the client summarized what she had been doing the previous day with 'I was just faffing about' :).
I'll agree with that as well, most update meetings I've been in are mainly spent with being half-present whilst listening, and then mentally updating my own list based on how granular other people are being.
- Other works streams might not affect yours, but don't you find that it helps you to understand aspects of the project that will affect future workstreams?
- How do you or they know that it will have no affect on your area without the daily stand up?
- If someone is experiencing a blocker, you might have come across the same issue earlier in your career or even last week. Then you can help them.
These are all very valid points but I don't feel the need for a daily stand up to achieve them! Effective communication and meetings already achieve these things.
If your team has effective enough communications to not require them, then I guess they're not for you. For me, that has never been the case in any team that I've worked in.
No, because the moment a meeting starts allowing discussion it starts taking ages, and you've got your entire team standing there waiting for it to be over and it becomes an enormous waste of time.
Maintaining discipline for daily standups is phenomenally difficult.
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.
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.
"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...
Stand ups at an agency I am currently working for on a short term engagement just has people in the tech team listing what clients they're going to be working for today. You know, because that's very helpful for everyone to know....
I think the spirit of agile development is lost on most places and blindly sticking to process without questioning it becomes the norm.
"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.
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.
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.
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".
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.
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.
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.
>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.
> 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.
> 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 haven't done standup in 6 months and I just feel generally better. Where I work you just report to the tech lead every 2 or 3 weeks. So much nicer than daily standups. Could you imagine other professions doing what we do?
Where I work you just report to the tech lead every 2 or 3 weeks. So much nicer than daily standups.
This might work for some organisations, products or development styles. In my team of five, over a two or three week period we might have delivered half a dozen customer-facing features or changes, and the team will generally be working quite collaboratively on those. It would not be feasible to 'report to a tech lead every 2 or 3 weeks'.
Could you imagine other professions doing what we do?
Yes, and I think in some cases they would gain a lot from it.
Are your developers children who won't work together unless they are micromanaged by a lead?
Obviously not, and as I pointed out earlier it's clear that different organisational styles can work well for different teams and that's fine – please don't lower the tone of the conversation like that. My development team are experienced professionals, and because we are organised in a different manner does not mean that we are 'children'.
I'll give you some background which will maybe clarify our particular structure (that's not to say that there are no alternatives). My current project team is five people – three developers including me, a product owner/manager, and the 'head of development' who works across multiple project teams and serves in the organisational/administrative/scrum-master role. There is no 'lead' to report to, and while our 'head of development' is nominally the line manager of the development team, she is not responsible for product delivery and is there to provide general support and problem-solving rather than take progress reports.
We have a daily stand-up which lasts around 5 minutes (the other two developers are exclusively remote); 'sprints' last two weeks; each sprint starts with an hour-long planning session in which we as a group figure out the priorities with input from the product owner, figure out what technical work is required, and break it into deliverable and testable features. Then we go away and work for two weeks, demo what we did to the wider company, and spend an hour together doing the whole retrospective thing where we review what went well/bad/needs more work.
Everything is collaborative; I don't have to 'spend 1-2 full days together so we can "go deep"' with anybody, because all interested parties are consistently involved in the process. It works well, doesn't involve micromanagement, and everybody is happy. Obviously this is not the only way to run a team, but it's also not invalid or childish.
I'm sure you can understand that I'm kind of tired of bad teams with bad process blaming it on 'Agile' when their real problem is that they have poisonous developers or other underlying issues.
> Are your developers children who won't work together unless they are micromanaged by a lead?
This is black and white thinking. It depends on the personality type, but many developers have a tendency to go down research rabbit-holes or to think only about the tech and not about the business.
Therefore, a more frequent calibration to business goals may be necessary.
Well, I saw sales and HR do stand ups and retros mustered by the agile officers. It was imperative that scrum must fit all. Scrums of scrums everywhere. The agile singularity was reached.
>Could you imagine other professions doing what we do?
I worked in advertising before a tech startup and the whole rigmarole of standup, agile, scrum whatever felt like being back at school to me. Couldn't really understand why as professionals people couldn't be trusted to just get on with their work and know whats going on.
Had a chat with a colleague and mentioned this is the first place I've worked where you had to do this stuff and they couldn't believe it wasn't what was done in literally every workplace (this was their first job out of uni, but they were 3 years into it).
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.
We have switched to asynchronous, slack-based standups a long time ago, moderated by a bot (we're using a modified version of https://github.com/eelzon/morgenbot). This way everyone knows what everyone else has been up to, will be up to and what blockers are, without being caught up in endless discussions, and since it's asynchronous, people can supply their standup (within limits) at their own leisure. Works well for us.
Apologies if the repo makes this obvious. I'm on my phone. Do you maintain a virtual scrum board? What software do you use and how do you like it? I am on small scrum team and we all would like to go virtual for many reasons. Mostly we are from different parts of campus and the travel time eats productivity. And many of us have families that get in the way of the morning standup. A virtual one can be done from anywhere. Thanks for any help.
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.
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.
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.
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.
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.)
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.
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.
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.
> 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.
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.
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."
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.
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.
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.
"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.
> 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.
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.
[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.
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.
> "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"
> 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.
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.
Not very convincing. But standups should be tailored for team needs, rather than imposing a standard. And I don't get the role of a Scrum Master. Good article overall in terms of encouraging discussion.
I've worked both in a standard office setting and remotely. When I was in-office, I found the daily stand-ups tedious, because everyone was telling me stuff I was already aware of. But now when I am remote I find the stand-ups much more useful, because they are telling me stuff I don't already know. It's like stand-ups are overkill when the team is already working together in close quarters.
This is nice in theory, but I am afraid it fails quickly in practice.
I am a leftist, but I don't believe self-organizing works in situations where there is some higher level of control. People don't have incentive to self-organize in small scale, if there is some other big beneficiary outside their control. This is very abstract, so let me give two examples of what I mean.
1. In communist countries, sometimes, self-organization was tried on the level of individual state-owned companies (basically they were supposed to run as worker-owned cooperatives). It mostly failed horribly. But all of these countries were dictatorships with top-level, directive planning of the economy. So these "cooperatives" were still subject to larger plans, and that broke the incentive (or will) to self-organize.
2. Similarly, even though many companies try to have people self-organize, it falls flat because of the basic capitalistic premise - that there is an owner (or multiple owners) to the whole enterprise. This owner takes in a large amount of economic profit, which, if the team was truly self-organizing, would stay within the team. This breaks the incentive to self-organize. Why make something more efficient (even as a group) if some other people are going to decide how much you benefit?
So I think, taken my and your conclusions together, bad stand-ups are inevitable, except maybe in worker cooperatives (which are actually very efficient in capitalist economy, that is, if they operate entirely for the benefits of their own members).
I disagree with the premise that self-organization can only work when people are motivated by money. I believe that money is only a component of motivation, and sometimes a negative one. Intrinsic motivations like mastery and a job well done are much more effective in my opinion.
You should check out the book "Reinventing Organizations" which is a case study of 12 successful self-organizing companies and how they do it.
Also I'd like to hear your feedback to my post that shows how my team has accomplished it for over a decade and counting.
It's not really that much about money, as it is about that you cannot built a non-hierarchy at the bottom of hierarchy. The non-hierarchy must come from the top. Maybe there are some outliers for which it works out, because the top level management buys into it, but I don't see it happening in most normal organizations.
Self organization means that multiple wanna be dominant devs will attempt to make themselves leads - leading to ugly politics and constant attempts to micromanage other team members.
Single clear and accountable leader is much better way.
You've shown one way self-organizing teams can fail. That is not true for all teams.
I can similarly show a way a clear, accountable leader can fail: they can be good enough at politics to make a huge, micromanaged mess yet have all the blame placed on their team and get promoted. Just because sometimes it does happen, it doesn't mean it always happens ;)
Self organization witout accountability works when all of you are perfect and there is no pressure or blame game going on. It works only rarely. There are bad and good managers obviously, but most bad managers basically force team to self organize.
In any case, it takes only one team member to be aggressive micromanager in order to blow self organization in hell.
Alternatively, you can have democracy (either direct or representative). That solves precisely this problem. No matter what politics is played, in democracy, you always have the same vote. So fighting for power becomes meaningless (actually, not quite so, but it becomes possible for you not to get hurt even if you don't do it as a full time job).
There indeed are self-managed enterprises which use democratic principles (worker cooperatives), and they work quite well. However, I understand that people who try to sell "self-management" to companies avoid mentioning democracy, because, as I said, there is an elephant in the room and that is that the capitalist organizations (capital-owned) are fundamentally not democratic from the workers perspective.
I used to like standup because that's the only time I have to see what my team is soingnsince most of them are remote and working in a different time-zome. It was a great way to give tips and do the "okay let's talk about this offline afterward."
But now I hated it. Not only rhe standup is mismanaged ao badly, I also don't have much to update on a daily basis which means I feel useless if I have nothing to say or have little progress on my tickets.
The standup meeting can burn in hell. It's a lovely bit of useless micromanagement. Consider:
If you're organized at all, there should be notifications going out when anyone on your team commits code, or comments on tickets, or whatever. If your communications are so dysfunctional that you need to have a defined point every day to apprise people of what is going on or ask questions of your teammates, focusing on that root problem would be more effective than band-aiding it with a daily standup.
There's never a good time to schedule it. No matter when you do so, it's going to frig someone up and waste one to two hours of productive flow time, at best. First thing in the morning doesn't work, because people run late. Later in the morning, and you might as well kiss the whole morning goodbye for productive work. At the end of the day, it will inevitably run over and piss off everybody who needs to get the hell out of the office and take care of their personal obligations at the end of the day.
There's always one or two people that want to ramble along and narrate every little thing they did in excruciating detail. Or that want to turn an issue that turns up relevant to two people into an interminable status/planning meeting on that issue. Mostly, I'm just not convinced that there is any way to do a standup meeting right, so that it is useful for it's stated purpose without being more costly than it is worth.
If you need this kind of fine-grained progress reporting, have everybody send an email or a group chat with the three standup kindergarten circle-time questions answered. Then if there is an actual need to meet and go over something, you can identify the relevant people and not waste everyone else's time.
We ditched standup meetings a while back. It's been glorious.
I'm in a small team. I am the lone coder and I report directly to the CEO. I asked to do a standup because it's imperative for me to gain focus on tasks and frame my work. We used to have weekly status meetings but that was too infrequent. Instead of a weekly half-hour we now do 2-5 minutes of me standing in his doorway running through the "Yesterday I worked on [tasklist]. I am [not] stuck. I [don't] have resources for my tasks. Today I commit to work on [tasklist]."
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.
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).
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.
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.
If you're working in an interdisciplinary team you need to know what the other groups in your team are working on. Maybe if you're doing deep research or something, you can hide in your cave and focus purely on your own work, but if you're doing implementation rather than research, you have to understand all of what's going on.
But if you need to know what the others are working on, isn't it simpler to ask them at any time when the curiosity arises? Do you need to stand up and listen to what everybody is working on, every day, in order to do what you should do naturally, that is, be in touch with the members of your team?
In regular corporate settigns, I see these standup meetings are a way to simply make information flood across organisation hierarchy. A good leader can then parse and make sense of signal amongst plenty of noise. But it does rarely serves that purpose. We used to 've standup of 10 members several years ago! Since then I kind of developed disliking towards regular meetings. Currently we 've a trello-kanban updated so that we've information flowing. And a weekly mail with traffic lights, explaining current-and-next week activities - working well so far.
256 comments
[ 42.7 ms ] story [ 5600 ms ] threadIt's important to realise that they are a tool, like any other form of meeting or organisational strategy. For example, if you find that your team are sometimes stepping on each other's toes, then a daily stand-up might be able to help with that. If you don't need them, then don't have them.
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).
Goals are:
1. Discussion on who's doing what ( details )
2. Discussion on who did what, since last meeting.
3. Help / suggestions based on the conversations above.
I am just trying to say that you do not necessarily need a daily meeting to achieve these goals. And that you might get all the value from the daily scrum with something that better suits your team.
And in many cases, the precise details of what someone is doing aren't really relevant to everyone, either.
That is, the information has never been actionable for me, so it really doesn't matter what people did.
People SHOULD flag stuff they encountered that others should know about, but to me that's part of the 3. "what you need/can help on" category (essentially "anything you want to flag?" be it gotchas, blockers, offers of help etc)
Even 1. I find usually not useful, provided you do regular planning meetings (I like them to be weekly personally) where people are roughly assigned to areas and then just work off the backlog, although it can vary I suppose.
I buy into the peopleware model personally: status meetings are a distraction, other meetings need an agenda (with a clearly defined "end point") and be time boxed. Aligning people and sharing knowledge should be accomplished through informal "coffee morning" conference-breaks-hallway-conversation style events. Ideally an hour set aside once a week, purely for this. That largely covers the cases of people overhearing what you're doing and saying they can help.
In my experience, my team works so closely anyway that the standups don't add much, if anything, and the people who could benefit are not at the meeting (other teams basically). I've tried text updates in slack and that had the great side effect that other teams could see them and offer advice or help, but the downside is they're boring and people often don't read them. Informal coffee morning chats largely solve that in my opinion.
Besides peoplewares suggestions on meetings, I also really like the GROWS Method model of agile.
In my experience, the frequency seems to be more about maintaining a feeling of supervision.
1. I'm already aware of what everyone is doing which is relevant to my own work outside the daily meeting. Everything else is just noise.
2. I don't want to know what someone else did since the last meeting unless it was relevant to my stream of work, in which case I already know about it.
3. See above.
Needless to say I found the daily stand-ups a complete waste of time.
- How do you or they know that it will have no affect on your area without the daily stand up?
- If someone is experiencing a blocker, you might have come across the same issue earlier in your career or even last week. Then you can help them.
I can't understand what other people are actually doing when it's provided in 1-2min snippets each day.
Even after a few months of this I will be clueless.
Maintaining discipline for daily standups is phenomenally difficult.
Without asking, standups are counter-productive.
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.
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...
I think the spirit of agile development is lost on most places and blindly sticking to process without questioning it becomes the norm.
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.
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 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.
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.
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".
Recognising the existence of one-person teams might help a bit.
If the discussion can add more value than those costs, then go for it.
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.
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.
We shouldn't completely ban interruptions, but we shouldn't ignore the cost of them, either.
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.
This is highly context sensitive. The models I deal with when I develop software change very seldom, if ever.
Different projects have different cadences for inputs and outputs, even within this wide domain we call "software engineering".
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.
Stand-up meetings are dispatch, not processing.
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.
Sounds pretty much perfect to me (although I also know people who would go stir-crazy like this...)
Can I ask: what sort of company is this? Dedicated software operation or a tech department inside a company doing something else?
This might work for some organisations, products or development styles. In my team of five, over a two or three week period we might have delivered half a dozen customer-facing features or changes, and the team will generally be working quite collaboratively on those. It would not be feasible to 'report to a tech lead every 2 or 3 weeks'.
Could you imagine other professions doing what we do?
Yes, and I think in some cases they would gain a lot from it.
I meet with my manager once per month to ensure our goals are aligned. We tend to spend 1-2 full days together so we can "go deep".
In contrast I work with other developers almost every day.
Obviously not, and as I pointed out earlier it's clear that different organisational styles can work well for different teams and that's fine – please don't lower the tone of the conversation like that. My development team are experienced professionals, and because we are organised in a different manner does not mean that we are 'children'.
I'll give you some background which will maybe clarify our particular structure (that's not to say that there are no alternatives). My current project team is five people – three developers including me, a product owner/manager, and the 'head of development' who works across multiple project teams and serves in the organisational/administrative/scrum-master role. There is no 'lead' to report to, and while our 'head of development' is nominally the line manager of the development team, she is not responsible for product delivery and is there to provide general support and problem-solving rather than take progress reports.
We have a daily stand-up which lasts around 5 minutes (the other two developers are exclusively remote); 'sprints' last two weeks; each sprint starts with an hour-long planning session in which we as a group figure out the priorities with input from the product owner, figure out what technical work is required, and break it into deliverable and testable features. Then we go away and work for two weeks, demo what we did to the wider company, and spend an hour together doing the whole retrospective thing where we review what went well/bad/needs more work.
Everything is collaborative; I don't have to 'spend 1-2 full days together so we can "go deep"' with anybody, because all interested parties are consistently involved in the process. It works well, doesn't involve micromanagement, and everybody is happy. Obviously this is not the only way to run a team, but it's also not invalid or childish.
I'm sure you can understand that I'm kind of tired of bad teams with bad process blaming it on 'Agile' when their real problem is that they have poisonous developers or other underlying issues.
> It would not be feasible to 'report to a tech lead every 2 or 3 weeks'.
Yet there is nothing in your workflow that demands a daily standup either.
So really you are saying "We find standups helpful". That's a far cry from alternatives are not feasible.
This is black and white thinking. It depends on the personality type, but many developers have a tendency to go down research rabbit-holes or to think only about the tech and not about the business.
Therefore, a more frequent calibration to business goals may be necessary.
So it is a trust issue.
Surely you can see how this makes people feel they are being treated like children?
I worked in advertising before a tech startup and the whole rigmarole of standup, agile, scrum whatever felt like being back at school to me. Couldn't really understand why as professionals people couldn't be trusted to just get on with their work and know whats going on.
Had a chat with a colleague and mentioned this is the first place I've worked where you had to do this stuff and they couldn't believe it wasn't what was done in literally every workplace (this was their first job out of uni, but they were 3 years into it).
http://programming-motherfucker.com/
Well in that case I sure hope you're not planning on wearing one of those t-shirts...
Only to be judged by appearance by people who claim to have soft skills.
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.
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".
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.
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.
(But if there isn't a compelling reason to be counting the days, it's still nice to have the option to "go dark" for a few days sometimes)
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.
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.
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.
"Yes, I said the same yesterday, it's a big job, but it's going fine."
and, this is even more defensive, you feel people will not believe you so you invite them to see some proof:
"Anyone can come over and ask me about analytics if they like!"
Maybe the biggest problem is this though:
"Yesterday, analytics. Today, analytics"
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.
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.)
IMO, only for a small minority of tasks.
The vast majority of projects I've seen and worked on are measured in dev years of effort.
My current project is well over a thousand dev years.
In comparison a few days is meaningless.
Most often it's a trust issue.
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.
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.
Kind of. It's upper-medium.
It's nothing compared to Microsoft Office, a web browser, etc.
Microsoft for example has maybe 50k developers and so creates 50,000 man years of work every single year.
> Typical project size is somewhere around 500 to 1000 man days.
That's roughly 2 devs for a year. That's hardly even a prototype where I work.
It is fascinating to see the difference in scale in our industry.
Tracking progress goes on a Kanban board (or digital equivalent).
www.scrumguides.org/scrum-guide.html#events-daily
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.
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.
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.
The team knowing about whole thing won't make your job for you. It will just make them lash at each other unpredictably.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 ...
Wait, we created "agile". Haven't we?
Overreport and micromanage to deal with issues.
"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"
(later that year)
"Why have you lost your motivation?"
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."
(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.
Do you think that before standups were common developers just spent weeks spinning their wheels?
I think "bad stand-ups" is a symptom you are using a self-organizing practice in a command-and-control team.
I am a leftist, but I don't believe self-organizing works in situations where there is some higher level of control. People don't have incentive to self-organize in small scale, if there is some other big beneficiary outside their control. This is very abstract, so let me give two examples of what I mean.
1. In communist countries, sometimes, self-organization was tried on the level of individual state-owned companies (basically they were supposed to run as worker-owned cooperatives). It mostly failed horribly. But all of these countries were dictatorships with top-level, directive planning of the economy. So these "cooperatives" were still subject to larger plans, and that broke the incentive (or will) to self-organize.
2. Similarly, even though many companies try to have people self-organize, it falls flat because of the basic capitalistic premise - that there is an owner (or multiple owners) to the whole enterprise. This owner takes in a large amount of economic profit, which, if the team was truly self-organizing, would stay within the team. This breaks the incentive to self-organize. Why make something more efficient (even as a group) if some other people are going to decide how much you benefit?
So I think, taken my and your conclusions together, bad stand-ups are inevitable, except maybe in worker cooperatives (which are actually very efficient in capitalist economy, that is, if they operate entirely for the benefits of their own members).
You should check out the book "Reinventing Organizations" which is a case study of 12 successful self-organizing companies and how they do it.
Also I'd like to hear your feedback to my post that shows how my team has accomplished it for over a decade and counting.
It's not really that much about money, as it is about that you cannot built a non-hierarchy at the bottom of hierarchy. The non-hierarchy must come from the top. Maybe there are some outliers for which it works out, because the top level management buys into it, but I don't see it happening in most normal organizations.
Single clear and accountable leader is much better way.
I can similarly show a way a clear, accountable leader can fail: they can be good enough at politics to make a huge, micromanaged mess yet have all the blame placed on their team and get promoted. Just because sometimes it does happen, it doesn't mean it always happens ;)
In any case, it takes only one team member to be aggressive micromanager in order to blow self organization in hell.
There indeed are self-managed enterprises which use democratic principles (worker cooperatives), and they work quite well. However, I understand that people who try to sell "self-management" to companies avoid mentioning democracy, because, as I said, there is an elephant in the room and that is that the capitalist organizations (capital-owned) are fundamentally not democratic from the workers perspective.
But now I hated it. Not only rhe standup is mismanaged ao badly, I also don't have much to update on a daily basis which means I feel useless if I have nothing to say or have little progress on my tickets.
If you're organized at all, there should be notifications going out when anyone on your team commits code, or comments on tickets, or whatever. If your communications are so dysfunctional that you need to have a defined point every day to apprise people of what is going on or ask questions of your teammates, focusing on that root problem would be more effective than band-aiding it with a daily standup.
There's never a good time to schedule it. No matter when you do so, it's going to frig someone up and waste one to two hours of productive flow time, at best. First thing in the morning doesn't work, because people run late. Later in the morning, and you might as well kiss the whole morning goodbye for productive work. At the end of the day, it will inevitably run over and piss off everybody who needs to get the hell out of the office and take care of their personal obligations at the end of the day.
There's always one or two people that want to ramble along and narrate every little thing they did in excruciating detail. Or that want to turn an issue that turns up relevant to two people into an interminable status/planning meeting on that issue. Mostly, I'm just not convinced that there is any way to do a standup meeting right, so that it is useful for it's stated purpose without being more costly than it is worth.
If you need this kind of fine-grained progress reporting, have everybody send an email or a group chat with the three standup kindergarten circle-time questions answered. Then if there is an actual need to meet and go over something, you can identify the relevant people and not waste everyone else's time.
We ditched standup meetings a while back. It's been glorious.
Standup for me is making me accountable.
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.
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).
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.
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.
Nope.
That's simply too frequent.
People will spend all their day thinking about what they will present the next day instead of doing actual work.
Sure, but does everybody need to be updated every single day? And does that update have to take the form of an all hands meeting?
- if it's a status/reporting meeting - don't do it, there are better tools.
- if it's knowledge transfer meeting and it benefits a whole team - do it.
We were all shocked that a manager could justify wasting that much time every single day.
We have no standups since we all work on different projects, we don't really need to know what everyone else is doing.