This post is a continuation from my previous article on Choice "Enabling choice for Agile delivery Scrum teams."
Although my kids benefited from empowering choice in many ways, they still needed structure to know when and how to consume or buy content and games. Clear guidelines on when they could stream and play, as well as parental restrictions to ensure age appropriate content once the absolutes where set and understood, they could just play, things worked out well.
Agile delivery teams are no different; they need those Absolutes to provide the structure and guidelines, etc. to let them move quickly with a clear understanding of where they have choices and where, and how, they need to work with absolutes.
Absolutes provide the backbone or foundation for teams to operate on and build innovative solutions. They provide the structure and stability that managers, EAs and CTO/CIOs need to do their job. They also provide the framework for Agile teams to get going quickly and stop them re-inventing complex and time-consuming aspects of their product solution.
Absolutes are sufficiently complex and can be slow to acquire and implement, they often need specialist skills to manage, and it would not be viable or rational to allow for many different team level implementations in these areas. Absolutes should not be project specific so sharing these foundational items across many teams is a definite benefit to them. Absolutes are chosen based on the greater need as opposed to application stacks which are selected based on the individual team application requirements.
Here are a few examples of Absolutes:
Dev-ops and Continuous Integration/Continuous Delivery: Dev-ops processes and release pipelines are complicated and time-consuming enough to get running smoothly without having every team build the same thing over and over again. Mandate your build/release processes and make them easily understandable as well as readily available. Protect the release pipeline by making any enterprise processes needs like audit trails etc. part of the end to end flow to ensure the pipeline remains smooth all the way to production deployment. Work hard to remove traditional process delays around centralized release management.
There are obvious low hanging fruit opportunities like having a central source code repository for all teams. The repository should be as self-managed as possible, and any waiting or delays for access or approval will be detrimental to the team's productivity.
Identity and Access Management: IAM should be a defacto standard for all teams to follow. Central IAM platform that authenticates and authorizes access to all aspects of the solution. API tokens, user authentication, OAUTH2 tokens or whatever you need, it should all be performed in a consistent, well-defined standard way.
Metrics, Metrics, Metrics: Metrics are an Absolute. They allow teams to manage quality efficiently and be responsible for releasing a quality product. Here is just a sample of metrics that need to be tracked and managed:
Automated Testing: Every team must have automated testing, no exception. Testing results allow for choices made to be trusted as the results speak for themselves.
Monitoring, Analytics, and Logging. Monitoring for access, issues, usage and events need to be captured and logged. Sounds basic but it’s a core requirement.
Team Metrics: Velocity, Stories, Testing Coverage, etc. Defects Analysis: how many, when did you discover (dev, test, prod), customer defects logged. All of this data is vital to increase your quality over time.
Build metrics: Build time, Broken build time, # of code branches, etc. While we can talk about choice in the tooling to generate these metrics, the existence of them must be an absolute.
Integration Protocols: An important absolute is an established protocol that is decoupled from the implementation. Define a protocol standard to share data and logic between applciations and clients, e.g. With a Micro Service or API approach, HTTPs is an obvious but great choice,that if every delivery team adopts, integration will be smoother.
Solution Architect assigned to every team: Perhaps the most absolutes of all absolutes. Having a skilled architect assigned to the team to help guide them through the choices and absolutes to understand tradeoffs and benefits that will lead to the design of the highest quality solution, a solution that meets the needs of both your business partner and the teams that manage it.
Documentation Standards: Every solution requires documentation; appropriate code level comments, micro services in Swagger, etc. Documentation is an absolute, no exceptions. Without responsible documentation of the solution, the solution is a moment in time that will be useless to the team members coming behind you.
Absolutes are not absolute forever: Absolutes are fluid; they need to evolve as technology and methodology practices evolve to stay relevant and avoid becoming legacy. Some of the absolutes from yesterday have become the choices of today; I wouldn’t have imagined a few years back that allowing choice on runtime application stacks, hosting and data stores would have been practical. Cloud, PAAS, Server-less, containerization and managed services are changing all of that.
Is it a Choice or an Absolute?
Ok, so we have all these absolutes, but what about X or Y? Surely they need to be absolutes too? Undoubtedly there will be disagreement here, based on each team or enterprise; I'm sure there will be reasons for absolutes that make sense. However, no two teams are the same. Here are some areas where choice in traditional areas can also work, no need to be so strict.
Data Store: Hopefully, all of your teams will be using APIs or Micro Services and therefore abstract the data store away from consumers and producers of the data that flows through them. If that is the case then where the data resides becomes less significant, sure it needs to be reliable, resilient and accessible, etc. but the team responsible for the data should make the choice of which data store to use based on the needs of the solution and business requirements.
Runtime Platform and Application Logic Stack: When you have protocol absolutes defined, The runtime platform and application logic stack used behind that API is irrelevant to the consuming clients. This will allow the team to choose the stack that best fits the use case and makes them most productive. If the team is skilled in Node.JS, then its probably a good choice as the stack for them to use for building their microservices etc. Don't force .NET or Java on them just because it's a "coporate standard", especially if there is no real benefit of doing so. Product support should also be performed within the development team to negate the need for a separate support team structure as well as maintain the overall quality of the product.
Hosting: Where we host our logic and data also becomes less significant as we move towards server-less, docker or PaaS approaches. Teams can and should just deploy their build to a destination without anyone having to manage the application stack, OS or server platforms. Whatever the choice, you need to ensure that monitoring and logging can still be managed effectively as this remains an absolute.
Allowing choice, where at all possible, will drive innovation and yield significant team level productivity gains, however, without absolutes in the major foundational areas teams will be confused and frustrated. Enterprise IT has a long evolutionary journey ahead to realize the promise and benefits of Agile but maybe by being a bit more prepared and supportive centrally with our absolutes, we can let them be as close to the self-contained team that will deliver a truly innovative quality product.
Thanks for reading. Please feel free to contact me on twitter: @tonymaley
Thank you to @kristofsajdak for input on this post