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 shoul...
For further actions, you may consider blocking this person and/or reporting abuse
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:
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.
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.
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.
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.
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.
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.
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.
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.
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.
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?
Reviving an old thread, because a debate over standups on LinkedIn led me here when Googling things to quote from scrum[dot]org.
You don't need a standup meeting (ironically, the people defending them in the aforementioned LinkedIn debate keep insisting that standups aren't meetings, contrary to scrum[dot]org and showing what a cult the Church of Scrum has become). It is helpful to know, though, what team members have done in the last 24 hours, are doing in the next, and what their blockers are. But yeah, forcing everyone in the same spot 15 minutes every day is pointless.
Set up a DailyBot and move on with your life. You get a dashboard everyone can view throughout the day, instead of trying to remember what everyone said while standing and waiting for the MEETING (lol) to end.