With the Government urging organisations to reduce ICT complexity and adopt agile project management methods, many will now start to explore this route to greater agility in their software projects – but achieving this goal is not easy.
Quicker and cheaper
Whilst it is an admirable objective to achieve quicker and cheaper results for projects, this should not be the primary objective for greater agility. The key objective should be for IT teams to be more predictable in their delivery, increasing stakeholder confidence and satisfaction, and delivering against business objectives. Most executives would be happy to just get what they are promised, for a change. Driving for cheaper and faster can also result in a reduction of focus on quality, which will of course be costly in the long-term.
Most governance rule sets were designed to provide stakeholders added confidence in the delivery of their solutions by the project teams. However, how they are interpreted has often led to the governance of projects by the production of documentation. Delivering Agile projects in this kind of environment can be very tough, and unless you can return to the principles of the governance rules, being allowed to demonstrate real value as opposed to false effort-spent, your agile project is unlikely to prosper.
The total cost of ownership for any system has a very large proportion being spent during its operational life, so the ability to run and maintain a system efficiently is a very important outcome for a project. However, there are dangers when supposedly-agile projects don’t produce any documentation or include the needs of the operational stakeholders that the system will not be efficient to maintain and run. By failing to consider the needs of operational stakeholders early in the life of a project, a perceived project success may turn out to be a costly long-term failure.
IKIWISI (I know it when I see it)
A common issue for any project team is that what the customer said they wanted is not necessarily what they later want or indeed need. IKIWISI (I Know It When I See It) is a factor that unless addressed and utilised throughout a project will put any project at risk. Agile projects should provide continuous insight into progress and regular demonstrations to the customer. If this visibility is lost or the customer is not engaged with the project to “see it”, then the opportunity to know if the right solution is being developed will have been lost.
To achieve an early ROI for an agile project, the customer needs to be engaged continually in determining the priorities of the project to ensure that this meets the prioritised needs of the business. Without this prioritisation effort, the project will have to start guessing, and make investments to develop solutions that potentially don’t add significant value to the business.
Value versus Risk and Strategy
Whilst agile projects should always remain focussed on the delivery of maximum value to their customers, there has to be a balance maintained against the need for an overall project strategy and the management of project risk. An agile project that maintains a sole focus on value as the customer sees it, may discover that they have overlooked technical risk and a strategic alignment to the customer’s enterprise environment.
There is a growing market for outsourced test services where rigorous testing practices are applied post-development, but whilst it may seem like a cheaper and more rigorous approach to determining quality, the separation of test activity from the development process will have a more costly effect over time. The agile team needs to have a test element to its activity within every iteration of delivery, maintaining quality, and removing the likelihood of major issue discovery late in the project lifecycle.
Command and Control
The legacy of waterfall and a misguided belief in up-front detailed Gantt charts, may cause some in the project organisation to feel they have lost control of an agile project team. This can be particularly true of the project managers (PMs) who have been used to defining every action of the team to deliver a result. There is a place in the agile organisation for the PMs but it’s not telling people how to do their job, it’s about helping remove obstacles and distractions from the team’s path, and ensuring that the customer remains engaged at all times. The old-school PMs will only create inefficiency, frustration and animosity in an agile project.
Skills and Discipline
A long-held myth is that agile projects are full of “hacker” developers, throwing away all processes of the past and exposing the organisation to great risk. However, the reality is that for an agile project to be successful the team does need skills, experience and discipline to do the “right thing” in a responsible manner. Unfortunately, not all organisations have invested in their people in a way that allows them to work in a successfully agile way.
One of the benefits of agile delivery is the ability to react to the changing needs of the customer. However, where this can go wrong is when the project team never has any stability in what it is trying to achieve at any point in time. Within any project iteration, the team must be able to focus on a stable set of requirements that have been previously prioritised by the customer.
If needs do change, then priorities for the next iteration can reflect these changing needs up until the start of the next iteration. Without this discipline of change management the delivery team can suffer from change fatigue and their productivity will certainly suffer.
In essence a “fragile” project environment is typically when an element of what is done is “agile in name only” and activities are performed without discipline and the appropriate level of rigour. However, when applied correctly an agile approach will deliver results and massively reduce the risk of a poor return on investment.