BT

The Pitfalls that You Should Always Avoid when Implementing Agile

| Posted by Annette Vendelbo Follow 0 Followers on Jun 27, 2015. Estimated reading time: 17 minutes |

In this article, I will focus mainly on the role that the management plays in organizations that have decided to adopt agile. I believe that a bottom-up approach to agile adoption cannot release its full potential until there is support from the management layer and the organization. There is a need for managers to understand what it takes from them in terms of agile behavior and support, if they want their agile projects to be truly successful.

My background is project management and my perspective on projects is holistic. I want to deliver cool technical solutions but I also want to make sure that we realize the expected business benefits. I plan my projects according to the context. I.e. how complex is the project, and how risky? How mature is the organization, and what team do I have? Am I working in an agile or non-agile organization? In other words, I do not believe in a one-size-fits-all approach to projects and project management.

I have several PM certifications, but I am also a convinced “agilist”. According to my experience, agile projects are often carried out in organizations that are not fully agile. Therefore, I suggest that there is a higher chance of success if we dare be less dogmatic regarding project methods and start combining good practice from both traditional and agile methods. One initiative I have taken to accommodate this thinking is to start up a new, method independent organization: APMA - Agile Project Management Association.

Why Wait Until Tomorrow when You Can Start Today?

A couple of months ago I was speaking at a conference, and one of the participants made this statement. He was a business manager and said the following: “We want better projects, so the management of our company has decided that everyone will start working agile in January 2015”.

I was puzzled. Very puzzled. Did he honestly believe that the whole company would wake up one Monday morning in January 2015 realizing that now a whole new era would begin, and everyone would leave all their old habits, attitudes and approaches behind and start being agile?

It made me wonder. Several things, actually:

If the decision is already made, why don’t they start their agile journey today?

Do people really think that transforming a business from a traditional approach to an agile approach to projects will happen overnight just like that?

Have they realized that the decision to work agile means that the management will also have to change their ways?

Do they know that doing agile is not the same as being agile?

Making the transformation to becoming an agile business is a significant endeavor that will not happen overnight and just because the top management gives the order. There are too many old habits to be broken, and many agile principles are counter-intuitive when compared to traditional ways of managing projects, people and teams.

Once you have made the decision:

It requires determination

It requires training

It requires a will to change at all levels

The Managers’ Contribution to Successful Agile Implementations

One thing is, however, certain – an agile transformation is only likely to succeed if heavily supported on an ongoing basis by the management. It is also a prerequisite for a robust agile implementation that the management level is acting according to agile principles, and not only the project teams.

This means among other things:

  1. Being available for timely strategic decision making as and when required
  2. Providing the frame for true delegation of operational decision power to the operational level
  3. Accept that errors will happen (and understand that they always did)
  4. Fostering an environment of trust at all levels in the organization

Only 4 points - how difficult can that be?

If (agile) project managers were managing their projects in an environment that lived these 4 points, it would result in a significant leap forward to increased project success. So why not just do it?

Well, mainly because it is not that simple. Organizational culture is a powerful thing that is not easily changed. Adopting agile will impose significant changes to an organization that may have worked according to traditional principles for maybe even 10 – 20 years or more. It may look simple but it is not.

The Price of Becoming Agile

There are many good reasons for wanting to get more agility into organizations. First of all the numbers are very convincing. Check the agile communities or Project Management Institute’s annual “Pulse of the Profession”. Research shows that project success rates are significantly higher in agile projects.

Who would not want that?

However, everything comes with a price.

In this case, the price for a robust agile implementation is a significant change in the behavior concerning projects throughout the organization, and changes in organizational behavior will most likely happen, when managers make the first move and change their own behavior:

  • Managers must accept that supply and demand must be in balance, and they should only start as many projects as the organization is able to handle.
  • Spreading key resources (bottlenecks) over too many projects only makes matters worse. Stop starting and start finishing projects rather than having them drag on due to lack of resources, and stop multitasking. It generates enormous amounts of waste.
  • Make the organization’s priorities clear to everyone. When help is needed on projects from other parts of the organization, is this more important than their “real” job? Has time for project work been allocated so that employees can work on projects without other tasks suffering?
  • Delegate operational decision power to the (agile) project managers, Product Owners, etc. Waiting for decisions generates a lot of wasted time, and the decisions will usually get better when made by the people that are directly involved in the projects on a daily basis.
  • Be ready to make strategic decisions on an “on demand” basis, but understand that it requires a deeper understanding of the project to make the best possible decisions. Do not just scratch the surface, and do not be a Project Sponsor only by name.
  • Understand that nature of projects and project complexity does not change just because they are controlled using agile techniques. Therefore, accept that the project team will most likely make errors, knowing that it is better to make mistakes, correct them, learn from them and progress than making no mistakes and stand still.

Once that is in place, trust will automatically grow in the organization.

Most of the above is about organizational agility and not about what method you use on your projects: Scrum, Kanban, PRINCE2, or PMI etc. You can start this transformation at any time, but there is an investment to be made. The result will be healthier projects and fewer failures, and since projects are such a big part of the work that organizations do, why not gain the benefit sooner by starting today?

The Top 4 Management Contributions to Successful Agile Implementations

As mentioned above, agile transformations are only likely to succeed if heavily supported by the top management, and it is a prerequisite for a robust agile implementation that the management acts according to agile principles themselves.

Here is why the four points mentioned above are all easier said than done.

Point 1 – timely strategic decision making:

Top-level managers often do not see the necessity to involve themselves in projects on an ongoing basis. Yes, they allocate (a lot of) money to projects, and yes, they do get upset, when projects overspend or get delayed, but usually they do not see themselves as more than an escalation point for their Project Managers.

They may be dealing with change requests once damage has occurred, but they do not realize that they could have helped prevent the damage from occurring, by being involved more directly in the projects in which they have decided to invest. By simply being available for “on demand” decision-making.

Some agile methods try to cover this lack of business involvement by having a “Product Owner (PO)” representing the business with all decision power vested in him or her. This role, however, is one that I have never truly seen work as intended. Here are a few reasons:

  1. Because of politics. Not all managers are working according to the same agenda
  2. Because the organization do not trust, that the PO is able to make the right decisions
  3. Because the PO do not understand the purpose and nature of the role
  4. Because the PO has not been educated, coached, or mentored to fulfil the role

The result of lacking will or ability from the management layer to involve themselves in projects, and helping with timely decision-making, is agile projects suffering.

Point 2 - true delegation of operational decision power:

Approximately 50% of all projects fail. That might be the reason for the resistance to delegate decision power to project teams, Project Managers (PMs) or to POs as “their results prove that they are not able to handle that kind of responsibility”.

However, as long as inexperienced, not sufficiently trained PMs are asked to manage projects that are too complex for them to handle, and to manage teams that may be inexperienced or lack the right skill set, it is no wonder that projects fail. Here are a few reasons why managers delegate projects to PMs and project teams that are not ready to assume the responsibility:

  1. Managers do not realize that (IT) projects are complex by nature
  2. The right teams with the right competencies are not available, but they want to start the project
  3. Many believe that as long as you “work agile”, everything will be fine
  4. There is a “how-hard-can-it-be” attitude when it comes to project management

However, complexities on projects usually do not arise from systems but from people, politics, and organizational behaviors. How these complexities should be handled is not explained in any method.

Not understanding the complex nature of projects will not surprisingly lead to poor project results. Much would be achieved if organizations would start having look at:

  • How they allocate their project teams to projects depending on skills vs. project complexity. Often teams are allocated according to their availability and not skills. I.e. “Whoever is on the bench gets on the team”
  • Whether their project method is fit for purpose (it is usually either too complex or lack agile aspects)
  • The way they educate their organization. (Certifications are not enough)

Point 3 - Fostering an environment of trust:

Having seen many projects fail, managers may not trust their PMs, teams, and POs to do things right. Therefore, they insist on having the last say in project matters although managers are usually the ones who are least involved, and therefore cannot make the best decisions. Other than poor decisions, which can be bad enough, this causes waiting time, lost resources, and delays.

Organizations do buy in to agile methods, but they often do not realize what big implications this will have on organizational behavior. If you work in a control-and-command type organization, the shift to agile where trust is a prerequisite, may be too big a leap and will not work.

If on the other hand, organizations really want to realize the benefits of going agile, they must analyze how and where changes are required from top to bottom in the organization on an ongoing basis. Agile comes with a price in terms of behavior. Here are some reasons why this price is not willingly paid:

  1. Managers do not want to move away from systems they may have used for many years
  2. Known false sense of security and poor results feels more comfortable than trying “the unknown”
  3. Company culture and politics may hinder a trusting environment. The transformation is too difficult
  4. Managers just don’t see their role in facilitating the transformation to agile and walking the talk

Point 4 – accept that errors will happen and always have:

Projects are taking organizations to where they have not been before. No matter how thorough you are and how well you plan, you cannot predict the future – particularly not if the future lies years ahead. Therefore, project teams will make mistakes, estimates will be wrong, contracts may be bad, etc.

Furthermore, project teams, are often forced to deliver under conditions regarding scope, cost, or time that everyone knows are too optimistic. Thus, you are planning for disaster from the very start, and to keep your budgets, deadlines etc., you start cutting corners. You cut quality, reduce test activities etc. This will also result in errors. Errors that could have been avoided by setting realistic project goals.

Error-free projects do not exist and never have. With agile techniques, you can avoid many errors from getting out to customers or end-users, but to get to that point, managers must realize that they must:

  1. Support their agile teams by helping the whole organization to become more agile. Understand that education is needed at all levels, that old habits must be changed e.g. regarding meetings, reporting etc.
  2. Stop forcing unrealistic project baselines on their project teams. Reality cannot be changed anyway
  3. Do not expect the impossible. Error-free systems or projects do not exist

The 3 Pitfalls that You Should always Avoid in Agile Implementations

I have mentioned some points about how managers can help agile implementations to succeed. Additionally, there are some very important aspects that are often forgotten when organizations decide to go agile and can cause agile implementations to fail.

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

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, some of the team members do not buy in to the agile concepts:

  • They are not comfortable with visualization. They do not like or want to discuss daily what they are working on, what they have completed, etc.
  • They are not very keen on sharing information but prefer to remain the indispensable specialist
  • Some team members just like to get 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 the teams can be the best to decide how to get from A to B
  • Managers do not like to delegate decision power (to Product Owners) and are too busy maintaining their own position and are sub-optimizing on the department level
  • They do not know enough about how they can 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 in place since the sixties and have expanded ever since, but because agile methods look so simple, organizations tend to forget 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 start and 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.

The very purpose of having 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 enough to get a Scrum Master certification, and to understand WHAT should be in place in terms of events, roles, and artifacts. However, HOW it can be done is not part of the certification. A very important thing to understand is that Agile is not intuitive! Therefore, an effort should be made to describe the way the chosen agile method should be used in the organization, i.e. the HOW.

Furthermore, just as you need to be in control of the traditional project portfolio, the same is just as relevant for the agile portfolio. You usually have a limited amount to invest in your project portfolio, and you still can only do a certain number of projects. Therefore, you need to prioritize and keep track of how your projects are doing, 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 cannot be emphasized enough is that the nature of the project will not change just because you start using agile methods and techniques.

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

Quite a few people 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 risk, but there will be transparency, so your problems/impediments/blockers/challenges become visible as they arise and you and your organization can act on them in a timely manner.

Acting on impediments is one agile way to control and manage risk in agile projects. Risk management is also an integral part of traditional project management, but only one of several knowledge areas that you must master in your projects.

Where most traditional methods cover projects end-to-end, the most widely used agile methods e.g. Scrum focuses on what need to take place in the development phase. 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 that have proven to work?

I am suggesting keeping an open mind to different methods and avoiding dogmatic thinking. At the end of the day, 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 which 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 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

Becoming agile 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, coach, and mentor 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 results on traditional projects, there is still room for improvement. You might get part of the way to increased project success by applying good practices from traditional methods to agile and thus combining the two approaches based on the context. Here are few examples of traditional practices that could be useful to incorporate: Status reporting on agile projects, benefits realization, agile KPIs, stakeholder management, communication in agile projects, contract management etc.

About the Author

Annette Vendelbo has true passion for projects and what makes project management and methods work. She has 25 years’ PM experience and via Xvoto, she delivers project management, PM and agile training, as well as advisory services regarding the implementation of (agile) methods mainly Context-based Project Management®. In 2014 she founded APMA – AgileProject Management Association®. She blogs about Project management in real life. You can find her on Facebook at Xvoto and follow her on twitter: @AnnetteVendelbo.

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Multi-cultural aspects affect culture by David Halonen

Hi, nice article. The notion that culture eats strategy is spot-on. Basically, the culture is a way for the troops to get the execs fired for not delivering!

Given that many teams are now from several continents/countries, agile should be noted as an American approach. These pesky folks don't have the same "command/control" comfort that, say Asians like. Whilst it's important for mgmt to be involved, there are a ton of decisions that need to be resolved w/o their input. Traditional methods give comfort by pushing that responsibility up the chain...

I could be wrong, but agile has significant cultural obstacles that need consideration.

Re: Multi-cultural aspects affect culture by Annette Vendelbo

Hi David,

Thanks for your comments. I strongly agree that culture plays a significant rolle, But having worked in several big global US based IT companies, it is in fact my experience that you also see "command and control" culture coming from America too. I think that company size may play a role as well.

However, I do agree that in some parts of the world, agile will not work very well. Whereas agile is very widespread in the Nordics where we have quite an unhierarchical culture, the same is not the case (yet) in e.g. Eastern Europe and Asia, as you mention. I am of course speaking in averages :-)

Culture is an interesting aspect that I will surely include in any future articles. Thanks again for mentioning it.

what remains the same when you go agile by Jaksa Vuckovic

Hi Annette,

nice article. I like that you're addressing the issue of what will remain the same after switching to agile, that is rarely addressed, however I must disagree on some of those points.
1. The vision of the project will (hopefully) not remain the same, but evolve
2. Requirements complexity will stay the same, but you may choose different (simpler) requirements, code complexity may rise a bit, but risk will certainly diminish which is the crucial point of going agile
3. Ideally agile projects should be time & materials, so talking about budget doesn't make too much sense, productivity may go up or down depending on how productive you used to be and whether you have additive or multiplicative complexity
4. Teams stay the same, roles change
I hope I haven't misunderstood the points you were making.

Cheers,

Jaksa

Re: what remains the same when you go agile by Annette Vendelbo

Thanks for your comment!

I do have some additional information to share regarding the points that you make:

1) The vision of the project should not change. You may of course change the product backlog along the way, as you get wiser, but the vision regarding what you aim to build should remain unchanged.
2) When I mention project complexity, I mean from an overall project perspective: is this the first time you have undertaken such a project? Have you worked with the client/supplier before? Is the team a mature project team? The answer to these questions (and more) will have an effect on the risk Picture.
3) I certainly agree that agile Projects should idealy be time & materials, but living in the European Union, and working under conditions where public organizations must use fixed price projects, yet want to Work agile, you need to find a way around that. But surely, there will more often than not be a budget set aside for each project. I have not yet had the pleasure of working on a project with unlimited budget :-)

I hope this better explains what was behind these 3 points.

Cheers,
Annette

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

4 Discuss
BT