Agile Project Management for Large-Scale Research Projects - An Introduction
2 likes4,838 views
The document discusses the implementation of agile project management in the EmployID project, focusing on its responsiveness to change and collaborative learning processes. It highlights the challenges faced in applying traditional Scrum methodologies in a chaotic research environment with diverse teams and requirements. Key principles include adapting plans for change, delivering units of value, and fostering effective team communication and decision-making.
Agile Project Management for Large-Scale Research Projects - An Introduction
- 1. Scalable & cost-effective facilitation of professional identity transformation in 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
- 2. 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
- 3. 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
- 4. 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 brink of anarchy… http://www.lostgarden.com/2006/04/managing-game-design-risk-part-i.html
- 5. www.employid.eu Agile Project Management for EmployID Structured Projects Structured Projects Agile projects Agile projects Chaotic projects Chaotic projects The project is a continuous collaborative learning process, which converges through the negotiation of different perspectives and ideas. The project is designed to be open to experimentation and change, but delivers value.
- 6. 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)
- 7. 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)
- 8. 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
- 10. 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
- 11. 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
- 12. 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
- 13. 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 EmployID Timeline
- 14. 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