Showing posts with label team leadership. Show all posts
Showing posts with label team leadership. Show all posts

Monday, July 27, 2020

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

Thursday, May 23, 2019

Review: The Infinite Game - How to Lead in the 21 Century

tl;dr: See summary below.

Even in the world of technology, it's important to understand how to lead. Else, you'll get left behind. Now, this doesn't mean that you have to lead everyone and become the next Bill Gates or Mark Zuckerberg. But, this does mean that you should want to become the next point guy on your team or even an adviser to your team lead when a decision pertains to a specific context like, for example, "optimizing team ergonomics for better team collaboration."

But, how do you lead in a world filled with leaders? How do you become a leader when the whole world is promoting leadership? Furthermore, how do show leadership when many recruiters are looking for experts who can lead?

If you don't already know the answer, then I'll direct you to Simon Sinek.



My Summary

"In an infinite game, there is no such thing as win or lose; only ahead or behind." - Simon Sinek

The only real competitor in an infinite game is - yourself.

5 Things to become an Infinite Game Leader

  1. Just Cause
  2. Trust in Teams
  3. Worthy Adversary
  4. Existential Flexibility
  5. Courage to Lead
Happy Leading!

My Side Note

Simon Sinek antagonistically quotes Milton Friedman saying, "He said, 'the responsibility of business is to maximize profits within the bounds of the law.'"

"If businessmen do have a social responsibility other than making maximum profits for stockholders, how are they to know what it is?" - Milton Friedman (more quotes , movie)

This kind of mindset (and lack of heart) is really bad. If I may and I'm no Simon Sinek, then I would like to add one more thing to his points on becoming a person with an "infinite game" mindset. When leading, know that your team will have high-performing times and low-performing times. Although corporations still push for a single performance review, know that it's unrealistic to believe that each individual will function at the level of high-performance, always. A good leader recognizes the high performing days and the low performing days while accepting the whole person (i.e. team member). A good leader encourages his/her team to focus on team performance rather than individual performance. After all, no business survives on an individual.

If interested, see Adam Smith's original vision for Capitalism.