When Agile Projects Are Not Agile

AGILE has become a buzz word. This is good and this is bad. It is good, because it proves how successful and useful the concept is. It is bad since it generates pressure on companies or teams to become agile even though they have neither truly understood the concept nor are they ripe for introducing it.

Even though agile project methodologies are implemented in hierarchical organizations, the AGILE concept is inherently hierarchy-less. Hierarchies are considered structures that do not adapt quickly — and slow adaptability is the exact opposite of agile. The very fact that hierarchies are viewed differently often causes a culture clash when hierarchical organizations try to implement agile methodologies.

Non self-explanatory terms

In addition, agile project management comes with a lot of terms that are not self-explanatory: SCRUM, KANBAN, cards, backlog, sprints, tribes, retros, masters, daily syncs, dashboard, epics, stories, story points and many more.

Companies that are inexperienced with the agile project management philosophy superimpose these agile terms on existing structures in order to claim that they are also working agile now. However, as a result they only achieve the opposite: unchanged organizational structures, which are re-branded as agile and that now have a new terminology result only in nobody understanding anything anymore. The old world does not work any longer and the new world does not work either. Instead of becoming more agile companies just have generated more chaos. This is the worst situation that can happen: a good concept is implemented so poorly that it is discredited.

To not let something like this happen or remedy it if it has happened one needs to concentrate on the intentions of agile project management. But what are the intentions of agile project management, what is at its core?

The major achievement

The major achievement of the agile project methodology is that it formulates two important objectives and then constructs an approach that is meant to achieve these two objectives systemically. This means, the agile system is principally setup and organized such that the achievement of the objectives should result automatically. This is very different from traditional approaches that do not take a systemic (and organizational) approach to achieving project success.

The two core objectives

But what are these two core objectives?

1. Total customer focus with the objective to satisfy the customer and to allow for change. Remember this has often not been the case in traditional (waterfall) project management approaches. This is to be achieved by having a defined customer on the one hand and a product owner on the other. Both are in constant exchange. The customer is regularly informed and shown the progress of the project. The project progress is done in many iterations and the product owner invites the customer to bring in changes and reprioritizations.

2. Efficiency of team work. Work is not allocated to team members any longer but it is pulled by team members so that they become task owners. Teams are self-managing themselves because they know best where problems and challenges sit. They hire and fire their own team members and they constantly work on the improvement of the team efficiency: (a) by measuring and visualizing progress, (b) by having an explicit role that has a dedicated focus on team performance and on team efficiency, and (c) by having re-curring meetings (e.g. retrospectives) to discuss and review team improvement possibilities.

The technique to put this organizational and systemic approach into practice is to move away from hierarchies and instead introduce a role based system that uses the idea of ownership. For things that are important there is an owner (for products, for deliverables, for tasks and for team efficiency). This idea is a significant mindshift: from hierarchical responsibilities for activities to individual ownerships for things.

So are you really working AGILE?

Given the two objectives above, it is really easy to tell if a project is truly agile in its core. You must not look for KANBAN boards, or SCRUM masters or sprints and the likes.

Instead you just need to find the customer. If you cannot even find a customer in the first place, the answer is obvious: not agile. If you can find the customer, but the customer is not satisfied, does not see the progress of the project or cannot introduce changes then again you are far away from having an agile project.

Should the customer be satisfied, you can then concentrate on the team. Is the team satisfied? Are they working as a team. Does the product owner exist and prioritize the product features. Do they feel that they are making fast progress and can each of the team members see the progress transparently. Are they working on improving their team efficiency and are they given the infrastructure for that? If you have to answer most questions with »no« then again you probably do not have a truly agile setup.

But the good news is this. AGILE projects work in iterations on their products. The same holds true for their own organization. That means agile team management can also improve over time and with each cycle. It is absolutely no problem to start with a project organization that is slowly and steadily becoming more agile over time. And with these iteration you will probably see that all of the above terms will also be introduced step by step.