Last time, I wrote about how I started the Scrum Team without stressing the Scrum terms. After the preparation before everything begins, it’s time to start our development cycle.

Daily Scrum

Our Daily Scrum is similar to the standard one. Apart from developers, our manager also attends the Daily Scrum. Some might argue against the existence of the managers in the Daily Scrum. The Scrum Guide states that Daily Scrum is an event for Developers, but it isn’t meant to disallow managers’ existence.

The Developers can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next day. This creates focus and improves self-management.

It could be a problem if talkative non-developers attend the Daily Scrum. Luckily, our supportive manager doesn’t speak except when we ask for her help. We talk and discuss freely during the event. Thanks to her participation, she doesn’t ask us about our progress during the daytime. Moreover, if we get stuck at the organisational level, we can ask for immediate help without explaining the problem again.

Mob Programming = War Room

Initially, everything was new to us, especially the microservice architecture and Spring Boot. To prevent the developers from being lost, or working on an overdeviating path, I was about to introduce mob programming. At that time, no one knew about mob programming. Some managements doubted the effectiveness and efficiency of using pair programming. But I was sure everyone knew about War Room.

Therefore, I explained our concern about the uncertain business and technical stack and suggested setting up a War Room with all the developers in a meeting room. All developers stayed in the same meeting room for a month without being (wrongly) criticised mob programming versus productivity.

Early this year, I introduced mob programming to the team. It becomes one of the tools for collaboration on unfamiliar stuff.

Sprint Review

Like many development teams, I didn’t know what we should do during the Sprint Review. By tradition, we should demo the Product Backlog Items during the week. However, after I became responsible for preparing the weekly updates, I noticed the stakeholders were unsure of our plan for the Product Goal. Therefore, instead of simply demoing the Product Backlog Items, I began to state the current Sprint Goal and potential Sprint Goals indirectly.

As I said in the last blog post, do not expect the stakeholders to know the Scrum jargon. Instead of stating “Sprint Goal”, I start the Sprint Review by saying the most important thing we wanted to achieve that week, followed by other nice-to-have items. At the closing, I list the things expected to work in the upcoming weeks.

“This plan is determined by what we know now,” I said, “And it might change once we’ve learned more in the future. Don’t expect it is the exact plan we must execute.”

Sprint Retrospective

There isn’t anything special in our Sprint Retrospective. We never do “fun” retrospectives, nor weird ice-breaking activities such as creating a playlist or dancing before the retrospective – we hate these activities. We are here to solve our internal problems, but not playing the Mario Kart or Harry Potter role-play.

Our managers never attend it, either. The team freely speaks up to plan ways to increase quality and effectiveness. I know some teams involve their managers in the Sprint Retrospective. I can’t say it’s 100%, but in many cases, these teams become reluctant to speak.

Weekly Sync

Our product is one of the components of a large solution. It requires plenty of cross-product integrations among the components inside and outside the solution. Coordination is so necessary that every team understands the common goal at the solution level and adjusts their plans, hoping not to block the other teams’ deliveries. I introduced the weekly sync, gathering all the Product Owners and the managers inside the solution and determining the future adoptions.

Some might say we should discuss this matter during the Sprint Review. It’s true, but every product team has its schedule. We can’t attend all the Sprint Reviews and discuss the matter as a fragment. Centralised events at the solution level are inevitable. I strive to push things unrelated to the common goal back to the individual Sprint Reviews and focus on the things related to the common goal. However, it takes time for others to understand the purpose of the weekly sync and change their behaviour.

Scrum is essential to the Scrum Team but isn’t a must-know for non-team members. They mightn’t even care about those terms. Blindly following the Scrum Guide or constantly quoting scriptures doesn’t build trust with them. Use common language, and slowly develop their Scrum knowledge. Empowerment takes trust, transparency and time.