Agile Team – Maturity Guidance
There is no single set of prescriptions or a silver bullet for every team that will ensure repeatable success, each team is in constant pursuit of excellence and growth to achieve effectiveness, which makes up the Agile team maturity Journey…
The following points provides the guidance to Agile Leads or Scrum Masters, which helps to improve Agile teams maturity in the right direction.
- Maintain the Competency/Skill-Matrix with all skills required for the team and map each member; this helps to identify skill gaps and plan upskill actions. This also helps to define primary and secondary competency responsibilities within the team.
- Ensure all team members completes the formal Capgemini university – Agile trainings.
- Scrum Master should educate the team about autonomy and same should be promoted by SM during each event.
- Create Team’s working agreement – should ensure the Agile Team shares responsibility in defining expectations for how they will function together and enhance their self-organization process.
- Roles and responsibilities need to be clearly defined ( create RACI matrix ); mainly differentiate activities of Line Manager and Product Owner.
- Ensure Product Roadmap and Release plan are created and share access place for whole team and stakeholders.
- Team should have a dedicated Product Owner (PO); or at-least define Proxy-Product Owner (PPO) role. PO/ PPO should not change frequently.
- Establish openness in Agile team, so that team contact directly with PO as per need.
- Ensure Product Backlog is populated enough for N+2 sprints and prioritized.
- Every PBI/story in Product Backlog should have an Acceptance Criteria.
- Always use story-points for estimation and update in Agile tools (like JIRA, Rally,TFS… ), which will drive key metrics.
- Do include spikes, technical debt, NFRs,…etc.; along with business requirements in product backlog .
- PO should use Agile tools to create product backlog items and conduct product refinements meetings weekly.
- Automate following quality practices at every applicable environment ( ex: Dev/SIT/Pre-Prod).
- Code quality using tools ( like SonarQube / ReSharper/ SonarLint )
- Code vulnerability
- Unit test coverage, using tools like Junit…
- At the end of every sprint, related reports to be captured and stored (e.g., confluence) as an artifact.
- Test automation capacity should be accounted for, during Sprint planning, so that Shift-Left approach is followed and ‘In-Sprint’ test automation can be done.
- Use Test case management tools track test execution and traceability for functional/feature, Regression, system Integration, Acceptance Test…
- At-least once before the release, ensure these tests are executed – as mandatory
- Run Load Test to verify whether the application/ product can handle the expected load. Use tools, like Jmeter ( if applicable ).
- Execute performance test on application / product to collect metrics such as availability, response time, and stability.
- Running Security / PEN Test is mandatory at-least once before the release.
- All peer review comments to be tracked in version control tools ( like bitbucket/ GitHub /TFS …) instead of mail’s.
- Implement TDD/BDD to Enable Shift-Left Testing Approach
- Automated CI/CD pipeline. When build is generated, automatically build should move to SIT environment for automated test runs. ( ensure pipeline works well till SIT later extend till Pre-PROD ).
- The number of automated tests should increase with each sprint.
- Adopt Tunk based development ( eg. GITflow) or ensure minimal branches with daily updated main branch.
- Ensure whole team knows architectural plan ( understands architectural runway /roadmap)
Events and Artifacts
- Team should follow same fixed-duration for all sprints throughout a development release.
- Sprint Planning is mandatory; Ensure whole team participates and contributes. Sprint goal must be defined and agreed by team.
- Ensure ScrumMaster educates team to pull stories to match the team capacity during sprint planning itself.. Also, team should create relevant sub-task during planning.
- During the DSM, team needs to review the progress towards the sprint goal using JIRA burn-down charts.
- Team needs to create and maintain consolidated impediment log in JIRA/Confluence with clear action and owner.
- Retrospective meetings are important, ensure retro action items are logged and visible for whole team.
- Definition of Ready (DoR) & Definition of Done (DoD) need to be formulated and agreed by the team. The Agile team should verify DoR/DoD at the start/end of sprint for each story.
- Product backlog refinement meeting should be happening more frequently/preferably every week to ensure that User stories in backlog are still relevant and enough for N+2 sprints.
- JIRA and confluence should be single source of truth for all communication.
- Ensure team adopts video-enabled meetings. at-least try to mandate meetings like Retro, DSM, review.
- Regular (once in month/sprint) Team breakouts to-be planned, this will help to build positive team morale.
- JIRA board to be modified from Individual level to Team level by creating swim-lanes on Story basis, if required filters can be created for individual assignees
- JIRA out of box gadgets must be used, JIRA filters must be leveraged; ensure dashboard configured for all key points like sprint progress, Velocity, Burnup/down, Story status, defect status,..…etc.
- Burndown is a key metrics of progress towards the sprint goal, must be standardized as per story point remaining and must be visited on daily basis during DSM.
- Scrum Master should share simple report summarizing the Sprint at Sprint closure.
- Team needs to revisit the impediment log periodically during DSM..
Measure and Grow
- Configure Burndown chart based on story points, and ensure its updated everyday based on remaining work.
- Review sprint velocity end of every sprint, the outcomes will be input parameter for next sprint planning.
- Scrum Master should to ensure all key quality metrics are define and tracked.
- Capture Stakeholder feedback score for every sprint during Sprint review.
- Track Team happiness index during Sprint retrospective.
Release on Demand
- The release roadmap should be defined and visible to the team.
- Automate continuous deployment (CD) till Pre-PROD. Avoid manual approvals / Intervention at-least till SIT environment.
- Conduct release governance events on a regular cadence to discuss:
- Impediments which impacts future release.
- Review quality of solution being built and expected value planned to release
- Check if everyone aligned with scheduled release dates.
- Take structured survey feedback after major release and make it transparent to all team members.
- Need focus to develop more T-shaped skill members in team, the skill matrix tool will help to identify the improvement areas.
- The retrospective improvement action log should be a live document, with all open and close actions.
- Team should adopt problem solving tools like RCA / Kaizen/ POPCORN …etc. to improve incrementally.
- The capacity allocation for refactoring or innovations should be considered in sprint planning.
- Product improvements/refactoring items should be included in product backlog.
- The project metrics measured ( tracked in Agile tools like JIRA board; ) to-be used to improve the team, delivery, quality performance
- Frequently revisit DoR/DoD checklist, accordingly refine. ( Initially every sprint, later every quarter)
- One team’s best practices should be shared across other teams in a program, and ensure thy adopt the practices.