Agile Healthcheck
More and more organisations are realising that expert advice and guidance from experienced agile practitioners is key to being successful when adopting agile. A deep understanding of why agile approaches work, what to do and how to do to make them work is essential if the potential benefits of agile are to be realised.
Agil8’s Agile Assessment service is part of our proven Vision, Action, Traction framework for Agile. It provides a clear pathway to success for your agile initiative through both quantitative and qualitative assessment of the way in which your agile practice is currently operating. It can cover every aspect of agile operations from agile technical engineering practices such as DevOps through team and organisation structures, roles and responsibilities, Backlog management, planning, reviews and retrospectives, mind-set and climate of culture. It can be applied across single or multiple teams right up to the largest programmes and enterprises.
Outputs
One or more highly experienced agil8 consultants will work with your team and their stakeholders using a mixture of interviews and direct observation to produce an Assessment Report covering all key aspects of agile using a Red / Amber / Green indicator approach with comments to provide context and further explanation. Overall Findings and Recommendations are played back in a report and presentation on completion of the Assessment to enable creation of an Improvement Backlog and Improvement Action Planning.
Example of Agile Assessment Report
| Assessment Item | Score | Comment |
| Roles and Responsibilities | ||
| Product Owner | 3 | Business Analyst acts as PO in lieu of real business ownership |
| Development Team | 3 | Development team is cross functional but not T-shaped |
| ScrumMaster | 3 | ScrumMaster role is peformed by Technical Lead |
| Management | 4 | Management allow team to self-organise |
| Team Practices | ||
| Sprints | 3 | Sprint timeboxes are respected. Additional work is often forced into Sprint by Stakeholders |
| Estimating | 2 | Story Points are equated to days when estimating |
| Product Backlog Refinement | 1 | Insufficient. Product owner alone. No Development Team involvement |
| Other Meetings and Events | 5 | Product Backlog Prioritisation with stakeholders works well |
| Artifacts | ||
| User Stories and other Product Backlog Items | 2 | PBIs are not well defined, frequently too large for Sprint and Technical rather than User focused |
| Definition of Done | 3 | Not formally defined. Tighter definition recommended |
| Sprint Backlog | 5 | Kept up to date by Development Team |
| Potentially Shippable Product Increment | 3 | Increment is not properly tested on completion of each Sprint. |
| Large-Scale Multi-team Agile | ||
| Feature Teams vs Component Teams | 2 | Teams are 100% organised as Component Teams leading to a higher number of dependencies |
| Joint Team Planning | 3 | Joint team planning is only performed at PI Boundaries. |
| In-Sprint Co-ordination (e.g Scrum of Scrums) | 4 | Scrum of Scrums every other day is attended by ScrumMasters only. |
| Joint Team Backlog Refinement | 3 | Teams only work together to refine the backlog at PI Boundaries. |