agile governance

Copyright © 2014 National University of Singapore ATA/TUS-Agile Governance V1.0

Agile Governance

Robert Firth

[email protected]

Copyright © 2014 NUS.

Total slides = 17

Agile has a light side and a dark side


Outline of the Session How did Agile happen?

What are its key ideas?

What is appropriate Agile governance?


A (very) brief History of Agile Takeuchi Hirotaka & Nonaka Ikujiro:

The New Product Development Game (1986)– introduced the SCRUM concept

Jeff Sutherland & Ken Schwaber (1990s)– brought the ideas to the West

Alistair Cockburn: Crystal Family (1990s) Kent Beck et al: Extreme Programming (1998) Group of 17: The Agile Manifesto (2001)

www.agilemanifesto.org


What are the Key Ideas of Agile?

Agile is a way to conduct IT projects

It uses small teams with diverse skills

It is focused on a single mission:– to produce innovative functions

and features, that deliver the best possible value to the customer

It is incremental, user centred,and reflective


Agile Methodologies There are many Agile methodologies

– SCRUM– the Crystal Family– Extreme Programming (XP)– Lean Development– Evolutionary Development Model (EVO)– ...

They evolved out of earlier practices– Spiral Model– Joint Application Development (JAD)– ...

One common thread is that the customer is part of the development team

Agile is about

PeopleProcessesThings


Traditional versus Agile - People hierarchy synergy seniority competence directed autonomous

managers coordinators workers collaborators trained mentored

appraisal reflection

People are trusted:to do the right things,at the right time,in the right way


Traditional versus Agile - Processes plans tactics linear iterative rule based goal based

scheduled time boxed quality assured peer reviewed task based rôle based

In an Agile project,quality is not tested in:it is designed in


Traditional versus Agile - Things requirements needs content context deliverables value documentation communication

critical path priority list baselined evolving reports events

cubes workrooms

Things that do not delivervalue to the customerprobably need not exist


Recapitulation Agile is not a great new invention; it is the

consolidated result of a lot of experience, experiment, thinking, and lessons learned

It succeeds as much because of what it does notdo as because of what it does do

It requires a change in the way people at all levels and with all competencies think about, perform, and guide projects

We shall now move on to the issue of governance


Agile Governance - Issues An Agile project is subject to the same “people

risks” as any other IT project

– teams focus on difficult problems, not important ones– they adopt innovation because it is “cool” even when

inappropriate– they revisit solved problems to effect dubious

improvements that are costly and disruptive– they sometimes fall into technical conflicts

that become personal conflicts– they build what they would like to use,

not what the customer needs to use

Managing these risks is the main purpose of Project Governance


Key People Product Owner

– the person responsible for all delivered value– maintains an up-to-date, prioritised list of customer needs,

expressed as tasks that will deliver tangible value – the Product Backlog

Scrum Master– the mentor and coordinator of an Agile team, but

emphatically not a manager or giver of orders

Skill Owner– everyone else– each team member maintains a

skills inventory: what they can doand how well they can do it


Agile Governance - Techniques Agile governance is needed at three levels

– internal to the team» the responsibility of the Scrum Master

– between team and customer» the responsibility of the Product Owner

– above both developer and customer» the responsibility of higher management

The internal measure of success is simple: how often are issues escalated from one level to another? The fewer, the better


Internal Governance The Scrum Master must ensure

– all development work addresses a specific customer need– the effort expended is proportional to the benefit– the correct skill sets are present in all team members– alternative technical approaches are evaluated using

objective criteria– work done and accepted by the Product Owner

is not redone unless so requested– user feedback from deployed increments

is accepted and acted upon without dispute

Making this happen is perhaps the hardest part of being a Scrum Master – at times you haveto be a demon


Relationship Governance The Product Owner must ensure

– the Voice of the Customer is accurate, comprehensive, and agreed to by all stakeholders

– the Product Backlog is traceable to the VoC at the necessary level of detail

– the Product Backlog is prioritised based on customer need, and this prioritisation is accepted by the team

– deliverables accepted are fielded without delay, and real-world feedback is collected and communicated

– changes that affect the Product Backlog are costed and again prioritised

– any user experience testing is based on user stories or scenarios, and ad-hoc testing is deprecated

The Product Owner is the guardian angel of customer value


Higher Governance Higher Management must ensure

– both Scrum Masters and Product Owners are exercising due diligence at their level of responsibility

– value delivered is measured accurately and honestly– real-world feedback is honest and comprehensive– needed project changes are surfaced and

communicated without delay, from both parties– any breakdown of the lower levels of governance is

addressed by immediate and decisive intervention

The last issue is why Agile must have the whole-hearted and educated support of higher management; it cannot be a “skunkworks” project


How to Become Agile 1. Read the books

2. Read guides such as– http://www.agiledata.org/essays/becomingAgile.html

3. Practice, practice, practice

4. When you are ready, get certified– http://certifications.bcs.org/category/17491

agile governance

Business