Imagine that you as a project manager want to benefit from agile project tools without having to implement an agile culture throughout the organisation. Your team has followed a classic planning approach to date, but you want to work agile and use the best tools available in the agile world. How do you approach and master this challenge?
The conflict between classic and agile
When I coach a project, I like to start with a briefing. In such a briefing I got to know “Martin”. Martin, a project manager for 20 years, told me about a conflict he was facing: The vast majority of Martin’s projects were successful. Not one of them was ever a failure. Although he and his team were not always able to land on the dot for every project, the general conditions were not always easy. Martin has a good education, has always continued his training and knows many project management methods and useful tools. Of course, he came into contact with the agile project world several years ago. He attended various seminars for agile project management and from then on he was enthusiastic about the idea of making projects easier and more flexible. But unfortunately his organisation was exactly the opposite of what he had learned about agile culture. With agile project management he had no chance with his supervisor. When he exchanged information about their agile projects with colleagues from his network, he regularly felt left behind and disadvantaged. Agile work seemed impossible for him in his organisation.
An exciting task! How is it possible to use agile tools in a classic project environment without immediately questioning the entire organisation?
The five best agile tools
Before we look at how you can meet such a challenge, one thing is especially important: Those who have internalised Agile know that it is dangerous to simply slavishly apply this approach like a new method. Behind Agile is a mindset, a way of thinking. Bringing a project organisation established over years to a changed mindset can only succeed step by step with a lengthy change process. Nevertheless, there are ways of not completely doing without all the advantages of agile instruments in a classic project environment. Below you will find a list of tools that can easily be used in operational project management:
1. Definition of Done
For the setup of the project, implementation of the Definition of Done (DoD) is suitable. The Definition of Done extends the acceptance criteria for final results of projects – for example, as with classic project approaches according to PRINCE2 – by a fundamental principle: For everything that is achieved by the project team in terms of important progress, there is a definition of when it will be finished. It is important to develop a common understanding with the team where this principle should be applied. Martin and his team have agreed on the application for work packages with the following criteria: A work package is complete when
- the employee responsible for the acceptance has declared “Fitness for Purpose”,
- a test has confirmed compliance with the acceptance criteria,
- the creator has released the documentation in the project workspace,
- the status was set to “Done” by mutual agreement with the team.
In practice, it has proven to be a good idea to use this DoD as a checklist for each completed work package. If you use a similar checklist, you will find that not every work package is completely finished as defined. A small tool with great benefits.
2. User Stories
For the request phase Martin and I introduced user stories. With the use of user stories, every requirement specification, every catalog of requirements and every specification document can be significantly enriched. Through the given format “As a user, I would like to have the following features to achieve this benefit” you manage to focus customer-side team members on a clear role view and purpose orientation. A small change of perspective with a big effect.
Communication is a major strength of agile projects. Like Martin, you probably know projects where the exchange of information is very difficult. Status reports are seen as an annoying duty and are rarely read. This is where the use of a taskboard comes in handy. With a taskboard, every team member knows at a glance which work packages of the current project phase are being processed and where the project stands at the moment. We recommend a “haptic” version of the taskboard; you only need 2 m² free wall space, some tape for the design of columns and Post-Its in different colours. A simple instrument for easy exchange of information.
4. Daily Standups
One agile tool that can bring about an immediate increase in efficiency is the Daily Standup. Have you ever had to participate in project status meetings lasting several hours without a coordinated agenda or goal-oriented moderation in advance? Such meetings are often characterised by long statements, heated detailed discussions and parallel e-mail-writing colleagues. Anyone who has had such an experience will feel a great willingness to change. Daily standups are 15-minute, daily votes that serve only one purpose: to ensure the ability to work. In the Daily Standup, this is achieved through a defined agenda of 3 points:
- What did I do yesterday (in order to reach our goal)?
- What am I doing today (in order to reach our goal)?
- Who do I need to be able to do my work (in order to reach our goal)?
All discussions, problem discussions or opinions are deliberately excluded and discussed bilaterally elsewhere. In addition to the ability of all team members to work, the Daily Standups lead to a regular, content-related exchange and stimulate communication and cooperation within the team.
In classic projects, there are often lessons learned meetings at the end of the project. These have a serious disadvantage: the experience gained does not lead to an improvement in the next project at the earliest, and certainly not in the current one. A better alternative here is the retrospective known from Scrum. During the coaching with Martin I took over the moderation of the first retrospective and followed a clear agenda. In a 90-minute session we not only created the impetus for greater project efficiency, but also ensured greater motivation for the employees. From then on, Martin planned further retrospectives at the end of each phase and additionally – if a phase lasted longer – at least every six weeks. He took over the moderation of the following retrospectives and as he told me later, he felt like a Scrum Master for the first time.
The implementation of the agile tools
With these five agile instruments you too can improve your project environment. Martin and I didn’t make much fuss about the new approaches when using them. We didn’t even call them “agile”. We simply avoided possible criticism from the organisation. We simply described them as effective project management tools. But how can a comparable introduction of these agile instruments succeed in your company? Martin did not need to be convinced of the importance of agile principles when implementing changes. Nevertheless, there are some things that help to work “subversively agile”:
- Incremental approach
Step-by-step introduction of each new agile tool that you implement in a classic project environment. Start with a very simple execution. If this works, add something else. This way, team members are not confronted with complicated new things, but can familiarise themselves with the new things step by step. In Martin’s case, for example, the taskboard initially had only three columns (Backlog, Doing, Done) and the user stories were initially applied only to functional requirements.
- Iterative approach
The new tools do not have to be designed at the beginning to work perfectly right away. It is even advisable to schedule a few loops and use the experience gained from the application again and again to optimise the tools. And if a tool does not meet with any acceptance and thus offers no benefit, then simply drop it.
- Encourage experimentation
Some of the best solutions come about by chance. Motivate team members to simply try the tools, use them for other purposes or come up with something completely new. For example, this could lead to Daily Standups taking place virtually across multiple locations.
- Short feedback cycles
Actively encourage feedback on the use of the new tools. For example, set up a separate email address for comments and use meetings and conversations to collect feedback time and again. And, of course, you should always take this feedback seriously and always respond to the comments.
At Martin, the project colleagues didn’t even notice that we were gradually using agile tools. That wasn’t crucial either, because it wasn’t about the tools themselves, but about more effective, better collaboration. The project developed new momentum and dynamics that Martin had previously only known from the reports of work colleagues from his network. In his company, this project is now regarded as a positive example of the committed cooperation of a project team. Our “subversively” introduced tools are now happily spreading to other projects. Would you perhaps like to try a similar setting with such a subversive approach?
Oliver Buhr has been managing director of COPARGO GmbH for many years. He has more than 17 years of experience in project management functions and, with his great expertise and enthusiasm, is considered one of the best and most renowned PRINCE2 trainers for medium-sized companies and corporations in the entire German-speaking region. The SmartPM developed by him provides project companies with an ideal framework combining the best classical and agile approaches.