“Great achievement appears to be inadequate, yet its use is never exhausted.
Great fullness appears to be void, yet its use is boundless. Lao Tzu”
8.1 Agile beyond IT
Many Agile initiatives have started in IT and cover projects and programmes where IT plays a significant part. As these are seen to be successful in organizations, some of the principles start to permeate the organization and Agile techniques start to be used in many different areas. At the centre of Agile is the principle of personal accountability, responsibility and empowerment.
Empowered teams can be used for solving any problem or creating innovation. This can change how areas of an organization operate as people start to find ways to improve existing roles, and the results can be very beneficial for the business. Teams are often formed of people from throughout the organization, and this leads to more general collaboration and communication, as well as an understanding of how other areas operate.
8.1.1 Approach
The iterative and incremental elements of Agile can be implemented across sectors of industry. In fact, some may have been used for years without people realizing it was Agile. The idea of delivering change or benefits in small increments obviously makes sense, and I have seen it applied to business teams opening new offices, legal teams, universities, and even on the battlefield to deliver new communication systems.
Agile in practice
Here are two good examples of using Agile approaches for hardware.
The first is in the bespoke jewellery industry. After a jeweller has had initial conversations with a customer, the jeweller produces the first designs on paper. Once the customer is happy with these, the jeweller will create a prototype in wax or similar material for the customer to review. Once the customer has accepted the design, the jeweller crafts the final version using precious materials.
The second is in the film industry. For large, complex sets, initial designs drafted to an architectural accuracy are created, first on paper and then in stiff cardboard. The cardboard model is used for small cameras to navigate. Only when the model has been validated is the actual set created. A similar approach was used in medieval times to plan and build castles.
Iterative feedback is useful both to get a user population’s views and requirements and to help to introduce change. If people are involved early and often, and can contribute, they are more likely to accept changes when they eventually become a reality. An incremental approach ties in well with current thinking on implementing change – it is better to take small steps towards a goal than try to implement everything at once.
Agile in practice
My company was moving all its staff to a new building. At the same time, personal offices were to be abolished, to create an open-space environment.
Firstly, the project team had members from different areas and levels of the organization, ensuring a representative view. Various potential architectural designs were shared with the team and put on general display for people to comment, before the final designs were agreed.
Secondly, mock-ups of new desks and private spaces were set up for people to give feedback. This helped to define the configuration that would work best for the organization, and to allay fears about having no offices.
Thirdly, the move to the new offices was split into increments – those moving early could feed back on their real experience, which made it better for those moving later.
8.1.2 A word of caution
Although Agile can be used in many areas, it is not a silver bullet. In some situations, Agile will add no value and may even disrupt an operation that actually already works well. It is always worthwhile to undertake a feasibility assessment of using Agile to understand not only the benefits but also the risks in the area under consideration.
8.2 Benefits management
Benefits management is as important with Agile initiatives as it is with any other. In fact it is probably more important, since the Agile philosophy is all about delivering value, which can be equated in the broad sense to benefit. Organizations mature in their Agile implementations apply Agile principles to the processes supporting benefits management, and vice versa.
In practice this means taking an approach that will enable benefits to be realized incrementally, underpinned by good processes for measuring them. The Agile planning process will start with defining benefits that can be decomposed and prioritized so they can be realized incrementally, as shown in Figure 8.1.
Various capabilities (the combination of features and organizational process) enable the benefits to be realized. This helps us to understand what features should be delivered when, and hence prioritize which features to create. Planning the realization of benefits helps us to focus and understand which components will give most benefit or contribute to benefits later.
Figure 8.1 Benefits decomposition
© Dynamic Systems Development Method Ltd. Reproduced by kind permission.
Understanding the exact benefit and being able to measure Agile are important. This means that incremental plans for benchmarking and measuring improvement need to be produced in parallel with the feature implementation plans. These will help the Agile implementation and its adoption in organizations, as the results will provide true evidence that the Agile approach is working.
There are many methods of benefits management, and publications are available on the subject (see, for example, Jenner, 2012). It is my intention here to stress its importance rather than go into detail.
8.3 Contract management
The point of a contract is to protect all parties involved in it. The contract defines the expected roles, the remuneration due, and the penalties for failing to complete defined responsibilities. It is a legal document, and will be used if situations break down irreparably.
It is, therefore, understandable that the legal profession likes contracts to be precise, and to define in detail what is expected. Traditionally, contracts are based on requirements defined upfront, and can be full of misunderstandings and errors. Based on this rocky foundation, each party agrees a price and timescale to deliver everything required.
We are then surprised that an atmosphere of stress and mistrust emerges on both sides. The supplier has to protect itself with change control mechanisms. The customer wants to ensure it gets what it needs for the budget agreed. The relationship often becomes strained and is not collaborative – particularly as it emerges that what was said in the requirements is not what was actually meant!
Unfortunately, this approach tends to contradict Agile, which, by definition, expects things to be imprecise, evolving and highly subject to change. So how can we create contracts that will facilitate the Agile way of working? A lot of work is being done in this area, and some legal firms and individuals have produced papers and sample contracts for Agile. The sections that follow give a high-level overview of the approaches being investigated.
8.3.1 A new way of thinking
Many Agile approaches fix time and cost and are flexible about features. This can be a useful approach when we consider Agile contracts. All parties, including the lawyers, should be satisfied that something is guaranteed at a certain time, for a certain amount of money. The ‘something’ needs more definition, however.
Most Agile methods use the concepts of ‘minimum usable subset’ (MUST) or ‘minimum viable product’ (MVP). The customer is guaranteed a solution that will meet their needs, even if it does not have all the features that make it easier to use or add value. These extra features are expected to be delivered, but are not guaranteed.
8.3.2 The estimating conundrum
Although we have changed the parameters, the biggest problem in contracts still exists – how do we know early on how long something will take, particularly when we know little about it? Does this get worse in Agile approaches, where we let the solution emerge, and want to incorporate change?
Some Agile methods allow for inaccuracy of estimates by stating that the effort required to realize the ‘must haves’ should be no more than 60% of the total estimated effort. This allows estimates to be out by a factor of 2. This is a better approach than trying to force all requirements into a fixed time estimate. The contract is then costed based on the worst case. If the ‘must have’ does not take all the time and cost, the items marked as ‘should have’ can be delivered as well, and possibly also those marked as ‘could have’.
In effect, the high-level prioritized requirements list or product backlog becomes part of the contract.
8.3.3 Incremental contracts
Agile contracts can reduce risks for both the supplier and the customer. This can be achieved by a contract based on incremental delivery and/or release points. Both parties only contract for delivery of the next increment. After this, the framework agreement is reviewed and either party has the option to continue or to opt out. Either way, value has already been delivered to the customer organization.
8.3.4 Enough design upfront
The definition of the contract is based on an initial stage. In this stage, enough work is carried out to determine how the project can be separated into increments, and to estimate with a higher level of confidence. The important point is that the requirements are kept at a high level. The detail will emerge during later phases. This is equivalent to the concept of the ‘epic’ in Agile approaches. The level of detail required will enable the item to be estimated with a degree of confidence adequate for the contract (accurate to a factor of 2, as described above).
Initially, there is only a contract for the first stage. This has some advantages as the two parties can get to know each other, and build up a relationship based on trust. Equally, it may become clear that the relationship will not work. This allows both parties to walk away before there has been any major expenditure or development.