Agile Management Components
There are several fundamental elements that provide
the cornerstone for APM. It is important to stress that these techniques can
also be used in traditional software development methods to improve project
performance. They are:
control. This is a method using cards in the wall so as to
assist a team in
organizing the work of the project. For example, one
successful Agile project team
placed different color groups of cards that reflected
the features of the solution on the wall. The characteristics that were
designed, developed, tested and in production were one color, the features which
were designed, built, tested but not yet put in production were another one.
The team was able to see immediately where they were with each set of features.
Visual control is a valuable method for all projects, as it ensures that every
member of the team views the project the same way.
2. Co-located high-performing teams. Based on Agile development, all the key team members are
located on the same place, including the end-user. This approach is conducive
to quality of coordination and communication enhancement. However, this may reflect
a significant cultural change as far as IT developers are concerned. In
traditional development methods, the developers more often than not work
independently, and have minimal interaction with the customer till the solution
is entirely developed. Project managers are responsible for building a high
performing team, so it is their duty to ensure everyone is working well
together and that assigned developers can work in such a collaborative way.
3. Test-driven development. In cases when requirements
are difficult to be defined by the customer, Agile teams more often than not use test-driven development. In this
way, the test cases were often developed first, and then the team comes back
into the requirement, which apparently calls for more iteration between
requirements, design, development and test phases.
In any case, Agile teams almost always develop test
plans simultaneously with
time they define requirements; in case a requirement cannot
be tested, then the requirement is not yet fully defined. This can be used also
as a best practice in traditional development to ensure requirements are
complete, accurate and testable.
4. Adaptive control. Instead of setting rigid
instructions for the entire team to follow,
the project manager, who needs to be viewed actually
as a leader, is responsible for establishing such working relationships, which
foster collaboration among team members. Agile team members have to be adaptable
to assimilate lessons learned from previous cycles-iterations, so as to improve
their methods as into the next iteration, which is also a best practice for a project.
5. Collaborative development. APM depends
on cooperation among all team members to
deliver final outcome, assimilate feedback and apply it creatively on the next
iteration. This process of constant feedback and enhancement is the power of
APM. The project manager carries out the initial planning while the business
analyst defines the solution features assigning the
appropriate priority in collaboration with the customer and technology
representatives. Then the Agile project teams collaborate on the design, development,
testing and reworking incrementally. This constant collaboration with the
customer promotes project success.
6. Feature-driven development. This practice
greatly lessens complexity, as it allows the team to focus on one feature at a
time. For instance, one team is working on Feature no 4 and that’s the team’s
only concern. They don’t occupy themselves about Features no 1-3. It is the
business analyst in cooperation with the project manager who ensure the next feature
in the queue is indeed the next priority, taking into account business value
and assessing risk. Usually, components with high risk or key infrastructure
pieces are built first, and then everything else is prioritized assessing
business value. The aim is to build the feature driven components with only a one-way
dependency to the core system; therefore, specialized components are
independent of each other and can be created in any order or even in parallel.
7. Leadership and collaboration rather than command
and control. “The principles of APM are timeless. APM is more closely
related to leadership. It addresses a lot of the steps that facilitate
leadership much more than traditional management,” says Sanjiv Augustine,
Managing Director of the Lean-Agile Consulting Practice at CC Pace Systems in
manager works with the client, the IT management and the core stakeholders to make
sure they know the status of the project. Additionally, the project manager
removes anything may hinder the core Agile teams. The business analyst manages
the business aspect of the project and any benefits may arise and continually
drives the Agile team in the direction of the business need.
8. Move from C (cost) to R (revenue) focus. Features
are given a certain priority based on a value as a criterio, such as sales revenue
or market share. It’s the business analyst’s role to ensure the Agile project
team is not investing extravagant time in the development of the new solution.
If so they will have eroded the business case and the
project cost will exceed the potential gain. While the project manager focuses
on project costs, the business analyst focuses on the TCO (Total Cost of Ownership)
which includes not only the development or acquisition costs new solution
entails, but also the cost of operating the system after deployment.
9. Lessons learned. After each iteration, the
team holds a lessons learned session to define what they proposals for
improvement on the next iteration. As the team learns, it adapts how the members
are working together to continuously improve team performance.
Although many scholars agree that APM methodologies emerged
from software engineering agile frameworks such as eXtreme Programming (XP) and
Scrum in the 1990s (Larman 2004; Boehm, 2006; Cicmil et al, 2006; Fitsilis,
2008; Hoda et al, 2008; Macheridis, 2009), Aguanno (2004) traces their
development to the 1980s when the Japanese automobile manufacturers embraced
them in their product development. He mentions that they were initially known
as light weight methods before the adoption of the term agile to show their impact
on projects experiencing high levels of change. This stance, however, is
somewhat controversial because Aguanno combines both lean and agile. According
to Augustine and Woodcock (2008) APM principles and practices are hinged on the
theory of complex adaptive systems (CAS). This complexity theory is derived
from the’chaos theory’which is defined as the study of how order and patterns arise from
apparently disordered systems (Elliot, 2008). It is more concerned with
understanding how complex behaviour and structures emerge from simple
underlying rules as observed in the flocking of birds and ant colonies
(Augustine et al, 2005; Fernandez and Fernandez, 2009).
APM is based on the twelve principles that were
formulated at the Agile Manifesto Declaration of 2001 given in Appendix 1. Just
like the agile values above it must be noted that some of the principles given
in the original declaration are more inclined towards software development.
Consequently a number of authors give different principles depending on their
point of focus. For example Fitsilis (2008) and Larman (2004) give only five principles
i.e. adopt change, focus efforts on customer value, deliver part of
functionality gradually, collaborate and, and continuous. Whilst Alleman (2005)
gives 10 principles which among other things include simplicity, embrace
change, enabling the next effort ensuring that the team is strengthened through
learning), incremental change, maximising stakeholder value, rapid feedback,
deliver and manage with purpose. It is interesting to note that although these
principles might look different in a way, they are all similar because they
emphasise one and the same thing drawn from the agile manifesto.
However, it must also be noted that some things that
are listed as principles by other authors are listed as practices by others.
For instance Alleman (2005) lists travel light/light touch and manage with
purpose/vision as principles whilst Augustine et al (2005) and Elliot (2008)
take them as practices. Nevertheless the reflection from these principles
suggest that APM is people oriented, customer focused, less bureaucratic,
iterative development focused, delivery driven, and acknowledges change.
Complex adaptive systems are such that each ant colony
follows simple rules and behavior at the localised level whilst a collective