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!

Don’t be a silo

I know this is a joke. An intended exaggeration. But it is frustrating nonetheless.

As I was watching a show on Hulu last night, this commercial kept playing for an online K-12 school. One of the “students” was saying how awesome it was that she could do 5 classes in one day on the days she felt like doing a lot, and none on the days she didn’t.

Which is great. But then it kinda isn’t.

That’s really not life, for most of us. We don’t get to do whatever we want to do, and only when we want to do it.

We work together. We accomplish things as teams. We need other people to support and inform and help us, therefore we must do our work at roughly the same time to be efficient. Just because you don’t feel like doing your work on some days doesn’t alleviate your responsibility to do it. Your team is counting on you, so you do what you need to do on the appointed day.

Perhaps it was just the combination of this illustration and that commercial, but I got peeved. I feel it furthers the notion that developers are delicate flowers that should never be interrupted, that their concentration should be preserved above all else.

I totally agree that devs need long uninterrupted stretches of time to do work to be most efficient. And I strive to provide that. But to be effective as a team, you have to be willing to stop and talk to your team. And the daily standup is that method.

Sometimes, you have to subjugate your individual needs to better the team. That’s what a team is all about. Being pissy about a standup means no information gets transferred into other brains, which makes you a silo, and if you go on vacation, the work comes to a halt because you couldn’t take 15 min a day to have a very short conversation. You are not that important, that you should be able to bring a team down by taking a vacation.

Do the standup. Support your team. Don’t be a silo.

Get used to being uncomfortable

After going through the Certified Scrum Master class (I am fancy now!), I’ve been re-evaluating how projects are ‘managed’ at work. We are not fully agile, but we’ve been slowly applying some of the agile concepts and structures to our workflows. In an agency environment, where projects are fast, furious, and many at the same time, there is not always the luxury of doing full scrum processes.

In addition, I play both Product Owner and Scrum Master, which is less than ideal. I represent the client’s interests, prioritize backlogs, and also try to help the team organize themselves for delivery, remove their roadblocks, and basically keep them running smoothly. I think I play Product Owner well. But I’ve realized I’m not an awesome Scrum Master right now.

We need to shift towards more team choices where the team decides what to do next – I’m trying to adjust my phrasing and my approach to conversations so that the team feels more empowered to make choices on their own, that they don’t depend on me to tell them what to do. It’s an interesting shift. I feel like I’m forcing them to take more control – and that they don’t always want it!

It’s a good transition, and a necessary one as well. The process is a little bumpy, but we’re getting there. I have this vision of a group of awesome people who can discuss issues, make choices, and perform to their stated expectations all on their own initiative. A group that can control their own environment, and that feels not only empowered to make change, but a group that feels the ability to change and improve is their opportunity and obligation.

We’re gonna get there. Strap in and hunker down. We’re gonna get used to being uncomfortable. It’s a price of change that I’m willing to pay.

Ain’t nobody got time for that.

Damned if you do, and damned if you don’t.

Sometimes, I feel caught in that conundrum. Especially when it comes to things like planning meetings, or retrospectives. If we stop to plan better, we lose development time, but we should make up that time by doing the work properly the first time. If we stop to figure out what we did well and what we did not so well, then we lose development time, but we should be making ourselves more efficient by reflecting and improving.

Specifically in an agency environment, where the pressure to deliver MORE ALWAYS MORE AND EVEN MORE NOW AND WHY CAN’T WE JUST SQUEEZE THIS IN TODAY, it can be difficult to prioritize those things. We live or die by happy clients and billable hours.

Sure, we plan. But do we sit down and do nothing but plan and do deep thinking exercises over what really is needed? Not consistently.

It’s a matter of priorities, really. If we don’t feel the meetings are important enough, then they slide by.

So what’s in the way of prioritizing these events?

Constant adjustment of client expectations.
…which can lead to unhappy clients.
The loss of billable hours, potentially.
The lack of staff buy-in, that these things are valuable.
The lack of a process champion to convince the staff to just try it for a while.

It’s all about how much risk we’re willing to take on. Is it more risky to slow down delivery for these clients, understanding the theory that development becomes more effective over time, ultimately (one hopes) leading to happier clients? Or is it more risky to devote as little time as possible to planning and reviewing, only enough for a general understanding, while keeping billable hours and deliveries as frequent and comprehensive as possible?

Can you convince an unseasoned client to value quality over volume? How many meetings will a client tolerate on their invoice before they start to balk at what most clients think is just useless overhead? On a 4 month project, how much client education can you legitimately expect to accomplish?

I suppose there’s only one way to find out!

Unexpectedly delightful

I walked by our “atta-boy” wall the other day and realized that I hadn’t updated it in a while. I used to be better about pointing out our successes, both as a team and as individuals, and I have let that fall by the wayside.

I do deeply appreciate the staff here. And I need to be more explicit about that.

For all the effort we put into the experience of our products, we aren’t focused on the experience of the staff. What’s the UX of your workplace?

It got me thinking about the unexpectedly delightful. How do you fashion an experience where each person feels appreciated, feels safe, and still experiences moments of delight in the workplace? It’s a challenge, since we are all such individuals. There are some team members who are truly overjoyed by a free burrito lunch. And there are some who feel a long office lunch is an intrusion on their workday, it doesn’t match their style.

There really is no one-size-fits-all answer here, but I feel a solution is worth pursuing. Time to inspect, adapt, and deliver.

Agile delightment FTW!

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.

Accountability, responsibility, and trust

One of the fascinating things about agile team structure is the delineation between responsibility and accountability. While I may be in charge of making sure something gets done, I may not actually be the one to perform the work. I am accountable to a task without being responsible for actually doing it.

As a scrum master, I may be accountable for explaining and improving the team’s velocity, but I do not directly impact the velocity – I am not responsible for the work done that creates or alters the velocity. Only the development team can be responsible for the estimation and volume of work that is completed.

It’s an interesting paradigm, to separate who is held to the fire for something from who will actually do that something. That takes a huge amount of trust within the team – to trust the responsible party will do what they say they will do.

And if there is no trust? That’s a huge problem if a team member doesn’t fulfill their responsibilities. Which gets exacerbated if there are no reciprocal dependencies between us – if mutually assured destruction is not an option, albeit a last resort, clearly.

If I am accountable for things that you are responsible for, and you never fulfill your responsibilities, then there is a problem. A foundational breakdown of trust and responsibility, fracturing a team from the inside.

Be on the lookout, team leader, for small breaches that may lead to larger collapses. Defend your team vigilantly against actions that erode trust.