├── README.md ├── business_value.md ├── culture_people.md ├── automation_tooling.md └── devops_agility.md /README.md: -------------------------------------------------------------------------------- 1 | The LeaseWeb maturity model for DevOps teams 2 | ============================= 3 | 4 | This is the maturity model for devops teams as we use it in [LeaseWeb](http://www.leaseweb.com), and some parts might be quite specific to our organisation. Yet we feel it's a good thing to share this model and welcome any feedback or collaboration on it. 5 | 6 | How the model works: 7 | ------------- 8 | The model consists of four categories of requirements (links below). Within a category, a team progresses through four levels, starting at “Initial Level” which essentially means none of the requirements have been checked, from here a team progresses through “Basic Level” and “Intermediate Level” to achieve the “Target Level” - our ideal DevOps team. 9 | 10 | Categories: 11 | ------------- 12 | [Culture & People](culture_people.md) 13 | 14 | [DevOps Agility](devops_agility.md) 15 | 16 | [Business Value](business_value.md) 17 | 18 | [Automation & Tooling](automation_tooling.md) 19 | 20 | 21 | Other links 22 | ------------- 23 | [The Kniberg Scrum checklist](https://www.crisp.se/wp-content/uploads/2012/05/Scrum-checklist.pdf) 24 | 25 | -------------------------------------------------------------------------------- /business_value.md: -------------------------------------------------------------------------------- 1 | Business value 2 | ============================= 3 | 4 | Basic Level 5 | ------------- 6 | 7 | |Feedback loops |Business value |Value steering |Roadmap planning |Validate value |Stakeholder Happiness | 8 | |------------------------|----------------------|----------------------|----------------------|----------------------|----------------------| 9 | |We inform our Stakeholders about the changes in the product|The Product Owner or our Stakeholders create a business case for each accepted epic|We collect input from relevant stakeholders when defining priorities.|We have an agile roadmap|We measure the usage of new features|Our Stakeholders understand the backlog we proactively explain it. We measure this on a monthly basis.| 10 | 11 | 12 | 13 | Intermediate Level 14 | ------------- 15 | 16 | |Feedback loops |Business value |Value steering |Roadmap planning |Validate value |Stakeholder Happiness | 17 | |------------------------|----------------------|----------------------|----------------------|----------------------|----------------------| 18 | |Our Stakeholders review the changes in the product and provide us feedback on that|Our Product Owner and Stakeholders jointly create a business case for any new epic|We collect feedback from Customers and prospects when defining new features.| |We analyze the business cases to verify if they have been realized|Our Stakeholders feel they have an important role in the Backlog prioritization. We measure this on a monthly basis.| 19 | | | | |Our Stakeholders are updated on roadmap progress each month| | | 20 | 21 | 22 | Target Level 23 | ------------- 24 | 25 | |Feedback loops |Business value |Value steering |Roadmap planning |Validate value |Stakeholder Happiness | 26 | |------------------------|----------------------|----------------------|----------------------|----------------------|----------------------| 27 | |Our Stakeholders actively participate in the definition and outcome of the product|Our Stakeholders discuss business cases with the PO and other stakeholders, to come to clear prioritization|We make sure analysis of the market needs and prospected ROI are done, when creating a new feature|We plan based on the velocity report and realize these plans|The usage result of the new features is verified with all internal stakeholders, customers and Market|Our Stakeholder are satisfied with the features delivered by our team. We measure this on a monthly basis.| 28 | | | | |We follow a process when introducing changes to the roadmap| |We have a Stakeholder radar in place, and published.| 29 | 30 | 31 | -------------------------------------------------------------------------------- /culture_people.md: -------------------------------------------------------------------------------- 1 | Culture & People 2 | ============================= 3 | 4 | Basic Level 5 | ------------- 6 | 7 | |Happiness |Failing Fast |Transparancy |Shared Responsibility |Focus |Self Organization | 8 | |------------------------|----------------------|----------------------|----------------------|----------------------|----------------------| 9 | |We measure & share team happiness each sprint |We register failures, so we can use this as an opportunity to learn| We proactively share information with the whole team | We understand each other s concepts, concerns and problems (of different expertises) | We focus on our team goal & product vision | We plan our activities together with the PO | 10 | | |We no longer deploy in a sprint after 2 failed deployments (error budget) | |Our team is able to fully develop, maintain and support our products, applications and infrastructure (also in terms of skills & resources)| |Our team understands the boundaries in terms of resources, cooperation with other teams and departments, decision making policy and information flow| 11 | | | | |We have our own EOD shifts to respond when services are down out of business hours.| |We know the team KPIs| 12 | 13 | 14 | Intermediate Level 15 | ------------- 16 | 17 | |Happiness |Failing Fast |Transparancy |Shared Responsibility |Focus |Self Organization | 18 | |------------------------|----------------------|----------------------|----------------------|----------------------|----------------------| 19 | |We measure & share team proudness every sprint|We have a blameless post mortem for each major incident or failure|We proactively share information with the whole department|Everyone in our team is willing to share & learn|We focus on the complete value chain goal (value creation incl. all departments etc.) |We monitor our work process & performance| 20 | | |We publish blameless post mortem result and make it available to every department| |All tasks in our team can be done by more than one person.| |We provide reporting of our performance/progress| 21 | | | | | | |Individual's performance is evaluated on team KPIs and feedback from peers| 22 | 23 | 24 | Target Level 25 | ------------- 26 | 27 | |Happiness |Failing Fast |Transparancy |Shared Responsibility |Focus |Self Organization | 28 | |------------------------|----------------------|----------------------|----------------------|----------------------|----------------------| 29 | |We are proud of our team, our department and our company|We celebrate & share failures with the entire company|We proactively share information with the whole company|We are acting proactively to learn from each other, across teams|We focus on LeaseWebs goal|We check our performance and find ways to improve on it| 30 | | | | |Everyone in the team can do the basics tasks, no matter which specialism it concerns| | | 31 | 32 | -------------------------------------------------------------------------------- /automation_tooling.md: -------------------------------------------------------------------------------- 1 | Automation & Tooling 2 | ============================= 3 | 4 | Basic Level 5 | ------------- 6 | 7 | |Automated deployments |Testing |Monitoring |If it moves: graph it | 8 | |------------------------|----------------------|----------------------|----------------------| 9 | |All our code and infra changes are reviewed by at least 1 other team member.|All of our applications can be build in Jenkins and at least they pass a lint check.|All of our products, applications and infrastructure (servers & services) are monitored with basic checks. ( uptime, cpuload, memory usage, high risk functionality) and we receive alerts if anything goes wrong| We have central server & application logging in place and every team member can access them.| 10 | |Our pull requests are only merged after review and we enforce this in Stash.|We have a functional test automation framework in place where time consuming, high risk features can be tested|We have screens which show our monitoring metrics.|We graph basic metrics like bandwidth usage and system load for all systems.| 11 | |We deploy all our applications / infrastructure ourselves (manual or automated)| |We monitor service impacting alerts 24/7| | 12 | |All our code is versioned| | | | 13 | 14 | 15 | Intermediate Level 16 | ------------- 17 | 18 | |Automated deployments |Testing |Monitoring |If it moves: graph it | 19 | |------------------------|----------------------|----------------------|----------------------| 20 | |Push button deployment and release of any releasable artifact to any environment.|All of the code we are currently writing has a minimum of 70% good quality unit test coverage|We have trending monitoring, so we can solve issues before they become a incident where desired|We have a dashboard that shows our current app/infra usage and status (including trends)| 21 | |Our integration test environment is automatically updated after each merge to master branch.|Unit tests run automatically in every Jenkins build and we fix them when they fail.|We monitor based on server and application logging| We gather business metrics (for example: load times of pages, # of orders, etc.) | 22 | |Pull requests can only be merged after a successful build and we enforce this in Stash.|We have insight into the quality (test coverage, complexity) of the code for each of our apps (sonar).| | | 23 | |We have automatic generation of release notes via the appmgmt portal.|We have fully automated functional regression test of all key features on every release| | | 24 | 25 | 26 | Target Level 27 | ------------- 28 | 29 | |Automated deployments |Testing |Monitoring |If it moves: graph it | 30 | |------------------------|----------------------|----------------------|----------------------| 31 | |We have zero touch continuous deployments.|We run automated functional regression, performance and security tests for all apps/infra where this is applicable.|We have monitoring automation in place: servers and service checks are automatically added.|We have dashboards that not only show technical metrics but also business metrics related to our team| 32 | |We always roll forward, do not rollback|All code we are currently writing has a minimum of 90% good quality unit test coverage| |We can correlate our metrics to events on the platform.| 33 | |Our deployments do not impact our services| | | | 34 | 35 | -------------------------------------------------------------------------------- /devops_agility.md: -------------------------------------------------------------------------------- 1 | DevOps Agility 2 | ============================= 3 | 4 | Basic Level 5 | ------------- 6 | 7 | |Scrum |Incident Management |Change Management |Architecture Policies |Documentation |Company Policies |Production standards |Compliance | 8 | |------------------------|----------------------|----------------------|----------------------|----------------------|----------------------|----------------------|----------------------| 9 | |We score 3 out of 10 on the Kniberg Core Scrum Checklist|We understand the change management process and register all software/infrastructure deployments & customer impacting changes via the APPMGMT portal|We understand the change management process and register all software/infrastructure deployments & customer impacting changes|We understand the architecture policies, and deviations from it are identified|All our new deliveries & changes are accompanied with the desired documentation|We follow the company policies for new deliveries & changes|Our team is aware of the production standards|Our team understands the identified business risks related to Product Development| 10 | | |We measure time to resolve|We make sure architecture & security assessment are part of each change| | | |We have code standards|Our team is aware of the necessary controls that mitigate the business risks| 11 | | |Our active incidents are displayed real-time and conspicuously|We register peer reviews of all changes (code & infra)| | | |We have preferred technology definition| | 12 | 13 | 14 | Intermediate Level 15 | ------------- 16 | 17 | |Scrum |Incident Management |Change Management |Architecture Policies |Documentation |Company Policies |Production standards |Compliance | 18 | |------------------------|----------------------|----------------------|----------------------|----------------------|----------------------|----------------------|----------------------| 19 | |We score 10 out of 10 on the Kniberg Core Scrum Checklist|We analyze incidents to find patterns and improve our product with this knowledge|We make sure a risk assessment & rollback scenario are part of each change|Our team works in line with architecture policies|Our desired but missing documentation is identified and we spent time on completing it|We follow the company policies for all existing products, infrastructure and applications, or have well considered exceptions to this|Code standards are enforced for new/changed code|Our team has implemented all necessary controls that mitigate the business risks| 20 | | |Our customers are well informed about the status of major incidents|We manage & coordinate change dependencies with other teams| |Our recovery procedures are well documented| |Technology definition is enforced for new/changed architecture|Our team is aware of the standards we want to comply with| 21 | | |We fix incidents by making changes to our codebase or infrastructure so they are permanently fixed.|We inform our customers of impacting changes| | | |We have SLO's defined| | 22 | 23 | 24 | Target Level 25 | ------------- 26 | 27 | |Scrum |Incident Management |Change Management |Architecture Policies |Documentation |Company Policies |Production standards |Compliance | 28 | |------------------------|----------------------|----------------------|----------------------|----------------------|----------------------|----------------------|----------------------| 29 | | |We proactively find potential incidents before they impact the customer service, and take structural actions to avoid them|Releasing changes is easy, painless and automated where valuable|We actively maintain & improve the architecture policies, across teams|All our desired documentation is available and maintained|We proactively participate to improve company policies|All our software meets production standards|Our team actively identifies business risks related to DevOps| 30 | | | |Registering changes is easy, and automated where valuable| | | |All our infrastructure meets production standards|Our team actively helps improving the controls that mitigate the business risks| 31 | | | |We manage & coordinate change dependencies with our customers| | | |We meet our SLO's| | 32 | 33 | --------------------------------------------------------------------------------