This document discusses purchasing agile development services. It emphasizes the importance of buying talent over outcomes. Key factors in purchasing agile include buying talent, ensuring teamwork, keeping talent over the long term, maintaining scalability, controlling budgets, assuring quality, enabling transferability of assets, and providing support. Talent is the most important asset, so projects should be made worthwhile and advertise to attract the best people. Teamwork is also essential. Budgets require incentives for maximum effort focused on high-value solutions. Quality depends on agreed definitions and processes. Support from organizational leadership is critical for success.

1. Digital Innovation Group
Arla Foods
Medicine for the pain points of
purchasing agile
Karoliina Luoto
3.9.2013

2. Karoliina Luoto + Codento

Presently consultant for
 Business and use cases
oriented digital service
concepting
 Agile project management

Before: product owner,
collaboration strategist,
communications specialist
 Consultancy company for
intelligent software
development

3. This presentation

Pondering agile project management and leadership

Special emphasis on the purchasing techniques and
agreement tools

4. How many of your
organizations have used
agile development
for web tools?

5. (Really? One set of agility criteria:)
1. End users are a constant part of the development process
2. The team has power to make decisions
3. Requirements strech, the schedule doesn't
4. The requirements are described on top level, lightly and visually
5. The development work is done in small increments that ca nbe developed further
6. Focus on regular delivery of working product parts
7. Finishing each requirement before moving to next one
8. 80/20 rule: focus on search of 20 % solutions that can fulfill 80 % of the need
9. Testing throughout the project – test early, test often
10. Collaborative approach from _all_ players in the project

6. 6
Photo: Boy-piyaphon, Flickr
Beatiful but
potentially
dangerous

7. The possible dangers of waterfall

Waterfall project models (plan – implement – test –
launch) work fine for clear, well-defined targets

When we step ouside this zone, problems easily arise
 Lack of communication
 Development does not focus on the most value-adding
functionality
 Delays due to cascading problems
 Changing requirements / growing understanding
 Time and money gets spent on arguing
 Client avoiding responsibility
 Who can know and communicate the business needs if not you?

8. Agility test (borrowed from Perttu Tolvanen)

1. How known is the project objective?
a) Blurry b) A bit unstructured c) Quite clear

2. How code-oriented is the project?
a) It's all about new code
b) We are using a product but customizing it a bit
c) We are just taking on out-of-package product and making it work
for us, content is the king

3. Can the project be resourced with a full-time
product owner?
a) No probs, we want to invent in this one
b) It will be a bit painful c) No way

9. Results
3 points for each a) answer, 2 points for each b), 3 points for each
c)
7-9 points: Clearly there is a case for an agile project.
Still, remember to resource and support it well and
ensure that main stakeholders share the agile ideas.
4-6 points: Twilight zone. Do you have enough
resources? Would a clear waterfall still suit you
better?
1-3 points: No question, your case is a clear one. Just
take the vendor's process and launch the project.

10. Agile Principles (for Scrum, Kanban...)

Early and continuous
delivery (couple of weeks)

Valuable software

Welcome changing
requirements, even late

Business people and
developers work together
daily

Build projects around
motivated individuals and
support and trust them

Self-organizing teams
 Face-to-face communication
 Primary measure of progress
working software
 Continuous attention to
technical excellence and good
design
 Simplicity - the art of
maximizing the amount of
work not done
 Team reflects on how to
become more effective and
adjusts its behaviour

11. The basis of purchasing agile

Paradigm of continuous
development and
commitment

Vision and goals from the
client – responsibility

Requiremet prioritizing
most important client duty

Product owner work 20 %
of the team effort

Steering group shares the
values
 Buying work, not outcome
 Agreement termination
main ultimatum tool with
the vendor
 Transparency main risk
management tool
 Code needs to stay with
the client, e.g. in GitHub
 Minimum viable product is
targeted first, elaborated
on customer feedback

12. The key factors in purchasing agile

Buying talent

Buying team work

Keeping the talent

Scalability

Budget control

Quality assurance

Transferrability

Support

13. Buying
talentPhoto: Guilherme Jófili, Flickr

14. Buying talent

Make sure that you get knowhow from specific people,
not from the generic firm

Tools available:
1. In the tendering, ask forrelevant references from the named
team members attending this project
2. Can be verified with interviews
3. ...or with reference requests from former clients
➢
To allure the best talent to participate, make your project
worthwile and advertise it!

15. Buying
team work Photo: scarlatti2004, Flickr

16. Buying team work

The talent does not help much if it doesn't work together

Compare for example:
1. The summed co-work experience days of the team
2. Description of the supplier support and method development
for team work
3. A small test task as part of the tendering process helps
verifying
4. Also psychological tests used in some cases
(would not recommend)

17. Keeping
the talentPhoto: massdistraction, Flickr

18. Keeping the talent

Basic problem: in long projects, people in teams tend to
change

Basic solution: make the project worthwhile

Rules for team member changes
1. Right to say no to a specific substitute member
2. The new person must have at least equivalent experience
compared to the original one
3. Verifying know-how with the original process
4. Agreed sanction for team member changes, for example 10
person days of free on-board work
5. In big projects: two suppliers bringing team members

19. ScalabilityPhoto: Andy Hay, Flickr

20. Scalability

In big projects, work can be divided between two or
more teams
 One backlog is then used to serve meaningful goalsets / sprint
backlogs for several teams
 One supplier can be asked for multiple teams, or
 This can build on multi-supplier basis
 Coherent backlog management key success factor

21. Thoughts on the
talent/people management?
Spotted problems / extra
ideas? Experiences?

22. Managing
the budget
Photo: 401(K) 2013, Flickr

23. Managing the budget

When buying work not outcomes, need for incentives for
maximum effort
1. The product owner can give supplier 5-10 % prize/sanction per
release based on subjective valuation of effort
2. Crucial to aim together at 20 % solutions with 80 % user need
solving
3. 50 % of budget used for the minimum viable product, if not
obtained, missing work with 25 % discount
4. Possibility for the supplier to bring in new talent when
knowledge gaps spotted

24. Quality
assurance
Photo: MTSOfan, Flickr

25. Quality assurance

Means for adding quality in agile project
1. Mutually agreed definition of done (DOD)!
2. Agreed minimum interval for depolying to production, for
example every two sprints, to avoid technical debt
3. In-house developer as part of the team
4. Outside peer evaluation as part of the agreed process
5. Agile guarantee: an agreed sum paid for all the fixes of already
developed but since that broken features or a reduced price for
such fixes

26. Transferrability
Photo: ibm4381, Flickr

27. Transferrability (in case of supplier
change)

Even best co-work ends sometimes

Tools for transferrability:
1. Demand the code where you can see it (for example in
Github)
2. Client in-house developer as part of the team
3. In the tendering process, ask for a description of the
transferrability process

28. Thoughts on the asset
management? Spotted
problems / extra ideas?
Experiences?

29. Support
Photo: 4 Cdn Div/4 Div CA – JTFC/FOIC,
Flickr

30. Waterfall triangle
SchedulePrice
Scope

31. Agile triangle
RestrictionsQuality
Value

32. Agile Manifesto – bottom values
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

33. Support: ?

Since for a lot of organization this is revolutionary, the
macro key success factor is support from the
organization

Tools
 An oath from the steering group members to be able to steer
the vision and leave the day-to-day decicions for the product
owner
 An oath from the steering group members to be able to
prioritize between product constraints
 Release planning in steering group
 Open reviews the official Scrum answer
 Mutual agile coaching for all key stakeholders and steering
group

34. What else is there? Must be
something more?
(Worst case scenario: individuals - and
projects - crushed between paradigms)

35. Thank you!
www.codento.com / @codento
Karoliina Luoto
Karoliina.luoto@codento.com
@totoroki
+358 40 765 8504