Working on Lync

I recently wrote a bit about my role on the Lync test team at Microsoft. I thought it may be interesting to share a bigger picture of what the team does for those interested in how we do what we do.

At the surface is the "who" and the "what" of the team. We have a team of eighty or so testers (smallish on Microsoft scale, but otherwise large/huge) who test the Microsoft Lync client application (instant messaging, presence, voice and audio, desktop  / application sharing, and a few other odds and ends). Our role is like most test teams – we test the product, provide information, and help inform (or make) product decisions.

The "how" part of our work is (to me) much more interesting (and a big reason why I love working on this team). We strive to have a culture high in trust. We have few (none that I can think of, but I’m sure I’m missing something) top-down mandates. We believe that the people closest to the work are in the best place to make decisions on what the work is that they need to do. We obviously give more guidance to employees new to the team and managers are involved in coaching, but for the most part, we trust the people on the team to do what they think is best. For example, we have no requirements on test case counts, bug find rates, code coverage rates, or anything else like that. If someone decides that working on a side project for a few days will help them get their job done better, they don’t need to clear it with anyone – they just do it. Failing is ok (and expected – if you’re not failing, you’re not trying hard enough).

If you’re worried (and I know some of you are), it’s not chaos – we’re surprisingly efficient and good at what we do. However, I think that if you’re going to create a high-trust work environment, that  you need to provide just-enough structure to keep people headed in (more or less) the same direction. On our test team, we have a set of five guiding principles / values that our team uses to help figure priorities and our work.

At the top of the (non-prioritized) list is self-organizing teams. For example, we just finished a "quality milestone", where we had a few months to prepare for the upcoming release cycle. Like many teams, we had a pile of technical debt from our previous release, some big work items we had to do to get ready for the next release, plus some ideas for new tools that would make us more efficient down the road. In many organizations, test management would draw up a plan of what needed to be done, select who was working on what, then align the team on the work. On our team, we basically just told people to get to work. Because we trust them to discover the most important work, and because we value self-organizing teams, that’s what they did. They formed teams and tackled everything they would have if we had a top down mandate. In an extension of this principle, when we formed feature teams for the product cycle, we let people choose their own team. The idea has worked extremely well – we have unheard of (on the low side) levels of attrition, and people are excited about what they work on. We have plenty of other opportunities for self-organizing teams, but I’ll have to save those for another post.

Another bit of structure that helps when the work isn’t generated top down is showing value frequently. Sharing progress frequently a great way to discover what each other are doing (which is fantastic for learning as well as plain-old information sharing), and a way to celebrate our successes. As I mentioned above, we encourage failure, but one of things that needed for this is the ability to fail quickly. It’s one thing to hit a blocking dead-end a week into a project, but without sharing progress frequently, you could go months before discovering your idea isn’t going to work – and that’s not so good.

We also drive our progress and priorities through the value of continuous improvement and innovation. This simply means that we want everyone to think frequently about how we can be better. For example, we expect people to frequently identify practices that our team(s) follows because, “that’s the way we’ve always done it”, and to ask, “Is there a better way to do this?” We encourage (and expect) everyone on the team to contribute to the overall improvement and innovation.

We also put a big emphasis on customer focus. We do a ton of work in analyzing customer data, interacting directly with customers and on customer-focused test design (something I’ll be talking about at a few upcoming conferences).

And finally, we have fun. It may seem strange to have this as a guiding value, but we think it’s important critical! Whether it’s playing on the Lync Test intramural softball team, or playing Xbox in one of the conference rooms, or just taking time off to take a walk with teammates and joke about the guy who blogs about the test team, we value balancing work with play.

I don’t know of a lot of other test teams like this, but it’s certainly a fun and interesting place to work.

What do you think of our test team?