This document summarizes a presentation on using agile project management techniques for purchasing digital services. It discusses key aspects of agile purchasing including buying talent, keeping talent on projects, managing budgets, ensuring quality, enabling transfer of assets if suppliers change, and providing support. The presentation emphasizes that purchasing work instead of outcomes, continuous delivery, transparency, and customer collaboration are important agile principles for purchasing. It also notes challenges like potential "dangers of waterfall" approaches and importance of organizational support for the agile paradigm.
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
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
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!
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)
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
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
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
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
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?
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)
