I’ve been working in companies that practice Agile development for about a decade now. I’ve always enjoyed delivering customer value as fast as possible. It fits with my personality. I like structure that helps me go fast, and abhor bureaucracy that slows me down. Even though I’ve worked in an Agile environment and attended numerous workshops on the subject, I never took the time to get myself formally trained and certified in Scrum, until this week.

For some of you, I might be getting ahead of myself. What is Agile? Agile is first and foremost, a manifesto. It was created in 2001 by 17 software development leaders. Because it’s important, I’m going to go ahead and take up the precious space in my blog article by quoting it in its entirety:

We are uncovering better ways of developing

software by doing it and helping others do it.

Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on

the right, we value the items on the left more.

I used to be the type of person that would use terms like Agile and Scrum interchangeably. Now I know better. The Agile manifesto is awesome but is mostly just a list of values and principles. Scrum is a framework that actually helps organizations put these values and principles into action. I spent part of this week with my co-workers taking a Certified ScrumMaster training class, taught by Lonnie Weaver-Johnson at Intertech.

I’m not going to spend the rest of this blog explaining Scrum to you. You’ll have to take the course yourself if you want that. Instead, I thought I’d share a few leadership lessons that were reinforced to me during my training that apply to all technology leaders, Scrum Master or not.

Servant Leadership

So, you already know that I’m all about servant leadership. I’ve written extensively about it here and here. A Scrum Master leads her team, not from a position of authority, but with servant leadership. Software projects are always filled with conflict. Anyone in a leadership position, even a project manager, may be tempted to revert to command and control to resolve conflict and get the project back on track. Not the Scrum Master. She knows the power of servant leadership and wields it wisely.

Built for transparency: The Product Owner is a member of the Scrum Team

The Product Owner is the customer. The customer is on the team. In the world of traditional enterprise IT, this sounds like crazy talk. We usually try to build a few layers of abstraction between the engineers and the business. We usually have structured communications like tickets or requirement documents to buffer the relationship. There are no go-betweens in Scrum. The customer is not merely adjacent to the team. The customer is a dedicated, interactive member of the team. Without those layers of abstraction and status reports, there’s nothing but raw honesty and transparency between the makers of the software and the users of the software.

All technology leaders have customers. How open and transparent are we with them? How intimately involved are they in products or services we provide? Scrum raises the bar significantly on that expectation and makes it normal. Whether you do Scrum or not, you have to admit that is an impressive amount of trust and transparency, and something all leaders should admire and emulate.

The Retrospective

Scrum builds self-reflection and continuous improvement into the normal operations of a team. I think technology leaders tend to resist that. Sure, we will do a post-mortem exercise after a major catastrophe. We might pause to do a lessons-learned after a major software launch, but the Sprint Retrospective is different. It’s every single sprint. For most teams, that’s every two weeks whether you think you need it or not. It’s not based on a major success or failure, it’s just part of the normal work.

As leaders, we don’t do this enough. Imagine if we gathered our teams every other week to look back and inspect what need to change for the next two weeks. That’s what a Scrum Master does. That’s real continuous improvement. Our once-per-year goal planning and performance review cycle just isn’t the same. In our regular staff meetings, we talk about project status and upcoming efforts, but we don’t spend enough time honestly evaluating how things are going with regards to people, relationships, process, and tools.

After taking this Scrum course and getting certified, I’m on an Agile kick. We’ve already expanded Agile beyond the typical software development projects. We even used this to do a Data Center migration. You can read all about that one here. I want more. I don’t think we should do half-way Waterfall-Agile hybrids anymore. We can do better, and we will get better if we do. It’s not just a good way to make software, it’s a good way to lead.