The Development Spectrum
Having worked for about a dozen different companies and organizations, I have the opportunity to reflect upon a variety of experiences that define what software development teams look like and how they are organized, and as I do so, I like thinking of human behaviors and traits and the processes they create as being along a spectrum. Perhaps my recent exposure to this terminology and my years spent trying to untangle its nuances have colored my perspective (wink).
Just as we have often heard that each person is different and unique, so too, I posit, the way we create is different and unique. For example, my insignificant exposure to art and artistry has shown me? that artists tend to find a unique and recognisable style as they develop. Similarly, if you write code and review other people’s code you can start to recognize a developer’s fingerprints in their structure and style. The same is true in writing, and consequently, often writers will have to make a conscious choice to adopt a different style for different purposes. Why not see this same uniqueness in the software development methodology of a team?
Someone recently reposted Ron Jefferies’ article, “We tried baseball, and it didn’t work”. He meant this as an allegory for how the customization of a process or manifesto can eventually deviate so far from the original that it ceases to achieve the intended purpose.? To fully catch the nuance of the allegory, it is important to note that most sports? don’t leave a lot of room for customization, especially if you are competing in a league. The rules are set, hard and fast. Change, if any, is adopted slowly and usually after heavy consideration. The Olympic Javelin, for example, was redesigned in the 1980’s only when throws were exceeding the 100m field length.?
With athletics, you want to compete on an even playing field. The goal of athletic competitions is to train to the rules and measure and compare human achievement in a controlled environment. With creative works, such as art and, I would argue, software development, the competition isn’t among the individuals or teams, but in terms of outcomes. When outcomes are measured and resources, methodologies and all else are left unchecked, then the idea is to see how you can gather the right people in the right environment with the right resources to build the “best” product. Here, even the definition of “best” varies as it could be the ability to innovate, improve performance, or some other measure.?
So here we are, in the world of software engineering, trying to figure out how to build and deliver a product that’s easy to maintain, well optimized to task, stable and reliable and a host of other “non-functional” requirements. The game, then, is to select the best assortment of the following elements
and then decide on what’s going to be fixed, and what’s open to revisiting and changing.
In several organizations I have actually found that the list above isn’t that easy to nail down, specifically in terms of what’s open to discussion and what isn’t due to a lack of clear communication or inflexibility. Many engineering leaders will say that they can relate what is on the table and what isn’t, but it’s seldomly true. In general, some things are not open for discussion even in the very early stages.?
领英推荐
The most apparent example of this would be the language and framework for development. If you have chosen to use JavaScript as your primary development language and have developed even the simplest prototype in it, the likelihood you will change your mind decreases quickly day by day to an infinitesimal level. It would take some significantly disruptive event to bring about change. Often if this does come, it comes when there is schism in the fiefdoms that form within organizations where the Old Guard is seen as stodgy and old fashioned and has lost favor with the powers that be, and some new incoming division or department lead comes along and? is seen as the future of the company or a significant source of revenue. Twitter’s switch from Java to Scala is one such example. I remember the CTO talking about how much he felt that transition was a mistake but it seems it was out of his hands. To see this division within any organization, just look at what their job descriptions state for closely similar roles in different teams. To sum this up, changing the language or framework is difficult as the size of the legacy rises, but doing so isn’t impossible--many organizations have successfully made those changes. Figuring out which type of organization you are will help you navigate change management and constraints.
To reiterate, all organizations are not the same, they aren’t constrained by the same things and they aren’t playing the same game with the same rules. The iconic album cover for Pink Floyd’s Dark Side of the Moon (or the same picture in any physics text book from high school) is a great metaphor for the fact that without some way to filter differences, things might look the same but really are not. What this also means is that whenever we, as a team or organization, come to a fork in the road, the optimal path for us to take will depend on who we are and how we work together. What works for one team won’t work for another. If you are trying to redirect electromagnetic radiation, you will need to understand its composition before picking the correct reflective materials. For example, you can use a household mirror to reflect visible light but how effective is it at reflecting X-ray or Gamma-ray radiation? I wouldn’t take my chances.
But before I leave you thinking that the spectrum of development organizations can be reduced to some one-dimensional list, I want to introduce the notion that within each of those elements there is a level of proficiency and maturity which is also a significant contributor to your team’s make up. In the late 80s and early 90s there was quite an effort made to rank development teams. Various models were generated and one of the more famous ones is the Capability Maturity Model. A closer look at this model identifies a variety of attributes of a team or organization and then looks to rank them by their maturity within that model. While such formal process is often scoffed at by the private tech sector, there are important learnings to take away from the rigor that was put in developing these models.?
Back to these models and their value in a moment.
Change is inevitable. As the circumstances surrounding your team changes, so will you. Some change will happen naturally and organically, a simple act of natural evolution where each iteration of the team’s output will respond to the pressures put upon it. However, there will be points at which the change will need to be more than incremental evolution and a significant leap will be needed. It is at these moments where a more carefully thought out change will be needed, and it will be stark and painful. What you’ll want is to ease the discomfort of change and transition and to be thoughtful and convincing in the choices made about what to change. Most controversially, you will want the change to take place while retaining the identity of the team, making its members part of the change as opposed to forcing it upon them.
When Twitter killed Vine, a lot of Vine creators said that Vine failed to include them in the discussions about what they needed as creators to still want to create on the platform, which ultimately led to its demise. It was a very interesting time as these creators are still successful today on a variety of other platforms. In order to have successful change, the people making that change have to be committed to it. Every individual involved in the change has to be given the opportunity to either agree or disagree, but commit to the success of the change. And every change maker must be ready to hear the dissent up front and during the process and be ready to handle the feedback in whatever form it comes. When people are invested in the success of a project, process or initiative, they will also be vested in making it better and looking for improvements. Sure, you can force the change with determination and sheer will and perhaps even threats, but that will only work on so many for so long and this isn't as effective as when those involved are actually invested,
There are a lot of stories where some of the greatest human endeavors were achieved on the backs of the subjugated, the oppressed and the indentured. There is plenty of debate as to the working conditions of the people that built the pyramids in Egypt or even the Temple of Quetzalcoatl. Most likely there were a small number of designers and architects and the rest of the build team were stripped of much participation and initiative. The Taj Mahal may have been the brainchild of one man but the names of all the others involved in the design, build and finishing are long lost. Creativity was the purview of the few and the builders were just that, implementers of someone else’s vision, design and instruction.
Why then, have we started to consider alternative management and leadership styles and team organizations? The answer is most likely “creativity at all levels”. In a highly competitive landscape where solutions can be developed on the scale of months and not decades (as used to be the case) the need for creativity is paramount. In order to foster creativity, new management styles and team organizations are needed. At various points during the development of the product or solution there will be opportunities for creative solutions and designs and opportunities for brute force implementation of those designs. A single inflexible model is unlikely to achieve the best results as the nature of the work changes. When creativity is needed, the environment must foster that spirit. When implementation needs to be done, so too, must the process support the swift execution of plans. When bugs need to be addressed, that too requires a different mindset and management process. The work isn’t the same and therefore the tools, supports, and processes can’t remain the same.
And so we return to the idea that development teams, their processes and management and their structure, all lie along a spectrum. And depending on where you are along the spectrum, your needs change and the way that you implement change management itself must change.