The Agile BA. A Visionate process asset. v i s i o n a t e. c o. n z

Transcription

1 The Agile BA A Visionate process asset Version: 1.0 Version date: March 2015 T h i s d o c u m e n t i s p r o v i d e d f r e e f o r u s e p r o v i d e d t h a t t h e f o r m a t t i n g i s n o t c h a n g e d a n d c o p y r i g h t n o t i c e s a r e m a i n t a i n e d. R e a d e r s a r e w e l c o m e t o m a k e a n d d i s t r i b u t e m u l t i p l e c o p i e s o f t h i s d o c u m e n t. v i s i o n a t e. c o. n z

2 Document Information VERSI ON REVI SI ON DATE DESCR IPTION EDITOR 1.0 Mar 2015 Initial Creation Visionate Contents Document Information... 2 The Agile Challenge... 3 Flexing to the Agile Environment... 4 Scrum Master... 5 Product Owner... 6 Agile Requirements Analysis... 7 Value Realisation... 9 Solution Specification Technical Activities Configurable Systems Testing Conclusion P a g e 2

3 The Agile Challenge As Business Analysts, we tend to be passionate and proud of what we do. We have invested the time and effort to develop ourselves and fine - tune our analytical skillset to the best of our ability. And it has taken a significant amount of time for the IT industry as a whole to truly appreciate the role and value that the BA brings to project delivery. We are now in a time when many organisations realise that BAs are indispensable, and this brings us great career satisfaction. With the rising popularity of Agile-Scrum, we have seen an apparent shift of focus around the execution of project related analysis. We may feel that our hard won reputations are threatened by this new paradigm. The Agile approach encourages a reduction in detailed analysis and a scaling back of traditional documentation. There is a push towards generalist rather than specialist roles, and some might even go so far as to suggest that the analyst has become redundant in Agile environments. Given the situation, it s no wonder that some BAs feel bewildered and anxious about the future of business analysis. But as the Agile methodology has bedded itself in and we have observed how it truly functions in practice, we can see that there is no need for BAs to feel this degree of anxiety about their careers. Agile-Scrum does not remove the demand for the specialised analytical skills that we bring to the table. The BA skillset is still of great value within the Agile context. But it does mean that BAs will need to be flexible in how they perceive their role within the project team. The key to engaging with an Agile-Scrum project is to understand the approach more clearly, and to recognise how we as BAs can flex our hard-won expertise to contribute and provide value. In the following pages we will examine some ways that the Business Analyst role can engage in an Agile-Scrum approach. Note: in this document we will simply outline how the BA role applies to Scrum. The document is not intended to be an exposition of the Agile-Scrum method. As such, a familiarity with Scrum is assumed. V i s i o n a t e L t d / 1 5 a l l r i g h t s r e s e r v e d P a g e 3

4 Traditional SDLC Model The straata version of the V Model represents the IT project lifecycle. In an Agile project, these activities are still addressed, but the timing, depth of detail and rigour may differ from the traditional approach. We will use this model to structure our discussion and consider the role of the Business Analyst in these activities within the Agile context. Flexing to the Agile Environment The aim of Agile, where appropriate, is to allow project teams to bypass the formal approach used in Waterfall, thereby getting more work done in less time. The effectiveness of the Agile approach depends on the size and nature of the project, as well as organisational culture and tolerance for risk. There are many different types of Agile methodologies, with Scrum being the mos t popular. P a g e 4

5 Agile methodology does not mean no method, and in this context the value that the BA brings to Agile-Scrum in terms of applying a structured analytical approach should not be underestimated. There is great value in ensuring that amidst the swift and collaborative environment on an Agile project, that a degree of rigour is maintained to ensure that the project addresses the underlying business need and provides genuine value to the organisation. This does not mean weighty overhead and paralysis by analysis ; it means right-sized and effective approaches to assure quality and ensure that the business value is realised. We will now look at the different roles and activities that the BA can assist with. Scrum Master In Agile-Scrum terms, project management is a shared responsibility of the self-organising Scrum team. In practice, however, this concept can become more aspirational than real, at least until such a time as Agile-Scrum has been well established within the organisation and the Scrum teams have accepted and taken ownership of managing their own projects. In this context, taking responsibility for the quality outputs of other people is a challenging concept for many in IT, irrespective of their area of specialisation. The Agile-Scum role of Scrum Master is not meant to be a project management role. The Scrum Master is meant to be a mentor and guide for the team to assist them in taking joint ownership. In practice though, because of a reluctance to take shared ownership, or an unfamiliarity with doing so, the Scrum Master will often wind up acting as a de-facto Project Manager. V i s i o n a t e L t d / 1 5 a l l r i g h t s r e s e r v e d P a g e 5

6 Irrespective of how the Scrum Master role is applied, as Business Analysts we are ideal candidates for the role. We are already accustomed to working with all roles in the SDLC to ensure that the business benefit we help the business define at the earliest stage of requirements, is designed, implemented, tested and deployed to ensure value for our business stakeholders. Often in smaller scale waterfall style projects, we may have acted as the Project Manager and as such are accustomed to applying project management techniques. So taking on the role of the Scrum Master is a natural area that we as BAs can flex to in support of the Agile-Scrum method. Product Owner The Scrum team includes the formal role of Product Owner. This individual is essentially the representative for the business and is empowered to make immediate decisions within the context of the project. The Product Owner ensures that a focus on the business benefit is maintained at all times and that the viewpoints of all relevant stakeholders are considered. Ultimately the Product Owner is responsible for ensuring the project s success. In the ideal Agile environment, a dedicated Product Owner fro m the business is available on a full-time basis to the project. However for some organisations, this is simply not practical. The primary focus for business people is running the business, so dedicating themselves to fulltime project delivery is not feasible. In this scenario, the individual best suited to step in as Product Owner is the Business Analyst. The BA has the necessary skills and experience when it comes to understanding the needs and drivers for the business. In this situation we can end up with one of two scenarios. The first being where a business Product Owner is available to the project part-time and attends only key meetings and planning sessions. Outside of these sessions, the Business Analyst supports the Product Owner by liaising with them and acting on P a g e 6

7 their behalf. The second scenario occurs where there simply is no Product Owner available from the business and so the Business Analyst steps into this role full-time. In this way, the skillset of the Business Analyst is indispensable in terms of supporting the objectives of the Scrum team. In the context of either supporting or being the fulltime Product Owner, the Business Analyst will provide valuable structure in terms of stakeholder engagement. A key thing to remember with Agile projects is that just because the Product Owner represents the business and has decision making power, this doesn t mean they always know what every area of the business needs. The danger here is that we may end up following the restricted viewpoint of a single business representative. The key activity is that of stakeholder engagement, a core BA focus area, and a critical expertise that we are able to provide to the project. Agile Requirements Analysis In terms of analysis, the Scrum approach does not aim to define requirements with utmost rigour and depth at the beginning of the project. The reason for this is to support speed and agility in delivering a project. This approach allows for maximum flexibility in an environment where the requirements are changeable and the organisation does not wish to spend a great deal of time attempting to pin down the detail upfront. Requirements are understood at the highest level at the start of a project, with the detailed requirements being articulated just before the iteration or sprint where the development is to take place. In an Agile project, the preference is often to articulate requirements as user stories. The user story captures the essence of the business need and is not examined and elaborated u pon until just prior to development this is termed just-in-time analysis. These user stories V i s i o n a t e L t d / 1 5 a l l r i g h t s r e s e r v e d P a g e 7

8 are prioritised by the Product Owner and held in the product backlog which acts as a requirements repository. Like the Product Owner, the product backlog is also a formal Agile-Scrum construct. During the inception phase of the Scrum project, headline requirements are identified and captured as epics. An epic is a large user story which is typically too big to implement in a single iteration. Epics are then decomposed into smaller user stories during the course of the project. Scrum is primarily a software development methodology and the Scrum team operates in iterations during which collaborative development takes place. It is therefore important to note that much of the traditional requirements analysis takes place outside of the iteration, and as such outside the Scrum team. The Business Analyst works with the Product Owner to create and refine the product backlog. The Analyst typically works one to two iterations ahead of the team to make sure the epics are decomposed into user stories and the necessary detail is ready for the team to pick up and run with. As such, there is still very much a place within the Agile project for a Business Analyst to apply skill and rigour to process of identifying, validating, decomposing and prioritising the requirements. Over time, there has been a shift in attitude within Agile projects towards documentation. In the early days, committing anything to paper beyond user stories and acceptance criteria was frowned upon. This made the Business Analyst s role challenging as most traditional BAs are experts in producing structured documentation. So to be plunged into a world where documents were not permitted was somewhat disconcerting. But these days, there is an appreciation within Agile for the value of lightweight documentation. This is surely a heartening shift for most BAs, and revalidates one of our hard earned and well-practiced skillsets. P a g e 8

9 In their zeal to embrace the Agile philosophy, advocates of the approach can become unnecessarily resistant to anything that smells like a traditional waterfall method. To a degree, this is understandable because they need to maintain some rigour in adhering to Agile principles. However, there is a risk in Agile projects that the importance of structured requirements analysis is overlooked and undervalued. In this situation, the Scrum team runs the risk of using agility as an excuse to become sloppy in their efforts. The straata method provides an approach that can be flexed for use in an Agile environment in order to rightsize the analysis effort, thereby ensuring a degree of rigour is maintained without overcooking it. Click here to access documents that cover the straata approach for requirements analysis. Value Realisation In the straata method we speak of value realisation. By this we mean putting in place measures to ensure the organisation receives tangible value from the project work we are doing. These are the requirements to ensure that the delivered product is actually adopted by the business, training is identified and in place, resistance to adoption has been identified, mitigations have been defined and ways and means to measure actual business value realisation are identified. Whether a project is implemented using a traditional Waterfall delivery methods or a collaborative Agile approach, this concept is still relevant. We all undoubtedly want to make sure the value of what we are doing is realised by the organisation as a whole. Once again, this is an area where the Business Analyst can assist. Whether Waterfall or Agile, specific requirements for value realisation must be considered and included in the project scope, and as the BA it is our role in Scrum to ensure they are captured in the product backlog. V i s i o n a t e L t d / 1 5 a l l r i g h t s r e s e r v e d P a g e 9

10 In terms of assessing whether or not the project has realised the intended value, this is something that will generally occur outside of the sprint, potentially using tools delivered during the sprint. For example, a report identified as a requirement for Value Realisation measurement and generated during the sprint could show that the functionality added to the ABC website has increased customer sign-ups by 20%. Solution Specification During the solution specification activity the Business Analyst lays out the functional and non-functional specification for the solution. The degree to which this analysis activity is necessary during an Agile-Scrum project will depend upon complexity and level of business engagement in the project. In some situations, functional specification will occur on-the-fly as part of the sprint. And in other situations, the developers have sufficient analytical abilities themselves to design the solution. In both cases, the role of the BA may be reduced in this activity. However, in some projects there may be a need for additional rigour and focus in this area. Developers may feel the need for a more detailed specification of the functio nal design for a requirement, or testers may need it in order to comprehensively design a testing regime. Functional specification of requirements, or detailed exposition of acceptance criteria for testing is of course a core skill set of the BA function. P a g e 10

11 Technical Activities The technical arena is one in which the Business Analyst does not often venture, with the exception being those Business Analysts that have come from a technical background. Activities in this area involve ensuring the right technical principles, protocols and procedures are in place, application architecture is defined, and technical architecture patterns and standards are identified. How this gets done will depend on how Agile-Scrum is being used by the organisation and the shape of the internal IT function. Some organisations will mix these activities into the sprint, on-the-fly, whilst other organisations will take a more formal approach. The formal approach may involve a separate Scrum team tasked with creation of the application and technical architecture. Another formal approach is to include specific architectural requirements as pre-requisites in the product backlog, or even via separate preliminary sprints to set-up the required technical environment. BAs with a strong technical bent may dabble in this area, but traditionally most BAs shy away from this and leave it to the technical experts. And it s safe to say that most BAs will steer will clear of actual hands on development and coding. This generally is not a role that the BA can easily flex to fill. The exception once again, being those BAs that have come from a strong technical background. V i s i o n a t e L t d / 1 5 a l l r i g h t s r e s e r v e d P a g e 11

12 Configurable Systems In the situation where a configurable offthe-shelf package is being implemented, a different dynamic applies. Typically, configuration of an off-the-shelf system involves the identification of business rules (i.e. detailed requirements) which are then applied to the package through in-built configuration. The package solution may require specialist configuration resources to be involved (e.g. SAP FICO specialists), or it may be amenable to configuration by an individual knowledgeable in the business process. In either case, as BAs we are well suited to be involved in determining how the business requirements can be fitted to the capabilities of the configurable package. And in some cases, we could even be involved in carrying out the configuration itself. Testing The validation activities that are traditionally handled by a formal testing function are, with Agile-Scrum, the responsibility of the Scrum team. These activities are carried out within the sprint. The Scrum team may or may not have formally assigned testers. There are a number of different aspects of testing to consider, and Business Analysts are able to assist in many of these areas. Technical testing such as integration and unit testing are not something that most BAs would attempt, however a BA with a technical background may feel comfortable lending a hand in this area. Functional testing of the solution is an area that most BAs could flex to perform, depending of course on the nature of the project and complexity of the system. P a g e 12

13 User Acceptance Testing (UAT) is an activity that traditionally the Business Analyst will assist in coordinating. Depending on the level of business engagement with the project, the BA may simply assist with scripting and coordinating the testing, right through to actually participating in the execution of UAT. If the business is heavily engaged in the project, then the UAT may occur during the sprint, otherwise some form of UAT will need to be conducted outside of the sprint. Conclusion In summary there are a number of roles within the Scrum team that are ideally filled by Business Analysts. There are also roles which we can flex to, in support of the multi-skilled approach promoted by Agile thinking. Irrespective of the project methodology in use, we should all have the same ultimate goal: to deliver a quality result to the business that provides measurable value. As Business Analysts, this is our core focus. To enable our own flexibility and be capable of filling the different roles described in this document, we as BAs must cultivate a mind-set of willingness and cooperation. In doing so, we must shed any attitude and rigidity around what a Business Analyst does and does not do. At the end of the day, on an Agile project, the BA needs to be the sponge that expands and fill any perceived gaps within the team. Much of the success of the Agile approach lies in the empowerment of a self - organising team. The BA, and all members of the Scrum team for that matter, need to adopt an attitude of serving the team in any way possible to support the successful execution of any given sprint. V i s i o n a t e L t d / 1 5 a l l r i g h t s r e s e r v e d P a g e 13

14 The nature and degree of our involvement as BAs will vary, depending upon the particular organisation. But it is clear that regardless of how Agile-Scrum has been adopted in practice, there remains a primary requirement for Business Analysis expertise within the Scrum team. Thank you for reading our document on the Agile BA. For more information on the straata method, please visit our website P a g e 14