Les ébauches d’un manifeste d’entreprise: un ensemble de valeur liant les personnes avec l’organisation

Capture d'écran 2014-07-27 18.50.43

Cette semaine, nous avons commencé à travailler sur le sens de l’entreprise avec notre client Wemanity.

La notion de sens est à interpréter comme l’ensemble des éléments qui vont lier l’entreprise avec ses employés et vice versa.

Pourquoi une telle approche?

Notre mission est d’installer une culture agile qui est le coeur de l’entreprise. Wemanity a choisi cette voix car cela représentait la vision de son créateur, Jean-Christophe Conticello. Celui-ci ne souhait pas une entreprise comme les autres, mais une entreprise disposant d’un esprit “start’up” où chacun trouve sa place et crée les conditions de sa réussite tout en contribuant aux projets de ses collègues. Depuis le mois d’Avril, date de notre implication, le concept agile, la culture de l’entreprise a pris racine et les résultats ont été probants depuis les premiers jours: rien qu’au mois de Juillet, le bureau parisien a augmenté ses effectifs de 10 personnes passant à 60 (Wemanity n’a qu’à peine plus d’un an d’existence), moins de 10% n’ont pas de missions, et les candidatures spontanées vont croissant.

Le Manifeste.

Il nous fallait des repères, une histoire mettant en lumière le concept de cette entreprise. L’Agilité est basé sur quelques points essentiels qui ont fait de cette démarche une des plus grandes innovations organisationnelles depuis ces 50 dernières années.

Ce manifeste est un brouillon qui sera revu avec l’ensemble des intervenants (internes, externes, clients et fournisseurs), jeudi prochain en soirée lors d’un Serious Game.

Voilà donc les éléments du manifeste:

  • La diversité est notre richesse. L’uniformité réduit la variabilité de nos pensées. Notre “métissage” nous rend plus fort.
  • Chacun est unique et irremplaçable. Nous sommes une communauté de femmes et d’hommes faisant corps dans cette aventure.
  • La transparence est une preuve d’amour. L’opacité est une preuve de haine ou pire, d’apathie.
  • Même pas peur. La peur est un frein à l’innovation. Nous, nous voulons innover sans cesse.
  • Nous partons du principe que chacun fait de son mieux. L’amélioration est continue. Chaque personne est à sa bonne place.
  • Nous ne donnons jamais de prestation en solo, nous sommes une équipe. Par la dynamique du groupe, nous apporterons le plus de valeur à nos clients, à nos collègues, à notre entreprise, à nous même et à notre famille.
  • Nous sommes une entreprise sans patron. Nous sommes tous l’auto-entrepreneur de notre destin que nous partageons avec nos pairs.
  • Nous ne vendons pas de l’Agilité, nous sommes agiles. Nous sommes convaincus que l’être est plus fort que le paraître.

La semaine passée j’ai pu tester ce manifeste lors d’un recrutement à l’instar du “pitch” traditionnel. L’effet attendu était au rendez-vous et pour valider la démarche, nous avons fait visiter les bureaux et rencontrer l’équipe à notre candidat. Je vous laisse imaginer le résultat.

 

Pierre Neis

Associé We&Co – Head of Agile Wemanity (Paris, Bruxelles, Amsterdam)

Les “TOP 12″ leçons apprises de Guy Kawasaki par Steve Jobs

 

  1. Les experts sont ignorants
  2. Les clients ne peuvent pas vous dire ce qu’ils ont besoin
  3. Les plus grands défis engendrent le meilleur travail
  4. Le design compte
  5. De grands graphiques, de grandes polices
  6. Courbes de saut et pas une meilleur similitude
  7. “Fonctionne” ou “ne fonctionne pas”, c’est tout ce qui compte
  8. La “valeur” est différente du “prix”
  9. Les “très bon”  joueurs embauchent des “très bon” joueurs (voir meilleur)
  10. Les vrais CEO peuvent démontrer (faire la démo)
  11. Les entrepreneurs livrent
  12. Quelque chose doit être crue pour être vue

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