Background
The term agile programming was coined during a meeting in 2001, by proponents of XP, SCRUM, DSDM, Adaptive Software Development, Crystal, and other programming methods. The result was the Manifesto for Agile Software Development from a group who found common ground in software development and named themselves “The Agile Alliance”. The alliance forms both a body of knowledge and community of practice for Agile Development or Agile Programming.
The manifesto is an elegantly crafted set of values, to which this group of independent thinkers ascribe. The alliance places a higher value on individuals and interactions over processes and tools; on working software over comprehensive documentation; on customer collaboration over contract negotiation; and on responding to change over following a plan. This does not in anyway negate the value of the other items.
During this meeting they also reached an agreement on twelve Agile Principles unpinning the manifesto:
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- Business people and developers must work together daily throughout the project.
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- Working software is the primary measure of progress.
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- Continuous attention to technical excellence and good design enhances agility.
- Simplicity--the art of maximizing the amount of work not done--is essential.
- The best architectures, requirements, and designs emerge from self-organizing teams.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.
During the last four years as part of the agile movement, the discussion on Agile Project Management (APM) has also grown. This discussion has concentrated on the differences between traditional and agile project management methodology and processes, in association with the project development life cycle for software development or product development (Kutschera, 2001).
Introduction
As one who subscribes to an “adapt and adopt” approach, selection of the key elements is important whether looking at project management or development methodologies. One of my recent projects was an organisational change project that also included process and system development. During the course of this very successful project, a highly flexible approach was taken to deal with the situation at hand over the project life cycle, adapting the methodology, changing the approach and styles several times to ensure delivery of the absolute essentials that would ensure customer satisfaction. That is the delivery of the core processes & functionality that passed both internal & external audits, was certified as meeting industry requirements and achieved the nominated critical success factors. Some of the expected, plus additional business benefits were realised within the first two weeks of delivery.
On reflection, during a review of lessons learnt on the project, and subsequent review of the subject, little appears to have been written on leadership of agile projects. This paper summarises my reflections, outlining the favourable conditions that support an agile projects, the leadership styles required for an agile project and areas of focus required by the project leadership team.
From a generic project perspective (not just for software development), I believe that the following are an interpretation of the Agile Manifesto principles that can be applied to any agile project:
- Customer satisfaction;
- Acceptance that requirements change throughout the project;
- Frequent & early delivery of usable deliverables (processes, product or software);
- One team combining business & technical people;
- A supportive and trusting environment;
- Face-to-face communication;
- Sustainable development at a constant pace;
- Simplicity is essential;
- Empowered teams (rather than self organizing teams);
- Adapt to lessons learnt through out the project.
Conditions and Environment
There are a number of conditions that are required to provide a favourable environment and culture under which an agile project approach can succeed. Without any one of the following conditions, the chances of the project being successfully delivered are reduced:
- Organisation embraces or is highly receptive to change;
- A learning environment exists;
- No blame environment exists;
- A partnering approach with suppliers;
- One team inclusive of business, technical and suppliers;
- Flexible and adaptive framework rather than prescriptive methodologies.
Organisation embraces or is highly receptive to change
Agile projects are, by their very nature, ones where the requirements tend to evolve during the term of the project. The project team concentrates the currently known requirements, knowing that change is expected and can be managed. However, other requirements may well evolve and surface during the duration of the project. This means that the scope of the project may need to change; for some it could mean the interpretation of the boundaries for the project scope may alter or it may be that what is required to achieve the scope changes. Planning and preplanning are critical activities, as is change management, so that the project is “planning driven” rather driven by the plan.
The changes can be rapid, and so risks can also be high. This makes for a turbulent environment. Organisations in markets or industries, where changes are prevalent are more likely to support an agile project and have a leadership team that can adapt to the changes and are not risk adverse.
A learning environment
The culture is one where the executive and management are prepared to try new things or to do things differently, while the practitioners consider these new or differences to be a challenge and that no challenge is too hard. The organisation and its people are generally not afraid to make mistakes; in fact personnel are encouraged to learn from their mistakes. However mistakes are not expected to be repeated as the organisation does expect people to learn and that these lessons are shared. Under an agile approach the project team (and organisation) must apply lessons learnt from one activity to the next piece of work or activity.
The culture is one of “thriving on chaos” (Boehm, 2004), though in agile projects it is the leadership ensures that the chaos is not chaotic!
No blame
In an organisation, where learning from one's mistakes is encouraged and part of the culture is to share and apply lessons learnt by others, the organisational leadership is more likely to take a “no blame” approach. That is “we are in this together” and there is no “us and them”. If a mistake was made, who made it is not the issue; rather the organisation will look to the future and ensure it doesn't happen again.
As project teams can involve both internal staff and suppliers, for some the “no blame” approach could be a stretch. Internally the issue is often a result of poor communication between the business people and the technical team, though I have also observed it between two business units where they did not have the same understanding of terminology that they used. External suppliers may be working under a contract or agreement that includes clauses which specifically cover situations where blame may arise. I have observed that these clauses are included as a result of past experience with the other party or from an adversarial contract negotiation.
A partnering approach
Good relationships are extremely important in an agile project. It doesn't matter whether the relationships are internal or between internal and external parties.
A partnering relationship is one in which each party commits to work in an atmosphere of understanding, cooperation and trust to contribute skills and knowledge relevant to the organisation's business strategy. The intention is for each party to recognise and communicate, in advance, their respective inputs, obligations and expectations.
A partnering approach is founded on strong relationships and value realisation that strengthens over time and is based on history, consistency in behaviour and from lessons learnt. Therefore such a relationship is highly conducive to agile projects being successful.
One team
Part of the partnering approach and “no blame” atmosphere is to function as one team. The one team consists of all parties (business, technical and include suppliers) that are preferably co-located, as they need to work closely together with freedom of access to each party. The agility required from a project team on agile projects, relies on the tacit knowledge embodied in the team, rather than writing the knowledge down. This is one reason why an agile approach tends to be light on documentation, and is why co-location is so important.
Agile projects need a CRACK team (Boehm, 2004) that is one which Collaborates with each other, is Representative of business, technology and suppliers, has the Authority to make decisions, and is both Committed to the vision, and Knowledgeable about the requirements or solution.
Flexible and adaptive framework
As organisations seek speed to market or get into areas that are foreign to their workforce, requirements are generally not known or understood to the same degree that may have existed in the past.
Robert K Wysocki (2003) proposes that an “adaptive project framework, which maximises business value by adjusting scope at each stage” should be employed, that allows “planning and executing those parts of the requirements that are clearly known and using those requirements as a stepping stone into a great unknown.”
Only by utilising a framework as a guide, rather than mandating the process, can these projects be both agile in nature and successful. People become more important than process. A light or minimalist approach by experienced project personnel will still ensure the project is kept on track and that the progress is clearly communicated.
Leadership Styles
In an agile project, where change is intrinsic and an adaptive approach is required, is one style of leadership sufficient?
Organisational culture and leadership styles based on behavioural models are often considered together. The Barrera model (Barrera, 2001) describes four types of behaviour: Relater; Socialiser; Thinker; Director. The type of behaviour is dependent on the speed of decision-making and on preference for relationships over tasks.
Exhibit 1. Behavioural leadership model
Within the model of organisational culture types (Elmes, 1998) four leadership styles are described based on the flexibility of decision-making and on information gathering modes.
Exhibit 2. From a model of organisational culture types.
Although these two leadership models have a slightly different basis in terms of behaviours used to identify the leadership styles, they are highly compatible. In the diagrams above I have used the same colour to depict the compatibilities. The other aspect to behaviour based models is that we can see our selves fitting into the different styles at different times, even though one will probably predominate.
Motivational models describe nine leadership styles (Bast, 2004) (Goldberg, 1999). The authors believe that you should focus on the “driving force” to determine your style and that analysis of personal motivation is an excellent means of self-discovery and personal growth. They believe that to focus on behaviours could be very confusing, because you will see yourself in more than one of the quadrants.
Within agile projects, my hypothesis is that you need to adapt your styles of behaviour, and therefore your style of leadership, to best fit the situation facing you at any particular time. You may even find that your style changes during one meeting, depending with whom you are currently interacting. Meanwhile your underlying motivation and driving force is unlikely to change. An inflexible leader with only one approach will be effective in certain situations but is unlikely to rise to the daily or hourly challenges of agile leadership. Therefore, I believe that leadership in agile projects needs to be like a Chameleon. The philosophy and methods remain constant, while an adaptive approach is taken that focuses on the situation and people, and where strong values and consistent behaviours are demonstrated. This can be depicted as a dial (exhibit 3) where leadership styles changes, while the environment and agile framework form the underlying foundations.
Exhibit 3. The Barometer
Leadership focus
Whilst the empowered team concentrates on producing the project's deliverables, the leadership team needs to main their focus on the following:
- The vision;
- Risk mitigation;
- Removing road blocks;
- Communication.
One of the most critical areas of focus for the leadership team is to maintain the vision for the project. An agile project calls for frequent delivery of project outcomes, so the team tends to be concentrating on the activities required to achieve the project deliverables. However as the requirements are also changing, the team could lose sight of the overall project vision. It is up to the project leadership to maintain an enterprise view of the project; its interlocks and dependencies to the business and the scope and requirements that support the vision. They also need to ensure that this is clearly reinforced with the team.
As change is a constant factor throughout the project, risk mitigation is even more important. Risk management is always iterative during the course of a project as risks either become issues or they no longer apply. However, in a project where change is high and requirements are generally not known or understood, there is a greater need to have regular checkpoints. Planning becomes a daily activity, and that includes identification of new risks and reviewing the mitigation strategies.
As risks become issues, it is even more important for the project leadership to remove roadblocks and resolve issues promptly so that the project team can continue to focus on the frequent and early delivery of usable deliverables. Escalation paths need to be clearly identifiable and freely accessible. Any issue that is not dealt with in a timely manner could contribute to the project's lack of success.
It is also important that the project team are kept informed of how the issue was resolved. Open, clear and frequent communication is essential in an agile project. All parties and individuals need to communicate well to ensure that everyone knows what is going on, changes required, progress achieved and decision made. It is up to the leadership team to facilitate communication by whatever means is necessary.
Conclusions
In summary, organisations that subscribe to the generic agile principles that I outlined are more likely to foster the conditions that are favourable for the success of an agile project.
There is no one behavioural or leadership style that will make for success. Rather an adaptive and flexible approach needs to be adopted, so that the most appropriate style is utilised for that situation.
In empowering the project team, the leadership needs to be planning driven and focus on communication especially reinforcing the vision, removing roadblocks and reducing risks.
