choong pw

As an Engineering Manager acting as Scrum Master and Agile Coach for at least 5 years now. From being put into an established team, to starting a new team, and managing back a team I once owned. All to try to lead and decide what is best for the team to be efficient.

Disclaimer, I’ll use both terminologies interchangeably just because the functions served are about the same.

Expectation

The idea of either of the methodology is to be Agile. It goes back to this textbook of Agile Manifesto, which is

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

And of course, anywhere you read will be about following a set of defined rituals to achieve the ideal state of flow for the team. Like:

• Stand up
• Refinement and Planning
• Review
• Retrospective

Reality

That said. Setting up the schedule is just the easy part. The real deal is the content of the rituals.

We all know about the developer teams that consist of the 3 trios (Scrum Master, PM, and the Engineers). But then…

• How effectively does your team utilize the allocated time to achieve the goal of the ritual?
• Is the ritual just a show of a few team members while the rest just feel like observers?

That’s where the principal and leadership of the scrum master play a significant role. This may vary depending from person to person too.

Anyway, I will share a little of my personal experience and the thought process about some of the principles.

The team needs time to gel

That remains true in most cases. You may occasionally randomly mix a few engineers and be able to deliver quick results with high throughput. Usually, this won’t last. But why?

When a new team is formed. We usually will have a little excitement to solve something. It usually takes a couple of sprints of weeks before there are some slight mismatches between each member’s work. Something like the use of architecture, shorthand, comments, documentation, etc. This takes time for the team to adapt and to understand.

When the flow state happens. Managing the team becomes so much easier. Matter the fact, I would say the squad itself established a culture that it sustained itself. That also means, when people come and go (for holiday or attrition). The “we got each other back” mindset, will feel like the team just knows how to operate on its own.

Rituals are a waste of time

First and foremost, address the team harmony. We need to make sure that the team is a team. Is fine to have disagreements and different points of view. We need to make sure that everyone respects each other and learns to disagree and commit. Frankly, most of the time this happened between me and the devs.

The daily struggle for rituals is real. For instance, standup and planning tend to overrun the allocated timeslot. Now, should you extend or ask the team to keep it within the timebox?

My default mode of operation would always consult back with the team. That’s where retrospectives are for. The team usually knows what’s best. At the same time (as a scrum master and ex-developer), you also should be able to facilitate the discussion and decide what is best.

Sometimes environment also plays the deciding factor. We have been working remotely since Covid. Our touch point where the whole team gets their update to stay in sync is of utmost importance. By also advocating and reasoning your decision helps the team to understand and be aligned.

Ultimately, we want to make a democratic decision, that’s where I find it much easier to get people to onboard with the plan.

The ideal size of a squad

There was a time I was managing a team of 8 and decided to split the squad into 4-4 each. Each squad has their area of focus to contribute. And it works like a charm. When the size is small, even the juniors are much more involved in the discussion and decision. They feel that they are accountable for the delivery, easier to ask for help (no dilemma about who to seek help).

It works well until some resignation happens. Is pretty obvious that my team and working hard to carry on the extra load. What you be your choice then?

Again, the decision will based on the short-term state and principle you follow. Ultimately, we want to make sure the team is happy, able to perform and sustain the pace over some time.

Back to the question, personal experience tells me to leave it at 4. But going with 5 is a safer bet considering attrition or time-off while maintaining a consistent throughput.

Last thought

Most of the time, I am just living by my principles and values of what I think a good team should work. I believe a good leader for the team, bring can bring a lot of multiplier to the team. Most importantly, guiding and resonating their belief for the team to succeed.

Best, all based on my personal experience.