Today i’ll talk about a few agile enterprise solutions and what they might mean for your organization. Firstly, this varies wildly from company to company. My experience is specifically around lean software delivery and dora metrics. I’ll talk about a few available solutions and what might a VP/ CTO at a mid to large company look for and try to avoid in a agile enterprise solution. As with any solution, it’ll really depend on your needs and what you’re looking to accomplish. A startup will need something VERY different than a large enterprise organization with 1000s of team members. Same goes for a mid size 300 person engineering team etc.
If you have any questions on the below. Feel free to reach out to me. As with any solution, do what fits your business and ensure that the goal is to decrease time to market, increase efficiency and make customers happy. There’s no one cure all and you’re more than likely going to have to experiment and assess what is / isn’t working.
General Agile Enterprise Principles:
These aren’t frameworks and these are things high performing teams do. For example, releasing once a quarter is generally low performance or signals of low performance at an organizational level. Organizations I’ve worked with have done 800+ releases to production per week and have been able double their release frequency with similar team members. If you want a case study just message me and I’ll show a few. Here’s some general principles at a high level..
- DevOps Culture and Practices: A DevOps culture encourages closer collaboration between the traditionally separate teams of Development and Operations. The goal is to break down silos and create a shared responsibility for delivering high-quality, reliable software. Continuous Integration (CI) and Continuous Delivery (CD) are crucial DevOps practices that automate the process of integrating code changes and getting them ready for deployment to production, respectively. This automation can lead to quicker detection and resolution of bugs, enhanced efficiency, and the ability to deliver updates faster and more frequently.
- Automated Testing: Automated tests are used extensively in high-performance software delivery to ensure that new changes don’t break existing functionality (regression testing) and to verify that new features work as expected. Automated tests can run quickly and frequently, providing rapid feedback to the development team and minimizing the risk of undetected defects.
- Monitoring and Observability: High-performance delivery teams often use sophisticated monitoring and observability tools to keep track of their systems’ health. These tools provide real-time insights into the system’s performance and help teams quickly identify and address any issues.
- Microservices Architecture: While not without its own challenges, a microservices architecture can limit the scope of failures, since each service can be deployed, upgraded, scaled, and restarted independently. This can reduce the risk of a single failure bringing down the entire system. If you’re a startup, monoliths make sense. However, there’s going to come a day where you need to break it up more than likely.
- Chaos Engineering: This practice involves intentionally injecting failures into a system to identify weaknesses before they cause problems. By understanding how their systems behave under different failure scenarios, teams can build more resilient systems and be better prepared to handle unexpected issues.
- Feature Flags/Toggles: Feature flags allow teams to control the visibility and roll-out of features in their application. This allows for a phased roll-out, testing in production, and the ability to turn off features quickly if issues arise, all of which help mitigate risk.
- Postmortems/Blameless Retrospectives: When failures do occur, high-performance teams conduct postmortems or retrospectives to understand what went wrong and how similar failures can be prevented in the future. The emphasis is on learning and improvement, not on assigning blame.
OK, now you’ve read what high performance teams do at a high level (you can talk about these all day in theory). Here’s some frameworks you can use in combination.
Lean
Lean is a philosophy and set of principles that focus on creating value for the customer by eliminating waste. It was originally developed in the manufacturing industry by Toyota, but has since been adapted to software development and other knowledge work. Kanban is a visual system for managing work as it moves through a process. It aims to visualize work, limit work-in-progress, and maximize efficiency (or flow). Kanban boards are used to represent the flow of work and can be simple (to-do, doing, done) or complex, depending on the process.
At an enterprise level, Lean encourages organizations to:
- Eliminate waste across the entire value stream, not just within individual teams.
- Optimize the whole system, rather than sub-optimizing individual parts.
- Build quality in from the beginning, rather than relying on inspection at the end.
- Create knowledge and build capabilities throughout the organization.
- Defer commitments and decisions until the last responsible moment to take advantage of emerging information.
- Deliver fast by managing flow, which can reduce lead time and increase efficiency.
In terms of Enterprise Agile solutions, Kanban boards can be implemented at multiple levels (think of them similar to programs): Each level gets progressively high into a triangle in a way. Your teams will sit at the bottom, teams will then roll up into programs and programs will then roll into the strategy. Perhaps you have OKRs or some form of that to align the teams.
- At the team level, to manage and visualize the flow of work within a single team. This is more operational and execution oriented. Teams live here
- At the program level, to manage and visualize the flow of work across multiple teams. Ie, I need to coordinate work across multiple teams across the org. You may have a technical program manager help coordinate certain aspects
- At the portfolio level, to manage and visualize the flow of large initiatives or projects across the entire organization. This is very strategic and the slowest moving due to how high level it is. This is generally what an operating meeting might look at in an organization
DORA Metrics
DORA (DevOps Research and Assessment) metrics are a set of performance measures that are widely recognized in the industry as key indicators of the effectiveness of a software development and delivery organization. DORA was acquired by Google Cloud in 2018, and its research has been very influential in the field of DevOps and Agile software development.
Here are the four key DORA metrics:
- Deployment Frequency: This is a measure of how often an organization is able to deploy code to production. Higher frequency is typically seen as better, as it means that the organization is able to deliver new features and improvements to users more quickly.
- Lead Time for Changes: This measures the amount of time it takes for a code commit to get into production. This includes all aspects of the development process, such as coding, code review, testing, and deployment. Shorter lead times are generally better, as they indicate a more efficient development process and allow for quicker feedback.
- Change Failure Rate: This is the percentage of changes to production that result in a failure, such as a service outage, service impairment, or a defect that impacts the user. Lower change failure rates are better, as they indicate higher quality software and fewer disruptions for users.
- Time to Restore Service: This measures how long it takes an organization to recover from a failure in production, such as a service outage or impairment. Shorter recovery times are better, as they minimize the disruption to users and allow the organization to quickly resume normal service.
Other enterprise solutions
- Scaled Agile Framework (SAFe): SAFe is one of the more popular frameworks for scaling Agile principles across a large organization. It provides a structured approach for aligning the work of multiple Agile teams towards the same organizational goals. I don’t have too much experience with it and I am not a huge fan of it so i’ll leave it at that for now.
- Scrum of Scrums (SoS): This is a method for coordinating the work of multiple Scrum teams. It involves representatives from each team meeting to discuss their progress and any issues or dependencies that may affect other teams.
- Large-Scale Scrum (LeSS): LeSS is another framework for scaling Scrum up for large teams and big projects. It focuses on applying the principles of Scrum on a larger scale, without adding unnecessary complexity.
Closing
Assessing what you need at an organizational level is always difficult. Some consultants want to sell you huge transformations with expensive overhead and consulting fees. They’ll also struggle to quantify the success if they’re using certain frameworks. Furthermore, change is really hard. It’s best you take a deep dive into where you’re at and improve incrementally over time. If you need help with implementing certain principles or frameworks at certain levels of your organization, feel free to reach out.