agile purchasing - medicine for painpoints
TRANSCRIPT
Digital Innovation GroupArla Foods
Medicine for the pain points of purchasing agile
Karoliina Luoto3.9.2013
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
This presentation Pondering agile project management and
leadership Special emphasis on the purchasing techniques
and agreement tools
How many of your organizations have used
agile development for web tools?
(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
6Photo: Boy-piyaphon, Flickr
Beatiful but potentially dangerous
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?
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
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.
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
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
The key factors in purchasing agile Buying talent Buying team work Keeping the talent Scalability Budget control Quality assurance Transferrability Support
BuyingtalentPhoto: Guilherme Jófili, Flickr
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!
Buying team work
Photo: scarlatti2004, Flickr
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)
Keepingthe talent
Photo: massdistraction, Flickr
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
ScalabilityPhoto: Andy Hay, Flickr
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
Thoughts on the talent/people
management? Spotted problems / extra ideas?
Experiences?
Managingthe budget
Photo: 401(K) 2013, Flickr
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
Quality assurance
Photo: MTSOfan, Flickr
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
Transferrability
Photo: ibm4381, Flickr
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
Thoughts on the asset management? Spotted problems / extra ideas?
Experiences?
Support
Photo: 4 Cdn Div/4 Div CA – JTFC/FOIC, Flickr
Waterfall triangle
SchedulePrice
Scope
Agile triangle
RestrictionsQuality
Value
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
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
What else is there? Must be something more?
(Worst case scenario: individuals - and projects - crushed between
paradigms)
