I had the privilege of participating in a presentation discussing some of the MBF engineering and project management practices to a few senior leaders on the Visual Studio team last week. Using a theme of a “Quality Ecosystem”, we covered a variety of topics. The section that I presented covered our planning process and our combination of Plan Driven and Agile approaches. We also talked about our development and test practices around design, unit testing, scenario testing, code reviews, and other topics.

While we have plenty of work to do in a lot of areas, I do feel that we have a great team and some really good practices. But it’s not easy to quantify either the team or the practices. We did incorporate a number of metrics around meeting commitments, quantity of automated test cases, code coverage, and other areas. That helped, but it still doesn’t get at the essence of what separates a really good development team from others.

At the end of the presentation, Soma, the head of Microsoft's Developer Division, thanked us and said it was a good learning opportunity for him. He also said something that was a key takeaway for me and the other presenters. The comment was that he really appreciated the engineering culture on our team.

The concept of a software engineering culture had been bouncing around in my head all week as we prepared for this session. While we hadn’t made it explicit in our presentation, Soma hit the nail on the head with his comment. Really great development teams have on ingrained culture that produces high quality software. It is that culture that enables the introduction and ultimate success of best practices like Scrum, test driven development, code reviews, and others.

Let me give you an example. When I started with Microsoft and MBF over three years ago, the team had in place excellent practices for code review and unit testing. The interesting part was that nobody thought it was a big deal. It was just the way that the team developed software and it was the right thing to do, No manager was hounding people to do it.  No process dictated that it be done, or that it be done in a certain way.  The team simply implemented in a way that made the most sense.

Having had some exposure to getting these practices in place at my previous company, I knew it was a big deal! And I’m sure it was a struggle to get the practices in place before I came. But once it was in place, individuals on the team saw the value and it become ingrained in how the team developed software.

I believe this culture was also critical to our successful introduction of Scrum over the past year. It started with a willingness to try something different. It was followed by a little bit of success. Pretty soon, it became ingrained in how we do things on our team.

Karl Wiegers, the author of Creating a Software Engineering Culture, writes the following:  "A "software engineering culture" describes an environment in which the members and managers of a software group share a commitment to building high-quality products in a disciplined way. A healthy software engineering culture is a fusion of quality-oriented attitudes, constructive human interactions, and effective technical processes. The culture is based on a set of values, often unspoken, that guide the behaviors of the people in the organization."

Wiegers’ statement describes the team that I’m on right now.   Creating a software engineering culture is a challenging thing to achieve, but it’s pretty cool when you get to it!