Presented by Dr Robert Firth, Senior Member, Software Engineering at NUS-ISS at the ISS Seminar - Agile Software Development: Swift the and Shift on 18 July 2014.

1. Slide 1Copyright © 2014 National University of Singapore ATA/TUS-Agile Governance V1.0
Agile Governance
Robert Firth
robertjf@nus.edu.sg
Copyright © 2014 NUS.
Total slides = 17
Agile has a light side and a dark side

2. Slide 2Copyright © 2014 National University of Singapore ATA/TUS-Agile Governance V1.0
Outline of the Session
 How did Agile happen?
 What are its key ideas?
 What is appropriate Agile governance?

3. Slide 3Copyright © 2014 National University of Singapore ATA/TUS-Agile Governance V1.0
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

4. Slide 4Copyright © 2014 National University of Singapore ATA/TUS-Agile Governance V1.0
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

5. Slide 5Copyright © 2014 National University of Singapore ATA/TUS-Agile Governance V1.0
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
People
Processes
Things

6. Slide 6Copyright © 2014 National University of Singapore ATA/TUS-Agile Governance V1.0
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

7. Slide 7Copyright © 2014 National University of Singapore ATA/TUS-Agile Governance V1.0
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

8. Slide 8Copyright © 2014 National University of Singapore ATA/TUS-Agile Governance V1.0
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 deliver
value to the customer
probably need not exist

9. Slide 9Copyright © 2014 National University of Singapore ATA/TUS-Agile Governance V1.0
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 not
do 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

10. Slide 10Copyright © 2014 National University of Singapore ATA/TUS-Agile Governance V1.0
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

11. Slide 11Copyright © 2014 National University of Singapore ATA/TUS-Agile Governance V1.0
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 do
and how well they can do it

12. Slide 12Copyright © 2014 National University of Singapore ATA/TUS-Agile Governance V1.0
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

13. Slide 13Copyright © 2014 National University of Singapore ATA/TUS-Agile Governance V1.0
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 have
to be a demon

14. Slide 14Copyright © 2014 National University of Singapore ATA/TUS-Agile Governance V1.0
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

15. Slide 15Copyright © 2014 National University of Singapore ATA/TUS-Agile Governance V1.0
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

16. Slide 16Copyright © 2014 National University of Singapore ATA/TUS-Agile Governance V1.0
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

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