Test

How will we conduct this assessment

This assessment have 11 questions in total plus 8 optinoal questions for teams using DevOps

Read the question and answer to the best of your ability choosing one of the maturity levels along with the described criteria:
1. Initiate
2. Practicing
3. Transforming
4. Scaling
Remember this survey is ‘anonymous’
No one is grading anyone.
This is for us to understand where are as a team and determine improvement actions, learning roadmaps and tools that will help get to where we want to be!

1. Collaboration and Teamwork: Stand ups

Initiating: No regular team opportunity for sharing progress on work. Typically meetings maybe long and have limited engagement from attendees. - Meeting attendees are forced or feel obliged to attend rather than recognizing the value of the meeting and voluntarily attending. - Team members are unclear what work is happening or issues blocking progress. Team members typically perform additional reporting to highlight work completed.Transforming: Standup meetings occur regularly but are usually initiated by the Iteration Manager/Project Manager or another facilitator. At each meeting, all of the core team members answer the three questions "What I have done since we last met", "What I plan to do before we next meet", "What is blocking me or may block me". Geographically remote team members are involved in Standup meetings through telephone.Scaled: Standup meetings are rarely missed by any core team member and still occur regardless of attendance. Core team members use the visual wall and point to the work they are doing while answering the 3 questions. Standups are completed in under 15mins. Project stakeholders regularly attend standups and other team collaboration events. Geographically remote team members feel properly included in Stand ups and are able to see and hear progress updates. Blockers and challenges identified during the standup are assigned an owner, so that the impediment can be removed.

2 Collaboration and Teamwork: Walls of Work

3 Focus on the Customer and Business Value: Engaging the Product Owner

4 Focus on the Customer and Business Value: Backlog Refinement

5 Flexible, Adaptive and Continuously Improving: Release and Iteration Planning

Practicing: Release Plans and Iteration Plans are defined by the Project Manager/Iteration Manager with limited involvement from the core team and with limited consideration of business priority or involvement of stakeholders. Release Plans and Iterations Plans are not adjusted to reflect changing priorities. Variations in planned vs. delivered are not consistently measured or reported.Scaled: Key stakeholders (sponsors, business owners and steering committee members) attend most project ceremonies (showcases and planning sessions). Release and iteration planning produces an achievable plan that the team is confident to deliver. Work planned is regularly achieved with only small variations in progress. An overall (long-term) plan is maintained and accurately reflects the team's understanding of work, timing, resources, dependencies, etc. Sliders are used to inform planning.

6 Flexible, Adaptive and Continuously Improving: Retrospectives

7 Flexible, Adaptive and Continuously Improving: Work Estimation (Relative Estimates)

8 Iterative and Fast: Story Cards

Transforming: For the current release. Features are broken into Stories. Stories are used to describe all work activities using language/words that the customer understands. Features and Stories are recorded in a manner that is readily accessible by all team members and regularly maintained for future releases. Features are described using language/words that the customer understands. Features are recorded in a manner that is readily accessible by the project team.Scaled: For the current release. All Stories describe the business outcome (i.e. value), have an estimate and a priority. The Product Owner reviews and priorities Stories prior to work commencing. Relevant stakeholders (Analyst, Developer, Tester, Subject Matter Expert) are involved in defining and elaborating stories. Acceptance Criteria are defined and agreed for each Story. A Story should be able to be delivered within half an Iteration of effort.

9 Empowered and Self Directed Teams: Stable Cross-Functional Teams

10 Empowered and Self Directed Teams: Social Contract

11 Empowered and Self Directed Teams: Risk and Issue Management

Practicing: Risks and Issues have been identified and are captured using an appropriate artifacts such as a Risk Story Walls, Big Visual Charts (BVC), Risk Register, etc. Risks and Issue are identified by an appropriate group of stakeholders (i.e. not just the project manager or the team leader in isolation). Risk artifacts are "owned" by the team and team members have no reservations in making contributions or changes.Transforming: Risk management is embedded into day-to-day operations or project activities. Risks, issues and blockers are discussed in appropriate detail as part of all sessions (stand-ups; iteration planning; showcases; steering committee meetings; etc). Risk mitigations and action plans are treated like any other activity or feature; they are represented by individual story cards, included in iteration planning and tracked and completed during the iteration.Scaled: Risk mitigations and action plans take into consideration the source and cause of a risk. Risks, assumptions, issues, dependencies, constraints (etc) identified previously are periodically revisited, discussed, reviewed and updated. Risk Management is used to identify potential impacts on benefits, goals, objectives, strategies, problems, and success criteria. Mechanisms exist for reporting and escalating risks and issues which are beyond the capabilities or authority of the team.

12 DevOps Continuous Development

Transforming: Any one of the following error conditions automatically results in a build break/failed build: automated unit test error, static code analysis error, build verification test error. Production ready code (no error conditions in build/integration) is used as the primary measure of project progress. Automated monitoring & reporting of automated test execution is in place. Mixture of unit test cases written before and after development and the team is getting close to 80% code coverage for new code.

13 DevOps Continuous Development: Automated builds and continuous integration.

14 DevOps

15 DevOps Continuous Development

16 DevOps Continuous Testing

Scaled: Testing (regression, functional acceptance, unit test, system and integration) is automated and executed as needed. Test environments are under change control. Any version of a test environment can be recreated automatically. Test failures can be reproduced by automation recreating the failure environment. Teams monitor code coverage for tests and ensure it is appropriate for their application

17 DevOps Continuous Release and Deployment

18 DevOps Continuous Feedback and Optimization

19 DevOps Continuous Monitoring