Becoming a Scrum Leader

I've never been a scrum leader (fka: scrum master) before but have always been in scrums since probably 2005. My team lead at the time became Agile Certified and promoted the Agile Manifesto. I was a fresh college grad and had no idea. But over the years, I've developed my own opinions about "scrumming". Being mindful, scrum is an agile practice and nothing more. When a team scrums well, it's usually because of one thing: open & honest communication.

People will say lots of bad things about "scrumming" and I have been one of those people. To the defense of negative perspective, it's because the scrumming has lost its value. In addition, it's because the scrum leader didn't and isn't catching the devalue of the scrums or the team that scrums. (And usually one is to write a whole paragraph before starting a new one - but it lowers the value of the message when unnecessary, for example).

There are lots of good things about "scrumming". Again, when scrums are done well, the value increases and the team becomes more productive. When the team becomes more productive, the product will most likely satisfy the customer and then the customer will, too, become more productive. That's the goal: Become More Productive.

My Four Points on Scrum

Let's look at the positive side of "scrum" as I learn to be a scrum leader for the first time. Here are my four key points promoting scrum:

1. Understand why we "scrum" (i.e. necessary process).

We scrum to communicate clearly our progress to the customer. Without the customer, we have no work and thus no need to scrum and talk about work progress. In order to communicate our project status effectively, we along with other teams collectively deliver our status to the product owner who will eventually deliver the overall project status to the customer.

2. Who should "scrum" (i.e. necessary people).

Our small teams of 3-6 people. Luckily, my team is of four including me which means each contributor will be necessary, needed, and critical to get work done. Because the point behind scrums is to communicate frequently and with key contributors, keeping the teams small helps to keep the frequency of communication high and, most of all, clear and concise. Too many people will cause too much noise and drown our the product's music. We want our customers to dance while waiting. :-)

3. What are the "scrum" priorities (i.e. product needs).

Identify the needs for the product (which are the needs for the customer) and we now have priorities to discuss during scrums. These needs combined with the skills of our team determine the timeline of finishing the product to deliver to the customer. Basically, what needs to get done to give the product to the customer when they need it.

4. How we "scrum" (i.e. progress needs)

The "how" is what makes "scrumming" different across the spectrum of agile practices. From my experience, the daily scrum using a "managing ticket" tool is the dominant method during sprints (i.e. a set of selected features to complete over a few weeks). This daily scrum was invented long before the modern tools we have today in managing tickets like Jira. However, I have found on many occasions this compels teams to scrum when unnecessary. I have found individuals to become less productive because of relying on scrums to give their status updates. Therefore, I oppose the daily scrum method and think we should leverage the modern tools to maximize scrums. As a team lead, I think it's more effective to encourage contributors (i.e. individuals on the team) to keep their status updates in the tickets and meet two or three times a week.
We ought to keep status of:

1. completions - i.e. tickets completed
2. progress - i.e. tickets currently being addressed
3. blockers - i.e. tickets on waiting on ticket owner due to lack of knowledge, skill, funding, etc.
4. holds - i.e. any ticket waiting on something or someone and why

From these tickets, I (or a scrum lead) can provide the daily status update to the product owner and make any team adjustments as necessary including scheduling a meeting to "unblock" a ticket. Usually, I can see the status with the "managing ticket" tool and provide the necessary status and feedback to the product owner. In addition, I can manage tickets and team contributors easier with the tool. Lastly, our sprints are more realistic with timelines because of the convenience of history tracking with the tool (or tools including logs of code commits). Therefore, scrum is important to ensure progress toward product delivery.

Overall, I think it's good to set expectations upfront with my team (or any team). Keeping my expectations simple should also help with making future adjustments. Here are my expectations:

1. I will do my best. You can expect me to do my best. I will expect the same from you - do your best. (Please don't expect anyone to be the best scrum lead or team contributor.)
2. I will always aim for us to do and be better. But I can't do it alone. I can't aim higher if even with three of us. We need all four of us to aim higher, together. Expect the same.

With the end in mind, let's see how my outlook helps or needs to be adjusted. Pray for me and wish me luck!

References

Here are some references that help develop my understanding.
Scrum Intro < 10 minutes
https://www.youtube.com/watch?v=XU0llRltyFM

Investing in Scrum

https://agileforall.com/new-to-agile-invest-in-good-user-stories

https://www.agilealliance.org/glossary/invest/