agile purchasing
TRANSCRIPT
![Page 1: Agile purchasing](https://reader035.vdocuments.us/reader035/viewer/2022081604/5872b9921a28ab523c8b74dd/html5/thumbnails/1.jpg)
Digital Innovation GroupArla Foods
Medicine for the pain points of purchasing agile
Karoliina Luoto3.9.2013
![Page 2: Agile purchasing](https://reader035.vdocuments.us/reader035/viewer/2022081604/5872b9921a28ab523c8b74dd/html5/thumbnails/2.jpg)
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 forintelligent software development
![Page 3: Agile purchasing](https://reader035.vdocuments.us/reader035/viewer/2022081604/5872b9921a28ab523c8b74dd/html5/thumbnails/3.jpg)
This presentation Pondering agile project management and
leadership Special emphasis on the purchasing techniques
and agreement tools
![Page 4: Agile purchasing](https://reader035.vdocuments.us/reader035/viewer/2022081604/5872b9921a28ab523c8b74dd/html5/thumbnails/4.jpg)
How many of your organizations have used
agile development for web tools?
![Page 5: Agile purchasing](https://reader035.vdocuments.us/reader035/viewer/2022081604/5872b9921a28ab523c8b74dd/html5/thumbnails/5.jpg)
(Really? One set of agility criteria:)1. End users are a constant part of the development process2. The team has power to make decisions3. Requirements strech, the schedule doesn't4. The requirements are described on top level, lightly and visually5. The development work is done in small increments that ca nbe developed further6. Focus on regular delivery of working product parts7. Finishing each requirement before moving to next one8. 80/20 rule: focus on search of 20 % solutions that can fulfill 80 % of the need9. Testing throughout the project – test early, test often10. Collaborative approach from _all_ players in the project
![Page 6: Agile purchasing](https://reader035.vdocuments.us/reader035/viewer/2022081604/5872b9921a28ab523c8b74dd/html5/thumbnails/6.jpg)
6Photo: Boy-piyaphon, Flickr
Beatiful but potentially dangerous
![Page 7: Agile purchasing](https://reader035.vdocuments.us/reader035/viewer/2022081604/5872b9921a28ab523c8b74dd/html5/thumbnails/7.jpg)
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?
![Page 8: Agile purchasing](https://reader035.vdocuments.us/reader035/viewer/2022081604/5872b9921a28ab523c8b74dd/html5/thumbnails/8.jpg)
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 bitc) 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
![Page 9: Agile purchasing](https://reader035.vdocuments.us/reader035/viewer/2022081604/5872b9921a28ab523c8b74dd/html5/thumbnails/9.jpg)
Results3 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.
![Page 10: Agile purchasing](https://reader035.vdocuments.us/reader035/viewer/2022081604/5872b9921a28ab523c8b74dd/html5/thumbnails/10.jpg)
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
![Page 11: Agile purchasing](https://reader035.vdocuments.us/reader035/viewer/2022081604/5872b9921a28ab523c8b74dd/html5/thumbnails/11.jpg)
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
![Page 12: Agile purchasing](https://reader035.vdocuments.us/reader035/viewer/2022081604/5872b9921a28ab523c8b74dd/html5/thumbnails/12.jpg)
The key factors in purchasing agile Buying talent Buying team work Keeping the talent Scalability Budget control Quality assurance Transferrability Support
![Page 13: Agile purchasing](https://reader035.vdocuments.us/reader035/viewer/2022081604/5872b9921a28ab523c8b74dd/html5/thumbnails/13.jpg)
BuyingtalentPhoto: Guilherme Jófili, Flickr
![Page 14: Agile purchasing](https://reader035.vdocuments.us/reader035/viewer/2022081604/5872b9921a28ab523c8b74dd/html5/thumbnails/14.jpg)
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 interviews3. ...or with reference requests from former clients
➢ To allure the best talent to participate, make your project worthwile and advertise it!
![Page 15: Agile purchasing](https://reader035.vdocuments.us/reader035/viewer/2022081604/5872b9921a28ab523c8b74dd/html5/thumbnails/15.jpg)
Buying team work
Photo: scarlatti2004, Flickr
![Page 16: Agile purchasing](https://reader035.vdocuments.us/reader035/viewer/2022081604/5872b9921a28ab523c8b74dd/html5/thumbnails/16.jpg)
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 team2. Description of the supplier support and method
development for team work 3. A small test task as part of the tendering process helps
verifying4. Also psychological tests used in some cases
(would not recommend)
![Page 17: Agile purchasing](https://reader035.vdocuments.us/reader035/viewer/2022081604/5872b9921a28ab523c8b74dd/html5/thumbnails/17.jpg)
Keepingthe talent
Photo: massdistraction, Flickr
![Page 18: Agile purchasing](https://reader035.vdocuments.us/reader035/viewer/2022081604/5872b9921a28ab523c8b74dd/html5/thumbnails/18.jpg)
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 member2. The new person must have at least equivalent experience
compared to the original one3. Verifying know-how with the original process4. Agreed sanction for team member changes, for example 10
person days of free on-board work5. In big projects: two suppliers bringing team members
![Page 19: Agile purchasing](https://reader035.vdocuments.us/reader035/viewer/2022081604/5872b9921a28ab523c8b74dd/html5/thumbnails/19.jpg)
ScalabilityPhoto: Andy Hay, Flickr
![Page 20: Agile purchasing](https://reader035.vdocuments.us/reader035/viewer/2022081604/5872b9921a28ab523c8b74dd/html5/thumbnails/20.jpg)
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
![Page 21: Agile purchasing](https://reader035.vdocuments.us/reader035/viewer/2022081604/5872b9921a28ab523c8b74dd/html5/thumbnails/21.jpg)
Thoughts on the talent/people
management? Spotted problems / extra ideas?
Experiences?
![Page 22: Agile purchasing](https://reader035.vdocuments.us/reader035/viewer/2022081604/5872b9921a28ab523c8b74dd/html5/thumbnails/22.jpg)
Managingthe budget
Photo: 401(K) 2013, Flickr
![Page 23: Agile purchasing](https://reader035.vdocuments.us/reader035/viewer/2022081604/5872b9921a28ab523c8b74dd/html5/thumbnails/23.jpg)
Managing the budget When buying work not outcomes, need for
incentives for maximum effort1. 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
![Page 24: Agile purchasing](https://reader035.vdocuments.us/reader035/viewer/2022081604/5872b9921a28ab523c8b74dd/html5/thumbnails/24.jpg)
Quality assurance
Photo: MTSOfan, Flickr
![Page 25: Agile purchasing](https://reader035.vdocuments.us/reader035/viewer/2022081604/5872b9921a28ab523c8b74dd/html5/thumbnails/25.jpg)
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 debt3. In-house developer as part of the team4. Outside peer evaluation as part of the agreed process5. 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
![Page 26: Agile purchasing](https://reader035.vdocuments.us/reader035/viewer/2022081604/5872b9921a28ab523c8b74dd/html5/thumbnails/26.jpg)
Transferrability
Photo: ibm4381, Flickr
![Page 27: Agile purchasing](https://reader035.vdocuments.us/reader035/viewer/2022081604/5872b9921a28ab523c8b74dd/html5/thumbnails/27.jpg)
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 team3. In the tendering process, ask for a description of
the transferrability process
![Page 28: Agile purchasing](https://reader035.vdocuments.us/reader035/viewer/2022081604/5872b9921a28ab523c8b74dd/html5/thumbnails/28.jpg)
Thoughts on the asset management? Spotted problems / extra ideas?
Experiences?
![Page 29: Agile purchasing](https://reader035.vdocuments.us/reader035/viewer/2022081604/5872b9921a28ab523c8b74dd/html5/thumbnails/29.jpg)
Support
Photo: 4 Cdn Div/4 Div CA – JTFC/FOIC, Flickr
![Page 30: Agile purchasing](https://reader035.vdocuments.us/reader035/viewer/2022081604/5872b9921a28ab523c8b74dd/html5/thumbnails/30.jpg)
Waterfall triangle
SchedulePrice
Scope
![Page 31: Agile purchasing](https://reader035.vdocuments.us/reader035/viewer/2022081604/5872b9921a28ab523c8b74dd/html5/thumbnails/31.jpg)
Agile triangle
RestrictionsQuality
Value
![Page 32: Agile purchasing](https://reader035.vdocuments.us/reader035/viewer/2022081604/5872b9921a28ab523c8b74dd/html5/thumbnails/32.jpg)
Agile Manifesto – bottom values
Individuals and interactions over processes and toolsWorking software over comprehensive documentationCustomer collaboration over contract negotiationResponding to change
over following a plan
![Page 33: Agile purchasing](https://reader035.vdocuments.us/reader035/viewer/2022081604/5872b9921a28ab523c8b74dd/html5/thumbnails/33.jpg)
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
![Page 34: Agile purchasing](https://reader035.vdocuments.us/reader035/viewer/2022081604/5872b9921a28ab523c8b74dd/html5/thumbnails/34.jpg)
What else is there? Must be something more?
(Worst case scenario: individuals - and projects - crushed between
paradigms)