Enablement of Developers: Culture

Cultural differences should not separate us from each other, but rather cultural diversity brings a collective strength that can benefit all of humanity.

Robert Alan

When talking about development culture in an organization it is important to remember that developers are complex people. Culture for a development organization is a constantly mutating environment, and as such it is hard to make generic recommendations. There are, however, certain characteristics of successful development cultures which every organization should strive to adopt:

  • No blame: This is an oft cited but rarely followed cultural imperative for successful development organizations. It recognizes that failures in the planning, development, deployment and maintenance of complex software systems are both inevitable and not the fault of an individual human, but the failure to utilize proper process and tooling. Whilst this is a complex topic there has been much written about the ‘no blame’ culture (which was also recognized to be extremely valuable in reducing aircraft failures by enabling pilot and engineer feedback in that industry)
  • Inclusion: It has been well verified that a team of diverse individuals, on many spectrums of diversity, has less tendency to fall into “group think” and is more innovative as well as more productive overall. Different opinions and backgrounds can lead to different perspectives on a problem. Inclusion also requires respect for and understanding of the other individuals in the organization.
  • Best practices: Development organizations should strive to encourage the use of best practices which are widely recognized in the industry. Best practices are called such for a reason, yet many organizations feel that somehow they are unique and can avoid those practices. In reality, unless related specifically to the company’s core competency differentiators, it is unlikely that a company is better placed with their own processes to ignore best practices.
  • Not-invented-here: NIH is a cultural anti-pattern which describes the tendency of developers to always want to write systems rather than adopt existing technology. It results in developers spending a lot of time not focused on developing the code and systems which are central to the company’s core competency, but instead “re-inventing the wheel” of other systems.
  • Nitpicking: This is another cultural anti-pattern which can negatively impact velocity. For most modern programming languages there are tools which encapsulate best practices such as canonical formatting. In almost all cases it’s best to use the default rulesets for those tools rather than argue about things such as brace positioning (end of line vs new line) etc., as the rulesets have been widely adopted by many organizations in the industry. Choosing obscure local rulesets or “over-engineering” solutions to achieve a level of unattainable perfection can kill the velocity of a development team. In many cases a slightly less perfect system which is usable by customers is better than a nearly perfect one still stuck in development.
  • Siloing: Another anti-pattern, siloing refers to the focus of a group on their own issues, not those of the organization as a whole. Siloing results in friction between groups and artificial barriers to communication and productivity as artifacts and feedback flow between groups.

These are just a few of the aspects of culture which can impact a development team, I encourage the reader to search out others and read the literature available on these and other cultural phenomena in development organizations.

I would also direct the reader to understand Capability Maturity Models, such as the famous Carnegie Mellon Capability Maturity Model for Software Engineering. Capability Maturity Models are a way to gauge and direct cultural change in organizations.

3 responses to “Enablement of Developers: Culture”

  1. One thing to do. Make sure the Scrum master is not a PM, nor has anything to do with marketing. Otherwise, the daily standup meetings turn into kangaroo courts because the Scrum master becomes a mere boatswain, and this guarantees that anything related to security, code integrity, or technical debt gets tossed aside.

    Standup meetings that last 4-6 hours (the norm in some companies) effectively slice your development man-hours by 1/2 to 2/3s. Couple that with stress from having to deal with confrontations on a daily basis, ensures that little meaningful code will happen, especially when management threatens to offshore all the devs.

    • Indeed, good points! Running a good scrum process requires a lot of experience.