When organizations decide to adopt agile, this is what often happens: You are so keen on your decision to go agile, you may even have top management buy-in, but in the hype of the agile transformation, you forget to consider below 3 factors. This is dangerous because they can in fact cause your agile implementation to fail.

These are the 3 pitfalls you should always avoid:

1. Failing to recognize organizational resistance to the agile transformation
2. Not applying a structured use of agile and taking the “how-difficult-can-it-be” approach
3. Forgetting project management good practice

1. Organizational Resistance:

You will find resistance to change at all levels in the organization. On the team-level, most team members may be convinced of the value of agile, but very often, a few team members do not buy in to the agile concepts:

• They are not comfortable with visualization. They do not like or want to discuss what they are working on, what they have completed, etc.
• They are not keen on sharing information but want to be the indispensable specialists
• Some team members just prefer getting an order. They do not like to be made accountable for their own work and are reluctant to assume responsibility

On the managerial level, there are also obstacles when going agile:

• Some managers are more comfortable with the command and control approach. They lack the confidence that their teams can best decide how to best get from A to B
• Managers do not like to delegate decision power (to Product Owners). They are too busy maintaining their own position and are sub-optimizing on the department level
• They do not know enough about how they can best support agile teams and continue with “business-as-usual”, so the waterfall mindset lives on

2. A Structured Use of Agile:

Project management methods have been available since the sixties, they have expanded ever since, and have become quite complex. Therefore, it is tempting to look to agile methods because they look so simple – at least on the surface. When making the agile choice, organizations tend to forget project management good practice and to set some ground rules about how Scrum, or Kanban etc. should be used across the organization.

If your company is born agile, this may not be a problem. Everyone has worked agile from the very start and everyone knows the playing rules. However, most companies have used a traditional PM method such as PMI, PRINCE2, or IPMA, for numerous years. Then, when there is a move towards higher agility, and some or all project teams have started to use Scrum or Kanban, each team does it their way.

One purpose of using a method in the first place is to get a common vocabulary so everyone working on projects have the same understanding of the language used, the way teams should collaborates, how progress is documented, how KPIs are measured, etc.

It is easy to get e.g. a Scrum Master certification, and to understand WHAT should be in place in terms of events, roles, and artifacts, but HOW you do the work is not part of the certification. It’s important to understand that Agile is not intuitive! Therefore, you must describe the HOW, i.e. the way your chosen agile method should be used in your organization.

Furthermore, just as you need to be in control of your traditional project portfolio, the same is just as relevant for the agile portfolio. You usually have a limited amount of money to invest in projects, and therefore, you need to prioritize them – some provide more business value than others. You should keep track of how well your project money is spent, and follow up using the same set of KPIs so you are comparing apples with apples.

3. Forgetting Project Management Good Practice

One single thing that must be emphasized is that the nature of your projects will not change just because you start using agile methods and techniques to control them.

• The vision of the project remains the same
• The project complexity and risks are the same
• The budget is the same
• The team is the same

Many believe that their projects will be easier to do if they use agile methods to control them. This is not correct. Agile does not reduce complexity or remove risks, but there will be transparency, so your problems/impediments/blockers/challenges become visible as soon as they arise and you can act on them immediately.

Most traditional methods cover projects end-to-end, whereas agile methods e.g. Scrum focusses on the development phase, but: What happens from the project idea turns up in the horizon until the development starts? What happens when the development phase is over? How do you hand over to daily operations? What about the end-users? What about benefits realization? None of this is covered in e.g. Scrum, but should be, so why not make good use of relevant elements from traditional good practice?

I am suggesting keeping an open mind to different methods and avoiding dogmatic thinking. We are probably all working on projects because we enjoy it. We love the challenge, we like working in teams, and it gives us a kick when we succeed.

From the business perspective, it would most likely increase your project success if you considered the following:

1. If you have a PMO, decide what KPIs you will put in place for your agile projects. If you do not have a PMO, consider the agile KPIs anyway! Also decide how status reporting should take place
2. Train your organization in agile from the bottom to the top. What is the required behavior from top- and mid-level management in support of agile? What is expected from team members in terms of accountability and what responsibilities do the agile teams have? What is expected from Product Owners? It is not enough to train a few Scrum Masters if you want agile to work well
3. Becoming agile requires a cultural change, and since culture eats strategy for breakfast but probably also for lunch and dinner, be clear on what change you would like to see, put some goals in place, measure the results, and act on the findings.

The Agile Journey

Will not happen overnight. Moving from traditional project management to agile is a paradigm shift. From push to pull systems from a control-and-command culture to a trust culture where authority is delegated. This takes time, but a good structure with some control mechanisms will most likely help you get the wanted results quicker.

When starting on the journey be prepared to see an initial decrease in productivity, but trust that this investment will pay off very quickly. Train the organization. When everyone knows what is expected from them, you are more likely to get the results that you want.

Last but not least: even if the results on agile project are better on average than the results on traditional projects, there is still room for improvement. You will most likely get part of the way to increased project success by applying selected good practice from traditional methods to agile and thus combining the two approaches based on the context.

If you want to know more about, how Xvoto can help with a successful agile implementation? Read more (in Danish) or contact us via our website http://www.xvoto.dk.