Projects should become more agile. But in many cases, companies limit themselves only to the introduction of Scrum as a new approach. A few weeks later, one realizes that the surrounding business processes do not match the chosen agile approach. Since most project managers equate agile project management and Scrum, they do not know how to proceed in this situation. The below points probably will help to establish agile project management in large companies regardless of the chosen working method.
| Table of Contents |
Set Up Effective Agile Teams
In agile projects, great value is placed on team-based work. But how do you set up a well-functioning, effective and agile team? How can an agile team optimally support the project and bring the company forward? With the following five steps an effective agile team can be set up:
---
Give a common mission
People work best together if you have a common goal. Agile teams should, therefore, be equipped with a common mission or task. Ideally, the team should take responsibility for the overall result (project outcome or result of work) and act independently within the defined area of responsibility. The mission usually describes a goal state but keeps the way open to get there. Defining this mission also requires a clear distinction from other teams or topics (boundaries).
Get equipped with competence
The team should be equipped with enough skills to accomplish its mission. Ideally, an agile team consists of the employees who can solve the specified task without further support. In addition, the team should have sufficient decision-making authority to make it progress quickly within its area of responsibility.
Build empowering team structure
Important is the separation of roles and people. The roles are usually specified by the working method, for example by Scrum or Kanban. The rollers can be fixed or rolling occupied. The team has to be arranged in order to be able to fill all roles optimally and at all times. Experts recommend cross-functional teams – staffed with employees from different areas: for example, computer science, department, product development or legal department. In addition to the team composition, the size of the team must be chosen carefully. Last but not least, rules of behaviour must be explicitly defined, for example, what is and is not right (escalation path). Many agile teams set up a “team contract” for this.
Create a supportive environment
Project leaders and involved executives should create an environment in which the team can work optimally. Particularly interesting here is the handling of information needs, for example, the reporting to the outside of the interaction with the stakeholders and the steering committee. The working method of the team must be accepted and supported by the line. Requirements for reporting should be agreed in advance.
In addition, the reward or incentive system must be compatible with the workings of the team. It is imperative to ensure that individual target agreements of the team members are congruent with the team goal. To measure success, we recommend agile metrics instead of traditional project-related KPIs.
Coaching and exchange of experience
The application of the chosen working method should ideally be checked by experts. Sometimes the working method brings with it a suitable role. In a newly created team, coaches can help the team grow together and get on with their own responsibility.
Use Agile retrospectives
Many of the project managers express their difficulties with a lesson learned at the end of the project. What good is this round when the actual project is already completed? This knowledge can not change anything anyway and is hardly applicable to future projects because they are carried out under different framework conditions and with other project teams. Such rounds were worthless to me in nine out of ten cases. What if you make a shortened version of it regularly during the project? Let’s say, every fortnight or monthly. The project team could exchange structured information about current problems and challenges. The resulting findings would immediately flow into the project work and act as corrective measures – determined by the employees for the employees. Such rounds are generally referred to as retrospectives. A retrospective is usually past-oriented and gives all those involved the opportunity to reflect on and evaluate the previous course of the project. The retrospective is a structured meeting and can be run by a neutral party or by a rolling moderator from the project team. Some project teams meet at regular intervals anyway and need – at best – no separate appointment.
Project teams with regular retrospectives no longer feel like running blind. Employees appreciate that their opinion and they can work independently. Agile retrospectives are an effective leadership tool, they promote self-organization and can be implemented comparatively with little resources.
Use the potential of agile metrics
Changes in the mindset also bring changes in project control. Instead of traditional project-related metrics (Time, Cost, Quality, Resource), agile metrics are increasingly being used. Why is that important? We all know the effect of observation: we influence what we observe. By selecting and tracking certain parameters we set the incentives for those who work on it. Velocity measures the speed that an agile team achieves during a sprint or iteration. Velocity is specified in story points per sprint/iteration. The average velocity provides a numerical value that is commonly used to predict future completion of tasks (for example, release scheduling). Burndown charts measure project progress. The sprint burndown chart shows the progress within a sprint. The amount of open tasks (y-axis) assigned to the sprint is tracked against time (x-axis). Tasks can be specified in working hours. The release burndown chart transfers the same principle to a release. Due to technical debts, legacy is estimated in a program code, which should be eliminated in the future or in perspective can cause consequential costs. Technical debts usually arise from workarounds or quick & dirty fixes. The Happiness Index measures the influence of negative factors (team turnover, the overruling of team shifts etc.) on the mood and performance of the team. The procedure is very simple: after each retrospective, the team members answer fixed questions about satisfaction and working atmosphere. The numbers are consolidated in an Excel sheet and compared with history.
Conclusion
The use of agile metrics usually does not conflict with traditional enterprise metrics such as revenue or profitability. Indirect relationships are assumed: more agility manifests itself in a better solution development, which in turn improves competitiveness and thus leads to better company figures. Agile metrics are not performance metrics; they only measure success in using agile methods. Build the right understanding of metrics among stakeholders. Ensure the selection and tracking of suitable agile metrics. Do not interfere unwittingly, as long as the metrics are right. Keep the traditional metrics and agile metrics in line.
