Are you my leader?

If you asked me what I’m good at, I’d say administration. I’m not always the big idea person, but I know how to get big ideas done.

I’m reading this book about leadership, and I’m no where near as comfortable with that moniker. Am I a leader? I lead my team, surely. Why don’t I think of myself as a leader?

I keep coming back to these agile concepts of scrum, and the concept of myself as a scrum master. The facilitator of a self-organizing team. The scrum master isn’t really responsible for setting tasks. They don’t pick who does what. They just facilitate others, they define process and help the team implement those processes.

And then I think about a leader. Someone who sets the task, sets the standard, makes decisions, and is the source of team accountability.

Where do leadership and scrum mastery intersect?

It almost feels like socialism vs democracy. Old testament vs new.

There’s the concept of the ‘servant leader’ as scrum master, which covers this seeming dichotomy. In theory, everyone is accountable to the team, and the scrum master is responsible for maintaining process, but not the implementation methodology of that process. But in my reality, I have to chase after people for time sheets, I have to conduct reviews, and I’m accountable to leadership for standards that may or may not be different than the standards of the team.

I suppose this whole post is just thinking out loud. I am drawn to act in service to the team, and yet there are times I must lead. How do you draw the line? How do you set clear expectations? How do you keep that from sending confusing or mixed signals to the team? Where’s the middle ground – and is middle the right place to be?

Perhaps answers come with time and trial. Onward!

Efficiency and Effectiveness

I went and got myself a certification this week – I am now a Certified Scrum Master, thank you very much.

Overall, the class was interesting. The teacher was engaging and the format was interactive. I enjoyed having time to dive into “true” scrum practices, see them at work, and better understand the reasoning behind the process.

A common complaint about scrum is the volume of meetings – the sprint planning, the daily scrum, the backlog grooming, the review, the retrospective. That’s 5 mandated meetings per sprint!

The teacher made an interesting comment, however, that scrum is an effective solution, but it might not always be the most efficient solution. This, I believe, is very true, at least from the day to day perspective. As a project, using scrum might indeed be more efficient, but as an individual contributor on a daily basis, scrum can seem like a lot of overhead.

Indeed, in some agency environments, and in very small teams, scrum may be too much process – there are many situations where a leaner solution like kanban would be more appropriate.

As a systems engineer, I am typically hyper-focused on efficiency – but that should never come at the price of effectiveness. What may be most efficient on a daily basis might not be most effective in the long run.

Things to consider.