16th March - IIBA Event - Basel
Business Analysis Case Study: Adding Business Value using Agile within Waterfall
2
Introduction
About me Brian Hill - CBAP
“Freelance” contracting in projects (IT and Process) for 10+ years
Committed to professional development
Strong sense of ownership
Focused on delivering value to the business and meeting stakeholder expectations
3
IntroductionObjectives To demonstrate the value a Business Analyst can bring to Project delivery and to the
Business, focusing on a case Study incorporating “Agile within Waterfall”
Expected outcome Increased understanding of the Business Analyst role
Demonstrated application of the BABOK framework
Demonstrated Agile thinking and practices - even within a Waterfall project
Clarity on how a Business Analyst can add Business Value
4
Initial assessment on joining the projectBusiness Need To provide a major update to an in-house, User Service Self Service portal
Organisational Process Assets
Enterprise Architecture
Expert Judgement
Project Management to align with Internal company specific project methodology (~ PMBOK)
Mandated use of Requirement Management (RMS) and Document Management systems (DMS)
Two development teams and two systems, geographically dispersed, mix of CSV/ Agile
First release with a Business Analyst (BA) - therefore a challenge to demonstrate BA value
Fixed project duration and go-live date, fixed budget – scope “fluid” at start of project
The challenge ● As a business analyst, determining:○ Is my role to simply document requirements OR ○ is my role TO be a leader and deliver real business value
● As a project○ Avoid conflict and simply overpromise and under-deliver OR○ Practice Agility to deliver optimal value within complex set of constraints
5
Checkpoint
Synopsis Internal PM methodology mandates waterfall approach
Waterfall approach requires scope/ time/ budget fixed
CSV mandates fixed scope & baselined documentation,
Agile methods are light on documentation, requirements change, scope variable
Pure Agile would spectacularly fail CSV and internal PM methodology compliance
Key Findings Full Development and Test Team Resources active for duration of the Project
Business Value related to maximising value from these teams
Business Stakeholders present an initial set of “requirements” which constitute scope
Requirements incomplete, associated effort and prioritisation unknown
Ability to meet stakeholder needs uncertain
Project Plan including Phase duration not yet defined
Business Analysis Planning and Monitoring (BAPM) - BABOK v2
6
Plan Business Analysis Approach
Rapidly perform iterative analysis of the requirements and group by moduleEstablish priority and associated project resource effortsCompare to project resource capacity enabling scope setting
Stakeholder Analysis
Plan BA Activities
Plan BA Communications
Plan Requirements Management Process
Manage BA Performance
As a first step, identify stakeholders and start to determine all constraints (location/hours)
Schedule daily workshops with the SME and Development Team Resources, Plan mandatory trainings (internal compliance for BA), gain system access and authorisation rights
Schedule daily Stand-Up meetings, schedule weekly team meetings
Use of RMS and DMS mandated for baseline/ signed off documents. Use of collaborative tools such as Google Docs, Google Sheets for the elicitation aspect of requirement definition. Common set of criteria agreed to assess, categorise and group the requirements
Creation of a tracking sheet that measures the planned activity for BA (and others) on requirements assessment - this also enabled ability to track original requirements plus uncontrolled scope creep
7
Business Analysis Planning and Monitoring (BAPM) tasks
8
Checkpoint
Synopsis Scope creep from day 1:
Need to educate stakeholders and manage expectations
Conflicts between stakeholders and availability issues
Caution/ inexperience toward BA role
SME in Americas time-zone, one development team in Poland billing from day 1 on fixed budget with no work to execute, scope not set
Immediate Priorities Work with PM to start planning – achievable scope and associated effort not yet known, but capacity and phases within waterfall mandated methodology will shape our approach
Keep track on original requirements, and those that are snuck in
Review ALL requirements, start prioritising and getting assessments from SME, dev team 1, dev team 2, testers: assessing effort and system interdependencies requiring change
Developing my own system context and expertise while demonstrating the role, and value of the BA role, to the project stakeholders
9
Elicitation
10
ElicitationMore than just documenting requirements
A popular misconception is that Business Analysts simply document requirements.
This section from BABOK clearly differentiates how documenting (requirement”elicitation results is just one part of the Elicitation process, which is part of the larger Business Analysis
Prepare for Elicitation
Conduct Elicitation Activity
Document Elicitation Results
Confirm Elicitation Results
Using stakeholder analysis, Organisational Process Assets (tools for virtual meetings, online document collaboration tools), I set up intensive schedule of requirement elicitation sessions - a mix of document analysis, interviews, daily workshops with SME/ Usability Expert and other key stakeholders - with a set agenda for each session planned and circulated in advance
Each session handled differently, but working under time pressures the decision to use collaboration tools proved valuable, as updates were flowing in real time and overnight between sessions (especially usability expert developing mockups and inserting to elicitation documents)
Online collaboration tools were used to document the elicitation results, including targeted feedback and clarification in addition to a standalone open actions google sheet. This mitigated the risk of the Business Analyst and SME availability (timezones) hindering progress - and allowed for rapid iterations to finalise individual requirement definitions
Due to the documentation technique and daily stand-ups, requirement elicitation could be rapidly confirmed, communicated to all stakeholders, and the baselined requirement stored in the RMS as record of truth, triggering individual requirement Design pre-work in parallel to the ongoing elicitation of other requirements
11
Checkpoint Synopsis BAPM highlights that scope needs to be set asap
ALL requirements need to be estimated and prioritised
Defining in Waterfall approach will erode Business Value
Solution Implement daily calls and workshops with key stakeholders via hangouts
Morning Stand-Up: 15 minutes focusing on key actions, blockers, and to build team identity.
Utilise google documents to collaborate during definition
During the workshop, requirements are reviewed for completeness and actions to be assessable
Requirement prioritised (1-10 not high/ medium/low)
First estimates from devs/ test of effort for design/ build phase provided
Interdependencies identified
12
Requirements Management and Communication
13
Requirements Management and CommunicationThe Waterfall v Agile Dilemma
In Waterfall, Scope and Requirements must be Baselined by end of Definition.In Agile, fixing scope and requirements is not very agile.In Validated environments, requirements live forever, projects do not.
Manage Sol’n ScopeAnd Requirements Manage Requirements Traceability
Maintain Requirements for re-use
Prepare Requirements Package
Communicate Requirements
Review/ estimate/ prioritise used to help business make a scope setting decisionRequirements being elicited, validated and verified prior to “baselining” in RMS
Within RMS, requirements will be traced to other (dependencies), User Requirements, Design Specifications and Test Cases
Requirements live forever, therefore essential to manage traceability and link to change requests and previous versions of the requirements. Defects or enhancements decision can be made by referring to the overall baselined requirements (operational, not just release)
Determine the best way to communicate a set of baselined requirements.Internal Project Methodology mandates published extract of the release plus new overall requirement baseline to exit Define Phase
More formal for Sponsors, PM - SME, Dev, Test all actively engaged in elicitation/ validation/ verification process
14
Checkpoint Synopsis Tools working well and all teams engaged and aligned
SME’s integrated and active
PM working on PMM deliverables and aligned with BA approach
Daily Stand-Ups working well – robust dialogue, everyone aware of priorities
Prioritisation and estimation taking place – plus scope creep addressed
Critical requirements verified and Design effort for these being reduced by development teams
Immediate Priorities Manage scope by performing capacity based planning
Make any excess demand over budgeted capacity a business problem – they choose the scope we can accept
High level estimates and prioritisation of requirements after first iteration of reviews provides assessment that “demand” exceeds capacity substantially
Delivering Optimal Scope by being “Agile” within Waterfall
15
Optimised Build Phase duration is critical to maximising scope
Define Phase agility reducing design phase duration and increasing build phase - maximising build scope
Manage scope by performing capacity based planning
Business Value from Build Scope maximised by the prioritisation and estimation technique
Operating in pure waterfall would deliver a very small set of scope within time/budget
16
Exiting Define Phase Project phases, capacity, in-scope requirements signed off:
Final requirements being validated and verified
Design work progressing well on defined requirements - effort to Design reducing
Dev Teams and Test teams demonstrate robust common understanding
Less and less problems to resolve now - we are a well oiled machine
Requirement documentation and traceability become focus
Build sense of team, maintain momentum, and coordinate team efforts for the upcoming transition into Build Phase
Solution Prepare “Requirements Package” and formally baseline Requirements
Exit Define phase
Schedule a face to face workshop at end of Design Phase
17
Design Phase Face to face workshop: Meet and greet, Design document sign-offs, bombshells and a planning lesson:
Conducted 3 day workshop, bringing most key stakeholders into a single room for first time
Expedited design documentation sign off
Agreed dev Team for non CSV will go Agile for Build Phase
Agreed Second dev team to work waterfall in Build Phase
Lead Architect from Dev Team A announced he is leaving the company imminently
Agreed development sequence between the two teams in the build phase● Default sequence proposed by teams not optimal
Outputs A common approach for Build Phase moving forward
Documentation sign off complete - into Build Phase
Progress measured via Burndown Chart (remaining effort) & “sprint based” working product
Build Phase Synopsis: Maintain daily stand-ups
Working Product Showcased at end of each sprint
Stakeholder confidence skyrocketed
Track progress via Burndown chart - small deviations but tracked closely to plan
Assisted Dev and Test teams with traceability
Maintained requirements for re-use: Minor adjustments to non CSV system result in an edit to project requirements baseline
Managed solution scope and stakeholder expectations: ● Raised change requests for future releases as needs identified which were not in scope
Identified use of new functionality in discussion with SME’s
Assisted OCM and Test preparations
Exited the Phase on time - but very tight schedule
18
Agile thinking - using a Burndown chart to measure Demand, Capacity and progress during build phase.
19
Test Phase Synopsis: Extremely nerve wracking Test Phase - lack of defects: High quality or bad testing?
Provided assistance to Test Team and SME in test preparations, incl peer reviews
Test Phases executed with unprecedented lack of defects
Final week of Test Phase used to wrap up project in a pressure free environment
Stakeholders extremely pleased with delivered scope functionality and quality
Project Deployed on time
20
Wrap up and Review Section
21
BABOK technique review
22
Business Analysis Planning & Monitoring
Requirements Analysis
Elicitation
Enterprise Analysis
Solution Assessment and Validation
Requirements Management and Communication
Underlying Competencies
Commenced by assessing the Stakeholders, Roles, Deliverables, created Business Analysis Plan and Performance monitoring, daily calls/ virtual workshops scheduled
Performed requirements analysis on initial prioritisation, extending into elicitation in subsequent iterations - working to define/ verify and validate the requirements and allow dev/ test teams to estimate the aggregate resource demand associated with all requirements
Scheduled/prepared for requirement elicitation sessions, conducted elicitation sessions using Google Hangouts for remote interviews/ workshops, documented in G-docs and confirmed by peer review before qualifying for design activities by development teams
Defined Business Need in first iteration of requirement review and prioritisation
Conducted Org Readiness/ Defined Transition Requirements and triggered actions which led to increase value realisation/ business benefit via training/ comms/ catalogue configuration
Used RMS for formal scope and requirement packaging/ traceability/ testing/ release allocation, G-Documents to communicate/ collaborate on requirements in definition/elicitation process, G-Sheets for scope setting/ project burndown, DMS for formal document sign-offs, daily stand-up and weekly team calls
Used Prototyping, Mockups, Workshopping, Interviews, Systems Analysis, Document Analysis, Problem Solving, Negotiating, Influencing, Conflict Management and multitude of other competencies as Business Analyst in this very challenging project
23
Case study: Business Analysis review in BABOK v2 framework
Cherry Picking of the Agile methodology
Like browsing a buffet, we cherry picked applicable aspects of Agile methodologies
What we applied We estimated and then prioritised requirements from the vast initial list
Business chose a capacity constrained bundle of scope in the “project long sprint”
We let teams self organised, but we did need to review, challenge and modify the draft plans
We used the burndown concept in conjunction to track progress once scope defined
We had “virtual standups” to ensure “face to face” conversations and team motivation
We showed business stakeholders working product during the build phase
Demonstrated real progress and built stakeholder satisfaction
We kept the team motivated and engaged - sense of team from daily standup and weekly TC
Most important: We communicated, did peer reviews, and avoided silo’s: Despite time and location issues
24
The Agile bits we cherry picked
The parts we could not use
Welcome changing requirements, even late in development.
Agile processes harness change for the customer's competitive advantage.
The best architectures, requirements, and designs emerge from self-organizing teams.
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
The parts we could use Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Business people and developers must work together daily throughout the project.
Build projects around motivated individuals. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Working software is the primary measure of progress.
Simplicity--the art of maximizing the amount of work not done--is essential.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
25
Agile Manifesto
26
Waterfall PrinciplesWaterfall mandated Waterfall delivery was mandated due to CSV and internal Project Management
methodology.
Waterfall Phases and deliverables to exit the Phase
Project Initiation: Project Charter, Roles and Responsibilities (PM Deliverables)
Define Phase: Baselined User Requirement Specifications (URS). Baselined Functional Specifications, Baselined Scope *** All essentially BA Deliverables
Design Phase: Draft Design Specifications, Draft Test Plan (Dev and Test Deliverables)
Build Phase: Baselined Design Specifications, Unit Test (complete), Test Plan (signed off), Traceability Matrix (baselined)
Test Phase: Test Report , Deployment Plan
Project Value Proposition
Following Waterfall method was a constraint we had to operate within, which without Agility would have potentially involved high expectations while delivering very little business value
Identifying this constraint early, and being Agile (in thinking and approach) allowed the project to deliver maximum scope and value while navigating the Waterfall gateways.
The Project Manager deserves immense credit for managing the documentation and gateways that allowed the project to be Agile within Waterfall, yet fully compliant and to first manage business expectations, and then exceed these expectations
Business Analysisactivities
Set the vision and planned activities to maximise build phase
Influenced Sponsors to focus on their highest priority requirements/ quick wins
Resolved conflicts between stakeholders
Managed and influenced business and project team stakeholder expectation
Overcame time/ distance issues
Collaborated with Operational staff to increase organisational readiness
Business Analysis Value Proposition
Maximised build phase - each week saved represented 10% of eventual scope!
Deliver those scope items that offer maximum Business benefit
SME interactions discovered unexpected, but significant business benefits
27
Adding Value through Business Analysis
Business Analyst uniquely placed to lead via Pivotal Role by setting the vision - others must follow
Project Manager support of approach made the implementation of Business Analyst approach possible
Tools and techniques used required buy-in and acceptance from project team
“Designing” during define phase required Development team agility
Thinking Agile only works if team adopts agile thinking
Peer review concept required teams to break down silo mentality
Business Analysis role in bringing the team together
BA set out the approach and fine-tuned it with feedback
The approach delivered quick wins and benefits
As the Project progressed, team kept doing what worked and optimised via feedback
28
Business Analyst as Project Team enabler
Initial Challenge As a project, chose to:● Practice Agility
As a Business Analyst, chose to:● Be a leader and set the vision
Project outcome As a team, we delivered “a text book” project, despite overwhelming challenges
We delivered full agreed scope, maximum benefit, on time, and with exceptional quality
A happy and engaged set of sponsors, business stakeholders and project team members
Personal outcomes A lot of satisfaction and enhanced profile within the client company
Many of the tools and techniques utilised have been a template for future engagements - especially around virtual teams
Demonstrated the value of a Business Analyst to the organisation - stakeholders better informed for hiring and collaborating with BA’s in the future
29
Summary
30
Final Notes
Documenting Requirements is a small part of the Business Analyst’s role - and does not reflect the value add activities a BA can bring to the Project and Organisation
It is simply one of the many tasks that a Business Analyst may perform.
Our role is to deliver Business Value
What distinguishes BA’s as a critical project resource is that we are a :● Pivotal role bridging
○ Operations and Project Team○ Business and Technical Stakeholders
● Pivotal role in ensuring○ Business Need is defined designed, built and deployed○ Business Value is optimised through scope management
Delivering Value to the Business offers career benefits for the individual BA, and BA’s collectively
