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.
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€
The particular business model of We&Co based on collaboration between experienced people, consultants and companies is growing.
Actiskills represents We&Co activities in France and Morocco.
Agir Anticiper Durablement is focused on Corporate Social Responsibility and Training.
For corporate questions ask We&Co governance people: Dirk Heindrichs, Pierre E. Neis
need more details? feel free to contact us!
Starting 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
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.
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
Evaluate, Direct and Monitor
- EDM 02: ensure business benefits delivery
- This is Product Owner’s job. The Product Owner tracks return-of-investment and time-to-market
- (s)he provides guidance data to management regarding project completeness
- EDM 03: Ensure Risk Optimization
- Risk should be assessed all along the Scrum process:
- at Development Team during the Daily Scrum Session
- through the Visual management Board (Scrum Radiator)
- at Review Meetings for scope, functional and business risks
- at Retrospectives for Process, Capacity, Non-Functional and Security Risks
- at Sprint Planning: risk supports Product Backlog prioritization (lowest first)
- The Scrum Team (Scrum Master, Product Owner, Developers) are all accountable for it.
- Scrum Master manage the Risk Process and Organization Transition Risks (the How)
- Product Owner manage Product Development Risks (the What)
- EDM 05: Ensure Stakeholder Transparency
- Transparency is the core of Scrum. Opacity is a Scrum issue.
- Stakeholder are involved in the Scrum process at last at Sprint Review and Sprint Planning.
- The Product Owner keeps permanent connection with customers and end-users (business) during the process.
- The Scrum Master is permanently connected with management. (s)he ensures that everything is highly visible to all stakeholders.
- Often seen issues:
- Sprint Review is only a Demo. Risk: developers try to hiding their real capabilities, the product is not linked to end-users aims.
- Sprint validation done by the Product Owner before Sprint Review only at Scrum Team level. Risk: hiding real capabilities.
- 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.
Align, Plan, Organize
- AP006. Manage Budget and Costs
- Product Owner is accountable for budget and cost tracking.
- Scrum Master and Development Team supports Product Owner activities.
- Product Owner works closely with Sponsor and Finance, ideally after each Sprint.
- Budget and Costs are tracked on a daily basis by Development Team and Scrum Master done task after daily Sprint
- Contingency is considered as an issue. Budget should be improved monthly at Sponsor Committee (part of the Sprint Review if possible)
- AP007. Manage Human Resources:
- Scrum Master act as Operational Human Resources and reports to HR Department (for mature organizations).
- At last, Scrum Master is in charge of Capacity Management.
- After Retrospective Reports done by Scrum Master regarding Continuous Improvement, Availability, Illness, Holidays, etc…
- For Providers, Scrum Master should monitor team morale, performance and commitment.
- Scrum Team members should be dedicated at 100% to the project. Deviation are documented as Risk.
- AP008. Manage Relationships
- alignment of IT and Business strategy is managed by Product Owner and the Development Team
- at Sprint starts during the Sprint Planning Meeting
- validation at Sprint Review
- delivery of IT services in line with Business requirements at Sprint Review
- integration of IT processes in Business processes and emerging innovation: input through Scrum Master’s after Retrospective report
- AP009. Manage Service Agreements
- delivery of IT services checked and managed by Product Owner and Scrum Master
- Scrum Master: check incidents regarding to non availability in line with the Scrum process
- Product Owner: check stakeholder satisfaction, reports quality of delivered services with Partner Management
- Product Owner validates State of Work for external provider if requested.
- AP010. Manage Suppliers
- 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
- IT services delivery in line with business requirement through relevance of Definition-of-Done and Sprint validation by Product Owner.
- It Agility is validated through the Scrum process:
- level of satisfaction of business at last at Scrum Review Meeting and all along through the process by Product Owner’s action.
- updated infrastructure and applications handled by Development Team under Scrum Master’s supervision and on-going testing policies.
- strategic IT objectives are taken into account in Product Backlog prioritization and permanent Business involvement.
- AP011. Manage Quality
- realized benefits tracked at Sprint ends by the Product Owner. Cost performance index is updated at portfolio level.
- Schedule performance index is part of the Sprint end reporting.
- Release Burndown Chart is up to date, Velocity is known
- Definition-of-Done (DoD) policies are applied:
- 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.
- There is a DoD for each levels: task, item, requirement, Sprint, Release, Integration, Production.
Want to have more information? contact us!
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
links to Cobit 5 will be added in next posts.
We & Co sàrl
19, place Bleech, L-7610 Larochette
Mobile (Pierre): +352 661 727 867
sàrl au capital de 12.500 euros