Do we need standup?

Rafal Pienkowski on August 13, 2018

Some time ago I read an interesting article about agile methodology made by an engineering lead at Spotify. As we know, agile is a tool which sho... [Read Full]
markdown guide
 

If the team is all working together on one feature at a time, I think the daily Scrum stand-up is invaluable.

The point of the daily Scrum stand-up is for the team, as a team, to complete the feature before moving on to the next feature. So it helps communicate with each other where things are at. What needs more attention, who needs help, what tasks are being added due to discovered work, et cetera.

But that is moot if the team isn't working as a team.

If the members of the team are all working on different features concurrently, I think the daily Scrum stand-up is a waste of time.

In which case the team is really working as a bunch of separate Scrum teams where each team has only 1 team member. And the daily Scrum stand-up becomes a status report, about where all the other "1 member Scrum teams" are at, which is of no value or interest to every other "1 member Scrum team". But may be of interest to the Product Owner and/or Project Manager, keeping tabs on how things are progressing on the many different feature projects happening concurrently.

Such status reports can be done more quickly and effectively in email.

 

Yep, I totally agree with that. As a developer, I wouldn't want to work with a team that doesn't do stand ups.

I applaud anybody who experiments with their process, tries different approaches and doesn't do something only because everybody else is doing it. But then I get sad when they write articles titled you don't need x meeting and make their point with a paragraph like this:

Standup has always bothered me. It usually serves to interrupt developers, make them feel pressured to prioritize features over tech debt, and has been known to last longer than 1/2 hour.

Many people think that having a meeting is as easy as opening your calendar tool, writing a title, adding a few people and sending out the invite. If the meetings are not properly planned, structured and facilitated, and the participants don't understand what is the agenda, the purpose and the expected outcome of a meeting, it is most likely going to be a waste of time. But the problem is not that you're having the meeting, the problem is that the way you do the meeting sucks.

Stand ups are not going to work out of the box if nobody around knows how to actually run a good stand up, but once you figure them out, they are really helpful. I've joined many teams with awful stand ups. None wanted to ditch stand ups after we added some structure and started asking the right questions, and many of them agreed that they were possibly the most helpful part of their process.

 

It is unfortunately necessary to have a lot of meetings when a team is new, reformed or has a lot of new people coming in. They are needed in order to establish a working cadence and to share information. As a team matures, they can make decisions on the meeting frequency and type based on their experiences.if information sharing isn't working or if user stories are constantly being blocked, then more meetings may need to be added back in.

 

True story. First interactions are most important in new team creation.

 

I’m all for the ”minimal meeting” rule. I am, however, having some problems with the reasoning behind the arguments put forth by the author.

Letting all devs freely prioritize working on technical debt instead of implementing features that adds business value sounds out of touch with reality, to be honest. As a dev it sounds awesome though :). Personally I always ask myself; what can we do to add maximum business value at the lowest cost. This is a question to be asked in a conversation between product owner, system managers, tech leads and scrum master (or whatever roles that may exist). This kind of approach lays the foundation, which upon future prioritizations can be decided by the product owner (not the devs).

Once again, as a developer, his reasoning sounds great and if it yields good results for his team that’s also awesome. It gets me a bit curios on how he reports back to his boss. I’m guessing his alone in analyzing the result of his teams efforts and if they are in line with the mission his team has and the goals of the company.

 

Letting all devs freely prioritize working on technical debt instead of implementing features that adds business value sounds out of touch with reality, to be honest. As a dev it sounds awesome though :).

It is somewhat counter-intuitive at first glance, but it makes total sense if it is setup appropriately. When devs are not going through a business unit or manager, and instead are directly responding to customer needs themselves. Then they won't prioritize refactoring as highly as you would think. They will have a real customer with a real need in mind when thinking about work priorities. Whereas when their manager tells them "no you can't refactor because adding new value is more important" the decision seems arbitrary and uninformed. Because the manager does not understand the pain and risks of the technical debt as fully as the devs do. So dev teams that directly work with customers have the best information and the most stake in choosing correctly, being answerable to customers.

 

Whereas when their manager tells them "no you can't refactor because adding new value is more important" the decision seems arbitrary and uninformed. Because the manager does not understand the pain and risks of the technical debt as fully as the devs do.

I would argue that the manager has failed in that case :) The manager, or product owner, must be able to communicate what and why, in a manner that convinces the team members that they are putting their effort in the right places.

But I agree with you in general, working closely with the end users leads to good things. But I would also like to mention another side of that story. Having devs exposed to end users without being guarded by a product owner or manager can at times become an unbearable situation for the devs. Becoming over-flooded with requests and expectations. The dev might also be unexperienced, maybe they're working in a domain where it requires several years before you have the knowledge necessary to grasp the bigger picture.

Well it is exceedingly hard to find good managers IMO. But in general, a product owner does not have to convince the team. Backlog items are not really optional. And if a dev places a technical debt story on the backlog, it will not likely get prioritized by the PO. Until such time that the product manifests systemic problems due to that technical debt. (But by then it is really hard to fix.)

The problem is that the product owner only has half the picture... what customers want. And in the situation where the devs are shielded from the customer, the devs also only have half the picture... the state of the code. So they will eternally be deadlocked into POs wanting features and devs wanting refactoring. But the PO "wins" because they control the backlog. (And here, devs sometimes just mix it in amongst other stories so they don't have to go thru the PO.)

Addressing technical debt has valuable long-term impact. The primary fear of allowing devs to refactor whenever they want is in wasting time by chasing the trends. Here it helps to have someone experienced on the team, because they have already been burned by this. They should be able to weigh the tradeoffs of new tech and guide the team, rather than being blinded by shiny newness.

 

Based on my experiences so far, I would be all for the minimum meetings rule. I'd say that we follow it pretty closely in my current team. Here's why.

In smaller teams, I have found stand-up is of limited value. I've probably already talked to the person about the things we would mention in stand-up. And if they have questions for me, I'd rather them ask right away instead of saving it so they have something to mention at stand-up.

I also despise estimation (aka planning) meetings. At the end of the day, you don't really know what it will take until you get into the implementation. What does have a lot of value and might be worth a meeting is to talk through what the implementation might look like. That could also inform a rough estimate (like t-shirt size estimates). Trying to estimate down to hours is a waste of time. It is rarely accurate in my experience, so it just puts unnecessary stress on the team. (Not referring to consulting work of course, which has different constraints.)

The idea behind retrospectives is solid, but I rarely found retrospective meetings valuable. Because it usually consisted of the Scrum master trying to get people to talk who felt like they had nothing to say. It was awkward and uncomfortable. Just like with stand-up meetings, I had rather address process improvements as we discover them and skip the meeting.

 

I also truly despise time estimations. It’s bad in several ways. They’re rarely correct and therefor creates unnecessary stress on the team down the line when deadlines aren’t met. They also makes you think about yourself and your teammates as a unit of work instead of human beings. When you come into work in the morning you’re bringing a lot more value to the work place than just X hours of code production.

Story point estimation, on the other hand, has always felt fruitful. Not concerning too much about what number the team finally agrees upon. More of a way to ensure that everyone has the same view of the task at hand.

 

Our team operates this way, accidentally. I have been recently trying to promote agile/scrum within our team but I'm getting push back. The thing is, though, we are getting work done faster than ever before. I consider that a success. Maybe we CAN succeed in agile/scrum with "minimal meeting" rules.

 

The question is: What is the purpose of "standups"?

I think the main purpose is distribution of information.

In order to do effective standups, one should ask the question: who needs which information.

If there is a bunch of people who work on interdependent work, it could make sense to bring this people into an active exchange via standups.

OTOH: If you have a really self organizing team, I see no reason for standups, since every member lets others know, if they need help or provide value for others.

Standups are a way to encourage good communication practices, but not needed when you have already working communication structures.

 

I agree with you. As you mentioned if the self-organized team doesn't see the purpose for the daily standup because there is no such need, we shouldn't force them to that, especially if there they haven't any communication issues. In another case, I will opt for the meetings.

 

we shouldn't force them to that

I think, this is the main reason for "agile" or "scrum" fatigue: If you want to do "orthodox scrum", you have to play by the rules - even if they do not make sense in your context.

 

Probably that xtreme workflow works for engineers that work alone or in small groups, without QA, UX and UI designers that need status updates and chat back and forth. Also without juniors and mentees that can learn a lot just by participating at these meetings.

I usually dont need standups, as the dev, but the other team members need.

 

I think this apprach is also good for teams working together in one room. In that case conversations between team members are natural and there is no need to set up dedicate meetings.

In opposite to you, I, as a Dev, think that daily meetings are crutial in my wiek. I like to know what others are doing.

 

I really think we waste a lot of time on meetings. Or maybe this time would not be so lost if we were prepared better. The "waste" comes - in my opinion - from the fact we are engaged in discussions we have no impact on, or this impact is minimal.

 

I agree that lack of preparation and out of the topic or diving into details discussion they destroy a standup meeting the most.

 

We went from a "minimal meeting rule" to a more structural approach with stand-ups, planning and so forth. It really benefited our project.

Before the revert to common agile, the project was in chaos. Twice a day priorities changed. We had no idea what the status on our projects was. When a feature was done, the feature was actually just started. It resulted in feature branches of 3 months worth of work, which were impossible to review in a merge request, created a weekly Git hell and in the end were buggy and still feature incomplete.

Because we need to plan our sprints, we now need to specify the requirements on an issue. If something is not in the definition of done, it is out of scope for that issue. In this case the sum of its parts is less than the total (regarding amount of work).

We've gone back to agile for the short period of three sprints now. However, I feel like we've been more productive in the last month than the half year before that.

I agree that teams shouldn't do agile because the book says so. It works for our team. It might not work for another team.

 

Interesting article, and I would agree with some of the benefits described in it but still think its important for there to be some meetings.

I have had a mixed experience with Agile. In the past I worked for an employer who was very over the top with Agile and so much time of every week was spent on the PROCESS of agile rather than actually DOING the work. As such projects would take ages, often meandering along for years.

The best project I have ever worked on was run with an "Agile Light" philosophy (as the project manager would describe it) where we did not have stand ups every day, and only had 1 retro at the end of the project. We were encouraged to work collaboratively together to solve problems as they arose, which really helped the flow of the development of the project.

The project manager would visit the people on the project individually each day or 2 to check if any blockers or issues and take care of them, but otherwise mostly left the developers (and others) to get on with the work planned for the sprint.

This involved some degree of trust and self responsibility to raise any issues with the project manager that they needed to know about, and actually get on and do the work.

Every week we would have a meeting with the client to report on progress, show and tell, and discuss larger topics or issues. Day to day we were allowed direct contact with the client - via email or slack - to ask smaller questions, technical things etc as the need arose which again helped with the flow of development.

Also we did not bother with a physical Kanban board with tickets. We found using our online user story ticketing system much better to track planned work for the sprint, the status of stories, etc was much better as all staff no matter where they were located - and even the client - could access it and see the current state of things.

The question I would propose to people reading this is: how much of your project's time and budget would you rather spend on development than meetings, arranging tickets on a board, retros, and other aspects of the agile process?

code of conduct - report abuse