Roy van de Water, Drew LeSueur and Chris Sims discuss:

• Transparency in compensation
• Using Scrum to run a Scrum consultancy
• Elements of Scrum and Scrum: A Breathtakingly Brief and Agile Introduction

Transcript

Roy van de Water:  Hello, and welcome to another episode of the Agile Weekly podcast. I’m Roy van de Water.

Drew LeSueur:  I’m Drew LeSueur.

Roy:  And joining us today is Chris Sims to talk about running a transparent consultancy.

Chris Sims:  Greetings.

Roy:  Chris, your company is a little different. You guys value having a high amount of transparency within your organization. You guys work in a fairly communal way. Can you tell us how your culture evolved to that point?

Chris:  Yeah, absolutely. Part of it was by intention. I started Agile Learning Labs about five years ago. We just do agile training in coaching and transformation work. It was my intention to create a company that was first and foremost for the benefit of the people who work there. I want it to be a great place to work. I figure well then you’ll get great people and then you’ll be able to deliver great value to the clients.

That was the general attention when we started and then some of these evolved basically using agile principles of inspect and adapt and all of that.

For example, one of the things that have got a lot of attention recently is the way we pay ourselves. Everybody in the company makes the same money. Everybody. Me, the person who does the billing, our creative director, our sales people, everybody makes exactly the same and it’s based on how successful the company is.

That evolved over time. We started out with more traditional approach and we found that it wasn’t working for us right. We wanted to create a team and we wanted to create a team that would work towards a common goal. We found that one of the things that helped create that alignment was having everybody’s compensation package be aligned.

Roy:  How does that work from an investment perspective? I assume that you starting the company put forth quite a bit of investment capital to try to get things rolling. Is that something that just went away in the wash? How are you handling that?

Chris:  [laughs] I love that question. It’s one of the things we’re actually working on together. One of our progression of goals is to first make sure that we’re all making enough money that we’re living comfortably and we’re happy with that. Then interestingly enough, the whole team is actually really committed to making sure that I ultimately end up getting a good return on my initial investment.

It’s kind of an exciting time because we’re actually at that point where that’s going to start happening. So, there is going to start to be a little bit of a return on owners equity you can think of and basically a little bit that’s coming off the top that’s going to come my way as a representation of “Hey, you currently own the whole company.”

Over time, my intention is for that to change ‑‑ for it not to be necessarily entirely owned by me. I think it’s probably healthier when a company is owned by the people who actually operate it. For the moment, having me own the whole thing is working, but I think long term, it will actually be healthier if I’m not the only person owning it.

Roy:  That sounds interesting. It sounds like you might run into some future bumps down the road bringing new hires. Would new employees have to buy into the company?

Chris:  Yeah, boy, we haven’t figured that one out yet. We definitely do expect bumps down the road. We’re really committed to basically working in a very inspective and [indecipherable 0:04:18] way working very collaboratively to make these decision about how we’re running the company and adjusting to the issues that present themselves.

I think none of us think that what we have is like the ultimate perfect arrangement. It’s just the best one we can come up with so far. I think we all expect it’s going to change and evolve as we go.

Roy:  In a really transparent company, how do you handle the traditional concept of performance reviews, or more importantly the value that I think most developers want out of those? How do you handle people getting feedback on their performance so that they can target how to improve?

Chris:  Well, I love this. This has been one of my pet peeves for ages, which is that I think the goals of performance reviews and what actually comes out of performance reviews like what you actually get out of them, in most instances most common thing are not actually aligned. Most companies have performance reviews because they think, “Hey wow, this’ll really help people improve and grow,” and they usually have some notion of, “We should identify the people who are the high contributors, and pay them more.” Because maybe that’ll keep them around, or maybe it’s just because somehow that’s good, that our high‑performers make more money.

What actually happens on the ground is ‑‑ especially if you do a traditional approach to performance reviews, where it’s an annual thing, and you do the traditional thing of tying it to compensation ‑‑ people get really wrapped up in making sure their performance review makes them look good. They want to argue about things that don’t sound good, and it really gets all wrapped up in, “Hey, I want a bigger raise,” and all of that sort of thing.

If you’re trying to work in a team environment, very often this sets up a “Zero Sum” game mentality, like, “I have to look better than my co‑workers, so that I get the lion’s share of the raise money,” and all of that. What we’re doing instead is we’re choosing to go without that. We’re choosing to develop a culture, where team members give each other feedback all the time.

Our goals are, on the individual level, people want to grow professionally, they want to grow their capabilities, they want to grow their skills, they want to become ever more valuable members of the team, and at the financial level, we’re all just lying around, “What can we all do, to make Agile Learning Labs even more successful?” Then that will directly translate into more money.

It’s not about, “How do I look better than the other guy,” it’s like, “What does my team need right now to help us actually create more value, and I’ll just jump in and do that.” That’s what we’re doing.

For bigger companies, that can be a struggle, especially if they have an entrenched HR performance review kind of situation, but some of our clients are actually moving in directions where they are changing their performance review systems to make them more aligned with their actual goals, which is to have higher performing teams.

It really changes things. If you’re managing for, “We want high performing teams,” you actually do very different things as opposed to saying, “We want high performing individuals.” It turns out that a high performing team can deliver way more than even a group of high performing individuals. It’s a case of, I think, managing for what you actually want.

Roy:  As far as the continuous feedback part of it, where it sounds to me like your company culture is that, if somebody see a team mate underperforming, then they’ll bring it up with that person, or if they see someone succeeding really well, they would compliment them, and let them know that they appreciate however they are performing well.

How does that work in practice? Because at Integrum, we’ve tried something similar, where we initially started with anonymous feedback, which we felt we got pretty much no value out of it. Perhaps we even got negative value out of it, because we felt like we wasted our time.

We tried doing completely transparent feedback, where all of us sat around a table and went one by one, and gave each other feedback. I think Drew will agree that we got a lot more value out of that. We have talked, in the past, about having a culture of continuous feedback, but in practice, it doesn’t seem to work out that way. We’re not always as quick to criticize or compliment as we should be when we see things happen.

Chris:  I’m not surprised to hear that didn’t get much value out of the anonymous feedback. In part, I think for feedback to be meaningful, it has to be a conversation. By its nature, it ends up needing to be personal. We would like to say, “Oh, no, no, it’s got to be very objective,” and in some theoretical perfect world, maybe that is even possible, but we all live here in the real world, where we’re actually working with people.

In order to get a common understanding about, for example, what behavior somebody may have engaged in, that wasn’t as useful and as helpful as we would like it to be. We need to engage with them, have a conversation, and say things like, “Hey, wow, just now, when you said such and such, it lead to this reaction, which wasn’t helpful. Boy, it would be better if, next time, we could find a different way to navigate that.”

It invites a conversation, and we start to understand more of the subtlety of what’s going on. The last, with people, with human beings, I think all the value is in all of that subtlety, so you have to go there. In terms of building the culture of continuous feedback, I think it’s one of those things that take practice.

It takes a framework and structure to get in going. For example, we run the whole company using Scrum. We run a two‑week sprint cycle, and we plan what are the major objectives we want to achieve with this sprint. All the classic Scrum meetings, daily Scrum, a strict review at the end to see how did we do, and, very importantly, a retrospective at the end.

So, at the core sprint, that becomes a place where, very exclusively, we’re looking for what can we do better as a team, which often involves how can we communicate better or how can we do a particular thing better, which might mean “Chris did something this sprint that didn’t work out as well as we liked, and we want to look at how could he do it better next sprint.”

Then, building off of that, working on it and trying to be conscious about giving people feedback regularly, both positive and negative, because, if it’s just one or the other, it’s way less powerful, and people end up valuing it less and being less open to it. We’re actively trying, succeeding better on some days than others, but actively trying to create a culture where we regularly give kudos and we regularly give, “Hey, here’s an idea, Bob, how we might do it even better next time.”

Drew:  That’s great. You mentioned how you guys run your agile coaches or Scrum coaches and trainers, and you preach Scrum to other places, but you also use it internally as well. That’s one thing I have a question for you, is in your open, transparent team, where everybody is probably a lot more equal in your company than in other companies, how do you handle not having a specific product owner? Or do you consider yourself the product owner?

I think of a traditional software development project. The product owner always has the final say. The team can help out, negotiate, and talk, but part of it is the product owner has the final say. How do you handle that while trying to run Scrum internally?

Chris:  Yeah. You nailed it right on the head. I am the product owner for Agile Learning Labs. We have a backlog. Anyone in the company can suggest items for the backlog. We talk about them, we refine them, we have identified acceptance criteria. Then, in sprint planning, I walk in with the backlog that I’ve set out ahead of time, saying, “Here’s the top of the backlog. These are the things that are likely to be offered in this sprint planning.”

I offer them to the team in order to decide the order that I’m interested in, and they get to vote to accept or reject, like, do we feel like we can commit to this or not. Sometimes, there’s some negotiation around that. Sometimes, they feel like, “Well, our capacity is going to be a little lower in that area, so we can commit to a slightly less ambitious goal than that, but not the one you want.”

We go back and forth all the usual sprint planning, Scrum team stuff.

Roy:  I think that’s something that we’ve been experimenting with. We have taken a rather different approach to running a Scrum within our organization, and we don’t really have a specific product owner. I think that sometimes hurts us more than it helps us.

Chris:  Yeah. We initially didn’t have a product owner. We tried to collectively groom in order to backlog, and we had a similar experience. It really didn’t work well. Everybody has an opinion, but then you come down to how do we arbitrate between all these different opinions.

Finally, we realized, “Well, somebody’s got to be the product owner.” Everybody looked at me and said, “Well, you started the company. You’ve set our big‑picture direction. I guess you’re the product owner.” One of the things that have come out of that is me going, “Great! Except that means I really can’t be the Scrum Master. Darn it! Darn it!” [laughs]

I like that job better, but it’s one of the things that have fallen out of that.

Roy:  You’ve actually used the Scrum process to write a book, recently, haven’t you?

Chris:  We did. Actually, two books. About a year ago, we released a book called “The Elements of Scrum,” and I have been just honestly amazed at how well it’s done. It is regularly the number one best seller on Amazon in the software project management category.

That just blows me away, because, when I saw our book up above books by people like Mike Cohn, Jeff Sutherland, Ken Schwaber, and people like that, I was like, “Wow! How did that happen?”

Then, about a week ago, we released a book that…it’s actually a bit of an excerpt from “The Elements of Scrum” that has been revised, updated, and polished, but it’s called “Scrum: A Breathtakingly Brief and Agile Introduction.” We intentionally targeted this one to people who really just need a brief overview, like, “What is this Scrum stuff, anyway?”

Paperback is priced $9.99, which is about as cheap as you can get it, but the Kindle, since there’s actually no production cost, we priced it 99 cents, and the darn thing is already flying off the virtual shelves, which we’re really excited about.

But yeah, the big book, “The Elements of Scrum,” we used Scrum to write it, and, in particular, the final big push was a writing retreat in Chicago in December, which, by the way, if you ever want to be able to focus on writing, go to Chicago in December.

Roy:  Nothing to do?

Chris:  Yeah, you don’t want to outside. [laughs] It’s below zero out there and it’s windy. So we just hold up, and we used all the classic Scrum tools. We had a story map that we used to lay out the book in the way we thought it should be. We estimated all the pieces that we had to write. We were actually running one‑day sprints. We had a burndown chart for every day and a bigger release burndown chart for the whole book.

It worked like a charm.

Roy:  That sounds awesome.

Chris:  Yeah, it was fantastic.

Drew:  I have a question. When you were writing this book, a part of Scrum is to deliver early enough. How did you do that with your book? Did you focus on the potentially deliverable product or did you have any deliverable while you were not quite done with the whole book?

Chris:  It’s interesting. During that final phase, we were basically working with the potentially shippable concept, like building up and flushing and all of that, but the overall process of writing, it was much longer. It took a couple of years.

What we were doing was, on a regular basis, we were actually going off to the copy shop, printing the whole book, spiral bound, and we were using it in our workshops. For two years, this was the ever‑improving, ever‑growing book that we used to take away from our scrum workshops.

Each workshop, that was kind of a release, so we were motivated to get one more chapter in, or get one more concept in, or clean up a section that we weren’t real happy with. We did have lots of incremental releases.

Right lying around the office, I could probably pick up maybe 10 different versions of the book before it got to the point where we actually published it properly.

Drew:  Awesome.

Roy:  Great.

Drew:  It’s been great having you on. Is there anything that you’d like to promote or anything that you’re working on that you’d like to tell us about?

Chris:  You already gave me this great opportunity to talk about the book, “The Elements of Scrum” and “Scrum: a Breathtakingly Brief and Agile Introduction.”

Agile Learning Labs, we do training and coaching and love to hear from people who are adopting scrum or evolving their scrum practices. You can find us on the Web, agilelearninglabs.com.

Boy, this was a lot of fun. I really appreciate the opportunity to talk with you guys again.

Roy:  Awesome. It was great.

Drew:  Yeah…

Roy:  We’ll definitely have to have you on again.