There are many reasons for this; they do not know agile, they do not understand agile, or they find the looseness of agile disturbing according to Hemini Mehta and Dr Steve Smithson, Senior Lecturer at the London School of Economics.
If the senior management have seen the utilisation of agile, the senior management may have been given an incorrect view of agile by the practitioners. The picture painted by the practitioners can be of chaos.
One of the main problems causing chaos is the lack of planning. Agile advocates planning, in fact it states that there should be a plan. A simple plan of a backlog with estimates in priority against all items is usually sufficient. The misconception is that agile believes in no plan and can add or change requirements at a whim without affecting time, quality or money.
This does not hold true. Agile allows issues to be nipped in the bud, for example, the product owner can view the implementation as it happens, and if they want to change or amend something, then this can be accommodated; however, it is always at a cost. Changes cost time, which in turn costs money.
The product owner can choose whether to change it mid-sprint, so then the sprint is stopped and re-planned, or they can add it to the backlog and reprioritise the change. Both options come at a cost. A very small change, e.g. a background colour may be changed in less than a minute, but usually changes do affect the plan.
In many projects, the role of the product owner is not well executed. The product owner is the responsible person for the project. The product owner is what it says on the title, it is their product, they own it and are responsible for the roadmap of this product. In many cases the role of the real owner is lost in the organisation hierarchy. The product owner in the team is usually a proxy, and not the responsible person.
Agile prescribes that the real responsible person is part of the team, and picking up issues as they appear, rather than having them occasionally popping by to see the product and leaving lots of issues until the end; this is seen as more of a waterfall type model that agile moves away from.
The development team needs to be the cream of the crop. Agile recommends that the team members are the best in their field. This is not unusual, every project wants excellent team members. Most readers would find this obvious.
However, this rarely happens. In some cases, the team members are below par or some do not pull their weight. This slows down development and can become a hindrance not only to the project, but to other team members. The brilliant team members can lose their shine because they are pulling dead weight.
The individual team members are all responsible for the success or failure of the product according to the agile principles. Every member is held to account. In most cases the team members are not made responsible, but a manager is. Although in reality some manager is held responsible, they are not fully responsible in agile.
If the team members are not accountable, they have no stake in the product, and they should do. They should want to feel they contribute to the product and therefore, the organisation, and they should feel passionate about their work. The product should feel like their child. Only when team members feel this way is a good product formed.
Agile recommends that the teams should be co-located, and this should be all of those involved from different areas of the business that help in the creation of the product. The idea is that when all the right people are sitting and working together the product can be developed quicker.
Questions are answered quicker and everyone has visibility of the product, and therefore everyone involved is on the same page. As stated before, this is an ideal, but there have been many cases of remote working that have also worked very well. The key for this is not so much geographical, but involvement, commitment and transparency.
The team assigned to work on the product are best placed to create innovative products / services / functions to the project. They should be allowed to put suggestions forward, and have them viewed by management. In order to keep the team motivated, the management should allow some form of innovation driven by the team. This also helps reinforce the team’s responsibility and morale.
All the above elements when not used correctly can create a state of chaos. When senior management see this, they start to probe and conclude that agile does not work. All the above tenets are part of the most basic foundation for agile, and if the foundations are not solid the implementation will suffer; hence causing various problems.
The key is to follow the prescription as well as one can. Practitioners cannot follow a theory 100 per cent; after all it is an ideal and no real life situation keeps to the ideal, but the closer they keep to it, the more they would be working in an agile format.
