A Recipe for Software Teams Organization

Challenge

Software development is still a human art. One or two developers cannot develop a sizable software. A successful significant software development needs properly working teams. Therefore in a product development company, the team organisation is one of the decisive factors.

Teams are responsible for creating outcomes (deliveries). At the same time, the teams must up-keep the quality of the outcomes (ownership). Therefore, deciding the team organisation based on software delivery and software ownership is a must-win challenge to a company.

Agile Software Development

Agile software development has brought various optimisations to software delivery. Most successful software development companies follow different forms of agile.

The basic agile practices focus on delivering software with small cross-functional teams. The extended agile practices focus on organising multiple agile teams to deliver and maintain significantly large software. The extended agile also makes sure software component ownership is kept within the agile teams.

The design of

1. a feature,
2. a software component,
3. a software component ownership,
4. a feature delivery,

are unique to each software irrespective the agile software development practice. The software development company should design these four aspects while keeping its team organisation in tandem.

1. Features

A feature is a unique business value to the software user. Considering faster software delivery, the company should design the users’ business value giving a sense of progression to the users. Therefore, always design a feature regarding the user need and sense of progress without eliminating one another.

Following are features requested by a user. Those statements are written as User Stories. The user stories are for email reader software. We will be using these stories throughout this text. The first story is already implemented. The second story is a new feature.

Story 1: As a reader, I would like to see all my recent mails from senders at the top of my email reader as default view, so that I can attend to them quickly.

Story 2: As a reader, I would like to see an Extract of Important Content in all my mails at the top of my email header on reader, so that can attend to them without opening the email.

The need for feature design and how to assigning features to the teams are explained in section 4. Section 4 has examples of how to create sub-stories considering user need and sense of progress.

2. Software Components

Let us understand more about software components. Software components are parts of the application which are built separately to reduce the complexity of the software. Most times, new features cause more than one software component in the application to change. When multiple teams are modifying the same component, the component changes create friction between teams. Nevertheless, based on the design approach taken to develop components, one can avoid the need for substantial changes to existing software components, hence reduce the friction between teams.

Following are alternative software component designs assuming the first story of the application is already developed. Each component is represented with a number.

Design 1 — Components based on Technology

1.1 Reader UI — Email reading view has a list of columns like From, To, DataTime, Subject and ordered by DateTime. Functions to filter / sort / read / unread /delete emails.

1.2 Handle Reader UI Requests — Accesses email cache, if emails are not in the cache, accesses email store for data, add emails to the cache and send responses to the Reader UI

1.3 Email Store Manager — Functions to list / read / unread /delete emails from persistant storage.

1.4 Email Cache

Story two would require changes in all four components in component design 1.

Design 2 — Components based on Domain

2.1 Reader UI View — Email reading view has a list of columns like From, To, DataTime, Subject and ordered by DateTime.

2.1.1 Reader UI Email Read, Update, Delete — list / read / unread /delete the emails received.

2.1.2 Reader UI Filter — filter from the list of emails received.

2.1.3 Reader UI Sorter — sort the list of emails received.

2.2 Handle Reader UI Requests — Functions to execute UI functions through email cache and access Email Store Managment if cache is expired.

2.3 Email Store Manager — Functions to list / read / unread / delete emails from persistent storage.

2.4 Email Cache

The domain-based component design needs a small change to component 2.1 and two new components shown below to implement story 2. Fewer changes to existing components mean less friction on feature delivery.

2.1.4 Reader UI Email Extracts — show email extracts of list of emails received.

2.4 Handle Email Extracts — Functions to create a extract of email from email body.

This example clearly shows the importance of software components and its design to the software development company.

Software Component Coupling

The communication between different software components makes each of the components coupled. The amount of change required to a dependent software component when change happens on an independent software component identifies the level of coupling between the two software components. I.e. The changed software component needs deployment of the dependent software components.

organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations. M. Conway

When developers communicate with speed and freedom, personal experience shows that they tend to forget about the boundaries of components and build heavily coupled components. Therefore, the companies should make sure to organise developers into teams and associate components along with teams.

An example of heavy coupling;

Email Reader Architecture — Technology based component design.

All software components are deployed as single monolith including Reader UI View, Handle Reader UI Request , Email Store Manager and Email Cache. After implementing story 2 all components are compiled, built and deployed together.

On the contrary, if the application is designed with loose component coupling, the impacted components of the application can be changed and rolled out without the friction of dependent software components. In loosely coupled software, the independent components do not have binary level associations with dependent components. The associations are mainly through messages passing. The software components are capable of handling message formats and versions.

An example of loose coupling;

Email Reader Architecture — Domain based component design.

All software components are deployed as independent applications (microservice or microfrontend). The two new components will be deployed as separate applications. The interface and internal logic change of the independent component Read UI View is re-deployed to integrate Reader UI Email Extracts component.

A new feature needs a lesser number of software component changes when the software is designed with loosely coupled components. Unwanted recompilation or deployments of software components are not required. The individual components can be released without waiting for dependent software components.

In last example the two new applications are released without waiting for Read UI View change.

Software Component Versioning

When software components are deployed as applications, it is essential to support multiple versions of the software component application.

Story 2 development team decides to support story 2 and version prior of Read UI View component due some performance limitations in story 2 implemetation. If the Read UI View component was designed to support multiple runtime versions, the team could deploy both versions of Read UI View component application until the limitations of new implementation is resolved.

3. Software Component Ownership

The software components are assigned to teams to control the lifecycle of the component. The owning team makes sure the component possesses required quality after a modification to the software component by any team in the company. The owning team also educates other teams of the design and development practises of the software component before the other teams try to modify it. This knowledge sharing avoids the problem of everybody in the company knowing everything. As a side effect, the education sessions help owner team to improve the component with the expertise from other teams. The component ownership also strengthens the development of loosely coupled software (See 2. Software Component Coupling). Considering all these advantages software component and ownership is a must for agile software development. Therefore, it is a major factor in organizing teams.

4. Feature Delivery

With agile development, the expectation is to deliver incremental value-added changes fast in predefined pace. If story two cannot be satisfactorily delivered quickly within a preset period with a single agile team, the company tends to avoid the problem by adding more agile teams. Most of the time, the story two would be split among agile teams based on component ownership to prepare a fast-tracked delivery plan. The company would create a role to run across multiple teams to resolved dependencies, establish contracts and monitor the project. This approach may meet the delivery date committed, but it would not make the incremental deliveries or keep up with the predefined pace in agile.

Three Team Delivery — Lets assume story 2 is estimated as 4 weeks if the story will be implemeted by single team with complete component ownership. The company divides the story among 3 teams where each team owns a one or two components to meet a 2 week deadline by the user. All three agile teams are working in 1 week delivery cycles and at the end of week 1 all teams are complete with the components. After the first week, the teams are not able to demo the feature as the changes are not integrated yet. The teams complete the component integration in second week and release the software meeting the deadline successfully. But do the teams can assure their work does not have any issues or user would accept it in the first go. If there are issues or new changes they need another week to complete the work.

The best approach to tackle fast predefined deliveries is to break the story into sub-stories and deliver sub-stories to a limited user group. This way, both incremental value and preset pace (sense of progress)can be maintained.

Three Story Delivery — Lets assume story 2 is estimated as 4 weeks if it will be developed by single teams with complete ownership of components as before. To meet the 2 week deadline the story was divided into 3 small stories and assigned to one team instead of breaking the main story responsibility among three teams. The new sub-stories.

Story 2.1 — As a reader I would see message stating “the extract of the email would be loaded here” next to email header with real formating.

Story 2.2 — As a beta version testing reader I would see the extract of the email in location mentioned in story 2.1. (Beta testing readers are identified by the routing software)

Story 2.3 — As a reader I would see the extract of the email in location mentioned in story 2.1.

At the end of week 1, the story two feature team delivers story 2.1 to the email readers. Readers can now give feedback on the feature like the place of extract, the appearence etc… The team has also completed 50% of story 2.2 in 1st week.

How did the team manage to release story 2.1? The software components were designed as decoupled applications. Therefore feature team managed to release the changed without impacting other components and teams.

In week 2 the team made the feeback adjustments from readers on story 2.1 and delivered the story 2.2. In week 2, the beta readers provides further feedback. Specially the team can now decide on performance of the feature. If the performance is acceptable to the beta readers the team can quickly enable the feature to entire user base without implement the cache which was added as story 2.3. Even though team did not achieve the deadline the team managed to make the final delivery before the Three Team Delivery.

In the case of feature team noticing a performance issue the team could implement the cache in story 2.3 and deliver the software at the end of week 3. This is the same delivery date as the Three Team Delivery.

So what is the magic in Three Story Delivery to make the same delivery time as Three Team Delivery with just one team? There are several reasons.

1. Even though only one team was delivering the feature, the other component owner teams were helping the team by reviewing the changes or imparting knowledge.
2. The story two feature team manage to get quick feedback before they did the final release for users.
3. The story two feature team got the chance to omit some over-optimization efforts.
4. There were no coordination work or integration work between teams.

The two teams which were not working on story two were working on two other stories at the same time the story 2 was delivered.

The design of the feature delivery is important when organizing teams.

Conclusion

organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations. — M. Conway

Conway made this law back in 1967 (ref). At the time the software was developed by multiple large teams. Therefore, the software built were massive monoliths and with limited communication between the software.

To make Conway’s law valid for today, the small agile teams should build small software applications which talks to each other in a decoupled fashion. Stop breaking the law!!! Do not work in small agile teams with large coupled applications.

Loosely coupled, versioned, domain-based component software makes feature delivery smooth and speedier given that a single feature team ultimately delivers a feature with the acceptance from the relevant domain component teams. — A recipe for team organization.