Thank you Rakia for your response. I understand where you are coming from, and I often see similar things in dev teams. I make for living helping teams and organizations to deploy agile or Scrum right. Or to manage knowledge-intensive organizations better.
I can see in your article, and in your response misconceptions very similar to what I see in my practice. That triggered me to write my comment. Including these few observations:
- People moving among organizations, so it is common to see people having "Scrum experience" from previous teams or organizations. Unfortunately, in my 10+ years of work in Agile, I saw only a few teams working in a real Scrum. The rests were crippled versions, rebranded waterfalls, or pure chaos. People have no place to learn Scrum properly because such good places are not so many.
- Crippled Scrum is a result of a lack of training, misunderstanding of some events or artifacts, unsupportive culture, lack of knowledge at the level of the team members, attempts of trying to insert the Scrum way of work into hierarchical or matrix structures, command and control operation mode, micromanagement, submissive team members, ... and many more.
- Many "teams" I visited were not teams at all, just a bunch of individuals, who were pretending they are together because some manager said so. Equally bad was when a team member was a member of multiple teams in parallel.- In real teamwork, we interact often, and we organize the work the way it supports appropriate interactions at an appropriate time. Performance evaluation is then always on a team level, not on an individual.
- Daily is a coordination tool FOR the team. It is not to report to somebody like a Scrum master or boss. It is to update the status from yesterday, put everyone on the team on the same page, execute mental check-in (in the morning), and assign today's work among members so everyone knows what to do, what to expect, dependencies, last-minute changes, or simply all. We expect all that is planned is also done. We monitor progress toward the goal and plan for corrective actions. In a well-organized team, the entire Daily can be done in 5 min. All team members are mentally present and participate in this, so no just response to 3 questions. Therefore a cognitive load is always much higher than just only who is doing what. Here was my comment about other industries, because SW development from this perspective is identical to any other industry. They do it for decades, just do not call it Scrum.
- There are many more things the team member must handle during the sprint/iteration. Innovation, onboarding new members, peer work, learning about the business domain, risk management, sometimes the economy, etc. Work is not only about writing code. Scrum provides here the luxury of helping people focus at one time on one thing only.
- The great team optimizes their work routine, they have allocated time for focused work with Flow. And they have time for coordination/mini-standups during the day, brainstorming sessions, handling exceptions, helping each other, and external collaboration.
- The work in the Scrum team is not about happiness. It is quite intensive work in a team. If somebody is a very heavy introvert, he might be not that comfortable with it. Agile and Scrum are not for everybody, it is for high-performing teams and it is one of the original motivations. Good and quality work as a result brings fun and joy. For some maybe happiness.
- Coding is in my book more about engineering than about art, although some artistic part is present. A disciplined approach is what matters. There are rules, best practices, and team agreements, ... all of this makes it easier, faster, or of better quality. I think the trend is to automate it so AI will be involved in writing code. The team can focus on designing the solution.
I see daily stand-up as an important activity for teamwork and I can't see any reason why it should be so "annoying" when there are many other activities the team has to do, which sometimes are indeed annoying.
