Issues with ‘Agile’
Most firms engaging with DevSecOps processes have issues with Agile-Scrum engineering. Common complaints include:
- -GDAD or Geographically Distributed Agile Development in which 65% of projects fail in some way
- -Requirements Engineering mismatch, especially when Indian offshore teams are present and most of the work is shipped to India
- -Lack of standard processes, ceremonies, management or governance, tooling
- -Lack of integrated security, code and system testing
- -Unrealistic expectations of improvements over Waterfall (time, investment needed, maturity of people within a new process)
- -Organisational pushback, reluctance to embrace a true Agile culture, inertia and lack of training and resource management
- -Not having the right skills on the teams
- -Team size too large, too distributed, Scrum master not technical
- -Lack of clear documentation
- -Inability to integrate with corporate milestones and deadlines
- -No centralised centre of Agile excellence which helps teams with standards, training, tooling, and coaching
| Agile | Waterfall |
| Architecture informal and incremental, current and end states are usually not documented or well known; requirements vague | Current and end states are well known, understood and documented, requirements clear, obvious |
| Developers share ownership of code | Silos of development, testing, business knowledge |
| Continuous integration and delivery | Integration and delivery are viewed as phases and milestones |
| Iterative to complete tasks and functionality | Milestones and stage-gate based |
| Relies on best engineering practices (design patterns, test cases) | Relies on micro-management driven by project managers, not technical SMEs |
| Light process and documentation; focus on pilot projects and delivery | Heavy documentation, processes with a focus on control, not delivery, meetings a priority, not pilot projects |
| Requires cross training across technologies and testing, technically driven | Main roles are project management related not technical |
| Business embedded inside Agile teams with the team composed of engineers, testers, business owners, QA and the sponsor | Silos of stakeholders, limited information exchange, formal procedures for communication |
Measuring Agile Maturity
Given these issues we built the Agile-Scrum Maturity Model (ASMM) which helps firms understand the Agile engineering process and map the use of Agile to KPIs and improvements.
ASMM allows firms to understand the key metrics and KPIs of the agile process by team, rolled up across the entire company. We can therefore track and improve our Agile engineering performance and prove to management that KPIs are improving and that the engineering processes are resulting in reduced error rates, improved code, higher velocity and satisfaction of business requirements.
This maturity model is used by individual teams and projects, and a view of a division or entire firm can be rolled up and presented as well. This allows companies to troubleshoot areas that may be impeding the proper usage of Agile and negatively impacting their DevOps processes.
Key Variables
| Agile Organization | Team Environment | |
| Key Variables | Agile Usage (process, artifacts) | Team Size (<9) |
| Culture (Agile culture) | Dedicated Team (one project) | |
| Centre of Excellence (COE) | Agile Roles (understanding) | |
| Training (roles, skills) | Trust (on the team) | |
| Change Management (HR issues) | Business Owner (BO) actively, daily on the team | |
| C Suite Support | Senior Management/Stakeholder support | |
| Budgeting (Agile budgeting) | Skills of the team (fitting the project) | |
| Project Management (not waterfall, but Agile-Scrum based) | Colocation | |
| Self-Organized | ||
| Impediments (ability to remove) | ||
Categories the model assesses
We assess the 5 key categories of success in Agile.
- Agile Organisation
- Team Environment (culture etc)
- Product or Project Management and Ownership
- Agile Mechanics or Ceremonies
- Agile Engineering Practices (tooling, processes etc).
Example:
| Agile Organization | Team Environment | ||
| Key Variable | Managerial Implications | Key Variable | Managerial Implications |
| Agile Usage | Documentation, clear understanding of Agile-Scrum, Roles | Team Size | Small, Cross-functional skills, SMART projects |
| Culture | Active change management | Dedicated Team | Resources are not shared |
| Centre of Excellence | Establish, empower, ensure SMART projects; long term investment in Agile-Scrum | Agile Roles | Training, Understanding, Buy-in |
| Training | On-going, multi-faceted | Trust | Cultural values of Agile |
| Change Management | Training, change request processes re-engineered | Business Owner (BO) | Business trained in Agile processes |
| C Suite Support | Communications, Reporting, Long-term investment | Stakeholder support | Senior Management, Business embedded |
| Budgeting | Waterfall to Agile cycles, long-term investment | Skills of the team | SME knowledge |
| Project Management | No Waterfall used, proper understanding of Agile-Scrum | Colocation | SMEs together |
| Self-Organized | Empowerment | ||
| Impediments (ability to remove) | Access, power to remove obstacles | ||
Try it
Demo https://trilogix.cloud/agile-scrum-maturity-model/agile-scrum-maturity-model-free-demo/
