Working agile without calling it that

How can a project manager profit from agile project instruments without implementing an agile culture throughout the entire organization? That is my starting question for this blog post. In certain ways, this is also an autobiographical article, because last year, as a project manager, I was faced with precisely this problem. A newly thrown together team needed a classical planning approach for a project but the project manager wanted to work agilely. Read for yourself how you can master such a situation.

The conflict between agile and classical

As in every contract for coaching a project, a first briefing with the project manager “Frank” was lined up. In it, I got to learn a lot about him and the conflict he found himself in:
Frank is the project manager. A very experienced project manager. He has already been working on projects for twenty years. He can be proud of his achievements. No project was a failure. Okay, sometimes he and his team didn’t manage a perfect landing. The frameworks were often not easy. Frank has a solid education. He knows lots of project management methods, has a diverse repertoire and knows many useful tools. A few years ago, agility entered his project world. He tried multiple seminars about agile project management and has since been fascinated with the method of running projects easily and flexibly. So he is convinced of the advantages of agile instruments and approaches. Unfortunately, his organization is exactly the opposite of what he learned about agile culture. With agile management, he doesn’t need to come to his boss. Whenever colleagues from his network report on their agile projects, he feels somehow as if he has been moved to the side. Agile seems to him to roar past him. He would also like to use it in his projects.

An exciting assignment! How to succeed so that the project is successfully lead and at the same time Frank is supported to build agile elements into his project?

Careful: agile is not a method

Before we look at how we can help Frank, this knowledge is important: those who have internalized agility know that it is dangerous to slavishly use this approach like a new method, because there is a mindset behind it, a way of thinking. To bring a project organization with years of experience to a changed mindset requires a change process that could take years. So Frank doesn’t need to entirely give up his classical project environment for the advantages of agile instruments.

The five best agile instruments

At our next meeting, Frank and I developed a list of agile instruments for the operative project level. Ones we can implement without having to bolt the mindset of his colleagues straight away. We identified and introduced the following five tools:

1. Definition of done

For the setup of the project, we selected the implementation of the definition of done. What classical project approaches like PRINCE2 name as an acceptance criteria for the end result of a project is expanded to a foundational principle with the definition of done. There is a definition of when it is finished for everything that the project team achieves as important progress. In the kick-off I explained the sense of the definition of done and the team discussed where its application could be the most useful. We reached an agreement on the fundamental definition finishing of a work packet. The results were:

A work package is finished when:

• The “fitness for purpose” has been explained,
• A test has confirmed its accordance with the acceptance criteria,
• The creator has released the documentation in the project workspace,
• The status is set to “Done” with the agreement of the team.

The team agreed on using this DoD as a checklist for each closed work package and ascertained more than once that a work package was not actually completely finished. Benefit fulfilled!

2. User stories

For the requirements phase, Frank and I introduced user stories. With the application of this concept, each specification and requirement catalog can be seriously enriched. With the three-part formula “I as a user want to have the following features to gain this benefit,” a requirement easily becomes a user story. That way we can clearly focus on customer-side team members, clear roles and an orientated purpose. A small change of perspective with a big effect.

3. Task boards

The third instrument supports communication in the project. Communication is an essential strength of agile projects. Frank showed me how slow and toilsome the exchange of information in his previous projects was. Status reports were seen as a tiresome obligation and paid little attention to. Agile projects jolt communication into action with visualization and transparency. With a simple task board that we set up for the work package of the latest project phase, we were able to make sure that each team member knew where the project currently stood at a glance. I recommended him a simple “tactile” variety of the task board. For that he simply needed 2 m² free wall space, test crepe for designing columns and a few blocks of different colored post-it notes.

Work agilely without calling it that

4. Daily standups

If there is one agile instrument that can bring about an immediate increase in efficiency, it is the daily standup. Before, I could see for myself a three hour project status meeting. In large rounds, all the participants were represented. There was neither an agenda nor a moderator to structure the discussion. The meeting was marked by its long statements and heated discussions of detail. The willingness to change was huge, as we introduced short, daily, 15-minute meetings that only served one purpose: securing the ability to work. That succeeds in the daily standup though a fixed agenda of three points:

• What did I do yesterday?
• What will I do today?
• Who do I need to be able to do my work?

Problem solving, expert discussions and exchanges of opinion are deliberately excluded and discussed in other places bilaterally. As well as an ability to work for all team members, daily standups lead to regular exchanges of content and enliven communication and cooperation in the team.

5. Retrospectives

At the end of the first phase we introduced the final agile tool: the retrospective, from Scrum. The “lessons learned” meeting at the end of classical projects has one obvious disadvantage: the lessons found in the workshop don’t lead to improvements in the current project. At the first retrospective I took over the moderation and followed a clear agenda. In a nine minute session we not only kicked off a higher project efficiency, but also fostered higher employee motivation. Frank then planned a retrospective at the end of each phase, and additionally – if a phase lasted longer – another retrospective at least every six weeks. He could take over the moderation of the following “retros” himself. He proudly explained to me later that he felt like a Scrum master for the first time.

With this set of just five agile instruments, Frank and I revitalized and improved the environment of his project. We didn’t have to make much ado for these new approaches. We didn’t once call them agile. That way we got out of the path of potential critics from the organization. We just showed them effective instruments from project management.

Do it the agile way

Now to the content part. We now come to the type and way of the HOW, so in which form we introduced the instruments. Because I didn’t have to convince Frank of the meaning of the agile principles when implementing changes, we heeded a few things that help to successfully implement this “subversive” approach.

When enriching the classical project environment, we fell back on our knowledge of foundational agile approaches:

Incremental approach

Each new agile instrument that we implement in a classical project environment, we introduce in steps. First a completely simple execution. If this works, we add something else to it. So team colleagues won’t be confronted with complicated new things, but can get to trust the new things step by step. For example, we only had three columns in our task board at the beginning and the user stories were only used as functional requirements.

Working iteratively

The new instruments were not created for us so that they should be perfect from the beginning on. We knew that many loops would be needed for that. We were ready the let experience from the application flow into an optimization. And if an instrument encountered absolutely no acceptance and therefore no benefit, it was stamped out.

Experimenting

Many of the best solutions arise by accident. And so we supported project team members to try things out with the project instruments, to use them for other purposes, or to let something completely new come about. For example, the standups were also used virtually from one to many locations of distributed service teams. Simply because a colleague from our project suggested this in a meeting and tried it out.

Short feedback loops

We supported active feedback on the application of new instruments. We set up a separate email address for comments and we also used meetings and conversations to get feedback about the tools we used. Of course, we also took each piece of feedback seriously and took every comment into account.

It can run like this

Our colleagues didn’t notice that we had breathed a little bit of agility into Frank’s project. That is not the deciding thing. What is important is that we enabled more effective communication with new instruments and facilitated teamwork. So our project developed a swing and dynamic that Frank had never before experienced. In his business this project applies as a positive example of engaged cooperation within a project team. Our “subversively” introduced tools are now being implemented blithely into other projects.

Note

If you want to exchange information with project managers like Frank about this theme and similar ones, if you want to get to know innovative approaches for a new swing in your projects, then the COPARGO community day is the ideal event. This year’s event takes place on April 27th 2017 in Frankfurt. Participants can expect a day full of lectures from renowned speakers with workshops – moderated by experienced project managers and bar camps that participants design themselves with their own themes. COPARGO offers readers of the microTOOL blog a discount of 10% off the entry price. The discount code is mt0304. Information about the community day can be found at http://cday.copargo.de/.