Scalable & cost-effective facilitationof professional identity transformationin public employment services

This project has received funding from the European Union’s Seventh Framework Programme for research, technological development and demonstration under grant agreement no. 619619

Agile project management for large-scale research projects – an introduction

Andreas P. Schmidt

http://andreas.schmidt.name

http://employid.eu

www.employid.eu

• Traditional project management methods are based on the assumption that it is best to plan and specify as early as possible and then monitor the execution of the plan and respond to any changes as exceptions

• Consequences• Focus on requirements,

specifications and decisions at an early stage

• Waterfall model

Why agile?

https://commons.wikimedia.org/wiki/File:Waterfall_model.png

www.employid.eu

• “We can’t start developing before we know the requirements.”• In most cases, we don’t know the solution in advance, but our

understanding develops along the way.

• “No, we can’t change it anymore. We’ve already developed and tested it.” – “But this is not what I need…”• Changes are not exceptions, but the normal case: customers

learn along the way, too, and change their minds.

• Results (among others)• Bad design and low customer satisfaction

• Delayed delivery

• Outdated before delivery

Why agile? – The Problems

www.employid.eu

Why Agile: Diverse requirements and innovative technology

We have a diverse target group and multiple perspectives

It‘s an ICT research project

So we‘re at the brinkof anarchy…

http://www.lostgarden.com/2006/04/managing-game-design-risk-part-i.html

www.employid.eu

Agile Project Management for EmployID

Structured Projects

Structured Projects

Agileprojects

Agileprojects

ChaoticprojectsChaoticprojects

The project is a continuous collaborative learning process, which convergesthrough thenegotiation of different perspectivesand ideas.

The project is designed to be open to experimentation and change, but delivers value.

www.employid.eu

• Responsiveness to change (over following a plan)• Envision and explore rather than detailed planning & execution

• Working products (or: products of value)• Rather than paper-ware: specifications, roadmaps, plans, frameworks

• Fail earlier rather than later

• Trustful collaboration with customer over negotiating contracts• Delivering best possible value is a shared interest for all stakeholders

• Individuals & interaction (over processes & tools)• The individual matters!

• Communication and participatory decision making

• Rather than sophisticated tools, reporting structures or hierarchies

Agile values(according to the Agile Manifesto)

www.employid.eu

• Plan for change: changes to the plan are the standard case• But don‘t do away with plans, but rather adapt them in a

controlled way

• Define periods of openness to change, and periods of stability

• Time boxes: Do not adjust the dates of delivery, but the scope of what is delivered at that date• If we believe that things take longer: split them into units

• Plan for delivering units of value• Each time box should deliver an outcome that has a value

(originally for the customer, here for overall project objectives)

Key principles of scrum(as one agile project management approach)

www.employid.eu

• Continuously collect items for a backlog what would be needed or great to have

• At the beginning of each iteration („sprint“):• Prioritize items from the backlog from a delivery perspective

• Team estimates effort needed and commits to a selection of these items („Goals“)

• During the iteration („sprint“):• Team works on its own, adjusts scope (narrow/widen) if needed

• At the end of the iteration:• Review the achievement of the goals

• Reflect on the overall process, team communication etc. (retrospective)

Scrum-based methodology

www.employid.eu

Scrum

www.employid.eu

• Assumption 1: a stable, fixed, and predictable capacity (best: 100%)• Many of us are not exclusively working on the project and have

varying workloads from other activities

• Assumption 2: team members exclusively assigned to a single scrum team and not to multiple at the same time (and that these teams remain stable)• Work organization in research projects and also design-based

research methodologies do not allow

• So… are we bound to be chaotic?

Scrum is a great idea, but we‘re enfants terribles for the Scrum community

www.employid.eu

• Longer iterations („sprints“): • 3 months instead of 2-4 weeks as in usual teams

• Synchronization between scrum teams becomes a prime focus• Iterations define synchronization points

• Collaborative prioritization and planning

• Team composition (and team existence) might change

Scrum for EmployID

www.employid.eu

• Iterations: 3 months (much longer than usual Scrum)• Aug – Oct

• Nov – Jan

• Feb – Apr

• May – Jul

• Multiple scrum teams in parallel• Overlapping membership possible

• Each team‘s iteration has an goal, expressing the expected value, which is linked to an overall project vision• Vision should span more than one scrum iteration

• Synchronization after each iteration• But learning from each other can already happen in between!

Scrum for EmployID

www.employid.eu

• Timeline

• Review before consortium meetings

• Retrospective on project level integrated into PM surveys and first session in consortium meetings

• Prioritization at consortium meeting (as conclusions from results)

• Planning I at consortium meeting (as second part of meeting)

• Planning II as follow-up flashmeeting

Scrum for EmployIDTimeline

www.employid.eu

• Scrum: Product Owner who takes the perspective of the customer and prioritizes• In EmployID: no clear role for that

• Scrum: focused on a single goal: (long-term) customer satisfaction• In EmployID: multiple goals (research, application, technology)

• No clear distinction between customer and provider

• Scrum: Stable teams• In EmployID: good working teams still to be identified

Scrum for EmployID:Our challenges

www.employid.eu

• http://de.slideshare.net/jurgenappelo/the-zen-of-scrum-10

• http://agilemanifesto.org/

Further reading