So for who's benefit are standups and "agile" in general?
It's for the benefit of managers who by their nature don't have insight into what's going on in general and they want the most superficial general overview of what everyone is doing.
For developers, I don't see any added value whatsoever. This applies to all pillars of agile, I could go on and on about this. Agile is only pseudo-beneficial for managers.
Everybody knows everything and then everybody(=nobody) is responsible when code breaks, giving the manager peace of mind but the developer couldn't care less: It's not like it was his baby.
Standups and agile are quite useful, especially for new teams or teams of greener developers. Which, in our growth industry, is 'most teams everywhere'.
If you're part of a team that's worked well for months or years, then the utility is greatly diminished. I think standups can gracefully fade away after some months.
Yes of course that can happen and I said so, which means that he should ask whoever is blocking him how to proceed. If he doesn't know who it is, he asks the manager and he will direct him to the right person. If there is literally no way to proceed, he will work on another issue in the meantime and inform the manager that he's blocked on the more important stuff. If there is some way to speed it along together with multiple other people, it will come up when he talks to that first guy. Obviously waiting for the next standup tomorrow is a ridiculous proposition, so standups solve a problem for 1 time of the day requiring by definition more people than should be required because everyone is in it instead of pulling the people in that need to be pulled in for that specific block or feature.
I don't even know how people defend standups, they usually say something like "hey yeah, I know it's mostly useless but it's just for 10min a day". Absolutely unacceptable. Now I get to the last line of your post, and it's such a relief: "I think standups can gracefully fade away after some months."
Well you should tell the other proponents of standups because I can guarantee you that this never happens.
Standups might be a good idea in the starting phase of a projects but frankly even then it's debatable and then you would just call them meetings.
Some folks don't think they need standups, ok. But in reality, many folks benefit from them.
There are at least one or two exchanges like this every week in my team:
Dev A: - I'm working on X, and will just need to fix the code for Y to handle it. It's a bit messy but I'm probably done tomorrow.
Dev B: - Eh... I think you need to do something to the Z code, we can take a look after the meeting.
Dev A: - Sure.
Is it? I haven't seen this very often and only with very junior engineers. Anybody with even a modicum of experience knows to ask for help when they're stuck. On the other hand, what I have seen all too often is an experienced dev blocking everybody else because of poor scheduling by the manager. Oftentimes, there's no way others can help with this. The dev knows what needs to happen, but it takes time and the dev just needs to do it. This makes every standup a humiliation. 'Is Joe still blocking Ted and Tara? Can you speed it up, Joe?'
In my opinion, processes are designed to resolve or prevent dysfunction. An extra-productive team member that completes assigned tasks and adds in some of their own creativity on top is generally not a source of dysfunction, so I prefer to encumber such people with as little process as feasible. I for one love engaged productive developers who deliver bonus features of the sort I mentioned above and I find over-processing curtails those bonuses.
I'm all for devs being involved in the process, but devs absolutely should not be making secret solo decisions on what features to build without consultation.
The last thing I want is to be surprised by a new feature just showing up unplanned in a project.
I dunno, perhaps you work on internal software for a small group of specific known users who sit a few desks away from you and that's acceptable to them, but for any team building a customer facing product that attitude would be a nightmare to manage.
When the managers stop doing this, we'll stop doing this. This adversity between engineers and management is one of the biggest reasons I hate the agile process as it is commonly practiced. It benefits management at the expense of engineering, thus creating animosity between two groups who are supposed to be working together.
Another bigger problem with beginners though is the "creative" beginner. For those a stand up is a good place to catch "I just started writing a parser for X to solve problem Y" when there already is a company standard X-parser that the beginner doesn't know about.
In this case just post the question of your team channel on slack.
If you are small and everyone is sitting close together at the same times, then maybe you have enough chemistry and passive awareness already and things can just flow naturally. That's amazing when it happens.
But there's lots of reasons it doesn't happen. Could be whether there are remote team members, or some team members are shy, or there is a general vibe discouraging interruptions and creating a chilling effect. In those cases, taking a couple minutes to share can be very helpful to keep people on the same page. Granted, every single day is probably excessive for this use case. Traditionally I've had best luck with once or twice a week.
As to capital-A Agile, I think it's even worse than you say: it ends up being used by consultants to justify their bloated bills. I would encourage you to go back and re-read The Agile Manifesto though, and realize that this is just what happens when good ideas are cargo culted and productized by the snake oil salesmen.
More generally though, I want to challenge the idea that something which only benefits managers is a waste of time. Good managers spend all their time doing things to help their reports, so why wouldn't developers want to take a chunk of time to help the manager do their job? As a developer it's nice to have your task and be able to focus 100%, but that will not be possible or effective if there is no coordination with an eye towards the end result. It can definitely work, but it requires ICs taking on managerial duties (even if they don't label them that way), and it is rarely as effective as having a good project manager once you reach a certain scale.
I'm also not knocking managers at all. I'm more than thankful for when they deal with clients and project management and solve inter-team issues and and and. That is real value that they are creating.
Using some a wiki is emphatically not the right tool for the job. If the personalities are such that you really don't want to have to talk to a group, you could use something like StandupMail.
Also as a single developer, it's entirely possible that you don't know what you don't know, and thus your estimate of value is dubious. As someone who built a product from 0 to 7M users and took a team from 3 people in a room to a team of 50, I can tell you that once we passed the 7 or 8 engineer mark but before we had bi-weekly standups, there was steady drumbeat of cases where the right hand didn't know what the left hand was doing. One way to manage this would have been for the PM to micromanage everyone, but given that the team was built of entpreneurial full-stack hacker types, it worked a hell of a let better for people just sync up as a group periodically.
Obviously you are entitled to your opinion, but also consider that the corner of the dev world that you inhabit is not representative of the universe of software development, and just because sometimes there is a cargo cult mentality doesn't mean that there aren't good reasons for some overdone practices.
I came to the same conclusion - standups are placebo for managers and nocebo for (at least some) engineers. Meaning, they have no observable effect whatsoever, they only make managers feel better and engineers feel worse.
Unfortunately, SCRUM (and many other methodologies) is not based on scientific method. If it was, then all placebos and nocebos would be weeded out during empirical testing.
A 15 minute standup means our team leader and I do not have to wonder what they might be doing or creating. They say what they are working on and we guide them. Daily we catch issues where they overly complicating something, or scared to ask for help, or doing any number of crazy things.
We are very laid back and don't have huge timelines. If someone doesn't show up or have much to say we don't even talk about it. We know they work hard when they do and standup is never about finding out if they are working or not. In a large enterprise the team leader has meetings all day and can't know what is going on when they have 10-15 people under them. The standup solves that issue.
It works great for us and no one has any issues. I'd much rather talk about what I work on for a few minutes each day than be micro-managed.
And if they seem to be competent, you can ask them less and less. Why do you need one-size-fits-all approach? I recommend this presentation: https://www.infoq.com/presentations/Developing-Expertise-Dav...
I should add: Maybe they will even appreciate it. Maybe they are not sure if they should talk to you because they worry they will rob you of your time.
My point was that what to do really depends on person.
I started on a new team a couple months ago and if it wasn't for the daily stand-up I would have no idea what was going on outside of the limited scope I've had a chance to work on.
More importantly, the scientific method relies on an oracle (nature) to tell us whether we're right or wrong. It's not so easy to apply when there's no conclusive way to know you're mistaken.
That said, I completely agree that standups are for managers. Someone once said that standups are to re-affirm that everyone reports to the manager, and pretty much nothing else.
If you use the rather stodgy and formulaic scientific method, sure. But if you approach this as a multi-arm bandit problem, and instead look at the question as "how much information do I need to collect with how much statistical power before I am justified in selecting an outcome?", it becomes quite tractable for a team to just try it out.
It also helps if instead of using merely "productivity" as your one and only goal that you also consider team happiness as a real and going concern. Then "Nobody likes it and it's demoralizing the engineers" becomes a perfectly valid form of feedback to use in the decision about whether to do it.
I also tend to use the metric that the brain is really, really, really good at figuring out what's important, sometimes perhaps even too good, so if we start a stand-up meeting plan, and it just sort of peters out, then I let it go. (Seems like somebody wants to try it every 2 or 3 years or so, I generally just let it happen and then evaluate.) Everybody's brains are coming to the conclusion that it's not important. Rather than fighting it, roll with it. There are some things in life where your rational forebrain must override the deeper instinctive algorithms about what is important, but that's quite cognitively expensive, and I've never seen any reason to believe that stand-up meetings are bringing enough value to justify that.
I emphasize the "I've never seen any reason". I hypothesize that in many ways, the work the teams I've been on have been doing is almost maximally pathologically bad for a stand-up meeting. Almost everyone is working on something independent of everybody else, so blockers are only rarely even possible. If your team is, on the other hand, chock-a-block full of blocking potential it may be useful to you.
Anyways, there's more ways to find out the truth of things that trying to split the universe into two precisely equal parts, make a change in only one of them, and come back ten years later to see what happened, only for someone to complain that a sample size of one isn't enough and we really need to do this a thousand more times to have a valid result.
You mean the scientific method that has proven to work since the 1700's?
I think we'll have to agree to disagree that you can just riff it and still get results.
The problem is, you'd have to find 100 projects where they care more about the scientific rigor of the experiment than they do about the results of the project. Good luck finding that with real-world projects.
jerf's approach gives you data that is less certain than you would get from a real scientific experiment. But it gives you data that is better than nothing, gathered in the real world. And you can actually run the experiment (at least in some environments) without getting fired, which is more than is likely true with a pure "scientific method" approach.
The "better than nothing" is precisely where this logic goes awry.
It's usually better to admit what you're actually doing: Going with your gut instincts. Pretending you're doing science adds fake legitimacy to your words and makes it easy to fool people. Unfortunately, the person you have to be concerned about fooling is yourself.
Not at all. If you're doing standups, try not doing them for the next month. If you're paying attention, you'll know if things got worse or better. Yes, that's anecdote rather than data. Yes, it's not statistically significant. Yes, it may be different outside your specific circumstances. But no, it's not just gut instincts - not if you're any good as a manager.
If you're paying attention, you'll know if things got worse or better.
Define "worse." In fact, define "better."
These are not qualities that can be measured until the company is either doing better or doing worse. And then you still have to figure out if the company is doing worse solely because of no standup meetings. Hence my original argument.
I'm not saying it's worthless to do that. I'm saying at least admit that it's not evidence-based science.
Now, you can still have confounding factors, because the project didn't stand still. You could have everybody waiting on a big deliverable from another team, for instance, in which case everybody's blocked, but the lack of standups has nothing to do with it. So you have to think about the results some, rather than just blindly accepting them. Still, it's better than just gut instinct, because it actually is an opinion based on facts.
Look up "multi-armed bandit"; it isn't just "riffing it" like you think it is. It is a mathematically-principled technique.
In fact, it is probably safe to say it's more mathematically-principled than the "scientific method" itself, as it is popularly understood.
But the main problem is - if people don't actually know if the standup meeting helps, they shouldn't recommend it as a part of SCRUM (or other methodology).
I know that in Agile, it's popular to say "if you think it doesn't work, change it". It's a first step towards scientific approach, but also very naive step - it can easily cause you to create rituals with no effects, just based on anecdotal coincidences.
It is kind of disconcerting. On one hand, I applaud the excitement of Agile fans for critical thinking and scientific method, but at least they could study it a little - to find out that there is a little more to it than just "if it doesn't work change it". And that they shouldn't propose things that are not properly justified.
Stop the meeting and instead of asking what people are missing, watch velocity.
The test of a productive team is spontaneous meetings, whiteboard sessions, and conversations. If people on your team are not getting up and talking, you don't have a team, you have independent contractors.
I've worked in a couple of shops where the company hired "Agile Coaches" and then assigned teams a dedicated Agile Coach. The Agile Coaches sole responsibility seemed to be to write up the sticky notes and do the physical moving of them to different swim lanes on the board.
It really felt we were having the standups solely for that person's benefit. I couldn't figure out what that person did outside of the 15 minute morning standup.
If your manager takes part in your daily, you're doing it wrong. The daily is for same-level coordination, not for hierarchical evaluation.
In a way, your dailies are to replace your manager, not enable him.
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.
It is great because:
1. Most of the time you skim the list, but sometimes want to follow up and collaborate. It helps ppl keep on same page and avoid redoing the same stuff.
2. Async, written as first thing when you come to work.
3. Writing todos and sharing them helps ppl to get focused and make them productive.
In one team I was coaching, we also experienced that standups improved when we switched to a kanban board and enumerating tasks on the board: We would not ask people "What did you do today", but pick a task and ask: "Who contributed to that task? Who thinks they can contribute?"
This made a huge difference (although there still were people that did not like the daily stand up - but less than before).
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.
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.
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".
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".
Recognising the existence of one-person teams might help a bit.
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.
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.
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.
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.
At my job, we meet for standup via video chat as early as we can. That's about 9am for some of us and 10am or 11am for others depending on timezones. We each say what we worked on yesterday and what we're working on now, which only takes about 5 to 10 minutes, then we enter what we call "parking lot." We call it "parking lot" because if this were an in-person meeting, this is bit where we would be talking in the parking lot on our way out to lunch. No one is expected to stick around unless there's something urgent related to what your working on that needs to be discussed. Anyone is free to hop off the call at this point.
During parking lot, we discuss impediments, anything that's going to keep someone from getting work done that day. If the problem is something complicated that's difficult to describe via text, we chat about it face to face and work out a solution together. If the problem is simple, we just agree to talk it out in either a public or private channel on Slack depending the kind of problem.
The purpose of the meeting isn't to build a big report of who's working on what or to guilt us into working harder. It's just to guarantee that we're all online at a given time each day to help each other out. Working across several timezones, we all have wildly different hours, and without standup, we would probably be waiting for days to hear back from each other about any issues we run into.
Maybe standup is a problem for other people or other companies, but for my team at least, we couldn't work without it.
I agree too.
Daily standup meetings help me to focus on my goals for the day. Communicating the same status in consecutive meetings makes me realize that I need to put more effort into progressing with a task so that I can report something new for the next standup. Standup meetings that go for more than 5 minutes per person are not ideal and the organizer needs to buckle up
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.
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.
"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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Tracking progress goes on a Kanban board (or digital equivalent).
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.)
"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?"
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.
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?
We need to stop approaching team development with the expectation that one or more team members will need checking up on because they're goofing off too much or not working on what they're supposed to be working on. Professional software development is a career, and we should be able to start all employer <-> employee relationships with the expectation that a) we're all adults, and will treat each other accordingly, and b) we're all, ultimately, responsible for our own work and the work of the team. If someone repeatedly demonstrates that they can't execute in this fashion, then they're gone. There's simply too much to do, and dragging the entire team down to the level of the least-responsible member is ridiculous. You're better off just distributing the extra work among existing team members.
For example: want the team to bond and communicate ? Ditch the daily meetings, and every Friday take the team out for a meandering late work lunch where everyone talks about the week, what they're working on, the overall project, etc. Any other time, everyone knows where the other team members are working - if there's something that you need, you ask in the least-intrusive way possible, depending upon how busy the other team member is and the importance of your task.
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...
Most of the time it turns into a beating stick for incompetent managers to feel good.
They are both defended by people for various superficial theoretical reasons that never come to fruition.
Like they try to defend open office because "it's good for collaboration" but in reality it's only to cut down office costs and to let employees watch each other.
If giving people private offices was much cheaper you'd never in a million years see a company accept the increased cost of an open office just because "it's good for collaboration".
This is a pattern that you can notice easily in business. Anything undesirable that is not good for you will be applied a lip-stick of colorful language in order to "sell" it to you and it goes right into the echo chamber.
You can put people in boxes that stack on top of each other and then say "Our beautiful stacked-box office promotes a culture of deep thinking and solitude where you can re-gain your focus and stay away from constant distractions.".
Were this testable, I'd absolutely take the other side of this bet. (Some) managers get too much satisfaction out of seeing their "doers" lined up and visibly working. And/or believe that watching one another makes people work harder. Open offices would happen, even at a premium.
Edit: actually, it kind-of is testable. If office costs were the biggest factor in how workers were deployed, we'd see far more remote work.
Please tell me when you open one of these, I might be after a job!
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).
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.
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.
So for who's benefit are standups and "agile" in general? It's for the benefit of managers who by their nature don't have insight into what's going on in general and they want the most superficial general overview of what everyone is doing. For developers, I don't see any added value whatsoever. This applies to all pillars of agile, I could go on and on about this. Agile is only pseudo-beneficial for managers. Everybody knows everything and then everybody(=nobody) is responsible when code breaks, giving the manager peace of mind but the developer couldn't care less: It's not like it was his baby.