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 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

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

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.

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 interviews

3. ...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 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)

Keepingthe talentPhoto: 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 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

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 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

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 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

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 team

3. 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 tools Working software over comprehensive documentation

Customer collaboration over contract negotiation Responding 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)

Thank you!www.codento.com / @codento

Karoliina LuotoKaroliina.luoto@codento.com@totoroki+358 40 765 8504