Agile Management Components There are several key elements
Agile Management Components
There are several key elements which provide the cornerstone
for APM. It is crucial to stress that these techniques can also be used in
traditional software development to improve project performance. They are the
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 which reflected
the characteristics of the solution on the wall. The characteristics that were
designed, developed, tested and in production were one color, those which were
designed, built, tested but not yet 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 make sure all team members are working well together and that 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 are 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 and accurate.
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, so as to improve their
methods into the next iteration, which entails 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 strength 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 gives the team the opportunity to focus on
one feature at a time. 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 objective is to build the
feature driven components with only a one-way dependency to the core system; consequently,
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.
systems are such that each ant colony follows simple rules and behavior at the
localised level whilst a