SurveyTeam agilityCollaborationAutomationArchitecture and designDevOps PracticesOrg Structure, Culture and IncentivesStandardizationScore DevOps maturity assessment Are you taking full advantage of your tools? Could your teams work better together? What next steps should you take on your DevOps journey? Complete the questionnaire covering the essential elements of DevOps-led software development and get practical advice on how to improve it at your organization. Fill in the fields below to begin the assessment. Your results will be displayed on the final screen and sent to your email address. You will also receive a copy of our guide, DevOps Transformation in an Enterprise.First Name Last Name Email I agree to receive marketing communications from Predica LLC via electronic means (email, website)*PreviousNextTeam agilityTeam Agility - Score Does the team have a new, potentially shippable, version of the product available every 1-2 weeks? Yes NoWhich of the following are measured by the team? (Check all that apply) Elapsed lead time to deliver valuable changes (from initial request to production) Frequency of deployments into production Change failure rate Time to restore service after a failure None of themDoes the team regularly meet to discuss what is working well, what isn't working well, and what they can improve, and are the top improvement items implemented? Yes NoDoes the team take action to ensure that they do not create or experience bottlenecks with/for other teams? Yes, and the actions are effective Yes, but the actions are not always effective NoAre any blocked work items swiftly identified and do people collaborate to rectify the situation? Yes NoIs there a clearly defined mechanism for prioritising the backlog? Yes NoDoes the team work on the highest priority items in the backlog? Yes NoAre the most experienced team members allocated last, so they can help others develop cross-functional skills and be free to focus on the most business-critical or complex problems? Yes NoDoes the team have fast feedback loops in place? (Check all that apply) From testers: usually less than 1 day From the product owner: usually less than 3 days From customers: usually less than 2 weeks From end-users: usually less than 2 weeksAre proactive steps taken to ensure there is no major dependency on "superheroes" (e.g. pair programming, mob learning, real options)? Yes NoPreviousNextCollaborationCollaboration - Score Are knowledge and interests shared within the team and with other teams within the organization (e.g. via communities of interest)? Yes Yes, but only within the team NoDoes the team have methods in place for asynchronous communication (e.g. Kanban Board, JIRA, Slack, Circuit)? Yes NoDo people on the team have mechanisms to collaborate with people outside of the team? Yes NoAre people on the team willing to work outside their usual specialism? Everyone on the team is willing to do this Some people on the team are willing to do this Generally people on the team prefer not to do this Do people on the team have a preference towards the most immediate (information-rich) comunication method available (e.g. voice call rather than email)? Everyone on the team does Most people on the team do Most people on the team do not Is there sufficient opportunity for people on the team to meet face to face? Yes NoHow frequently do misunderstandings occur between members of the team? Hardly ever Fairly frequently (at least once per week) Very frequently (at least once per day) Do people on the team share their ideas/concerns with the rest of the team and are they fairly represented? Yes, always Yes, most of the time Hardly everPreviousNextAutomationAutomation - Score Are development and test environments consistent with production environments? Yes NoIs the provisioning, configuration and management of infrastructure (e.g. networks, storage, etc.) automated (e.g. by using Infrastructure as Code)? Yes Partially NoFor which of these is the configuration and management of environments automated? (Check all that apply) Virtual machines Networks Operating systems Security elements Application stacks Applications None of themAre the required environments (e.g. dev, test, integration) available in line with demand (i.e. at the right time or in a way that doesn’t incur delay to activity)? Yes NoIs the provisioning, configuration and management of environments automated? Yes, and scaling is automatic Yes, but scaling is manual No Does the team have a high degree of automated unit tests in place (testing individual modules)? Yes, automated tests are in place and run on every build Yes, automated tests are in place No Does the team have a high degree of automated integration tests in place (testing the interaction of modules with each other)? Yes, automated tests are in place and run on every build Yes, automated tests are in place No Does the team have a high degree of automated system tests in place (confirming overall system functionality meets requirements)? Yes, automated tests are in place and run on every build Yes, automated tests are in place No Does the team have a high degree of automated performance tests in place? Yes, automated tests are in place and run on every build Yes, automated tests are in place No Does the team complete automated scanning of source code assets? Yes, automated scanning is in place and run on every build Yes, automated scanning is in place No Does the team complete automated scanning of binaries? Yes, automated scanning is in place and run on every build Yes, automated scanning is in place No Is code automatically scanned for quality during a build? Yes, automated scanning is in place and run on every build Yes, automated scanning is in place No Does failure to meet coding standards or security rules trigger a break in the build? Yes No Is automation code developed with the same rigor as product code (e.g. testing, source control)? Yes No PreviousNextArchitecture and design Architecture and design - Score Does the architecture of the application consist of loosely coupled components? (Choose the most accurate description) The application is built from a number of stateless components with scaling and resilience provided at the application layer (full microservices) The application is made up of several separate components but relies on external solutions to provide availability and scalability The application is largely monolithic but made up of code modules that can be worked on independently and then re-compiled into a single unit The application is built up of monolithic code and can only be changed in its entirety as part of a release schedule Does the architecture enable development, testing and other QA activities to be representative and performed independently of each another without impacting production (tick all that apply)? There are fully separate development, test and QA environments Environments are regularly re-built or synchronized (at least monthly) The 3 environments are similar at all levels (resilience, performance, security, dependencies) Each environment can be torn down and rebuilt without affecting other environments Environment specific configuration items are decoupled from the code in order to accelerate rebuilds Does the architecture enable the deployment of services independently of one another? Yes, every element of functionality can be updated individually and applied to the application Partially, some elements can be updated independently, but there are certain core components that need to be updated together in order to maintain functionality No, updates to the system need to be performed together in a formal release cycle Are all application logs written to a central log repository automatically with the configuration included in the environment design to allow portability between environments? Yes No PreviousNextDevOps PracticesDevOps Practices - Score Does the team manage their source code in a central source control system? (Check all that apply) We have a common code repository (e.g. Git-based repo) We have a defined branching structure We have defined repository structure Our structure and branching strategy are aligned to our Dev, Test, and Prod environments (enabling a smooth flow between environments) None of themHow frequently do developers integrate their changes into a shared mainline (trunk)? Code is integrated at least once per day Code is integrated at least weekly Code is integrated infrequently but at least once a month Code is integrated on an ad hoc basis when the developer feels it is ready to share Is there a defined code review and approval process? We have a targeted code review process that is appropriate and ensures code is published in a timely manner We have a code review process but the process incurs delays and hinders deployments We have no code review process and bugs can frequently be integrated into the mainline (trunk) Whenever code is integrated with a shared mainline (trunk), are automated processes triggered? Yes, automated software build is triggered into a production-like environment, automated tests are then triggered and software can be automatically deployed into production Yes, an automated software build is triggered into a production-like environment, manual tests are then performed before the release is manually deployed into production Yes, automated software build is triggered, however this build is then manually deployed into the relevant environments (QA and Prod) NoIs highest priority always given to fixing a broken build? Yes, builds are fixed / rolled back within 10 minutes Yes, builds are fixed / rolled back within 1 hour Yes, builds are fixed / rolled back within a day NoAre adequate notifications in place to communicate the build status and failures to the team (e.g. automated emails, Slack, Circuit)? Yes NoIs it possible to roll back the application cleanly and reliably? Yes NoDoes the team practice regular refactoring of their code? Yes, code is often updated independently of new functions or features to ensure technical debt is minimized No, code is only updated to enable new features or functionality Is time allocated/dedicated to refactoring in order to improve code quality and reduce technical debt? Yes NoAre there sufficient automated tests in place to enable developers to refactor with confidence? Yes NoHow widely does the team practice Test Driven Development (TDD), ensuring that automated tests are developed in advance of new features? All product code is developed using TDD Some product code is developed using TDD TDD is not used at all Is a standard test framework (such as JUnit) used by the team? Yes NoIs the refactoring step of the TDD cycle usually applied? Yes NoAre mocks/stubs/simulators used to ensure that tests can be run quickly, frequently and repeatably? Yes NoPreviousNextOrg Structure, Culture and Incentives Org Structure, Culture and Incentives - Score Is the team a cross functional delivery team comprising of development, testing and operations expertise? Yes NoAre incentives for people on the team (both financial and non-financial) aligned to overall team results? Yes NoAre those responsible for designing, developing, testing and operating the application all part of the same team? Yes NoDoes the team have accountability for the product throughout its life-cycle (introduction, growth, maturity, decline)? Yes NoDoes the team have a culture of experimentation and innovation? Yes NoDoes the team have a high trust culture which enables autonomy? Yes NoDo people involved in developing and running the application have aligned incentives and goals? Yes NoDoes the team have a say in what they work on (e.g. self selection days)? Yes NoDoes the organization's structure catalyze and support a DevOps approach? Yes NoIs there a team charter that describes how the team behaves and works together? Yes NoIs there a clear vision and purpose for the product? Yes NoAre all the product's stakeholders identified and engaged? Yes NoIs the team aligned and incentivised to a measurable business outcome? Yes NoDo management and the wider organization see the value in protecting time for continuous improvement? Yes NoDoes the team have enough time to learn new technologies, tools and practices? Yes NoHow frequently is there interaction between the business and the development team? Business users are embedded within the team The team meets with the business at least every week The team meets with the business at least every month Rarely or not at all Do senior stakeholders buy into and support the DevOps approach? Yes, we rarely have issues with business cases or bureaucratic processes Yes, there is buy-in and understanding, but business processes are still too rigid No Do members of the team practice continuous learning? Yes No Does the team have a feedback culture (where people are happy to quickly share negative and positive feedback)? Yes No PreviousNextStandardizationStandardisation - Score Has the organization defined a set of tooling standards? (Check all that apply) We have a defined set of CI/CD tooling that is universally used We have defined code repository tooling and standardised usage processes for them (e.g. branching pattern) We have defined monitoring tooling We have defined patching/upgrade tooling and processes (e.g. immutable vs. mutable) Has the organization defined a set of application stacks/development languages? Yes, with a sufficient portfolio of options to meet our development needs Yes, but with an insufficient portfolio of options to meet our development needs No, any team can choose any stack/language without constraint Do you make the best use of SaaS (Software as a Service) for utility applications (i.e. ones not used for competitive advantage, such as version control)? Yes NoAs much as makes sense, do you use PaaS (Platform as a Service)? Yes NoAs much as makes sense, do you use IaaS (Infrastructure as a Service)? Yes NoPreviousNextAll done! Click the "Get my results" button below to see your scores. We'll send a detailed summary along with further resources to your email address.Total Score Previous Get my results
