Les dessous d’une conférence: mes documents de préparation pour mon intervention au IPMA Global Congress de Rotterdam – James Bond, Stakeholder’s Engagement

Originally posted on The Scrum Coach:

2012-11-18 13.20.19

Le Roadshow “My Product is a James Bond Movie” poursuit son chemin. Le 1 octobre, je compte ressortir de ma zone de comfort pour expliquer lors du 28e Congrès Mondial de l’IPMA (International Project Management Association) comment James Bond (aka Agile) améliore et assure une excellente gestion de la relation entre parties prenantes au projet (stakeholders).

Pour vous faire comprendre, surtout mes 14 compagnons de coaching agile, que raconter une histoire aussi fantasque qu’elle puisse paraître nécessite un peu de préparation.

Objectif:

  • avoir une présentation fantasque, énergisante, inspirante et pertinente
    • fantasque: le public s’attend à voir un coach agile soit une personne un peu bizarre entre guru et geek. Pour ma part et avec tout le respect que j’ai pour l’audience, je me dis toujours que certaines personnes ne comprendront que peu de choses mais au pire elles auront passé un bon moment.
    • énergisante:… toujours le coach. Si…

View original 598 more words

SAFe – Scaled Agile Framework – big Agile so what now? (Conférence PAM Summit, Cracovie 06/14)

Originally posted on The Scrum Coach:

En juin dernier, j’ai eu l’opportunité de répondre favorablement à la demande d’Arie VanBennekum pour présenter une approche de la Gestion de Programme Agile au PAM Summit (PMI) de Cracovie.
Après avoir proposé plusieurs aspects de la gestion de programme dans le monde agile, l’organisation a souhaité une introduction à SAFe.
SAFe ou Scaled Agile Framework est un sujet d’âpres discussions dans la communauté, comme l’on été Scrum vs XP et Kanban vs Scrum en leurs temps.
Cette présentation se concentrant principalement sur l’aspect gestion de programme, je trouvais intéressant de transmettre mon point de vue en me concentrant sur l’Agile Release Train que je conçois comme une idée très intéressante. L’Agile Release Train peut aisément être vu comme une transition pour l’implémentation de Devops dans un environnement de développement agile sous Scrum. L’idée est de définir des dates fixes…

View original 291 more words

Plörk – Gamification and Group Coaching Combined

PLÖRK – GAMIFICATION AND GROUP COACHING COMBINED

viaPlörk – Gamification and Group Coaching Combined.

PLÖRK – GAMIFICATION AND GROUP COACHING COMBINED

Guestblog by Pierre Neis

Plork (play and work) is a workshop facilitation format combining the forces of group coaching and the dynamics of games (gamification). Some consider Plork as solution focused coaching in a minimal timeframe. The main reason for Plork is to install a dynamic of permanent change within the company by the dynamics of the team which composes. Learn through experience!

“Make business more fun than fun!”, is the driving vision of Plork.

plork1

The Plork model uses the format of the games to create a secure space for the expression of the needs of the participants, to convey a message, search the commitment of each of the participants to be actor in the dynamics of the organization. Serious Games, Innovation Games, Gamestorming allows to wake up the innovation at the heart of the business and project teams.

PLöRK makes it happen!

Come and discover how you’ll work better in the future with the power of games!

When? 8 Maart 2013
Where? Ter Elst, Edegem (Antwerp, BE)
How Much? 225€ 

rethingworkplayweblogo

getyourticketA

Share this:

Tips and Tricks to link your Scrum Audit with Cobit 5

COBIT5WatchandLearnStarting 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. 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. 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. 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.
  2. Align, Plan, Organize

    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)
    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.
    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
    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.
    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.
    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.

 

Want to have more information? contact us!

Auditing Scrum Programs/Projects as a coach!

Auditing is part of our job as Scrum Coach. I agree, it’s not usual at all but it can be interesting to measure where we are and where could go and with who!

Please find below the first approach on auditing Scrum programs. I didn’t share the Cobit links or how I did this but a work sheet based on:

So here the work:

 

 

These measures are off course for “junior” scrum projects and several other points can be added, like:

  • definition of ready
  • level of done
  • end users involvement
  • support of Risk Management
  • support of Finance
  • support of QA
  • Agile Product Life Cycle Management
  • Visual Management
  • People engagement
  • Change and Transition
  • etc…

links to Cobit 5 will be added in next posts.

Cheers

Pierre

References

Government:

  • Centre des Technologies de l’Etat (CTIE), Luxembourg (Grand Duchy of Luxembourg)

Research:

  • CNRS, Nancy (France)

Finance:

  • Euroclear, Brussels (Belgium)
  • Reuters Financial, Puteaux (France)