Professional Documents
Culture Documents
Agile Project Management - A Future Approach To TH
Agile Project Management - A Future Approach To TH
OF PROJECTS?
Aljaž Stare
University of Ljubljana, Faculty of Economics
Kardeljeva ploščad 17, Ljubljana, Slovenia
aljaz.stare@ef.uni-lj.si
Abstract
Like other professions, project management is constantly developing, new techniques are emerging, while newer,
more effective approaches are being established. As an innovative modern approach, agile project management is
most frequently mentioned and many experts argue that it is becoming the project management of the 21st century.
The approach was developed in the field of software development and has delivered a number of novelties and benefits
for the project team and the project client. On the other hand, it highlights some ‘new’ approaches that are not foreign
to ‘traditional’ managers and raises a series of dilemmas about the actual benefits it brings. Even greater dilemmas
arise when we attempt to use the approach for other types of projects. This speculative article summarises the most
significant innovations introduced by the agile approach and critically assesses the possibility of extending the agile
approach to other types of projects.
In this article, we would like to critically assess 2. THE AGILE WAY OF IMPLEMENTING
the possibility of extending the agile approach to PROJECTS
other types of projects, and to point out that we are
not discussing a completely different type of project 2.1 Agility and the agile approach
management, but rather agile methods that build The Oxford Dictionary (www.oxforddictionaries.com)
upon and enhance traditional project management. defines agile as the ability to think and understand
We will show the beneficial innovations brought by quickly (or to move quickly and easily). In the
the agile approach, while pointing out the advan- introduction, we mentioned the argument of one of
tages and disadvantages of the approach in the the authors of the Agile Manifesto that an agile
context of different types of projects. Our purpose approach is based on recognising and applying feed-
is to acquaint managers with the approach, and to back. After considering a variety of sources, we
stimulate professional discussion and research that found that:
will confirm (or disprove) the presented conside- • the term and the concept derive from agile meth-
rations.
ods for developing information systems (the first
In addition, we would also like to highlight the emerged in the 1980s) and are mainly used for IT
inappropriate use of the term ‘agile project man- projects;
agement’. Science defines management as a • methods emphasise the concurrent execution of
process of planning, organising, leading and control- the traditionally successive tasks of a project (a
ling; however, when studying the characteristics of ‘fountain’ instead of a ‘waterfall’), and the con-
the agile approach, it would be difficult to find the stant coordination of participants; in this sense,
type of differences that would justify management agile methods are comparable to concurrent engi-
being called ‘agile‘. We also checked the terms used neering, which also emerged in the 1980s;
in the literature. In 35 articles published in the last
• the essence of the approach involves constant up-
ten years, the highest number of authors (11) write
dating of the execution, and detailed planning of
about agile methods (of programming, of project
smaller cycles (iterations) to implement a project
management), while only five use the term agile
according to the current results, lessons learned,
project management. Otherwise, authors often
new ideas etc.; and
discuss agile software development, an agile ap-
proach, agile projects and teams, and rarely agile • the focus on the user is very important and the
processes, factors, standards and companies. We project team, therefore, usually involves a repre-
also found five books that discuss agile methods, sentative of end users who regularly checks the
although only Wysocki (2009) writes about agile partial results of the project (to ensure greater
project management, while others do not mention suitability of the final product with regard to the
this term: wishes and demands of the users).
• Rothman (2007) mostly uses agile project lifecycle, The method’s essence therefore lies in the fact
and also mentions the agile project, approach, that a project’s objectives (project scope, configu-
development, and agile practices and techniques; ration, and the deadline) are defined in less detail
• Forsberg et al. (2005) mostly talk about agile meth- at the start of the project, and a project execution
ods, processes and practices and agile development; schedule is also prepared roughly – the project is
• Brandon (2006) refers to agile methods, proc- divided into equal iterations with assigned parts of
esses, methods, and agile programming; while the project scope to be created. In the beginning, a
• Thomsett (2002), whose book deals with radical/ team undertakes the most important functions,
extreme project management, mentions agile while leaving the least important ones for the end.
development and process. Less important demands can later be omitted on the
basis of the results of already finished iterations, the
client’s changed wishes/requests, the performers’
proposals, or the changes in the environment. A
detailed specification of the iterations’ products and
by doing it and helping others do it.’ In doing so, the Figure 3: Principles behind the Agile Manifesto
authors stress that individuals and interactions are
more important to "agile software developers" than
processes and tools; that the working software has
the advantage of comprehensive documentation,
that customer collaboration is more beneficial than
contract negotiation, and that responding to change
is better than following a plan. The authors call these
Agile Software Development Values (Figure 2), while
adding: ‘That is, while there is value in the items on
the right, we value the items on the left more’.
stand), or that agile thinking contributes to etc.). However, this is a problem of individuals
technical excellence. In any case, technical rather than the ‘traditional’ approach. On the
excellence also has underpinned the quality of other hand, the idea might not be so irrelevant
work and deliverables in the ‘traditional’ ap- if we refer to studies that have found that a
proach. However, we must point out ‘too high’ team where the leaderwas not officially
quality! Searching for technical perfection can selected at the beginning eventually sponta-
prolong a project and increase the costs. Some neously asserts an ‘informal’ leader who takes
developers have a constant feeling that some- over most of the manager’s duties (leads plan-
thing can be done better, and they may get lost ning meetings, coordinates the work, warns
in a spiral of continuous improvement of their colleagues about delays etc.).
results! An effective team only provides the 12. At regular intervals, the team reflects on how to
client with what it requires: anything supple- become more effective, then tunes and adjusts
mental could be a waste of time and money its behaviour accordingly. This principle, of
unless the client is willing to pay for higher course, cannot be disputed. It should provide
quality. valuable guidance to project teams, and we
10. Simplicity – the art of maximizing the amount believe that teams often need to find the time
of work not done – is essential. This principle to talk about their work and to discuss ideas for
may partly contradict the previous one but with better and more effective approaches, also in
reference to the study of other sources we the context of longer ‘traditional’ projects.
assume that the authors meant simplicity in While reading the principles, we might consider
planning the iteration (how to achieve the that in the background of the principles of the Mani-
objectives of the iteration as efficiently as festo there is some sort of negotiation or bargaining
possible). However, this principle also partly along the lines of: if you give us (infinitely) more
relates to simplifying the customer’s require- time (and you pay us), we can realise all your de-
ments; the project team can propose a simpler mands and desires. Could this represent some sort
solution to the client’s need. Both aspects, of of ‘connivance’ for both the client and the con-
course, are not unknown to ‘traditional’ teams, tractor? In terms of: ‘Come on, let’s do something
but we definitely agree that it makes sense to useful as quickly as possible, then we’ll see what
point out the last two principles as often as we’ll do next’ (this is, of course, written with cons-
possible to provide an adequate (efficient) way iderable exaggeration). For the ‘traditional’ project
of thinking and working of all project stake- manager, this could be a difficult conceptual leap.
holders. However, do we need a manager in such cases?
11. The best architectures, requirements, and de- In addition, it is possible to feel the struggle
signs emerge from self-organising teams. Can between the developers (programmers) and the
we say that the ‘traditional’ project team is not managers (a good example is the eleventh principle).
self-organised, no matter how complex the We note here that up until 18 April 2013 when we
project is, and what level of team we are checked the number of signatories at www.agile
discussing? We suspect that here the authors manifesto.org, the agile manifesto had been sup-
are suggesting that teams do not need a ported by 13,705 individuals and organisations. We
manager as they are able to organise their own assume that the signatories are mainly professionals
work; we assume that we know the background from the IT domain, yet it would also be interesting
of this proposal: a precondition for excellence to know the structure of the supporters, i.e. how
in management is also (or especially) the many were managers and how many programmers.
excellence of leadership, and a problem arises In an interview with Bowles Jackson (2012), Hunt
where the manager is relatively alienated from said: ‘Agile probably has not impacted project
the team (makes his/her own plans regardless management as much as it should have. Primarily,
of the opinion of the team members, instead of the agile movement has impacted development and
coordinating he/she focuses on bureaucracy developers more than management and managers.’
achieve the objectives (of the project or of the iter- The start (and time) of exploiting the deliver-
ations)? Or is the planning more exact for a shorter ables strongly weighs in favour of the agile approach.
time frame? Early exploitation ensures the early start of the return
of the invested money (so we can invest the earned
Although we believe that the final product of
money in additional iterations in new projects). If the
an agile project can be higher in quality and better
first project deliverables bring benefits already after
meet the client’s demands and hidden wishes,
one month (and every new iteration delivers
several factors (characteristics and principles of the
additional value and increases monthly income/
agile approach) indicate a less efficient execution –
savings), the client will probably not object to an
the extension of deadlines and increased costs. And
extension of the project and a cost increase (see the
as we have already mentioned, the claim that the
simulation in Figure 4). The advantage of this ap-
product is constantly evolving and upgraded brings
proach is therefore mainly on the revenue side and
us to the conclusion that this endeavour, by
not in terms of effective execution!
definition, is not a project at all! Above all, it would
be interesting to know how frequently the already However, the possibility of using the partial
developed and operating/used parts are corrected deliverables is very limited. In addition, it is only
and amended in the later iterations. possible for IT projects and, moreover, it only applies
to a few types of IT projects. Even if the partial
Why then should a client choose a project team
products can be made use of in the development of
which offers agile software development? We beli-
websites or business information systems, this does
eve two prominent characteristics/principles favour
not apply to development software programs (to be
of such a decision:
sold in large quantities) or to the development of
• the constant possibility of changing the products software for new products or for the automation of
and adding new requirements; and in particular production processes. The latter is mainly because
• intermediate deliverables that can already be only the finalised product/system can be sold, and
used. the software can only operate in conjunction with
Figure 4: Comparison of the costs and benefits of traditional and agile projects
Table 1: Evaluation of the possibility of the agile execution of typical types of projects
Establishing
Applied Building Reengineering,
(Basic) Projecting companies/
development construction reorganisation, Organisation
research (construction, takeovers;
of products/ (without processes of events
studies engineering) other business
services projecting) optimisation
unification
Expected changes
Partial results can be used/exploited √ (√) (6) (√) (7) (√) (8) √ x x