Agile Project Management
Tore Dybå
Invited Talk @XP2015
About me…
Academic experience:
Chief Scientist at SINTEF ICT, Software Engineering
Professor at Univ. of Oslo in Software Engineering
Dr. Ing. from NTNU in Software Process Improvement For the period 2001-2012, I was ranked as the top
scholar worldwide in agile software development by the
Journal of Systems and Software (Chuang et al., 2014)
Industrial experience:
Consultant in Norway and Saudi Arabia within Information Systems, Software Engineering, and Telecommunications
Research interests:
Large-Scale Agile and Global Software Development
Empirical and Evidence-Based Software Engineering
Teamwork and Coordination in Software Development
Agile Project Management
Biography and publications:
http://www.mn.uio.no/ifi/english/people/aca/toredy/index.html http://scholar.google.no/citations?user=sA-TGysAAAAJ&hl
http://www.informatik.uni-trier.de/~ley/pers/hd/d/Dyb=aring=:Tore.html
Software Process Improvement &
Knowledge Management
Research areas:
Evidence-Based Software Engineering
Large-Scale Agile Software Development
Global Software Development
Structure of the talk
1.
Introduction
2.
Project management; Traditional and Agile
3.
Principles of Agile Project Management
4.
Agile project management at large
Structure of the talk
1.
Introduction
2.
Project management; Traditional and Agile
3.
Principles of Agile Project Management
4.
Agile project management at large
Sumantra Ghoshal
“Bad
management
theories are
destroying good
management
practices.”
Traditional project management
Largely derives from the
linear structure
and discrete,
mechanical views of the systems engineering and quality
disciplines of the 1950s and 1960s.
Contemporary project management methods (e.g.
PRINCE2) are
standardized, process-driven methods
,
which build on this engineering tradition and that contrast
“In the past the man has been first;
in the future the system must be first”
Traditional Project Management
Agile Principles Agile
Project Management
Agile project management
Agile project management requires a different approach, which is adapted to incremental development and the particular strengths of agile methods.
At its core, agile project management is about managing the impact of
complexity and uncertainty on a project, recognizing:
The need for a dramatically shorter time frame between planning and execution.
That planning an action does not provide all the details of its implementation.
That creativity and learning are necessary to make sense of the environment.
Traditional vs. agile project management
The
traditional approach
provides a structured framework
in which to operate:
The
agile approach
performs the same traditional steps,
but multiple iterations are used:
Initiation Planning Execution Tracking Closing
Initiation Planning
Execution
Tracking Final closing
The iron triangle
Structure of the talk
1.
Introduction
2.
Project management; Traditional and agile
3.
Principles of agile project management
4.
Agile project management at large
Four principles of
Agile project management
The principle of
minimum critical specification
The principle of
autonomous teams
The principle of
redundancy
The principle of
feedback and learning
T. Dybå, T. Dingsøyr, N.B. Moe, “Agile Project Management,” book chapter in G. Ruhe and C. Wohlin (Eds.),
The principle of:
Minimum critical specification
This principle is oriented towards the analysis and understanding of the nature of the overall problems:
Identify what is critical to overall success
Specify no more than what is absolutely essential
Keep the use of rules, standards, and predefined procedures to an
absolute minimum
Focus on the larger system requirements and boundary conditions, leaving as many design decisions as possible to those closest to the work
“In preparing for battle I have
always found that plans are
useless, but planning is
indispensable”
“Plans are nothing; planning is
everything”
“You don’t lead by hitting
people over the head—that’s
assault, not leadership”
The principle of:
Autonomous teams
Autonomous, or self-managing, teams bring decision-making authority to the level of operational problems and uncertainties:
Members of autonomous teams are responsible for managing and monitoring their own processes and executing tasks
They typically share decision authority jointly,
For autonomous teams to thrive, it is necessary to build trust and commitment in the whole organization, avoiding any controls that would impair creativity and spontaneity
Successfully dealing with this principle, we must understand the context surrounding the team
The principle of:
Redundancy
This principle is concerned with the overlap in individuals’ knowledge and skills
Each member of the team should be skilled in more
than one function, making the project more flexible and adaptive With increased redundancy within the team, individuals will find it
easier to share new knowledge
Cross-trained team members increase the project’s functional redundancy and thus the flexibility of the team in dealing with personnel shortages
Redundancy is also critical in turbulent environments where people need to work on tasks assigned by priority rather than the competence of team members
The principle of:
Feedback and learning
Without feedback and learning, agile project management is not possible: The focus on project execution rather than on up-front planning,
leads to an
intertwinement of learning and work, and of
problem specification and solution.
The complexity and unpredictability of software problems are typical of
‘wicked’ problems, which are difficult to define until they are nearly solved.
To deal with this principle, project activities have to be performed in an
Structure of the talk
1.
Introduction
2.
Project management; Traditional and agile
3.
Principles of agile project management
4.
Agile project management at large
Challenges with large-scale systems
How to scale agile methods to
larger, longer projects with
multiple development teams that perhaps
work in different locations and time zones
with separate sub-systems that have to communicate?
Many interaction requirements hinder flexibility and incremental development. Long development time makes is difficult to
maintain coherent teams who know about the system over that period.
It is practically impossible to involve all stakeholders in the development process. It is not possible to focus only on the code of
Coordination and control mechanisms
Complexity and uncertainty Mutual adjustment Direct supervision Standardization of work processes of employee skills of outputs
Perform: Based on the Scandinavian
model of collaboration
Focus on democracy, participation and (partially) autonomous groups.
Management understood as various
functions of the organization, but need not be tied to a particular person.
The leadership role is aimed at facilitating everyone to get the best possible
opportunity to do a good job. Dialog between managers and
employees to consider the design of work
Moltke the Elder – the Agile General
Moltke’s theory of war:
Detailed planning only for a short and
predictable horizon
High-level planning for the wider horizon
Directives expressing intentions
"No plan survives contact with the enemy”
Perform:
Tension between the central management and control, and the need for local autonomy and initiative
Steering and control through:
• Iterations every 3 weeks, with the number of
approved user stories as the main parameter
• Releases 3–4 times each year, to confirm that
the quality was good enough for deployment
Flexibility through:
• Revolving planning on 4 levels:
Project, release, iteration and day
• Autonomous teams related to working
methods, commitments and expertise necessary to perform the tasks
Structure of the talk
1.
Introduction
2.
Project management; Traditional and agile
3.
Principles of agile project management
4.
Agile project management at large
Conclusion
The challenge in managing agile software projects
is to find the balance between upfront planning and learning. Planning provides discipline and a concrete set of activities and
contingencies that can be codified, executed and monitored. Learning permits adapting to unforeseen or chaotic events. The two require different management styles and project
infrastructure.
Projects with low levels of complexity and uncertainty allow more planning, whereas projects with high levels of complexity and uncertainty require a greater emphasis on learning.
Contact me at: [email protected]
