back to notes

Agile Maturity Team Assessment workbook

"Welcome to the Agile Maturity Team Assessment workbook!
Follow the instructions below to perform a team assessment.
"
"Team Members worksheet
1. Enter each team member's name, select their role, employee#, location, and participation status.
Note: use the drop down menus to select role, location and participation status
"
"SUMMARY worksheet
1. Select Summary worksheet – enter team name and date that the assessment is held.
2. In Cell B17, use the drop down to select the Team Type to either “App Dev”, “Infrastructure”, or ""Service""
3. Each remaining worksheet represents one of the 5 Agile focus areas: Behavior, Product Management, Planning and Review, Product Delivery, and Technical Excellence.
4. As each worksheet is completed, the aggregate rating (Crawl, Walk, Run, Coach) for that focus area is propagated back to the Summary worksheet.
"
"BEHAVIOR worksheet
1. Read the Topic in each row
2. Have the team read the text associated with the A, B, C, and D columns.
3. Have the team discuss a “best match” consensus from the 4 column choices
4. Indicate the team consensus in the Best Match column
Note: Select ""A"" if the topic is feasible but not practiced. In rare circumstances, the topic is not feasible and ""X"" should be selected
5. Include any comments that to support the team's best match.
6. Perform this for all topic rows in the worksheet.
"
"PRODUCT MGMT worksheet
1. Repeat the above instructions for this worksheet.

PLANNING and REVIEW worksheet
1. Repeat the above instructions for this worksheet.

PRODUCT DELIVERY worksheet
1. Repeat the above instructions for this worksheet.
"
"TECHNICAL EXCELLENCE worksheet
Use the Technical Excellence Tab which corresponds to the option selected in the Summary Tab, Cell B17
Example:
If in Cell B17 you selected ""App Dev"", use the Tech Excellence - App worksheet
"
IMPROVEMENT PLANNING (During Assessment)
"
AGILE TEAM MATURITY GOALS"
During Assessment
1. Review the Summary worksheet ”Overall Team Maturity Level” rating.
2.  Enter the lastest revision date (Cell I5) and identify the calendar quarter (Cell P5) in which the team will begin the current roadmap by selecting from the drop down list.
3. Select the Maturity Goal (Crawl, Walk, Run, Coach) the team is working towards achieving during the calendar quarter selected.
4. Identify goals for their agile maturity growth for a 3 month/quarter timeframe and enter them. There is a limit of 5 goals, which allows at least one goal per focus area.
5.  Identify the owner who will be responsible to keep the team on track to complete the goal.
"6.  Identify which focus area each goal applies to. Goals can include multiple improvements for a single focus area (i.e. Improve Agile Ceremonies to meet objectives for each session; Understand and use KPIs to improve planning practices). Later these can be broken down into Action Items to address specific practices that improve their maturity for each goal.
"
AGILE MATURITY ACTION PLAN & ROADMAP
During/After Assessment
1.       Talk through action items that the team can complete within a single iteration to improve maturity against a specific goal. Enter those action items in the Summary tab under . Identify the goal that each action item will apply to by selecting the goal # from the drop down list.
2.       Select start and end dates for each action item. These dates should fall within the quarter for which this plan is being set.
3.       Set the status of the action items based upon the current progress. The drop down options include: Not Started, In Progress, On Hold, Completed, or Closed. Closed means the team did not complete the action item but determined it was no longer part of thar quarter’s plan. On Hold means the item is still in the current plan, but not yet planned for any specific time period (maybe a workshop or class needs to be arranged to start action items).
4.       Notes can be entered to identify progress or impediments as the team works through the plan.
5.       Review the Agile Team Maturity Roadmap graph to the right of the table to confirm the schedule and commit to the plan.
6. Save the self-assessment as a local file with the date of your assessment in the file name.
7. Send the self-assessment to your Agile Mentor and Coach informing them that the self-assessment was performed.
8. Print Summary tab by selecting area to print. Each section will print on separate pages.

AGILE COACHING PLAN
After Assessment
1.       PL schedules coaching session to align on ceremonies and/or workshops where support is needed to help the team accomplish their goals.
2.       PL updates progress and notes weekly with the team, updating assessment results as action items and/or goals are achieved to view maturity progress. PL reviews with leadership and coach to share progress and/or identify impediments/support needed.
"3.       At the end of the quarter, the Team is: 1) assessed for agile maturity growth to reflect the goals achieved; or 2) ready to set another quarterly roadmap/coaching plan and schedules an assessment for the next quarter.
"
"FAQ
1. Who should participate in the assessment? ANS: the entire Agile team
2. Should my manager participate in the assessment? ANS: No, unless the manager is the product owner
3. How long should I allocate for a team the assessment? ANS: typically a team assessment will take around 3 hours.
4. Why are my ratings not being shown on the Summary worksheet? ANS: Make sure Formulas – Calculation Options is set to “Automatic”.
5. What does it mean when I select the “A” (Aware) answer for a specific topic? ANS: this is the value which indicates your team is either (1) aware but does not practice the topic, or (2) unaware of this topic.
6. What do I do if the team determines they are blocked from completing the assessment because there are areas for which clarification is required? ANS: The Project Lead should contact their assigned Agile Coach, or, send an email to PVSIAgileCoaching to request assistance with clarifications as required
"

Team Member Role Employee# Location Participated


Zanshin (Awareness) - Aware of concepts, may not know the practices)
Shu (Operational) - focus of practices, generally teams know 1 way to do things
Ha (Adaptive) - agile values and principles are internalized, teams begin to do things multiple ways
Ri (Inventive) - when needed invents/modifies practice; takes knowledge beyond their team, extending to the organization


Crawl Walk Run Coach


Behavior

Product Management

Planning and Review

Product Delivery

Technical Excellence

App Dev


Behavior
Topic Comments Best Match A B C D
Agile Values and Principles B Aware Team understands the Agile values and principles and can speak to them Team has internalized the Agile values and principles, can speak to them and does their best to live by them Team has transcended beyond the Agile values and principles throughout the entire product/project lifecycle
Working Agreements C Aware Team has created static documents that typically include items like: DoD, DoR, meeting etiquette, etc. The team updates working agreement based on lessons learned during retrospectives and during the normal course of working together The team has internalized the working agreements - typically the team still writes them down, but team members live by them and understand them fully
Role-based training Aware Team members are actively completing the required Agile training for their role. The PL and PO have completed the recommended Agile training for their roles. All team members, including PL and PO, have completed their recommended Agile training by role. Team actively trains other teams in Agile values and principles.
Accountability Aware Team needs support to be accountable (e.g., task updates, running demos, needs reminders, …) Team feels accountable and is proactive (proactively updates tasks, plans for demos, …) Every team member embraces accountability - and holds others accountable (e.g., values tasks being updated, values attending daily standup, …)
Responsibility Aware Individuals take responsibility for their tasks Team shares responsibilities Responsible for actions, including completing work to the agreed upon standards, quickly fixing issues that come up
Empowerment Aware Team follows the WF PVSI Agile framework but may require help from a leader to make key decisions Team understands and follows the WF PVSI Agile framework, are empowered to adapt guidelines and make decisions as needed for their unique situation and help drive key decisions for the initiative. The team adjusts and creates processes as needed and with all stakeholders in mind makes decisions that support the needs of the broader group
Transparency Aware Team provides visibility via Agile Tools and assesses progress at required intervals (e.g. daily standup, demo) Team provides visibility via Agile Tools to provide real time access to up-to-date progress info The team communicates to all stakeholders, rarely leading to surprises - proactively provides updates including risks that may affect the project
Safety Aware Team members speak up, but may be careful choosing their words and topics Team members feel safe in meetings and openly and courageously discuss all relevant topics The team has a totally safe environment, where they can disagree but still feel part of the team. In the spirit of teamwork, the team can openly discuss concerns and issues without any fear of reprisal.
Collaboration Aware Team members collaborate effectively with each other Team members collaborate effectively with each other and with other teams The team naturally works together - it is the way they get things done.
Conflict Management Aware The team handles conflicts occasionally, but at times needs to escalate conflict to a leader/manager for resolution The team works together to resolve conflicts and rarely needs a manager/leader to assist Team understands that conflict is a normal part of team dynamics and resolves it with the goal of increasing understanding and alignment of the team with team goals
Communication Aware Communicates at regular working sessions and ceremonies (planning meetings, etc.), provides basic info at the end of each iteration, release, etc. Communicates proactively, provides info to stakeholders, team knows when to escalate Communication across teams and org
Decision Making Aware Team may offer recommendations, but will typically need leaders/managers to make key decisions Team is comfortable making key decisions and reports their progress/decisions frequently to leaders and stakeholders Team makes courageous decisions in the best interest of the business while including all stakeholder points of view


Product Management
Topic Comments Best Match A B C D
Product Owner Aware The Product owner is adequately knowledgeable in the domain and available when needed The Product Owner is part of the team, a domain subject matter expert, fully engaged on a daily basis and willing to help meet team goals Product owner meets with stakeholders and team regularly to manage the product across organizational boundaries
Backlog Management Aware Product, Release, and Iteration backlogs are separate; release and iteration backlogs are sized and prioritized. Release backlog mapped back to Product Roadmap; Iteration Backlog supports the Release Plan Actively managing current and future releases in the context of the program/organization thinking beyond the bounds of the project
Backlog Grooming Aware Scheduled session at least once per iteration preparing stories for the next iteration The scheduled sessions will look beyond the next iteration; actively looking for stories to decompose with risk and effective delivery in mind Uses advanced skills to assist/drive product level grooming (as opposed to project level grooming)
Prioritization Aware Simple prioritization (1..n) based on limited consideration of business or customer value. (e.g. First In First Out, Perceived Need, etc) Multi-dimensional prioritization based on business or customer value (e.g. WSJF, feature value, cost of development, market impact, organization impact, cost of not providing, cost of delay, need by date, risk,...) Model based prioritization coordinated with other parts of the organization - emphasis on empirical data
User Stories & Acceptance Aware Format of User Stories is correct and includes Acceptance Criteria Stories demonstrate high INVEST properties, the quality of the "so that" - is high and speaks to the true business value the story is delivering TDR plus additional modeling techniques
Features Aware Team identifies features during roadmap planning and review (e.g. Iteration 0, Release Planning) Features represent business or customer value; Team decomposes large features into smaller "right-sized" features to fit in a single release; linkage of features down to user stories exists Features, Epics, and User Stories are utilized and linked appropriately, Feature % Complete is used to make decisions in prioritization and resource planning in order to deliver the highest value in the shortest amount of time
Product Portfolio Management Aware Product Owner focuses primarily on the current project with only cursory views and consideration of other products, projects, services or dependencies Product Owner engages stakeholders and customers to assist in defining prioritization; Maximizes team ROI by combining/grouping efforts Consistently manages the product portfolio across products to deliver ROI, engages customers to consider prod mgmt across products


Planning and Review
Topic Comments Best Match A B C D
Vision Aware Team has a static vision document Living document and team can speak to it, updated at scheduled intervals Updates are made as and when needed, there is constant awareness of the end goal
Roadmap Aware Team has a static roadmap document Living document and team can speak to it, updated at scheduled intervals Updates are made as and when needed, there is constant awareness of the end goal and the roadmap
Release Planning Aware Team schedules and conducts Iteration 0 Planning sessions for each project kickoff (may sometimes include an Agile mentor/coach for guidance) Teams conduct their own Iteration 0/Release Planning meetings without the need for an Agile mentor or coach Iteration 0/Release Planning meetings are more informal, short in duration, with emphasis on getting to Iterations as quickly as possible with just enough planning
Release Plan Aware Team has a release plan Burndown charts and KPIs are used to make changes to release plan. Plan updates are made at regular intervals. Updates are made as and when needed, team makes proactive updates based on progress and current reality
Iteration Aware Team iteration planning is based on both story point velocity and available hours capacity; includes team commitment Team achieves 80% or more of planned scope per iteration consistently, holds themselves accountable to the commitment Cycle time of stories is optimized for maximum achievement
Tasking Aware Team tasks out all user stories by end of the 1st day of the iteration Team collaborates on creating tasks instead of individual tasking; tasks are sized appropriately (typically less than 6 hours) Tasking is completed collaboratively and within the Iteration Planning meeting, team is consistently able to identify most tasks that will be required to complete stories, they quickly update tasks as needed within the iteration.
Daily Standup Aware The team holds daily standups and each member answers the three questions Conversations around what got completed and plans for today, keeps conversations specific to tasks within stories, uses 16th minute for additional discussions All patterns of a Ha level team plus the question - "How can I help you?"; risks and hidden impediments are identified and proactively addressed; it is a priority based conversation - very tactical in nature, may not stick to formal format
Demos and Reviews Aware Conducts a demo and iteration review at the end of each iteration, team and PO attend, stakeholders (persons of interest to the project that are NOT the PO) are invited Regular demos and reviews with consistent stakeholder attendance and feedback Demos and reviews happen as regularly scheduled events; team creates other opportunities to demo progress to the broader organization as needed
Retrospectives Aware The team uses one way of conducting retros and holds them regularly; may occasionally use an external facilitator Always conducts Retros, multiple ways used, sees tangible improvements from retrospective action follow ups Not necessarily scheduled but organically done as and when needed, does not need external facilitator, continuous inspect & adapt cycle, properly identifies root cause
Estimation and Sizing Aware Estimates stories in the release backlog prior to the start of the release, may not be consistent using velocity with estimates to determine scope for a release Consistently estimates stories prior to the start of a release, ensures all stories in the backlog are estimated as soon as possible when changes occur Always maintains estimates and uses them consistently to predictably deliver releases with agreed upon scope


Product Delivery
Topic Comments Best Match A B C D
Tracking Progress Aware The team reviews iteration burn-down on a regular basis Actively monitors iteration burn-down and release burn-up charts to take action when required Actively monitors team level and personal level progress, looking to optimize flow of WIP
Testing Aware Stories are accepted by running the associated tests successfully against the acceptance criteria Test scenarios are based on aceptance criteria and delivered when the user story is created. Those scenarios are then used as test cases in User Acceptance Testing (UAT). Test Driven approach (TDD, ATDD, BDD) is applied for stories, end-to-end scenarios, integration testing, etc., coverage from automation testing increases over time
KPI's Aware Logs the KPI's on a regular basis Uses the KPI's to adapt team approach; addressed in retrospective and/or iteration planning Proactively addresses KPI's, including within an iteration
Managing Issues Aware When testing finds an issue, it is corrected before a story is accepted by the PO Issues found in the iteration for stories that were previously accepted are fixed within the iteration if possible. Team does not deliver issues that will become defects to production, modifies team behavior and approaches based on issue trends
Change Requests Aware Project Lead and Product Owners understand the official WF change request process as it relates to WF PVSI Agile Team mitigates risks and reduces potential impact by proactively responding to substantial impacts related to scope, schedule or cost Team transcends the official WF change request process and reaches out to stakeholders and partners to ensure coordinated changes are handled appropriately
Team Roles Aware All key team roles are represented as needed (PO, PL, QA, BA, DBA, Architect, Engineer, Developer...) Team members help out with other tasks when needed and the team as a whole is appropriately dedicated Persistent and dedicated team; responsibilities for all roles is covered whether a person with that role is on the team or not; the team takes control to ensure the role responsibilities are covered
Test Automation Aware Basic level of test automation Automated regression tests are run regularly All regression tests are automated, new test cases associated with user stories are automated within the current iteration
Developing user stories Aware Stories are developed in priority order and are accepted after the story has completed successful testing Team delivers stories quickly within the iteration (about 1/4 to 1/2 of iteration length) and team members swarm as needed to meet iteration goals Stories are consistently small enough to show progress throughout the iteration, optimizing flow and acceptance
Risk Mgmt Aware Identifies risks during planning Regularly reviews and updates risk lists Proactively manages risks within the team and across the organization
Spikes Aware Uses spikes to reduce risks and better prepare for business value user stories Uses spikes (with acceptance criteria) to increase learning and reduce technical debt; spikes have a 0 story point estimate. Team rarely requires Spikes because user stories contain enablement tasks to address technical research, issues or constraints
Product Deployment Aware The team deploys to production once per release. The team deploys to production multiple times per release. The team practices continuous deployment.


Technical Excellence - Application
Topic Comments Best Match A B C D
App - Code Reviews Aware Code reviews are done on a regular basis Code reviews are performed on a daily basis and fast reaction is taken by the code's author Code reviews are performed multiple times a day or the team uses pair programming
App - Environments Aware Has clearly defined environments - Dev, QA, Staging, Int QA, etc. The team uses promotion and deployment processes that mimic production deployment processes; run books are updated prior to completing a release The team uses promotion and deployment processes that support continuous deployment
App - Architectural Patterns and Reference Architectures Aware Team is aware of architectural patterns and uses them in the design of solutions; the architect is engaged and providing potential solutions and architectural guidance Team modifies and adapts architectural patterns and reference architectures to design optimal solutions Team actively creates new architectural patterns and reference architectures in order to design specific solutions; these patterns are reused within their domain
App - Coding Standards Aware Teams follows informal coding standards most of the time Standards exists and are strictly followed for all production code Standards evolve as needed by collaborating with the broader development community
App - Continuous Integration Aware Team checks in code frequently and uses automated build and version control tools most of the time Team integrates code and uses automated validation tools to obtain immediate feedback on the latest build Team routinely practices continuous integration and uses metrics to improve code quality
App - Technical Debt Aware Team does not knowingly create new technical debt while delivering value to the business Team proactively plans to eliminate technical debt every release Team proactively plans to eliminate technical debt every iteration
App - Design Patterns Aware Team applies common design patterns when developing new software Team uses common Design Patterns in developing new software; handles technical debt by refactoring existing code towards common Design Patterns Uses common Design Patterns by adapting them into new Design Patterns which improve the development process and the quality of deliverables
App - Code Ownership Aware Team members typically only work in their code areas Team values collective code ownership Team practices collective code ownership and each team member can fix issues in all areas
App - Testing Aware Unit tests are developed along with new code Automated unit tests are written before code is implemented Automated functional tests are written before code is written
App - Refactoring Aware Refactoring is done for code related to the User Story being worked on Refactoring is done for code impacted by or closely related to the user story being worked on Refactoring is done for code closely related to or impacted by feature delivery
App - Skills Development Aware Team learns new technical skills as they are needed Team learns new technical skills beyond what is required for the current need Team exhibits continuous learning of technical skills, team develops standards and frameworks that are shared with other teams
App - Deployment Aware Team deploys when needed using a combination of manual processes and automated scripts Team deploys when needed using automated scripts Team practices continuous deployment and fully automated rollback of deployments


Technical Excellence - Infrastructure
Topic Comments Best Match A B C D
Infra - Architectural Patterns and Reference Architectures Aware Team is aware of common infrastructure-related architectural patterns and uses them in the design of solutions. Team refactors existing configurations towards common infrastructure related architectural patterns Team can create appropriate architectures based on requirements and generally accepted good practices, patterns and reference architectures the team creates are reusable by other teams to solve related problems
Infra - Architectural Upgrades Aware Team can carry out significant architectural upgrades of infrastructure elements Team can carry out significant architectural upgrades of infrastructure elements by applying smaller upgrades in a well-planned way Team routinely upgrades architectural components
Infra - End of Life Aware Team can retire systems and infrastructure components gracefully on a case-by-case basis, using manual methods Team can retire systems and infrastructure components gracefully on a case-by-case basis, using automated methods End of life for infrastructure components is planned in advanced based on the age of assets, announced termination of vendor support, capacity planning, advances in technology, cost management, and other factors - end of life does not come as a surprise
Infra - Automated Configuration and Deployment/Rollout Aware Server configuration and standard deployments are performed manually Routine server configuration and standard deployments are scripted Team normally works out the automation of configuration and deployment steps in a lab or test environment before beginning any configuration or deployment in a production environment, scripts are maintained under version control in the same way application teams manage their source artifacts
Infra - Automated Verification Aware Server configuration and standard deployments are verified using manual methods Server configuration and standard deployments are verified using automated tools Team normally begins by developing verification scripts and then uses the verification scripts to guide the creation of configuration and deployment scripts; all scripts are maintained under version control, deployment scripts are subjected to automated regression testing
Infra - Production Issues, Automated Monitoring Aware Team develops repeatable ways to address recurring production issues and provides documentation of corrective actions in a well-known location Team develops repeatable ways to address recurring production issues and provides documentation of corrective actions in a well-known location, team reviews patterns in production issues and acts to remove root cause(s) as appropriate Team's applications and third party packages hook into the standard business activity monitoring facilities to provide early warning or automated prevention of production issues


Technical Excellence - Service
Topic Comments Best Match A B C D
Service - Deliverable Reviews Aware Deliverables are reviewed and edited by leadership prior to deploying such artifacts Deliverables are reviewed and edited by peers multiple times prior to deployment Deliverables are created, reviewed and edited collaboratively by multiple team members
Service - Work Intake Process Aware The team has a clearly defined work intake/priority process published to customers The work intake process is streamlined to enable quick and easy submission of work requests The intake process is reviewed/updated regularly for improvements based upon feedback
Service - Self Service Tools Aware Team has service/support information and guides available to customers 24/7, 365 to enable teams to plan their work Team has processes/tools enabling customers to address routine service options themselves (i.e. status, limited permissions) Routine tasks are automated and Team's focus is on high risk work items or those requiring greater expertise
Service - Service Level Agreements (SLA) Aware Team has a defined Service Level Agreement (SLA) identified for all services offered Team measures and monitors metrics to improve their SLA completion success Team is able to demonstrate at least 90% success of SLA metrics on a consistent basis
Service - Technical Debt Aware Team does not knowingly create new technical debt while delivering value to their customers Team proactively plans to eliminate technical debt every release Team proactively plans to eliminate technical debt every iteration
Service - Deliverable Ownership Aware Team members individually own requests related to deliverables they originally created Team collectively owns deliverables and can speak to each of them Team values collective ownership of deliverables and any team member can work on any deliverable
Service - Testing Aware Team performs limited internal testing on their deliverables Team occasionally tests deliverables with pilot user group and incorporates relevant feedback when time permits Team routinely tests deliverables with small, external, representative groups and incorporates relevant feedback immediately
Service - Deliverable Optimization Aware Optimization is done for deliverables only when issue/impact requires it Optimization is done for deliverables impacted by or closely related to user stories being worked on Team routinely and proactively optimizes previous deliverables based upon customer feedback
Service - Skills Development Aware Team learns new relevant skills as they are needed Team learns new relevant skills beyond what is required for the current need Team exhibits continuous learning of relevant skills, develops standards and frameworks that are shared with other similar teams
Service - Publishing & Deployment Aware Team deploys/publishes deliverables once per release Team deploys/publishes deliverables multiple times per release to solicit and incorporate customer feedback Team deploys/publishes deliverables immediately upon acceptance