In case you’ve innocently clicked here unaware that you’ve stepped in the middle of a conversation, this is the fifth in a series of posts where I’m discussing the elements necessary for a successful programming culture. (Check out Part 1, Part 2, Part 3 or Part 4)
As I’ve stressed before, having the right culture can make all the difference for a software development or programming organization, and breaking culture down into its constituent parts can be a crucial first step when building a new team or trying to improve an existing one.
For those scoring at home, the elements we’ve covered so far are interpersonal, innovation, standards, delivery, communication, empowerment and selectivity. For this final post in the series, we’ll take a look at excellence, focus and environment.
At first blush, the desire for excellence is a bit of a no-brainer — it’s how you meet client expectations, gain more business, and continue to grow. But it doesn’t happen in a vacuum. By making sure people know it’s a priority for your organization and that there is an expectation of excellence within your team, you’re encouraging team members to step up and achieve.
And what, you may ask, is excellence?
I’ll leave that for you to decide. No, really! You need to define exactly what excellence is and communicate that to your team. Excellence could be reaching certain delivery goals, increasing velocity, delivering with fewer bugs, adding more features in the next iteration … your definition of excellence is that which aligns with the goals of your organization. If you don’t know what those goals are, then this exercise will be a twofer, since establishing goals is crucial for a company to operate effectively.
One last thing: When defining excellence for your team, try to state it in terms that are measurable. This provides a means of feedback so that team members will know if they’re working according to company expectations, and it provides managers with a yardstick for gauging productivity and efficiency.
To be specific here, I’m talking about customer focus: really experiencing what customers go through and what problems you're solving for them. Such a focus might involve working with personas, visualizing the user, and creating stories that fit those personas in order to get a good visceral, concrete sense of what customers are going through, either without the software while you're solving the problem or with the software once they're using it.
Another means of encouraging customer focus is to make the development team use the software they’re developing. I've seen this in a number of different companies. At one, we had a product that was a database of information for electronic parts, and it was a very configurable system. It used what was called a metamodel approach, so you could basically define the data structure in the application, and the user interface would then adapt to that and give you the necessary screens to add or modify information within the system.
We realized, “Wow, this system is so flexible! You could use it as a bug-tracking system,” which was not anywhere near the reason why it was developed. In the end, though, forcing the development team to use it as a bug-tracking system really helped, because it let them experience the things that were good and the things that were not so good. As a result, the product’s flaws tended to get fixed more quickly. Until then, there had been no reason for the developers to suffer through those unintended product features the way a customer would.
The whole episode taught me that anything you can do to encourage focus on customer experience will ultimately benefit an organization’s programming culture enormously.
The environment element actually has two facets:
For an exploration of the former, read “What Tools Does Your Outsource Team Use?” about how some of the latest visual tools enhance programmer efficiency and work quality.
As far as the physical environment goes, beyond the obvious considerations of providing your team with decent equipment and the like, it helps if you can create an environment that encourages teamwork. This can involve everything from having whiteboards available for meetings to establishing nice public areas where people can meet and collaborate in an informal, spontaneous manner.
At the same time, of course, you want to create an environment where it’s quiet enough for people to get their work done. Fortunately, advances in technology — noise-canceling headphones, white-noise machines, etc. — have made a big difference in this area. (Such was not always the case. Back in the ’90s, we had this excellent programmer, Dave, who became so frustrated with the noise around his cubicle that he moved his work station into the office supply closet. We didn’t want to inhibit his productivity in any way, so needless to say our use of office supplies dropped considerably).
Work environment quality is definitely one of the things we look at when we’re visiting an offshore team. It’s been my experience that a high standard is maintained around the world — including among our partners — because companies realize the importance of treating programmers well if they hope to keep them. There’s that much competition out there.
So there you have it: five posts about the elements necessary for a successful programming culture. As I mentioned earlier, these posts were inspired by the book Managing the Unmanagble by Lichty and Mantle. They propose 17 different elements to be considered and we’ve covered most of them.
Hopefully this discussion will serve to remind people that company culture doesn’t just materialize from happy thoughts and earnest wishes. It takes planning, commitment and a sustained effort to ensure that all those many elements will be addressed. Like the old song says: “This ain’t no party, this ain’t no disco, this ain’t no fooling around.”
It’s worth mentioning, too, that one of the real advantages an outsourcing partner can bring to the table is the ability to provide a team with a successful, fully functioning culture right out of the box, no assembly required.
Whether you choose to work with an existing team or build your own, however, the bottom line is clear: Culture counts, and failure to acknowledge this reality and act accordingly can mean the difference between just getting by and having a truly successful organization.