Balancing the Hybrid Development Process. The role of the Business Analyst

Transcription

1 The role of the Business Analyst

2 This document is intended as a guide only. Readers are advised that before acting on any matter arising from this document, they should consult FINNZ FINNZ Limited. All rights reserved. Copyright 2013 FINNZ Page 1

3 Balancing the Hybrid the role of the Business Analyst In environments like the public sector, can Agile principles be injected safely into the software development process and yet balance the need to fix costs and timeframes? There is an increasing trend within IT projects to use a blend of methodologies to structure and manage the System Development Lifecycle (SDLC). Traditionally the SDLC has been managed using the document heavy Waterfall approach but in recent years Agile has become increasingly popular due to a lighter documentation, increased flexibility and openness to change. However, when software development is bound by contractual arrangements between the organisation responsible for delivering the software and the client a pure Agile approach is not always practical. This ebook considers the tactics FINNZ has used in adopting a hybrid methodology that meets the expectations of the clients but allows the project team to adopt Agile principles to deliver high quality software. This impacts the traditional role of the Business Analyst and progressively stresses the importance for Business Analysts to show an ability to demonstrate soft skills, especially well-honed communication skills and flexibility. Copyright 2013 FINNZ Page 2

4 Meeting the Need As a consultancy we work with our clients to provide solutions that solve a number of business problems whether this be enabling an organisation s response to legislative change or identifying process and system improvements. At the heart of our business is ensuring we deliver a solution that meets the need of the client. Responding to specific client needs can necessitate a Systems Development Lifecycle (SDLC) approach that best fits the business outcomes of the project and satisfies the client s need to have certainty in terms of commercial requirements (time and cost). There are a range of SDLC methodologies available to any entity wishing to build and deliver software. The two most popular currently in use are Waterfall and Agile (in particular, SCRUM). Copyright 2013 FINNZ Page 3

5 Waterfall The Waterfall methodology uses a linear approach to software development with each activity performed in a particular sequence and only once. Requirements are defined at the outset of the project and then remain fixed until the software is delivered to the client. The Waterfall SDLC Copyright 2013 FINNZ Page 4

6 Agile Agile was developed in response to the common drawbacks of Waterfall including the inability to accommodate change and meet projected costs and timeframes. Under the Waterfall approach software that didn t meet the requirements of the stakeholders was frequently delivered. Agile is based on iterations with requirements and software developed in tandem. The Agile SDLC Copyright 2013 FINNZ Page 5

7 Getting Agile Customarily client facing solutions or contractually constrained solutions are delivered using the Waterfall approach. Why do this? In short, Waterfall is the most appropriate methodology where the requirements have to be defined at the outset of the project. In the case of delivering a project on the basis of a contractual arrangement the requirement must be defined upfront in order to establish time and cost. Waterfall is document driven and the client will in most cases require documentation to be approved before development is initiated. Agile as a means of delivering software has gained popularity over the past decade. Using an Agile approach to software development is an opportunity for teams to improve collaboration, manage change throughout the software lifecycle, improve the timeframes of the project and deliver a higher quality product to the client thus avoiding the well-known pitfalls of the Waterfall approach including the document heavy style and an inability to accommodate change. However when engaged by clients external to the organisation time and cost are factors that must be fixed up front and requirements must be agreed to before development commences, how can this be managed? One significant factor is that the more information we have at the outset of a project the likelihood of providing an accurate estimate increases. Copyright 2013 FINNZ Page 6

8 A Hybrid Approach FINNZ has found through practical application that adopting a hybrid of SDLC methodology blending Agile and Waterfall SDLC methodology often provides the most suitable structure for, and management of, the SDLC. Using Agile principles FINNZ have simply adopted an approach whereby scope and requirements are defined prior to software development (thus enabling timeframes and costs to be fixed). We then follow the iterative development cycles of the Agile methodology to design and construct the software solution. This approach enables certainty in respect of the time and cost, while realising the benefits of an Agile approach. This blended approach has seen communication optimised by using Agile principles and ensuring that a collaborative approach is taken to understand and recognise our client s commercial and project requirements. FINNZ has used this progressive approach to the SDLC to deliver a number of solutions to a variety of clients. How does the role of the Business Analyst fit into an approach that mixes Waterfall and Agile methodologies? Copyright 2013 FINNZ Page 7

9 The Hybrid BA A hybrid approach requires a BA who can demonstrate flexibility. This approach changes the dynamic between the members of the project team and the role of the Business Analyst across the SDLC. Traditionally the Business Analyst works in isolation with the client to produce and approve a definitive set of requirements. When the client has approved the requirements development commences. Other SDLC activities such as testing and production of training materials are delivered by other roles as one off activities. Agility requires flexibility from the project team and team members need to be willing to take on different roles at different points of the SDLC. When a hybrid approach is taken, what new responsibilities and activities may the Business Analyst assume throughout the SDLC? The Business Analyst does a large amount of the scoping and requirements work upfront and then adopts a more Agile approach through the core phases of the SDLC by interchanging between project team roles (namely design and testing), working closely with the rest of the team as the solution is developed and repeating design and testing activities until the conclusion of the project. Copyright 2013 FINNZ Page 8

10 Accommodating Change Any changes to requirements during development are managed through the change management process but are easily accommodated due to the iterative approach that is taken. Initial scoping and definition of the high level requirements gives a stable frame of reference for the Agile development cycles. This means the detail of requirements can still vary but scope has been controlled within the high level requirements. The FINNZ Hybrid Approach to the SDLC Copyright 2013 FINNZ Page 9

11 Fixing the Scope The FINNZ Hybrid Approach to the SDLC When the project is contract based the customer often requires the organisation delivering the software to establish the deliverables and the scope at the outset of the project. The project is initiated using a Waterfall approach, time and cost are key factors and achieving an accurate estimate of time and costs is dependent on establishing requirements. The Business Analyst defines the requirements during the initiation stages of the project and these requirements form the product list. In some instances the client may have already completed the requirements and these need to be translated into design. Having a robust change management process is key to ensuring that if the scope or requirements change during the course of the project this is managed within the constraints of the contract. Copyright 2013 FINNZ Page 10

12 The Business Analyst will work with the Project Manager and the client to establish the scope of the project and document the high level requirements. Once the high level requirements have been approved by the client they are fixed. Requirements produced using a Waterfall approach will be grouped into iterations for Agile development and therefore it is crucial that requirement documentation is structured with this purpose in mind. The Business Analyst must ensure that requirement statements are concise and can be clearly traced to the subsequent design and products or features to ensure that requirements have been satisfied by development. This is key to managing the transition from Waterfall to Agile. Copyright 2013 FINNZ Page 11

13 Planning for Agile Once requirements are finalised the Business Analyst works with the Project Manager, Developers and the customer to group common features together, prioritise development and plan each iteration. The objective of planning iterations is not only to create commonalities between features for ease of development but to assist the client in meeting business objectives by delivering features as needed, need may be based on legislative requirements or prescribed go live dates. With the client s approval of the requirements the Waterfall approach is complete until the final stages of the project. The high level requirements should form the product or feature list and any natural groupings of features bundled together. This enables a cohesive approach to testing by grouping similar features together for design. The most important features should be delivered first, this is usually determined with the client and a priority is given to each high level requirement. Throughout these initial stages where the SDLC uses the Waterfall methodology it is important that the project team adheres to Agile principles and continues to take an Agile approach to communication and collaboration. Discussions are usually held with Developers to ensure requirements can be met through feasible software solutions and daily stand up meetings involving the project team ensure that communication is established and sustained through the course of the project. Copyright 2013 FINNZ Page 12

14 Planning The FINNZ Hybrid Approach to the SDLC Planning occurs at the start of each iteration. The Business Analyst works with the Developers, Project Manager and customer to ensure the initial product list and iteration plan is still relevant and where necessary changes are accommodated. Copyright 2013 FINNZ Page 13

15 Progressing the Detail The FINNZ Hybrid Approach to the SDLC The detailed requirements (this may include use cases and business process models) and design work for each iteration (or sprint) are usually completed by the project team and then approved by the client prior to commencing the development iteration. Entry and exit criteria are defined for each feature (standardly through the creation of use cases), these form the basis for the test documentation. Features are developed in the bundles defined in the product list and released to the test environment for testing. During development the Business Analyst works closely with the Developer clarifying points in the design documents where necessary, answering any questions and checking screens and functions prior to release to the test environment. This collaborative approach allows the team to achieve a continuous cycle of improvement and feedback and deliver high quality products that fulfil the client s requirements. Copyright 2013 FINNZ Page 14

16 Testing The FINNZ Hybrid Approach to the SDLC Getting it right As part of an Agile approach the Business Analyst takes responsibility for product acceptance and e testing is often managed and executed by the Business Analysts (usually with support from testing resource.) A fundamental aspect of this process is ensuring that testing is always independently carried out by a Business Analyst or tester who has not had involvement in defining requirements or designing the products for the iteration. While development is taking place the Business Analyst creates the test documentation, the form this takes is normally is agreed with the client and may include test cases for each feature based on the requirements and design documentation. With the features released to the test environment the Business Analyst commences testing. If defects are identified these are prioritised and (depending on the priority) fixed by the Developers. Fixed defects are released to the test environment during the iteration or deferred to a later iteration. When the Business Analyst (with the Project Manager) is satisfied that the iteration release is of a quality suitable for Production (or further testing by the client) the iteration is considered complete. Copyright 2013 FINNZ Page 15

17 Review The FINNZ Hybrid Approach to the SDLC At the end of each iteration the features are verified by the Business Analyst and the client. The Business Analyst with the development team will undertake a review of the iteration. Success factors and areas that require improvement are identified and this is documented and fed into the next iteration. Ensuring these reviews are conducted at the end of each iteration enables the team to continuously provide feedback and improve the quality of the deliverables through the SDLC rather than leaving review to the end of the project when it is too late to improve delivery. Copyright 2013 FINNZ Page 16

18 Closing the project The FINNZ Hybrid Approach to the SDLC When the final iteration is complete and all features delivered, tested and accepted, the solution is ready for release into the production environment. The project returns to a Waterfall approach for this final stage. This stage covers the following; ensuring all documentation is complete and up-to-date and reflects the product delivered to the client, completion of any technical and/or architecture documents (this is usually the lead Developer or solution architect s responsibility but the Business Analyst may assist with or complete these documents) and finalisation of any training or guidance documentation. A final and formal project review is completed. The final project review addresses all aspects of the SDLC from initiation to conclusion and the client is requested to provide feedback. The review is recorded in a central register and feeds the approaches taken to future projects. With these activities complete handover can take place, the Business Analyst may take responsibility for the training of operational personnel if this is required. Copyright 2013 FINNZ Page 17

19 Best of Both Worlds Taking a hybrid approach to the SDLC provides the better of two divergent methodologies and allows the project team to adopt the facets of each methodology that best fulfil the requirements of the client and provide the most effective collaboration and communication while delivering software of high quality. The following points are key to successfully utilising this approach: Agile principles of collaboration, co-location and communication must be followed throughout the course of the project regardless of the methodology that is being used at any one time. Therefore communication between team members must be frequent and regular including at the outset and conclusion of the project when Waterfall methodology is being used. Soft skills are vital to the success of the project, the focus is on collaboration and communication and team members must be able to demonstrate an ability to communicate, negotiate and cooperate. When communicating, the most effective method is in-person, so the project team should be where possible situated in the same location. Some projects may require the Business Analyst to complete requirement or design documentation off site. In these cases alternative methods of communication should be investigated. Business Analysts must exhibit an ability to be flexible. While the first stages of the project require a traditional approach to business analysis with the upfront definition of requirements, during the subsequent iterations of software development other activities that do not fall under the traditional remit of the Business Analyst such as testing will require completion. A motivated Project Manager or project lead who communicates with the project team on a daily basis is key to the completion of each iteration. The Project Manager needs to be working and collaborating and if possible, located with the team. Copyright 2013 FINNZ Page 18

20 A robust change management process must be in place before the project is initiated to manage any impact on timeframes and costs. Under Agile methodology, change is usually inevitable as the amount of development completed increases so does the client s understanding of what the end product should look like. Change needs to be accommodated to ensure maximum benefits of the Agile approach are realised but change must be controlled in order to meet contractual obligations such as time and cost. Requirements, use cases, and design documentation need to be well structured to ensure a smooth transition between the initial Waterfall approach and the subsequent Agile iterations of the project. It should be possible to establish without difficulty if the design documentation satisfies the requirements. Author: Annette Edwards, FINNZ Consultant For further information contact [email protected] Copyright 2013 FINNZ Page 19