Agile projectmanagement
Launched by the software development department, the agile mindset is already infecting project managers from all over the world across all industries. Projects should all be as “agile” as possible, because agile – everyone knows this – is supposed to be THE key to the development of customer and business value-oriented products. But what is “agile”? What is the philosophy behind it? Is it a new hype, or is it a value-added alternative to classic project management methods? Which agile methods are common? And why should you invest in agile project management, even if you are not an IT professional? These and other exciting questions are the topic of our blog post today.
What is agile project management
Currently there is no uniform definition of “agile project management” in the literature. In the field of software development, agile is often used as a generic term for a new way of thinking with respect to the classical project management approaches. The adjective “agile” emphasizes that the new approaches are much more dynamic and flexible, which allows to react faster and better to changing conditions and requirements. Characteristic for agile processes are an iterative, low-bureaucratic and transparent approach. Agile methods are likely to minimize the error rate within the development period and increase transparency throughout the entire process.
The history of agile project management
The agile way of thinking originally comes from the software development. In the 90s, the IT industry and thus also software development faced changing conditions: Due to the high speed of innovation, product life cycles were drastically shortened, the intensity of competition increased and the demands placed on products were constantly changing. In addition, the way of thinking within the software development also changed: software development was now seen as a creative process that could not be limited by bureaucratic regulations, e.g. regarding duration and effort. The changes forced the software development to rethink. A newer, more flexible, agile approach had to be created. While the mindset has existed since the 1990s, the word “agile” was only brought to life in 2001 with the writing of the “agile manifesto”. This includes guiding rules for the implementation of successful, agile projects and thus illustrates the agile philosophy. The term “agile project management” only came into being over the years, when agile approaches were applied to projects of all kinds.
The Agile Manifesto
The “agile manifesto” is a record of all values and principles that should be applied to any agile project.
The agile manifesto includes the following values:
We open up better ways to develop software by doing it ourselves and helping others do it. Through this activity we have learned to appreciate these values:
1. individuals and interactions more than processes and tools
With agile projects, the focus is clearly on people. Constant, active communication is essential for successful work. Furthermore, each project participant should not be restricted in his actions by strictly defined processes
2. functioning software more than comprehensive documentation
Especially in software development, it is more important for stakeholders to have a working prototype in their hands than comprehensive documentation.
3. cooperation with the customer more than contract negotiation
Instead of time-consuming contract negotiations, work should be started as soon as possible in agile projects. If the customer’s requirements change, they are continuously integrated during the course of the project.
4. reacting to change more than following a plan
Especially in software projects the requirements and wishes of the stakeholders like to change. Therefore, agile projects need to be able to react flexibly and quickly to changing conditions. For this reason, the project result is continuously scrutinized and coordinated with the customer.
This means that although we find the values on the right side important (processes, tools, documentation, contract negotiation, following a plan), we value the values on the left side higher (individuals, working software, cooperation with customers, reacting to changes).
agile principles
The agile values are concretized by the 12 agile principles:
– Customer satisfaction through early and continuous delivery of valuable software
– Agile processes use changes (even in late phase of development) to the competitive advantage of the customer
– Delivery of functioning software in regular, preferably short periods of time (a few weeks or months)
– Almost daily collaboration of experts and developers during the project (e.g.: Collective Code Ownership)
– Providing the environment and support needed by motivated individuals to complete their tasks
– Information transmission, if possible face-to-face in a conversation
– The most important measure of progress is the functionality of the software
– Maintaining an even pace of work between clients, developers and users for sustainable development
– Constant attention to technical excellence and good design
– Simplicity is essential (KISS principle)
– Self-organisation of the teams in planning and implementation
– Self-reflection of the teams on their own behaviour for adaptation with a view to increasing efficiency
Scrum and Kanban – the two best known agile methods
Among the best known methods of agile project management are Kanban and Scrum. With both methods, a backlog is created. It contains a list of product requirements, such as a list of all functions the software is required to have later. Another characteristic of Kanban and Scrum is the pull principle: Each employee may choose his or her own task. This should strengthen the commitment of the employees to the project and motivate them. Both approaches are not only used in software development.
Scrum
Within the frame works three roles are defined for Scrum: The Product Owner, the Scrum Master and the Development Team:
The Product Owner is the interface between the management and the stakeholders. He /She is responsible for the work of the development team and for the final product, which should provide the greatest possible benefit to the customer. Product Owners manage the backlog for this purpose, i.e. they prioritize, sort, question and, if necessary, delete the respective defined requirements. The product owner also organizes the Sprint Review, a meeting to monitor progress. During the sprint review, the product owner informs the development team which backlog entries have been completed, which still need to be addressed, and which sprint goals are no longer relevant. The product owner also decides on the release of prototypes. The product owner is always accountable for all his decisions.
The Scrum Master acts as an interface between the Product Owner and the development team. A Scrum Master always has a guiding, mediating and supporting function, but not a leading one. He is responsible for the Scrum process, which is why he constantly monitors the Product and Sprint Backlog as well as the Burndown Charts and optimizes the project process in case of backlogs. He also moderates so-called Scrum meetings and thus ensures the flow of information between the development team and the product owner.
The development team usually consists of a small group of 5-10 software developers.
The implementation of a Scrum project is done incrementally, in so-called sprints. These usually last two to three weeks. The team is supposed to develop an Increment of Potentially Shippable Functionality, i.e. an even more functional prototype than in the previous sprint. Each sprint begins with a kick-off meeting, the so-called Sprint Planning. In this usually all-day meeting, the product owner presents the highest prioritized requirements of the product backlog. Together the development team and the Scrum Master agree on a so-called Sprint Goal and define which items of the Product Backlog the team will master in the next Sprint.
The decision-making power of the development team should strengthen their commitment to achieving the Sprint Goal. After the requirements have been assigned to the sprint, the team autonomously breaks down all requirements into tasks. The development team always works through all sprints according to the priorities of the product owner. Within a sprint, the predefined tasks may not be changed.
The development team organizes a daily scrum. This is an approx. 15 min. stand-up meeting where all team members discuss what they have achieved since the last daily Scrum, what they want to achieve until the next one and what has hindered them in their work. Usually the Scrum Master and the Product Owner also take part in the meeting.
Often this happens within a Sprint Review. In a Sprint Review, the team presents the functioning system, they have developed during the Sprint, to the Product Owner and all stakeholders. The feedback from the stakeholders and the product owner, in turn, flows into the design of the subsequent sprints.
The Sprint Review is followed by the Sprint Retrospective Meeting. During this usually 3-hour meeting the Scrum Master discusses the completed sprint with the development team. Suggestions for improvement are developed, or measures to reduce the workload of the employees.
Kanban
Similar to Scrum, for Kanban a backlog is created first. The functions or requirements listed in the Backlog are each noted on a Kanban Card and sorted into a so-called Kanban Board. A Kanban Board is like a board that has several statuses, for example “not started”, “in process” and “finished”. The requirements are then moved from state to state along the Kanban Board. However, there is a predefined upper limit of requests that can be worked at parallel. When the employees have finished processing a request, they independently select their new activity from the backlog (pull principle). Compared to the Scrum there are no Sprints by Kanban, meaning no specification of how many tasks that have to be completed within a defined time period.
Further agile project management approaches:
– Extreme Programming (XP)
– Test-Driven Development (TDD)
– The Spotify Model
