I returned a few days ago from the annual PMI conference in Belgium, where I was giving a speech about the pitfalls in project communication. One of my main points was that too many different languages are being spoken in terms of projects in most organization. This is particularly true when it comes to agile projects.
- The project manager and team speaks one language. Probably Scrum or Kanban with all their special concepts and vocabulary
- The PMO speaks another language. One of tradition, where there is usually focus on traditional KPIs – cost, scope, time -, which are not in focus in the agile team
- Yet another language is spoken on the management level, where the focus naturally is on strategy, overall performance, business benefits and such
What only few companies realize is that having a common project vocabulary would result in fewer misunderstandings, and unnecessary iterations, and furthermore, expectations management would be far easier.
So what does that have to do with failure in agile implementations?
Well, more than one should think. Many companies want to go agile because the numbers and hard facts are very convincing. A lot of research has been done e.g. by PMI, where the annual Pulse of the Profession documents higher project success rate in agile organizations.
The key words here are “agile organizations”, because it is not enough to let project teams go agile, if the rest of the organization does not follow suite.
Access to the Management Layer:
Business agility also lies in the ability for the team to get access to business representatives for clarifications, and strategic decisions as and when needed, rather than having the team’s productivity decrease while waiting for the next steering committee meeting.
The Mental Change
Another reason for failure with agile implementations lies in the fact that it is a big mental change to go from traditional to agile project execution. Here are a few reasons:
- Not everybody likes visualization and daily follow-up on progress and productivity
- Agile transparency makes it difficult to hide and easy to determine where things go wrong. It could be due to:
- Organizational disturbances
- Lack of Product Owner competency and time
- Task switching, when team members are allocated to several projects
- Lack of management involvement
- Too many defects due to poor testing procedures
- Lack of team commitment
- Many project organizations find it difficult to leave traditional thinking. They might have managed projects “the old way” for many years, and are reluctant to move to agile
- Many resources may have been spent building the existing method. There is reluctance to take steps that make it look like all these resources are thrown in the waste basket
- Year-long habits are hard to break no matter how bad these habits are
Nothing Comes From Nothing
Yet an important reason for agile failure is the belief that you can get something for nothing. This is usually not possible, and certainly not when transforming your organization to becoming (more) agile.
Agility should never be inherent in project teams only. It should be a mindset that seeps through the whole organization from top to bottom. If the management layer, the PMO, the IT department etc. do not work with the same sense of urgency concerning the business’ projects that is required from the project teams, there will be a disconnect between the strategic and the executing layer. The result being that the benefits from moving to agile will not be realized to their full potential.
Moving to increased agility might be difficult step to take, but let me remind you of the following, very discouraging fact: For many years the project success rate has stabilized around 50%. That is not impressing given the fact that very extensive project methods have been available for more than 50 years. These methods grow and grow, while the success rate remains unchanged. Therefore, I would argue that there is really nothing to lose trying to become more agile.
Why not combine?
In fact, going agile does not have to be all or nothing. There is no good reason why you should not use good practice from both traditional and agile methods. This statement may upset some traditionalists and agilists, but as Kanban by definition respects the systems that exist in the organization, why not use some of the traditional tools, processes etc. from your current methods that really work and combine them with Scrum or Kanban?
Here Are the Simple Reasons for Agile Failure in Short
- Too much silo mentality. No common language concerning projects
- Lack of business involvement in the projects, the business has decided to start and fund. NB! Project performance is reflected directly on the bottom line.
- Mental barriers e.g. regarding visualization
- Difficulty with letting go of old habits and resistance to change
- Lack of education in agile from top to bottom
All this can be fixed. It just requires a conscious decision, preferably top-down, some enthusiasm and a bit of confidence. Agile does work, but it requires a dedicated effort.
If you want to hear more, please contact: annette@xvoto.dk
