Tips and Tricks to link your Scrum Audit with Cobit 5

cobitStarting auditing a Scrum Program is not that easy, you need to take into account:

  • Roles and Responsibilities
  • Quality Insurance
  • Risk Management
  • Communication and Governance
  • Acceptance criteria : Definition-of-done (DoD), Level-of-Done (LoD), Definition-of-Ready (DoR)
  • Lessons Learned
  • Team dynamics
  • Integrated testing
  • Management and Operation involvement
  • and …. calendar

Why calendar?

Usually an audit is planned for a dedicated time frame and you will start (the simplest process here):

– validate audit purpose with audit committee and stakeholders

– write an audit plan based on Risk Control Matrix and the dedicated Test Lead Sheets

Often you will be ready when the most interesting information has past i.e. after the Scrum Ceremonies like Sprint Review, Retrospective and Sprint Planning. If the iterations are over 3 weeks then you can postpone the audit start to this date.

Why?

Let’s be honest! In Scrum, the ceremonies (meetings) are key information drivers regarding program effectiveness:

  • Sprint Review has to parts: the demo when the developers show the work done to the customers, end-users and management, and the Stakeholders Inspect-and-Adapt process when you got the Sprint outcome approval and functional changes add-ons.
  • Retrospective gives you an overview on how the team is self-managed, how people are engaged, the level of maturity of the developers, capacity management issues, lessons learned and process improvement.
  • Sprint Planning, in other hand, gives a realistic picture on the relation between business and development, planning capacities, developers engagement…

Linking with Cobit 5

1.      Evaluate, Direct and Monitor
  1. 1.     EDM 02: ensure business benefits delivery
    1. This is Product Owner’s job. The Product Owner tracks return-of-investment and time-to-market
    2. (s)he provides guidance data to management regarding project completeness
  2. 2.     EDM 03: Ensure Risk Optimization
    1. Risk should be assessed all along the Scrum process:
      1. at Development Team during the Daily Scrum Session
      2. through the Visual management Board (Scrum Radiator)
      3. at Review Meetings for scope, functional and business risks
      4. at Retrospectives for Process, Capacity, Non-Functional and Security Risks
      5. at Sprint Planning: risk supports Product Backlog prioritization (lowest first)
    2. The Scrum Team (Scrum Master, Product Owner, Developers) are all accountable for it.
    3. Scrum Master manage the Risk Process and Organization Transition Risks (the How)
    4. Product Owner manage Product Development Risks (the What)
  3. 3.     EDM 05: Ensure Stakeholder Transparency
    1. Transparency is the core of Scrum. Opacity is a Scrum issue.
    2. Stakeholder are involved in the Scrum process at last at Sprint Review and Sprint Planning.
    3. The Product Owner keeps permanent connection with customers and end-users (business) during the process.
    4. The Scrum Master is permanently connected with management. (s)he ensures that everything is highly visible to all stakeholders.
    5. Often seen issues:
      1. Sprint Review is only a Demo. Risk: developers try to hiding their real capabilities, the product is not linked to end-users aims.
      2. Sprint validation done by the Product Owner before Sprint Review only at Scrum Team level. Risk: hiding real capabilities.
      3. Missing , poor visual management, or only IT tool. Risk: reducing team dynamics, hiding bottleneck and emerging issues, miss alignment with coworkers, over-commitment, missing workflow improvement, capacity fragmentation.
  4. 1.     AP006. Manage Budget and Costs
    1. Product Owner is accountable for budget and cost tracking.
    2. Scrum Master and Development Team supports Product Owner activities.
    3. Product Owner works closely with Sponsor and Finance, ideally after each Sprint.
    4. Budget and Costs are tracked on a daily basis by Development Team and Scrum Master done task after daily Sprint
    5. Contingency is considered as an issue. Budget should be improved monthly at Sponsor Committee (part of the Sprint Review if possible)
  5. 2.     AP007. Manage Human Resources:
    1. Scrum Master act as Operational Human Resources and reports to HR Department (for mature organizations).
    2. At last, Scrum Master is in charge of Capacity Management.
    3. After Retrospective Reports done by Scrum Master regarding Continuous Improvement, Availability, Illness, Holidays, etc…
    4. For Providers, Scrum Master should monitor team morale, performance and commitment.
    5. Scrum Team members should be dedicated at 100% to the project. Deviation are documented as Risk.
  6. 3.     AP008. Manage Relationships
    1. alignment of IT and Business strategy is managed by Product Owner and the Development Team
      1. at Sprint starts during the Sprint Planning Meeting
      2. validation at Sprint Review
    2. delivery of IT services in line with Business requirements at Sprint Review
    3. integration of IT processes in Business processes and emerging innovation: input through Scrum Master’s after Retrospective report
  7. 4.     AP009. Manage Service Agreements
    1. delivery of IT services checked and managed by Product Owner and Scrum Master
    2. Scrum Master: check incidents regarding to non availability in line with the Scrum process
    3. Product Owner: check stakeholder satisfaction, reports quality of delivered services with Partner Management
    4. Product Owner validates State of Work for external provider if requested.
  8. 5.     AP010. Manage Suppliers
    1. IT related risk management is managed by both Scrum Master and Development Team on Daily Basis: risk is visualized in the Scrum Radiator (Scrum Board) as a queue or an impediment
    2. IT services delivery in line with business requirement through relevance of Definition-of-Done and Sprint validation by Product Owner.
    3. It Agility is validated through the Scrum process:
      1. level of satisfaction of business at last at Scrum Review Meeting and all along through the process by Product Owner’s action.
      2. updated infrastructure and applications handled by Development Team under Scrum Master’s supervision and on-going testing policies.
      3. strategic IT objectives are taken into account in Product Backlog prioritization and permanent Business involvement.
  9. 6.     AP011. Manage Quality
    1. realized benefits tracked at Sprint ends by the Product Owner. Cost performance index is updated at portfolio level.
    2. Schedule performance index is part of the Sprint end reporting.
    3. Release Burndown Chart is up to date, Velocity is known
    4. Definition-of-Done (DoD) policies are applied:
      1. Developers are using Level-of-Done: code correspond to standards, code is clean, re-factored, unit tested, checked in, built, has a number of unit tests applied. They have a source code library, code standards, automated build, unit test environment.
      2. There is a DoD for each levels: task, item, requirement, Sprint, Release, Integration, Production.
2.      Align, Plan, Organize

Want to have more information? Contact me!

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s