Risky Business

Software Development is essentially risky. It is also marked by a very fluid and dynamic business environment in which requirements can change, new requirements can be added at any time, projects can stop and be restarted and some product features may even be removed entirely. Besides the external events surrounding software development, there are internal factors as well. The composition of a software team and its culture play an outsized role in whether the software product will be built. If the composition of the team does not have the appropriate capabilities or the knowledge base for the type of product being built or the system they are working on, the product functionality will suffer and it may not realize its full potential.

To stabilize the software development environment, businesses attempt to crystalize and formalize the software development lifecycle. Whether they are using the traditional waterfall model or SCRUM or Kanban or Feature Driven Development or Lean Software Development or any other framework, the attempt is to reduce risk and to promote certainty in the software development lifecycle. But no formal process imposed as a set of rule based behaviors necessarily becomes Agile. The principle of Agile methodologies arise from observation about the nature of software development itself. And if the nature of the product being built is understood, then the development process will be naturally Agile.

The primary objective of building an Agile team is to compose it such that the composition of the team should include individuals who understand the architecture of the product and how to decompose it into natural units of functionality that can be implemented in a timely manner. This effort we can call the development model.

Essentially the role of the Agile team is to understand the product model and map it to a development model.

The Role of Architecture

A software product has a structure. This structure is composed of the system components that provide the functionality of that product. Besides the software architecture, the behavior of the product can be decomposed into features and user stories. Additionally, there is the matter of the domain model which gives a product its unique personality. (Note: that a domain model is not a data model. Instead the data model is derived from the domain model. For more on this see Eric Evans “Domain-Driven Design“).

When building a software product it is essential that the architects work with the team to discover the product structure (architecture), user stories and its domain model. By doing this the system can be decomposed into smaller functional units, that can be prioritized and implemented in a timely manner. Decomposing the system into its component parts and domain model, is what we call the development model. The development model is based off the architecture, the user stories and the domain model. It is a crucial function of the development team to have one or more individuals who know how to do this or at least know how to discover the development model from architecture, user stories and domain model.

The implementation of the development model and its user stories is foundational to Agile development. But it is not always known completely upfront. Like anything else it can be partially known, discovered and evolved through iteration. This development model in its essential form is not derived from any Agile framework, but models the nature of the functional components of the products.

The mistake is often made that having a tool and a formal framework makes a development team Agile. It does not. Instead Agility is a function of understanding the system / the product, its development model and how to implement each behavior in that product. This effort, targeted towards continuously working to understand the product, deriving a development model and iterating over each user story in order to build out the product is essentially Agile by nature. And this process can be mapped to any formal framework or tool that the team chooses.

Team Composition

 Besides the role of the Agile Coaching Team the rest of the team should consist of individuals who know how to build certain parts of the system, either as specialized developers or full-stack developers. For instance if there is a strong database component in your system, it is advisable to get someone who knows how to build schemas and to translate domain objects into database schemas.

Similarly, server-side components should be built by the folks who know how to build server-side web apps. And it goes without saying that building the frontend requires people who know how to build user nterfaces. Very often small organizations do not have the requisite skills for these system components, and so they use UI developers to build out the entire stack. There are frameworks that allow you to do this, but the product so developed will not be flexible, will not scale and at some point will need to be rewritten.

On the other hand there are teams that build from the bottom up and attempt to turn infrastructure developers to UI developers and this leads to less than stellar outcomes. There is a strong argument for building small teams with real full-stack development capabilities. Either that, or grow the capabilities in-house. Basically, hire people with the skills that match the product you are going to build. Developers with immature capabilities produce immature products.

Team Culture

Culture: It is often the most overlooked aspect of software development but it is perhaps the most significant factor in the development of a successful software product. You can have a team of incredibly skilled software practitioners and yet, due to their interactions, have products of indifferent quality. A team dynamic, though intangible, has a huge bearing on the development and delivery of software products.

Culture is one of those nebulous things that is hard to define but is immediately recognizable in the workings of a team.  Agile promotes certain qualities in a culture: qualities like transparency, collaboration, communication, as well as dedication to high quality in every deliverable. But there are no formulas on how to establish a culture. It arises naturally from the values and practices of the core leadership of a team. Though there are no real guides or patterns for establishing the cuture of a team, there are definite antipatterns in software development:

• Hero Developer: One person who holds the key to the development of the product. When he/she walks the team falls apart.
• Power Centers: Team members joining together to discredit other members.
• Toxic Individuals: Individuals with damaging interactions with other members in a team. When this individual leaves the organization productivity immediately goes up.
• Excessive Meetings and Developer Interruptions: Excessive Slack conversations or meetings that take away focus on actual product development.

There are many other antipatterns and sometimes building a team can involve finding these antipatterns and removing them. This is not a recommended practice, but like everything else, team building is an iterative process and depends upon the indivduals leading the effort.

The culture of a team like any other culture starts with the leadership of that team and needs to be developed and grown and established by the Agile Coaches that make up the core team. Like the Agile process itself, culture is developed and grown and is not a set of rules to be followed. Building a team requires experience, understanding and continuous learning on the part of everyone in the team, but especially in those responsible for establishing its culture and creating its direction. Enterprises can rise or fall because of their culture.

Ideate Iterate Innovate