Agile Project Management. Respond to Changes Quickly.
What means agile project management? How does it work? And is it only recommended for software?
In classical project management, there is a solid, defined scope of the project and the effort and time is adapted to this scope. That means it is preferable to move milestones and change the use of the employees than to adapt one of these requirements that was defined at the beginning. The project plan controls the project.
Agile project management turns this idea upside down: deadlines and effort are fixed. Instead, the scope is changed continuously, because the requirements change over the course of the project. The goal is to achieve the highest business value for the stakeholders.
Where Did Agile Project Management Come from?
Back in the 90s, stiff and inflexible software development processes were not satisfactory – they needed to be more lightweight and flexible. And so, new processes like Scrum were innovated. Despite that, it wasn’t until 2001 that there was a name to bring all the similar development currents together. A few leading minds sat together and specified values and principles with which one could develop software more efficiently, and named this sort of development agile. So originally, the concept of being agile came from software development. From there, over the course of time, the description agile project management was developed, because not just software projects can be controlled and planned agilely.
The Agile Manifesto
The agile manifesto scrutinizes the roles, processes and project plans of the classic method. It also places great importance on intensively including stakeholders throughout the project and regularly delivering results to them. This means that changes are welcome, because only that way can the best results be delivered. Above all, requirements that reflect these constant developments and changes play an essential role here. If you want to manage your projects agilely, follow the values from the 2001 Agile Manifesto:
People and interactions are more important than processes and tools
This value puts everyone involved in the project in the foreground. So that everyone can reach their full potential, the scope should not be limited through processes, as is often the case in classical project management. People and their constant communication advance the project and not the processes or tools that are used.
Working software is more important than extensive documentation
This value explicitly concerns software development. To consider other projects, the value could be changed to “useful project results are more important than extensive documentation”. Agile project management prefers to produce continually functioning results rather than long reports or evaluations. In the end, the stakeholders prefer to have the product in their hands rather than the product documentation.
Cooperating with the customer is more important than contract negotiation
The third value brings the meaning of the stakeholders back to center stage. Instead of engaging in long and expensive contract negotiations with them, the work should be started earlier. Changes of stakeholders will be continually incorporated without having to disrupt the project progression with more negotiations.
Responding to changes is more important than following a plan
No project progression can predict changes to the requirements or to the desires and opinions of the stakeholders and these always result in changes to the scope and goal of the project. Classic project management shows that clearly: there the requirements are defined at the beginning and processed according to the plan. It is preferred to put off milestones rather than to question the defined requirements – and in doing so question the goal. This often results in the delivery of results that the stakeholders are not satisfied with. An agile project reacts to changes and adapts the plan based on them. The original scope of the project can also change through this.
As you can see, the values always contain two sides. Agile project management considers the first side – so the left one – as more important than the right. Working software is, for example, more important than documentation. Of course, the right side can’t move too far into the background: what is the use of functioning software if the user has to keep asking how it works? Or if you can’t even follow your own internal developments? If reports and evaluations about test results are too imprecise to be able to draw conclusions from them? Apart from that, if people are more important that processes and tools, how can you, for example, record the detailed communicated requirements efficiently, prioritize and estimate them, without a tool? It’s all about balance – the left side is always considered first, but it has to be closely followed by the right. That’s how to be agile.
The Agile Principles
The values above mentioned don’t give a practical guideline that you can directly use in your projects. That’s why the Agile Principles have also been defined in 2001. Since agile project management has its origins in software development, these principles focus on this specific field:
- The highest priority is customer satisfaction through early and continual delivery of valuable software.
- Changes are used, even late in the development, as a competitive advantage to the customer.
- Working software is delivered in regular – preferably short – time spans (a few weeks or months).
- Experts in the field and developers communicate every day during the project.
- Those involved in the project get a fair workplace and enough support to be motivated in fulfilling their tasks.
- Information is exchanged face to face when possible.
- The most important measure of progress is the functionality of the software.
- The work tempo is kept up by contractors, developers and users for sustainable development.
- Constant focus on technical excellency and good design increases agility.
- Simplicity is essential.
- Teams organize themselves so as to allow the best system architecture, requirements and designs to arise.
- Teams regularly reflect on their own behaviour to become more efficient.
A Comparison of Classical and Agile Project Management
Classical Project Management
Scope is fixed, time and efforts are variable.
Linear process (Waterfall model). Development from phase to phase.
Process is fixed.
Influence of stakeholders sinks over the project duration.
Requirements are only recorded at the beginning (e.g. in a specifications sheet).
At the end of the project, results are deliverd and evaluated.
Project manager manages and takes responsibility for the whole project.
Communication through long meetings and documents.
Agile Project Management
Time and effort are fixed, scope is variable.
Iterative Process: pass through all phases in an iteration.
Processes are improved progressively.
Influence of the stakeholders is constant in the project.
Requirements are continually recorded (e.g. throuh backlogs).
Results are regularly delivered and evaluated through the project progression.
Teams manage themselves and take responsibility together.
Communication through short daily meetings and less documentation.
How Agile Project Management Works in Practice. Try our Tool for Free.
objectiF RPM enterprise software for increased business agility »
Prominent Agile Processes
You can develop your own agile processes based on the values and princples of agile development. But there are also processes that have already been describe that provide a frame so as to not have to reinvent the wheel. Some examples of agile processes are, amongst others, extreme programming (XP), feature driven development (FDD), Scrum or Kanban. Scrum and Kanban are both agile processes whose use in businesses is still increasing today.
Scrum:
Scrum is one of the most well-known processes for agile project management and is also recommended for project development because it is described generally. In a Scrum project, there roles of development team, Scrum master and product owner are defined. Requirements are kept in the product backlog and constantly changed there. The project is planned in releases and sprints, for which there is a release backlog and a sprint backlog. Partial results are delivered after each sprint. Furthermore, the team meets up every day for daily Scrums, sprint reviews and sprint retrospectives.
Kanban:
Kanban visualizes the workflows with a Kanban board, on which requirements are sorted according to their state. A requirement is recorded on a post it note and travels along the board from state to state. An essential feature is the upper limit of requirements in each state – it can be specified, for example, that only four requirements may be worked on at once. There is no set amount of requirements inside a time frame, like for example in the sprint backlog of a Scrum project. Apart from that, the team independently takes new requirements from the Kanban board as soon as it has free resources.
No matter which agile process you use:
Handling requirements and changes is the focus of agile projects. They are the basis of reaching the goals of the stakeholders.
Agile Techniques
Processes just form the framework for agile project management. To implement a project agilely, use different techniques. They are, amongst others:
- Use Cases (customer requirements)
- Personas (representation of customer perspectives)
- Burn Up Chart (visualized state of the project)
- Cumulative Flow Diagram (detailed visual state of the project – Key Performance Indicator)
- Earned Value Analysis (progress and budget control – Key Performance Indicator)
When Is Agile Project Management Suitable?
Agile project management is suitable for projects where:
- only a vague image of the requirements can be drawn.
- constant changes are exposed and have to be reacted to.
- a complex goal is pursued because the end product is not evident.
- fast results have to be delivered because the market demands it.
When Is Agile Project Management Suitable?
magine you want to approach a new project. For example, you want to develop some new software. You will usually think of the following rough steps straight away to reach your goal:
- Planning
- Conception
- Development
- Test
- Delivery
First, you consider which added value the software should deliver to the users and how that will be achieved – you set up the requirements.
Then draft the architecture and interfaces of the software to then develop the features. As the next step you test if the software fulfils the requirements and deliver a product version as soon as it complies with your wishes. All steps follow each other, you can always close the previous one to start the next one – a dream!
This situation presents a dream in the truest sense of the word, because reality is so often completely different: your customers might tell you, for example, that the software is completely unusable because special features don’t exist. Why didn’t you speak with them more often? And why didn’t this requirement occur to you at the beginning? Because at that point in time, the situation looked completely different and you couldn’t have seen that. That is true, but you could have reacted to it if you had worked agilely.
What Does Agile Project Management Change?
Of course, there are also planning phases in agile project management. But no one sits down right at the beginning and sets up a detailed plan for the whole project – so for example, how many and which work packets need to be completed when. Because being agile means knowing that one can’t say everything from the get-go and canvass according to plan. That’s why agile project management works these development phases in iterative steps, whilst everything is actively communicated with all stakeholders. For example, in the first step you determine the requirements, set them and test them. After that you introduce the results to your contractors, get feedback and plan the next development phase based on that. That way you can iteratively develop the end product that the end user will also be satisfied with because they were included in the development.
Of course, many projects don’t have the previously listed features or maybe your business is still so anchored in classical project management that you can’t and don’t want to completely throw your processes away. Here, a mixture of classical and agile project management is an option – known as hybrid project management.
Live Agile Project Management
To be agile, develop personas and use cases to hold onto the goals and desires of your stakeholders. You work with a number of requirements – according to the project size they can go up to the thousands – and estimate their business value like expenses by allocating them to sprints and releases. And if there are changes, then these can be quickly taken care of so you can deliver the best results for the stakeholders. For key performance indicators you need diagrams like a cumulative flow diagram or an earned value analysis. Apart from that you might cooperate with multiple teams, all of which you need to manage. You need transparency, so that everyone knows exactly which requirements need to be implemented and the state they’re in. These sorts of agile projects can only be managed effectively with a suitable tool.