Building valuable software is difficult. The technical complexities of implementing what the business needs should be the focus of the development teams. Too many times, the teams can get caught up in activities which detract from their desired focus but are necessary from a technical perspective. Many of these activities are not unique to the team and there are opportunities for groups of development teams to be able to come together and share the benefits of the work.
One of the more famous models is the Spotify model, which does a great job in describing a way for teams to cross collaborate. The model identifies a bunch of different groupings which all have different focuses. One of the most powerful and valuable are the chapters, which are defined as the following:
Chapters are the family that each specialist has, helping to keep engineering standards in place across a discipline. Chapters are typically led by a senior technology lead, who may also be the manager for the team members in that Chapter.
https://www.atlassian.com/agile/agile-at-scale/spotify
The chapter is a great tool to help drive shared technical value across the squads in the enterprise. They are comprised of specialists in a particular area, so the chapter members tend to know and understand where the subtle nuances are in a given technology and most importantly, they understand the long term implications of adoption.
Standards as an Output
The chapter can serve as the gatekeeper for enterprise standards. They understand what needs to be standardized and more importantly, they know and understand what does not need to be standardized. It’s a delicate balance. You want your squads (teams) to be able to develop and deliver business value with as few constraints as possible. But simultaneously, if squads are left to their own decisions, you will end up with a myriad of implementations and subjective standards. Let’s walk through some of the chapters that almost every enterprise needs.
For example, API development within the enterprise is exploding with the adoption of microservice architectures. Left to their own, every team may or may not deliver their APIs uniformly. Simply saying generic statements such as “we should use REST as a standard” is not going to cut it. The devil is in the details and the API chapter, comprised with members who understand the details of API deprecation and even subtle aspects like how to properly document the APIs, will be able to help all the teams cut through the subjective decision making process and quickly deliver.
Automating Standards Compliance
The chapter members should not only be idetifying the standards for a particular area, but they should also be focused on how the standards adoption will be assessed. Manual architectural reviews will not work because they do not scale. For every standard, there needs to be a way to enforce compliance to standards using automation.
Using our example above, a company can adopt the OpenAPI specification and write a compliance check which can be plugged into the CICD pipeline. The check can either restrict any release from moving forward or it could simply produce a report to be shared with the chapter showing the APIs which are not in compliance. Ultimately, the answer for automating standards should be dependent on the type of release. If it’s a normal feature development release, the check should restrict the release. If it’s a hotfix, or something more time sensitive, the check should simply be reported. Regardless of the implementation of the checks, the main takeaway should be that standards are only as good as their ability to be enforced. If you can’t enforce compliance, then having the standard is generally pointless.
Management Training
The other things chapters (as well as the other cross-squad groups) can provide is valuable people development. These groups are great opportunities for those without management experience to gain valuable knowledge. The chapter ecosystem can help people figure out how to work with and influence the behavior with others through the work. Smaller efforts, such as developing and implementing standards automation, can give small scale leadership experience to those individuals looking to move from the role of individual contributor to leading teams. The question of whether an individual is ready for management is sometimes hard to answer and these cross functional groups provide a way to incrementally develop those with management aspirations. A valuable proving grounds for those with eyes on the next level.