This chapter covers the following topics:
• agile adoption;
• the business analyst role in an agile world.
INTRODUCTION
When agile approaches began in the early 2000s, they were mainly being applied by small teams to small, relatively simple problems and they worked really well. As the agile movement has grown and become more fashionable, teams and organisations are trying to obtain the benefits of agile for larger and more complex problems, and with larger and more diverse teams. The history in Chapter 2 clarifies that this is not how agile began. As a result, it should be no surprise that some of the recommended approaches and methods struggle when faced with large and complex problems where the adoption of agile methods can become lost or diluted if not managed or supported effectively.
Many companies who were relatively early adopters of agile found difficulties when trying to solve problems that did not align with the original intention underlying agile. To address this, they set about adapting the approaches, often with the aid of external consultants, and have now developed their own bespoke versions. This has been happening for several years and some of these bespoke methods have now coalesced into the more generic approaches that have gained popularity. The practice of tailoring and extending the methods continues, and the approaches to scale agile are not the clearly defined, well-publicised methods mentioned in Chapter 5 but bespoke adaptations created internally to address the needs of individual companies and enterprises.
Companies deciding to adopt agile practices today are comparatively lucky. Not only are the classic agile methods well understood, but there are also several new frameworks and methods available that work well on more complex or larger projects. It is also the case that organisations and businesses want to adopt agile at an enterprise level; they want to be agile organisations. This is because an agile approach to developing goods or services can realise the following benefits:
• shortened time to market of new products/services;
• adaptability to changing needs of customers;
• improved quality of products/services;
• maximised return on investment.
This chapter discusses the challenges in adopting an agile approach and how the agile business analyst can support agile transformation, as well as add value, working within and alongside agile change projects.
AGILE ADOPTION
It is difficult to be, or become, an agile project, programme or organisation as it requires a new mindset and core values. The extent of the change required to adopt agile will vary from organisation to organisation, depending upon the start point and culture. Often, organisations want the benefits that adopting an agile approach will bring, without understanding the amount of change that this will require.
Adopting agile software development
A good example concerns the adoption of agile software development. Making a statement that agile is to be adopted is far easier than doing this successfully. The adoption of agile should be considered a transformational change that encompasses all the POPITTM elements. In other words, the agile values and principles need to be applied to the agile adoption itself, and this should be seen as a programme for change. The use of POPITTM to analyse the changes required for adopting agile are explored in Table 16.1 below.
Table 16.1 POPIT™ analysis of agile adoption
This analysis demonstrates that even when deploying change into an IT function, where agile is likely to be recognised to some degree, delivering technology or new standards is never sufficient. This is a good example of why holistic business analysis is so important.
Adopting or scaling agile
Some key factors to consider when adopting or scaling agile are shown in Table 16.2 below.
Table 16.2 Key factors for adopting or scaling agile
Adapting agile standards
In his 2009 paper ‘Adapting Agile methods for complex environments’, Scott Ambler introduced a model to help teams identify whether they should be considering adapting their standard agile approaches. This has evolved into the ‘Software Development Context Framework (SCF)’, reproduced in Figure 16.1 with permission from Scott Ambler; it can also be applied to non-software projects. The SCF identifies six factors that, when analysed, can help identify the likelihood of a project failing unless changes are made to the standard approach.
Figure 16.1 Scott Ambler’s ‘Software Development Context Framework’
Each factor is a sliding scale. Being close to the left-hand side implies that standard agile approaches should work well; but the further to the right in any factor, the more likely it is that the methods and approaches will need to change.
Some of the scaled agile approaches described in Chapter 5, notably DA 2.0, provide a range of techniques, practices, mitigations and methods to deal with complexity without sacrificing the benefits of an agile approach. Some of these approaches utilise business analysis skills. For example, to counter the problems caused by being geographically distributed, teams can increase the amount of modelling and planning they do to reduce misunderstandings.
System of interest model
When embarking upon an agile adoption strategy it is beneficial to consider the ‘system of interest’ model shown in Figure 16.2. The area of interest is usually defined by an individual role or authority but could also be defined by a team or business area, for example, a chief technical officer (CTO), deciding to adopt agile development within, or across, an IT department or an agile business analyst deciding to apply agile principles and values in their day-to-day work on a business improvement project.
Figure 16.2 Levels of influence when adopting agile
Whether the system of interest is derived from the perspective of an individual, team or organisation it is useful to understand the three elements of the model as follows:
|
1. Can control |
What can the individual or team control when adopting agile? For example, a team may decide to improve how they run their iteration planning, change their estimation approach or improve the facilitation skills within the team. These things are unlikely to require permission and can readily improve the effectiveness of the team. |
|
2. Can influence |
What or whom can be influenced to improve the adoption of agile more widely? For example, an agile business analyst may feel hindered because others lack knowledge and understanding of agile. Spending time discussing agile may help others to see the benefits. Additionally, a manager of an IT department may be able to influence business users to work more collaboratively with development teams or influence funding for agile tools. This influence could expand the knowledge and understanding of agile, which could aid and extend agile adoption. |
What is it that constrains a team, individual or organisation from adopting agile more widely or scaling agile? Constraints could come from other organisations or even internal processes. Constraints need to be challenged, as they may be based on perceptions rather than reality. For example, project office process and templates that are suited to linear approaches may appear to be constraints but could be open to challenge. Real constraints, however, should be accepted and efforts applied to areas where change can occur or can be influenced. |
Because the history of many agile approaches is based on small, highly collaborative teams, it can be harder to make them work where that environment is not present. The system of interest model helps to identify which areas can, and should, be challenged to help address some of the obstacles that many organisations face in wider agile adoption. Areas that may require influence or challenge include:
• organisational culture and its resistance to change;
• pre-existing frameworks that follow a linear approach;
• audit, regulatory or safety critical requirements that expect higher quality assurance;
• projects with strict contractual commitments;
• complex user environments or where there are issues with availability of end users;
• sub-contracting into a project that is run in a non-agile way;
• lack of management support or understanding of agile.
THE BUSINESS ANALYST ROLE IN AN AGILE WORLD
In this book we have discussed the importance of having business analysts who can analyse the organisational situation and understand business needs, even when the business situation is vague and ambiguous. We have explored how the business analyst can understand and adopt an agile mindset and how this can add value when they deploy their skills across multiple levels within the organisation. Business analysts are trained to explore root causes of problems, analyse problems through a business lens, recognise multiple perspectives and never assume that IT is always the solution. As Abraham Maslow commented, in his The psychology of science (1966):
I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail.
As agile thinking and theory expands more widely into business systems, the need for business analysts who can readily apply the skills and approaches outlined in this book will be a key factor in organisational agility. An agile business analyst is not about doing agile, rather it is about being agile and this can only be achieved once an agile mindset is adopted.
The key characteristics that agile business analysts need to adopt are summarised in Figure 16.3.
Figure 16.3 Key characteristics of an agile business analyst
With the agile mindset firmly ingrained, business analysts can help to increase organisational agility and the success of change programmes. This requires them to work at the enterprise, programme and project levels as discussed in Chapter 3 and shown in Figure 16.4.
The business analyst and the product owner
Scrum has become the preferred agile development method in many organisations and this has raised the issue of the involvement of the business analyst, particularly with regard to the work of the product owner. Organisations that have not adopted Scrum, or use a variant, also report that they have a similar role to the product owner and the same issues apply.
Ken Schwaber defined the product owner role in the Scrum guide (July 2014) where he includes in his description the following:
The Product Owner is responsible for maximizing the value of the product and the work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals
The lack of clarification within Scrum regarding the business analyst role has given rise to the following two questions:
1. Can the business analyst be the proxy product owner?
2. How can the business analyst and product owner roles co-exist?
Within some projects and organisations, the business analyst may be asked to perform the role of the proxy product owner. This normally entails undertaking product owner responsibilities such as managing and prioritising the backlog, attending team meetings and representing the views of the business. This may be a temporary role or may be longer term and the business analyst covers the duties that are the province of the product owner. The reasons why a business analyst may be asked to be a proxy product owner include the following:
• product owner is overworked;
• product owner is under-skilled;
• product owner role split into product manager and product owner;
• product owner is in a different city, country or continent to development team.
While business analysts typically possess skills required of a product owner, we do not believe that the business analyst role should become the proxy product owner. Scrum is clear that the product owner is solely responsible for managing and prioritising the backlog and the work performed by the development team. We feel that the separation of responsibilities between a product owner and a business analyst operating as a proxy product owner could cause miscommunication within the development team resulting in delays to the product delivery. We believe the better alternatives are that:
• the business analyst becomes the actual product owner
• the business analyst acts as a critical friend to the product owner and the development team.
Business analysts work holistically across many business components, one of which is IT solutions. In doing this they are applying service, systems and Lean thinking. Business analysts who complete the International Diploma in Business Analysis with BCS, The Chartered Institute for IT, are trained to look beyond software solutions to define and resolve business problems. This training enables business analysts to take on the role of product owner or to be the critical friend to the product owner. Business analysts may have an IT or a business background, or, sometimes, both. However, the majority have progressed to a business analyst role because they have both logical and interpersonal skills, and a natural interest in business problem-solving. Business analysts who can offer this range of skills not only make great product owners, but are also perfectly capable of operating within an agile project team.
It appears to us that the product owner role requires business analysis skills – the skills that business analysts have been developing for over 20 years. This subject arose during an email exchange with Ken Schwaber (email conversation on 29 June 2016) regarding why business analysts often end up as proxy product owners.
This extract from the exchange is reprinted with permission from Ken:
Over and over, I find the business people so tired of dealing with systems people that the idea of [them becoming] a Product Owner is just too much. They [the business people] don’t trust or know how to talk with and direct software services, so they just delegate.
So, there is a need for skilled professionals who can support the product owner in representing the business, and who will be able to work collaboratively with the software team, and build relationships based on engagement and trust. We couldn’t have put it better – and we know just the people to do this.
CONCLUSION
Although agile was originally developed with software development in mind, its values and principles apply more widely. The shift in mindset to adopt agile principles and values requires a much deeper understanding and acceptance of the need for change. The three elements that constitute agile adoption, shown in Figure 16.5, apply to the individual, the project and the organisation.
Figure 16.5 Main elements of agile
We feel that this diagram also represents what is required for the business analysis profession to adopt agile across the three levels of business analysis work. We hope this book helps all business analysts to develop their agile mindset and deliver agility in all that they do.
REFERENCES
Ambler, S. (2009) Adapting Agile methods for complex environments. IBM Rational Software. Available from: www.webfinancialsolutions.com/wp-content/uploads/2011/10/Adapting-Agile-Methods-for-Complex-Environments.pdf [20 December 2016].
Maslow, A.H. (1966) The psychology of science. Chapel Hill, NC: Maurice Bassett Publishing.
Schwaber, K. (2016) Email conversation, 29 June.
Schwaber, K. and Sutherland, J. (2014) The Scrum Guide™ The Definitive Guide to Scrum: The Rules of the Game. Available at: www.scrumguides.org/docs/scrumguide/v1/scrum-guide-us.pdf [18 January 2016].
FURTHER READING
Ambler, S. and Lines, M. (2012) Disciplined Agile delivery: a practitioner’s guide to Agile software in the enterprise. Upper Saddle River, NJ: IBM Press.
Cadle, J. (ed.) (2014) Developing information systems. Swindon: BCS.
Pichler, R. (2010) Common product owner traps. Scrum Alliance. Available from: www.scrumalliance.org/community/articles/2010/april/common-product-owner-traps#sthash.4GSD4tRB.dpuf [20 December 2016].