BA World - BA in AGILE Projects
Post on 05-Dec-2014
1072 Views
Preview:
DESCRIPTION
Transcript
MethodGroup business analysis specialists
Lucas Murtagh – Lead Business Analyst MethodGroup – Business Analysis Specialists
Is a BA required on an Agile team?
MethodGroup business analysis specialists
Agenda
Agenda
Introduction
Projects
What are projects?
How projects work and why some succeed and some fail
Business Analyst
What role do BAs perform?
Good BAs Vs Bad BAs
Agile Concepts
So how does agile work?
Traditional Vs Agile Analysis
Wrap Up – We need to change our behaviour to become Agile
Questions?
MethodGroup business analysis specialists
Introduction
Lucas Murtagh
A little about me
A little about me
Born in 1974
A little about me
Lived in the bush for most of my teens
A little about me
Studied actuarial & maths at Uni
A little about me
Spent first five years of career crunching numbers in Actuarial and developing complex systems to
understand risk
A little about me
Got offered a job as a full time gambler
A little about me
Got married and had some kids
A little about me
Had to get a real job
A little about me
Became a BA…..Real Job!
A little about me
Worked on lots of projects
A little about me
Across many industries
A little about me
Telecommunications Throroughbred Racing
Mining Banking
Wealth Management Insurance
Media Property
Asset Management
A little about me
A variety of subject areas, sizes and complexities
A little about me
Some projects went well
A little about me
Some projects didn’t go so well
MethodGroup
MethodGroup
Clear philosophy Simple
Structured Collaborative
Industry Aligned Approach to Business Analysis
The world is changing
IT is moving faster than the business Companies are subscribing to services rather than
building applications
The world is changing
What does this mean for us?
MethodGroup business analysis specialists
Projects
© 2009 Forrester Research, Inc. Reproduction Prohibited
Rusty and Waterfall
Slow to market Documentation is out of date by the time it’s
complete Product/Solution is out of date by the time it’s
delivered Silo behavior May be restricted by what has been agreed in
contracts Worker slave relationships within project
It must have some good points….
Definition of Project
1. Project:“A temporary endeavor undertaken to create a unique product, service or result”
2. Has a definite beginning and end 3. Is Unique
4. Consumes resources
5. Starts with an objective
Where do Objectives come from (worst practice)?
From a senior manager’s posterior
As a knee-jerk reaction to a media article
From a big lunch with a supplier From something someone said over drinks at a conference
From the Chairman’s wife not being able to get through to the call centre
From the need to be seen to be doing something
From hearing that’s what they do in the US
Where do Objectives come from (best practice)?
An efficient business will continually forecast the emerging threats and opportunities in their market
An efficient business will continually measure and analyse the effectiveness of their operation and will thereby identify opportunities for improvement
Based on these inputs an efficient business will devise and maintain an explicit business strategy including strategic objectives
An efficient business will identify the programmes of work required to deliver the strategic objectives
Project objectives should trace up through programme objectives to the overall business strategy
All objectives will be SMART
Example of a reasonably clear objective
Our goal is, before this decade is out, to send a man to the moon and return him safely to earth John F Kennedy
JFK Stated this one objective in a speech
It is Measurable, either the astronaut returns alive or he does not
Congress passed the funding – it was Agreed
It was Realistic with the technology available at the time (although ambitious) to send a man to the moon
It is Timely, there is time component to the objective
SMART!
Why Projects Succeed
Project Success Factors % of Responses
1. User Involvement 15.9 2. Executive Management Support 13.9 3. Clear Statement of Requirements 13.0 4. Proper Planning 9.6 5. Realistic Expectations 8.2 6. Smaller Project Milestones 7.7 7. Competent Staff 7.2 8. Ownership 5.3 9. Clear Vision & Objectives 2.9 10. Hard-Working, Focused Staff 2.4 Other 13.9
Source: Standish Group, Chaos report, 2007
Why Projects Fail
Project Challenged Factors % of Responses 1. Lack of User Input 12.8%
2. Incomplete Requirements & Specifications 12.3%
3. Changing Requirements & Specifications 11.8%
4. Lack of Executive Support 7.5%
5. Technology Incompetence 7.0%
6. Lack of Resources 6.4%
7. Unrealistic Expectations 5.9%
8. Unclear Objectives 5.3%
9. Unrealistic Time Frames 4.3%
10. New Technology 3.7%
Other 23.0% Source: Standish Group, Chaos report, 2007
Why projects fail – My Experience
The real problem trying to be solved is not understood
The solution is agreed before the problem is understood
There’s no planning. Not just the PM but BAs as well
People don’t talk
People infer and assume rather than getting the facts
Project teams don’t work together to achieve the goal….SILOS and blame
Why projects succeed – My Experience
Everyone is on the one page and understand the end goal
Everyone has a clear role, deliverables and realistic scope/schedule
The project team works together. The business, IT and Vendors are one. Not Silos
The right skills are on the project
MethodGroup business analysis specialists
Business Analysts
BA ROLE IN PROJECTs
Someone who understands the business domain Someone who understands how people behave Someone who looks at the bigger organizational
problems Someone who helps with the management of
artefacts and requirements Someone who can help create diagrams/models to
illustrate system working better Someone who can help capture learnings and adapt
Every project team needs:
The IIBA defintion
A business analyst works as a liaison among stakeholders in order to elicit, analyze, communicate and validate requirements for changes to business processes, policies and information systems. The business analyst understands business problems and opportunities in the context of the requirements and recommends solutions that enable the organization to achieve its goals.
What are BAs really doing
Working in Business and IT projects. Mostly IT. 90% of the time BAs deliver
Business Requirements Functional/Non Functional Requirements Use Cases/ User Stories Requirements Traceability Process Maps and Procedures Data Modelling Lots of workshops/1-1 stakeholder interviews PA services to PM!!!
Good BAs
Have fantastic written and verbal communication Build trusted relationships with Stakeholders and their
team Keep all stakeholders on the one page Plan their activities Have a clear approach to completing deliverables Use modelling, benchmarking and reviews to identify
gaps and ensure quality of business needs and solutions Don’t over analyse. Identify and communicate risks and issues Love unraveling ambiguity Are proactive
Bad BAs
Write down what the stakeholder tells them to write down
Create the requirements themselves rather than engaging the business. Become SMEs
Write confusing requirements and define a solution rather than understanding the business need
Document to-be processes without testing they will work
Sign up to unrealistic deadlines Say yes rather than ask why Act as a PA rather than BA Are reactive
MethodGroup business analysis specialists
Agile Concepts
The Agile Philosophy
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
© 2009 Forrester Research, Inc. Reproduction Prohibited
Kate and Agile
Fast to Market Collaborative Everyone is clear of what they’re responsible for
delivering Team commits to each other Continuous review of approach, products and
outcomes
Sounds great but must choose the right project
Agile Methods
SCRUM Lean XP
Scrum is the most commonly seen
Scrum’s 3 + 3 + 3
Three roles
Product Owner – Describes the Vision. Represents the business and its stakeholders. BA often perform this role.
Helps write user stories Prioritises the product backlog
ScrumMaster – Runs the process. Makes sure the team adheres to the rules Sounds a bit like a Project Manager
Development Team – Build the product Self organising Analyse, Design, Build Test & Train
Scrum’s 3 + 3 + 3
Three artifacts Product Backlog
List of the features requirements that need to be delivered Provides an overview of the business value and development effort
required to build BA play a very important role in helping formulate and prioritizing this list
Sprint Backlog The sprint backlog is the list of work the team must address during the
next sprint. Work is not allocated. Team members pick the next task as required Can be split up into “Done”, “In Progress” and “To-Do”
Burndown Chart Charts the work remaining in a sprint
Scrum’s 3 + 3 + 3 Three Meetings
Sprint Planning Meeting Select what work is to be done Prepare the Sprint Backlog that details the time it will take to do that
work, with the entire team Identify and communicate how much of the work is likely to be done
during the current sprint Daily Scrum Meeting
What have you done since yesterday? What are you planning to do today? Do you have any problems that would prevent you from accomplishing
your goal? Sprint Review Meeting
Review the work that was completed and not completed Present the completed work to the stakeholders (a.k.a. “the demo”) What went well during the sprint? What could be improved in the next
sprint?
The Agile Overview
Agile works best when
Project delivery (and ROI) can be incremental Core team can be co-located and are dedicated
(business and technology) Governance model allows for high visibility and adaptive
planning High commitment and availability of stakeholders and
executive sponsors Scope and/or High Level Requirements are not stable or
clearly known A small team structure which is cross-functionally skilled
is feasible Majority of development is on a single system, although
may interface to many Project has low external dependencies on vendors or
other projects
There are tools to help you confirm your project is a candidate for agile
http://www.hostfrontier.com/.../008_Agile%20Project%20Selection%20Criteria.xls
MethodGroup business analysis specialists
Agile Analysis Vs Traditional Analysis
Agile Vs Traditional Analysis
Project chartering sessions to define vision, identify stakeholders etc
Analyse overall high level plan for project delivery- tasks, time, delivery dates
Conduct product vision and roadmapping workshops
Design and plan release and iteration planning workshops
Requirements planning activities Set the stage to gather requirements for the project, identify stakeholders etc.
Traditional Agile
Agile Vs Traditional Analysis
Plan elicitation techniques suitable for project and stakeholders
Plan, design, and conduct requirements workshops over weeks/months
Plan and conduct short requirements modelling sessions throughout each iteration
identify user acceptance test data in real-time while story is being designed/coded/prepare for testing
Requirements elicitation activities Identify the sources of requirements and then elicit requirements from those sources.
Traditional Agile
Agile Vs Traditional Analysis
Define full scope up front Develop analysis models for all
requirements
Work with customer, to define high-level scope up-front (just-enough scope)
Work with customer to define user stories and develop supporting models if-and-when needed through each iteration
Customer is responsible for prioritization based on business needs and ROI
Requirements analysis activities Understand and refine requirements further so as to help customer prioritize
Traditional Agile
Agile Vs Traditional Analysis
Write a full-blown requirements specification document
Customer and team work together to write user stories
Create user acceptance tests for each story
Determine the form and format of any other documentation that is necessary and sufficient for requirements-related work-in-progress, handover, or product documentation.
Requirements specification activities Refine and organise requirements into documentation
Traditional Agile
Agile Vs Traditional Analysis
Write Requirements Management Plan
Establish requirements baseline, document change control processes and generate requirements traceability matrices
Conduct change control meetings
Smallest necessary requirements attributes are established for each backlog item
Use simple requirements mapping and organization techniques such as story cards on the wall
Changes are considered an important aspect of the Agile approach and these are incorporated quite simply as part of the next iteration
Requirements management activities Monitor the status of requirements and control changes if any
Traditional Agile
MethodGroup business analysis specialists
WRAP UP
Tips to being a great BA in Agile
A change in mindset is required- same work, different tools/format/techniques/physical environment
Learn to keep the requirements slices to a bare minimum necessary until it is just about to be developed
Connect the development team to the ultimate sources of business needs
Get the clients closely involved in the development of the project
You are not the sole custodian of all the requirements, you are part of a self-organizing empowered team
We need to be more adaptable
Work beyond the title of ‘Business Analyst’
MethodGroup business analysis specialists
QUESTIONS?
top related