Is Agile Everything?
‘How Not to be Agile’ may seem a strange title for the blogs mentioning about how good Agile is!
‘How Not to be Agile’ may seem a strange title for a series of articles about how good Agile is! However, what I intend to do over this series of articles is to share with you the misinterpretations, omissions and mistakes that people make that significantly reduces the potential benefits for an organisation, or part of it, when it embarks on an Agile Transformation.
Agile Transformation is not easy! Yes, the ‘mechanics’ of all the Agile frameworks are relatively straightforward to implement, given that people are trained adequately. However, the root cause of just about all the problems that I have come across is inadequate training and/or coaching of everybody involved with the Agile Transformation including the development people as well as the senior and middle management, both business and technical.
Last time, I discussed the potential pitfalls of not having a suitable and visible Vision and Objectives for whatever it is that we are trying to achieve, be it a new product, a major change to an existing product or the Agile transition itself.
This time, I will cover some of the omissions, misunderstandings and malpractices that I have come across with respect to the Business Case; an overall product development ‘document’ with which we can track whether the ongoing development is likely to meet the business value outlined or specifically stated in the development Objectives for a reasonable cost; it is no use developing a product for $1 million dollars if it will take 10 years of product use before it pays for itself.
I will start with a description of an Agile Business Case and then give examples of what has and could go wrong.
What is the Business Case?
Having achieved an agreed Vision and Objectives, the business stakeholders and development team need to quantify the business value that is expected from the product, in what timescale, and the estimates of how much it will cost to develop so that that the business stakeholders can determine whether the development is justified from a business point of view.
These estimates are recorded in the Business Case; a cost-benefit analysis. In the past, in an effort to reduce development business risk as much as possible, some companies produced a detailed, task level, project plan with all the ‘who will do what and when’, factoring in known team member holidays etc. By this means, they hoped to establish the probable costs of the development with a high degree of accuracy. However, I have never seen the expected business benefits undergo such a rigorous analysis.
Also, I have never seen the Business Case updated periodically during the development so that it can be determined whether the development is still justifiable.
This way of producing a Business Plan usually involves a ‘development expert’ to do the technical estimations and takes a significant amount of time during which no business benefit is being accrued.
What is an Agile Business Case?
“Therefore, ‘experts’ are asked for their opinion about probable or possible costs for different ways of solving the problem:
- Develop the product from ‘scratch’ – usually the most expensive option
- Use an existing product as a ’base’ and modify/configure it – the next most expensive option
- Outsource the development – ‘passing risks to some other company’ – the costs can vary significantly depending on the contract type.
From these ‘guesstimates’, the development Sponsor can take a decision as to which development option to take. I will discuss Agile Roles in a later article.There is always another option for the Sponsor to take – ‘Do Nothing’; especially if the probable cost-benefit analysis indicates little Return-on-Investment.If the initial, ‘guesstimate’, Business Case cost-benefit analysis indicates that it may be worthwhile continuing with development,we can start gathering requirements.
What is Agile Business Case Lifecycle?
Once the initial Agile Business Case has been created it is not ‘set in stone’; like most other things in an Agile environment, it is subject to change as we learn during the development. Indeed, I use a set of development ‘document’ templates, which includes an Agile Business Case, that all have ‘This is Subject to Change’ printed in red at the top and bottom of each page.
Post Product Backlog Creation
The Product Backlog, which I shall discuss in my next article, is a list of ‘requirements’ that have been ordered by business value and estimated.
These estimates, that have been done by the development team, can replace the costs section of the initial Business Case. The initial Business Case expected benefits can be assessed by a wider stakeholder population and either confirmed or modified.
The cost-benefit analysis for the modified Business Case values can be used to, again, assess whether it is advisable to continue the development, modify the Vision and Objectives to obtain a viable Business Case or cancel the development.
The time taken from establishing the Vision to achieving this first modified Agile Business Case should be no longer than 2 to 3 weeks; usually, a lot shorter time than is usually taken in a traditional product development environment.
At the End of Development Timeboxes
A Development Timebox is the short, 2 to 3 week period during which the development team completely develop a subset of the ‘requirements’ and what has been developed demonstrated to the relevant stakeholders. Most of you will recognise this as the definition of a Sprint from Scrum; other Agile Frameworks use different names; I will use the term Sprint during the rest of this article because it is quicker to type!
It is recommended that the Agile Business Case be ‘reviewed’ at the end of each Sprint, during the Sprint Review, for the first few Sprints; it is during these first Sprints that the learning curve is steepest. The estimated costs against the actual costs can be assessed and the Agile Business Case updated if necessary. Obviously, assessing the actual benefits accrued at this early stage in development is almost impossible. However, a view can be taken on the new cost-benefit analysis as to whether to continue development.
Remember:
‘Fail Fast’
Once the initial learning has been done, most organisations revert to reviewing the Agile Business Case during the Increment Reviews, done just before a group of functionalities is placed ‘live’; probably every 2 or 3 months.
Case Study 1:
Many years ago, I was asked to help a team who were building a financial products sales system to replace a company’s current system. The ‘need’ that prompted this development was regulatory in that there had been ‘mis-selling’ of some of the financial products and the government had told the whole sector that they had 6 months ‘to clean up their act’.
The company’s current system was based on an ageing mainframe and it was decided that as well as trying to incorporate new regulatory business rules into the sales system, the whole process would be ‘transferred’ to a system using ‘modern’ technology so that additional sales processes could be incorporated, taking advantage of the capabilities of the new technology.
The company mitigated some of the huge risks that they were taking on by outsourcing the development on a fixed price basis; the outsource company decided that ‘Managed RAD’ (the precursor of Agile) was the way to go; I was helping the outsource supplier company team.
The ‘Vision’ was clear:
“To develop a financial products sales system that complies with Government regulation in 6 months so that the company can continue to sell financial products”
There was an onsite, senior salesman from the client company to give the requirements for the new system; the equivalent of a Scrum Product Owner.
Unfortunately, no one had taken the time to produce a Business Case; it was obvious wasn’t it? ‘New system in 6 months or die’!
The prevailing culture within clients and business management at the time was the ‘WISKY’ mentality; “Why Isn’t Someone ‘Koding’ Yet”.
That and the 6-month deadline led the team to cut corners on the preparation. Some rudimentary ‘As-Is’ business process modeling had been done to identify where the sales process needed to be modified to include the regulatory requirements as well as where the new parts of the sales process needed to be inserted.
The product Owner insisted that as much of the ‘As-Is’ had to be in the new system as well as the new parts.
The team decided to go for the ‘low-hanging fruit’ approach, developing the easy and quick parts first; unfortunately, these did not include the regulatory requirements nor the new sales processes.
After 2 months of development, the team released the first prototype to the client company to get feedback. The client was very concerned that there was no sign of the regulatory requirements or new sales process and that the team had developed ‘As-Is’ processes that had been in the old system that were there because of the limitations of the old technology, such as overnight batch processing of data.
It was at this point that the client was considering cancelling the development contract but they were 2 months closer to the important deadline so it was decided to bring someone in that could turn the ‘mess’ around; that someone was me.
I started by investigating the Vision and establishing what was the minimum that was needed in the remaining 4 months. It was decided that a system to support the end-to-end sales process of just one of the financial products, incorporating the regulatory requirements, without any of the new ‘bells and whistles’ would satisfy the regulators and the client company could continue trading.
The ‘Product Owner’ was replaced with a less experienced salesman who was not as ‘wedded’ to the old sales process as the previous Product Owner.
We established and prioritised the development objectives and put together a Business Plan that was used every week as a means to assess development progress toward the highest priority objective of getting the new regulatory requirements incorporated into the sales process.
The new system was ‘finished’ one month early and was demonstrated to the regulators who had high praise and used the new system as a benchmark with which to assess the new systems of other companies in the same sector.
During the month left before the deadline other high priority financial products were added to the system; the client deciding that they would suspend sales of the less important products until they too could be added to the new system.
Lessons:
1.The apparent lack of time always drives people to ‘cut corners’, especially in the preparation. How many window and door frames have you seen that look ‘rough’ because the surfaces were not prepared adequately before applying the top coat of paint? In this case study, some of the people were almost paranoid about the ‘New system in 6 months or die’ so that they focused entirely on the time aspect with little consideration about what the original Product Owner was asking them to do.
As a consequence, the team produced a less than satisfactory first prototype.
2. Don’t leave the requirements set to one person however experienced they are; the question of ‘do we really need to develop the whole of the new system in 6 months?’ would probably have been asked in the early stages if the requirements setting had been done by a group of people including some developers.
3.The lack of prioritised development objectives and a Business Case to assess development progress toward the highest priority objective(s) aided the ‘low hanging fruit’ approach adopted by the outsource company enabling them to effectively waste most of the 2 months work in producing the first prototype.
4.On a positive note, however, the incremental delivery nature of Agile had allowed the team to ‘fail fast’. If the team had continued development without customer feedback for all of the 6 months, who knows what sort of system that they may have produced.
Case Study 2:
I was asked to do an Agile audit in an organisation because one of the senior managers was concerned that he was not seeing the benefits of ‘being’ Agile that were ‘sold’ to him by a chosen ‘partner’ development agency.
The development was a programme of work to integrate 12 disparate systems, ‘inherited’ by the organisation by the acquisition of other organisations; the overall aim was to ensure consistency of data across the organisation and allow the use of a data warehouse for decision making.
The programme was using an in-house Agile framework based on the DSDM framework. The anti-Agile practices across the programme that I discovered during the audit could make the definitive guide on how not to be Agile.
However, I will confine my comments to the consequences of the lack of knowledge on building the Agile Business Case for just one of the projects.
The project ‘Vision’ was to automate many business processes that were currently being done manually. When I arrived, the project had been running, on and off, for about 18 months and had not delivered anything. I asked what the project costs to date were and was told that they were in the order of £1 million but this could not be verified because cost accounting in the organisation and for the programme was very ad-hoc.
The team was struggling with defining the details of some of the User Stories; several attempts had been made during several workshops to finalise these details before development in one or more Sprints.
I decided to sit in on one of these workshops to see what was happening.
A ‘Systems Analyst’ was sat in front of her laptop, not shared with the rest of the workshop, and asked questions of the business representatives. They discussed their answers to the questions which mostly were preceded by ‘It depends’. I asked if any prototypes had been attempted for the User Story under consideration and was told ‘we don’t do prototypes because we do not have any prototypers’. I then asked the stupid question ‘What is a prototyper?’. The obvious answer – someone who prototypes! It became obvious that the organisation believed that prototypes had to be produced in code, rapidly.
I went to the whiteboard, drew a large rectangle and asked the business representative what they expected to see on a screen, focusing on the most used path through the User Story. In 20 minutes we established the ‘core’ data and business rules for the User Story; it had taken 3 months of sporadic workshops not to get that far.
This workshop anecdote led me to ask how this ‘analysis paralysis’ situation had come about. The answer was that the team had ignored one of the basic Agile framework ‘rules’ that development takes place in short, 2 to 3 week, Sprints; the aim of a Sprint is to develop, as fully as possible, a group of User Stories so that they are potentially shippable. As part of the Sprint or Increment Reviews, the business should assess the Business Case to see if it remained viable.
Apart from not running Sprints as recommended, the team had a less than adequate Vision and no Objectives on which to base a Business Case. For some reason, which I was never able to fathom out, nobody in the programme or the rest of the organisation was questioning the lack of development progress for this project or the amount of money they were spending for no visible benefit.
To cut a very long story short, when an adequate Vision and Objectives were created and a Business Case put together, the business realised that what they were trying to achieve was fundamentally flawed and the project was cancelled.
Lessons
1.Despite the poor workshop processes and abandonment of key Agile development practices, the fundamental problem with this project was a lack of adequate Vision and Objectives with which to construct a Business Case by which assessment could be made of development progress toward realising the expected benefits at a reasonable cost.
2. When Vision, Objectives and Business Case were in place, the business realised the futility of the efforts so far and therefore had allowed a waste of £1 million by not having them earlier.
Become a project management expert with our PRINCE2 project management certification. Develop the abilities to lead successful projects and reach your objectives.
Conclusion
These 2 case studies illustrate the worst cases of no Business Case that I have experienced; there are many others.
Having tight deadlines or even no apparent deadline does not excuse the lack of sufficient and proper preparation.
I discussed the Vision and Objectives issues in the first of this series of articles but these should be used to build a Business Case that can be used to assess development progress toward meeting the expected Objectives for a reasonable cost; developing User Stories is not the aim of Agile; the aim is to develop the right User Stories in the right order.
