You are sipping your morning coffee and going through your inbox when you notice it’s 8:58 AM. In 2 minutes, you’ll have to join the “daily stand-up” (even though you are all sitting down!?). You feel discomfort in your belly, and the reason isn’t bad coffee.

The fact that you’ll have to waste at least 15, possibly even 45 minutes of your valuable time telling others the status of your work erases the smile you had after returning from a weekend in a mountain cabin with your family.

Besides your “regular” work, you also had a “quick” fix your Product Owner asked you to address, and your “regular” work suffered. You will probably get grilled and asked, “What is your impediment?”.

The perfect meeting to ruin the start of your day. 

Lots of antipatterns to unpack here, right? For the team to be empowered to do daily Scrum properly, the Scrum Master or Product Owner must understand that the team is not reporting to them. Even when the team is empowered, they usually see it as just another Scrum meeting. It is also challenging to balance between crushing a possibly brief discussion that could detect some dependencies and prevent another meeting and letting the team discuss because it seems they will reach a conclusion soon (but they don’t). 

The three daily questions 

Ah… Those “three daily questions” you must answer: 

• What did you do yesterday? 

• What will you do today? 

• What are your impediments? 

Except those were not the three questions (the latest Scrum guide omitted them). They are missing the crucial ending: “…that helped the Team meet the Sprint Goal.” The fact that most teams butchered these three questions could be why they were removed from the latest version of the Scrum guide. 

To be blunt – nobody really cares what you did yesterday if it does not concern them or the whole team. Team cohesion is built by a joint (Sprint) goal. Coming to the daily, no one should think in terms of (only) what they are doing (or did). They should ask themselves:

• What do I need from other team members to reach my and the team’s goals for the day? and
  
• How can I help others reach theirs as well?”

I’ve found that these two questions reduce the amount of time people spend talking about “what they did or will do,” and team members are much more focused on interacting with each other. 

Don’t ignore the Sprint goal! 

A common goal is a prerequisite for a team.
Without one, people don’t have a reason to communicate progress since everyone just has a list of tasks to complete. It creates team cohesion and motivates everyone to discuss important things daily. It creates focus and changes the tone of the conversation from status reports to inspecting and adapting to achieve that goal. 

In that case, the Daily becomes a place where team members look forward to participating in discussions, sharing progress, and cheering when the User Story is moved to the Done column. 

Hmm, okay, who will share the screen…? 

In certain situations, when the team is not yet familiar with the collaboration tool, I support sharing the screen every few days in a round-robin fashion. In my experience, this helps them become more comfortable when they need to contribute to writing stories, tasks, assigning them to sprints, and generally visualizing their progress. 

However, after a few sprints, this becomes a sign that team members don’t know where they stand in terms of progress toward their goal. If all the tasks are up to date and well-commented, and everyone on the team can access the board, what’s the point of reporting on every single task? It speaks more of a lack of commitment than anything else. 

A mirror of team dynamics 

If your daily Scrum feels pointless, the problem is probably not the daily itself. It’s just a mirror of team dynamics or a management style that is not in line with agile values and principles. 

If the team is newly formed and working remotely, don’t be afraid to use the daily to build the team. Don’t shut down normal human interaction, like sharing stories from the weekend, just because you “need to be done in 15 minutes.” It’s wiser to use it to build team spirit rather than making them instantly hate the meeting by asking for every trivial update on their tasks. 

Daily as a check-in 

If you’ve worked in a team that had some kind of team coach, you were probably asked to start a meeting with a check-in. This is a good tool that facilitators use to allow team members to take a moment and mentally commit to the meeting. 

Similarly to meeting check-ins, the daily should be a moment that helps you enter the workday with thoughts about what you need to get done, what your goals are, with whom you need to collaborate, and what kind of help you need to be productive that day. 

This ritual should also help us distract ourselves from things happening outside work—like a bad commute or the picture of your crying child as you dropped them off at kindergarten. 

It should help team members focus on accomplishing personal and team goals for the day, detect potential risks, commit to delivering what others expect from them, and, equally important, share small wins together. It’s the breath you take before diving in for 8–10 hours. It better be a deep one. 

The post The Daily (Buzzkill) Meeting appeared first on ShiftMag.

Scrum makes peace when there is war, bringing together business people and developers. Defined like that, it sounds like a win-win situation.

But then, if one is a Scrum Master, there is a good chance that many people don’t like them and that their role is greatly misunderstood. When you mention Scrum to developers, they won’t hesitate to express negative opinions, criticize, and make fun of it. At best, they will say Scrum Master is a fictional or non-existent role.

To find out if Scrum and Scrum Masters deserved the hate, we talked with Josip Osrečki, a developer turned Scrum Master and a Head of Business Agility at Devōt, a mid-size development agency.

Why people don’t like Scrum?

If we look at the early examples of agile stories before Scrum appeared, people didn’t like project managers either. There has always been this negative attitude towards organizational structures that impose rules, and Scrum is usually imposed on employees. The resistance starts because it comes with new concepts like backlog and sprint, Josip explains:

A big problem lies in the heap of new words that aren’t tailored to programmers. If someone came to me with a completely new framework and started throwing words like refinement and retrospective at me, I’d resist at first.

Another reason people don’t like Scrum is because organizations don’t use it correctly. When it’s not used correctly, it becomes Zombie Scrum. Josip compares it to driving a car:

It’s like driving a car. Someone tells you to go left, and then go right. It would be best if you thought about the goal and how to reach it.

We have a daily, ergo, we do Scrum. It’s like thinking you’re smart just because you have a brain.

Scrum brings people together in one team

Scrum is a perfect tool that enables short feedback loops and product development in small increments so that something can be validated in time, Josip points out:

You create a small part of the application and check if it works. Incremental development is significant in software because of its complexity.

Bringing developers and business people together in one cross-functional team solves the problem of long feedback loops. Also, it eliminates situations such as developers hating the business analysts who wrote 100 pages of documentation or business analysts blaming the developers for taking too long to do the job.

When you make all the teams sit together, then people start talking in a different language, Josip explains:

As a developer, I have learned that there is a customer out there who has requirements, not just my code. The business analyst knows that some technical requirements are not easy to solve, and that’s why I need to go through what they want me to do so that I can see if I can do it at all.

Scrum brings people together in one team and enables short feedback loops. Then we can be much more adaptable in the market.

Scrum Master is not a two-day certificate

Scrum Master role implies that the person should know only Scrum in order to “manage” the team. This often gives them little real mandate to support true organisation change. This is why some people in Agile are already moving away from the term Scrum master and so does he.

He prefers the term organizational or team performance coach because Scrum master sounds like they are the master of the whole team. On the other hand, an organizational coach sounds like someone who wants to enable people to work more comfortably and for the team to improve, Josip points out.

Also, the trivialization of the role has dramatically inflicted a lack of respect for the position. There are examples of people getting a Scrum Master certificate after a two-day course. It’s no wonder that people think that a Scrum Master brings coffee and arranges meetings, Josip explains.

The post Why do developers hate Scrum Masters? appeared first on ShiftMag.