Agile governance towards facilitative project management - article - fortes solutions

-‐ Towards Facilitative Project Management -‐

Source: Managing agile projects (Bert Hedeman)

Towards Facilitative Project Management

The changing role of project managers in agile projects N.B. This article was originally featured in ‘Projectie 08/2014’

Research shows that (project) managers and executives experience a lot less control in projects with an agile approach. After all, the scope of the project is not fixed and the teams are self-‐directing. Nevertheless, it doesn’t have to be that agile leads to less control. When agile is implemented correctly, an organization retains control over money, time, scope and quality. However, the role of the project manager will have to change. Instead of directing, the emphasis will be on facilitating and communicating. Regular measurement of and reporting about the quality of the product and process remains important. This enables organizations to ‘release their projects in a controlled way’ and be confident about the execution of the projects by the self-‐directing teams.

Cultural change

The ‘8th Annual State of Agile Survey’ shows that loss of management control and the lack of up-‐front planning are the main concerns for organizations that work based on an agile philosophy. The survey shows that 30% of the 3,500 respondents find these two concerns as most important. Organizations and (project) managers are primarily used to being directive and determining everything in detail before the execution stage(s). This is often the case with a traditional waterfall approach. This approach gives organizations often more sense of grip and control, but doesn’t always result in the desired final product. During the project a lot of things can change because of external factors which will require adjustments in the final product.

Apparently, organizations struggle to give self-‐directing teams enough space and find it difficult not to determine the final product in advance. In many organizations, projects with an agile approach require a cultural change. Besides, PRINCE2 also does not state that every detail must be covered in the project plan. These are also developed further in the stage plan.

Agile governance

It is therefore a misconception that agile leads to less control. When agile governance is implemented correctly, an organization retains control over money, time, scope and quality. Governance stands among others for management and supervision. Determining expectations, delegating tasks and verifying performance are the key components of governance. In other words, this is the role of a project manager in an agile project. The principles of Atern, one of the most complete agile methodologies, state that it is important to focus on the business needs, continually communicate clearly and ensure visible control.

In agile projects, a prioritized requirements list will be prepared during the Feasibility and Foundation stage and all stakeholder expectations will be determined. Subsequently, the Business Visionary or Senior User has to approve them. The requirements list will be developed further during the Exploration and Engineering stages. The Business Ambassador or Product Owner, in agile projects part of the Solution Development Team, is made responsible for the translation of the business needs to the


needs of the customer. Even though not everything is captured in detail in advance, there is up-‐front alignment about the final product.

Parameters for agile projects

To be able to provide self-‐directing teams enough room to maneuver and still ensure adequate management control for the organization, the project manager has to provide the Project Board with sufficient progress information. By reporting regularly, the project manager ensures that self-‐directing teams can do their job. In addition to reporting on standard parameters such as hours, costs and results, the Scope Churn (the number of changes in the back log), Effort at Risk (item has been built or supplied, but is not in production yet) and the Earned Value (the value of the delivered work) are parameters the project manager could report on. (also see break-‐out section on ‘Agile governance for more grip on agile’ on how to measure agile software projects). Other techniques, such as a Kanban board, burn-‐down chart, release chart, sprint quality and code quality are indicators for the Solutions Development Team. Some project management tools offer this kind of information by default. The information will help the team to get insight in the progress during the sprint and in the quality of the delivered work. It also helps the team to learn and improve themselves in the next sprint. These parameters are less interesting for the Project Board.

From being directive to being facilitative

All agile methodologies emphasize that project managers do not necessarily need to have sufficient knowledge of the actual project contents (this is also the case when using with PRINCE2). Too much knowledge about the project content can even be a risk, because the project manager will then take the place of the Team Manager or Team Member. The emphasis for the project manager in agile projects is more on facilitating and communicating. The project manager is responsible for the progress of the project as a whole and has to shield the team from the rest of the organization, in order to minimize disruptions. In general, self-‐directing teams are capable enough to translate the business needs to a technical solution and associated planning all by themselves. The project manager should pay special attention to ensuring that the right conditions are in place – conditions which enables the team to work as effectively as possible.

Moreover, a team does not simply become self-‐directing. This requires experience and time. This can be achieved by gradually being less strict and directive towards a team. The team has to have the chance and room to learn instead of being criticized or regulated. “Letting go is to fear less and love more” according to a famous quote by Nelson Mandela. The ‘controlled letting go’ is vital to let agile projects succeed. When a team is ‘released’ too fast or too slow, the trust between the Project Team, the Project Manager and the Project Board will be put under pressure. This endangers the success of agile projects.

Conclusion

Using agile governance and the controlled release of the teams, organizations are able to make agile projects a success without losing control over the projects. Just like with every other project methodology, it is important to continually measure the progress of the project and to intervene as soon as one of the parameters is likely to be exceeded. Clear and automated reports for the team and for the executives are crucial. This allows the Project Manager – and the rest of the organization – to hand over the project to the self-‐directing team with confidence.


Agile governance for more grip on agile Research into the quality of software systems shows that ‘applying agile’ often stops at the borders of the Solution Development Team. This triggered Professor Joost Visser of the Software Improvement Group to investigate ways how to increase control over agile software development projects. This research was conducted together with the Radboud University Nijmegen and VU University Amsterdam, and resulted in a new Agile Governance Quality Model.

Measurement and metrics for software and projects

Measuring software serves two purposes:

1. Internal: to give members of the Project Team insight into the progress of their work; this allows for adjusting things within the team and for the individual.

2. External: to give the Project Team the possibilities to show the Project Sponsors the progress and when it will be finished; this allows for adjusting the project.

These are two scenarios that require a different approach and different metrics. It is not desirable to use internal metrics (for the Project Team) without the team’s approval, outside the team. This may result in a team losing trust and the measurements to become less valuable.

It is also important that performing the measurements requires very little effort from the individual Project Members, so they can stay focused on their work as much as possible.

The Agile Governance Quality Model

The Agile Governance Quality Model utilizes pattern every agile or scrum project offers in the form of iterations or sprints. Typically at the end of every sprint, working software is delivered and accepted. At the beginning of a sprint the back log is updated and eventually the built software will be taken in to production.

Using the available information in the sprints, the following characteristics for an agile development process have been defined.


• Scope churn is a measurement of the scope of the project, as it is recorded in the back log. The back log can change because extra work is coming in, and tasks are deleted, modified or rejected by the stakeholders.

• Value is a measurement for the amount of value that has been created for the business, relative to the agreed initial value. By measuring the value it is possible to regularly test whether the business case is still valid.

• Effort at risk is the amount of work and costs, that have already been made, but not yet resulted in a working software product. This also includes the effort to define the requirements. Earlier in the project it is more likely that a requirement will not be implemented. Later in a project, the amount of effort invested in building a requirement will be much higher.

• The sprint quality indicates how well the team executes a planned sprint. When there is a lot of failure or a low effectivity, the team is able to make improvements.

• For measuring the code quality models have been designed based on ISO 25010 for software quality. With this, the performance, reliability, security and maintainability of the software can be measured. With the results, which are expressed on a scale from 1 to 5 stars, the software can be improved these specific areas.

For example, for determining the maintainability of the software, system properties are measured such as the volume (number of lines of code), level of de-‐duplication, the unit size and the unit complexity. The measurements are compared with benchmark figures, where the score is calculated relative to other systems in the benchmark.

From the start of the project, it is important to maintain a consistent and traceable administration in the back log. This means that from the beginning of a project it should be clear what units of work are, thus which functional ‘parts’ the Project Sponsor will recognize. These can be epics, stories or requirements; in practice the terminology often differs. All stories should be unique, even when changes are made such as extensions, separations or further developments at a later stage. Removed and rejected stories should also remain in the back log, so there is a clear picture of the realized scope relative to the initial scope of the project in every stadium. An advantage of working agile is the flexible scope. However, in practice the initial expectations of the stakeholders often remain. Especially if there is a distance between them and the Solution Development Team.

The concepts of scope churn, value and effort at risk are translated in the quality model in 11 metrics, such as the size of the back log, the extent to which stories are added, modified or expired, and the extent to which stories are transformed in working software and the effect on the expected lead time and final scope. Changes of stories can be the content (the functionality changes), but it can also be a change of the priority (a feature has become more important) or estimation (the story takes more time to be developed then originally expected).


Example: project in 7 sprints; optimistically planned, realism sets in

During the course of this example project more and more requirements will expire, for example to meet a deadline. This will decrease the expected value upon completion. The ‘effort at risk’ will also continue to grow because there is virtually no functionality brought to production useful for the production.

A possible course of an agile project in 7 sprints will look like this:

Benefits for the Project Manager

The results of the above model give the Project Manager insight into the trends and behaviour of his agile project. It provides objective perspectives on the shared reality. With these insights it is possible to make better estimations about scope and end date. It enables the Executive and Project Manager to agree about what can be done to increase the chance of success. For instance, they could decide to:

1. Add more people to the project 2. Decrease the scope of the project 3. Monitor the scope in the backlog better 4. Define more realistic milestones

By measuring and monitoring agile projects and their software characteristics, more control over the projects will be realized. This helps avoid undesirable situations in an early stage. During the alignment, the Project Manager will continue to fulfill a crucial role between the Solutions Development Team and the Stakeholders.

The authors

Erik Aalbersberg Niels van der Zwan Fortes Solutions Software Improvement Group

Agile governance towards facilitative project management - article - fortes solutions

Business

Transcript of Agile governance towards facilitative project management - article - fortes solutions