Project Management

Topics on Project Management

Agile project management in the public sector

Compatibility of agile methods with project management (PM) in the public sector
The advantage of agile methods - a fast, flexible development, in which customer wishes can be taken into account at any time - is particularly useful for complex projects. This means projects where the business and technical requirements cannot be described completely at the beginning or where changes in requirements are to be expected in the course of the project. Agile methods can also contribute to the acceleration of software development projects under the conditions of public clients and multinational teams.

More…

PM Tools like Customer Product Management (CPM) are and will remain the leading methods for the organizational regulation of demand determination, coverage and use in the public sector. However, a process supplemented by agile methods, in this case Scrum, can support these management tools effectively and efficiently. Especially in the implementation phase, Scrum is thus also suitable for "non-software development projects" to meet the demands for a transparent and more efficient public goods management. In addition to agile methods in PM, the use of agile requirements management is also conceivable within the Integrated Planning Process (IPP).

Advantages of agile methods considering spiral development


The Spiral Model or "Boehm Spiral Model" goes back to two publications by Barry Boehm (Boehm, Barry: A Spiral Model of Software Development and Enhancement) and describes as one of the first process models the so-called iterative-incremental development process of software. It is visualized by a spiral, which, starting from the origin of a rectangular coordinate system in clockwise direction, encloses an ever increasing area. Each revolution corresponds to the passing through of a development cycle in the phases of the waterfall model:
1. Clarification of objectives, survey of requirements, determination of boundary conditions
2. Risk analysis, design, creation of prototypes
3. Implementation, user test
4. Evaluation of the iteration, planning next iteration or stopping the project.
Typical for the spiral model is the strong emphasis on risk analysis, which should prevent a failure of the project at an early stage or stop a hopeless project as soon as possible. This is especially important for long-term projects, as the requirements and conditions can change frequently.
With agile methods such as Scrum and Kanban, in which a large project is broken down into smaller ones and projects run cyclically, errors can be avoided and processes can be made more structured and efficient.
Scrum is used as an agile method (Fig. 2) with the focus on achieving defined results (increments).

Figure 2 Scrum circle
Scrum consists of a few rules, described by:
- Events: Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective
- Artefacts: product backlog, sprint backlog, increment (product to be released)
- Personae: Product Owner, Scrum Master (replaces Project Manager), Scrum Team.
The goal is a fast and resource-saving development of high-quality (digital) products. The Scrum board (Fig. 3) has proven to be a useful tool in the actual project work.

Kanban, originally a method for the flexible control of production processes by visualization, is shown in many application development projects as a Kanban board (Fig. 4), in its simplest form with the categories "To Do", "Doing" and "Done" for the tasks to be performed.
The goal of using Kanban in a team is also here the structuring of tasks through regular meetings, status comparison, avoidance of multitasking and naming of obstacles in order to achieve an effective and efficient utilization of the team.


Limits from the perspective of project management such a procedure
As a basic assumption in software development one assumes that there is never a finished product. There is a continuous development through iterations / versions. The spiral model illustrates this very clearly and Scrum gives project management an adequate method. To successfully apply this method there is the so-called sprint boundary, an impermeable boundary from the outside to the inside; but also from the inside to the outside. It ensures: once the sprint goal is defined, it is not changed by "great new ideas" from outside. Once the sprint is started, the boundaries (sprint backlog, sprint goal) are valid until the time box of this sprint is completed or the sprint is aborted (in rare cases). This is an essential success factor of Scrum, the team can work in a concentrated manner.
These limits also set clear goals. The goals in the sprint backlog and a sprint goal limit the team's room for manoeuvre very exact and with the help of user stories also very clearly! Of course, sprint limits do not mean a limit or limitation of communication, this is rather promoted by working tools like scrum board and Kanban project control centre. The boundaries help to focus on the tasks of the sprint.
As essential and necessary boundaries/interfaces of the method, the lived Definition of Done, Acceptance Criteria and regular Retrospectives are mentioned. These often go further than non-lived specifications and unrealistic targets, which are the practice in some classical plan-driven contexts. So in many respects it is not the boundlessness but the limits that make agile methods like Scrum successful.
This is not only true for Scrum, but also for Kanban, XP, Design Thinking and other agile approaches - be it in the form of agreed processes, time boxes, roles, goals, purpose, etc.

Essentially these limits are:
- easy to understand and clear,
- clear and with comprehensible meaning,
- binding and are lived,
- only regulate what is necessary - no micromanagement, no unnecessary "how" specifications, but specifications for the "what" and a common understanding of the "why”
- and the limits are often developed further together,
to work towards the goal in a concentrated and focused manner.
This is what distinguishes agile methods from the common practice in the classical project management context. There, it is rather specifications that shape the management and define how to work. Specifications regulate the "how" of the service provision. In contrast to agile, where the "what" and the "why" are worked out and drawn as boundaries, while the team determines the "how" itself.
Necessary concrete prerequisites for the application of agile methods in multinational programs
As essential prerequisites for success, the following rules should be agreed upon, in addition to the availability of experts:
- Regular (e.g. weekly/daily) joint work and review meetings,
- Workshop atmosphere, 4-5 hours duration,
- Participants are the experts from the respective fields,
- Control of activities via Scrum methodology and Scrum boards,
- A project room for work and workshops as a "Kanban Control Centre", where essential results as well as Scrum boards are permanently visible and maintained.

Working with agile methods is no guarantee for success. Experience shows that the attitude of team members and managers is of crucial importance.
After all it is not the methods that matter, but the people.

Munich November 2020
Contemporary Management Issues

Less…