The agile Business Analyst

1
The agile Business Analyst

• Kent J. McDonald
• Central Iowa IIBA
• Thursday January 25, 2007

2
Agenda

• Conditions of Satisfaction
• Agile principles
• Agile practices and the BABOK
• Discussion

3
Conditions of Satisfaction

• Explain the key principles of agile in terms
  relevant to BAs
• Identify agile practices that fit into each of
  the six knowledge areas of the BABOK
• Explore how certain agile practices may be
  appropriate for use in non agile projects.

4
Agile Principles

• Collaborate
• Iterate
• Serve the Team
• Consider Context
• Practice Excellence
• Reflect and Adapt
• Deliver Value

5
The agile BA

• Understands most available tools
• Uses the appropriate tool
• Knows business and technology
• Language Coach, not a translator
• Champions Business Value
• Facilitates the definition of problems and
  description of solutions

6
Knowledge AreasA Disclaimer

• THESE ARE NOT PHASES!!!!!!!!!!
• The order presented is not meant to imply
  sequence
• Convenient way of categorizing the Analysis
  Toolkit
• Missing knowledge areas attributed to other
  disciplines
• Focus on Requirements shortchanges business
  analysis role

7
Knowledge AreasKents View

• BABOK
• Enterprise Analysis
• Requirements Planning and Management
• Requirements Elicitation
• Requirements Analysis and Documentation
• Requirements Communication
• Solution Assessment and Validation

• This Presentation
• Enterprise Analysis
• Planning and Management
• Elicitation
• Analysis and Documentation
• Communication
• Solution Assessment and Validation

8
Enterprise Analysis

• Understand the business strategy
• Identify Business Value models in terms of the
  organization
• Select projects based on strategic alignment

9
Enterprise AnalysisBusiness Value

• A project creates business value when it
  increases or protects cash flow, profit, or
  Return on Investment
• Should be presented as a model rather than
  statements
• Inputs to business value models become
  constraints on projects
• Success is measured against business value

10
Enterprise AnalysisStrategic Alignment

• Will this activity differentiate us in the
  marketplace?
• Is this activity mission critical to our
  operation?

11
Planning and Management

• Who does what?
• Plan in iterations
• A different perspective on scope and change

12
Planning and ManagementWho does what?

• Team decides who does what (self manage)
• Role of leaders is to Serve the Team
• Subject area owners
• Generalizing specialists
• Team collaborates on standards

13
Planning and ManagementPlan in iterations

• Describe solution at high level in beginning of
  project (placeholders)
• During each iteration dive deeply for a specific
  area of functionality
• Maintain and add to product/system wide models
  such as domain model, process model
• Functionality based plans instead of task based
  plans

14
Planning and managementScope and change

• Scope is realized by a prioritized feature list
• Change is realized by additions to, subtractions
  from, or reprioritization of feature list
• Progress is measured in terms of business value
  delivered thru running tested features.

15
Elicitation

• Collaborative invention
• Define a common language
• Multiple models

16
ElicitationDefine a Common Language

• Stakeholders and development team need to speak
  the same language
• Jointly develop object model/data model/class
  model
• BA facilitates this development
• Data model is progressively completed throughout
  the project
• Data dictionary is also a key part of this
• Language will be precise businessese.

17
ElicitationMultiple Models

• There is no one way to represent facts about the
  solution
• When working with stakeholders to define solution
  utilize different models at the same time to
  establish a complete picture
• Parallel, not sequential
• Pick the right model for the job

18
Analysis and Documentation

• Goal is to define the solution
• Know your audience (who is using the
  requirements)
• One potential format User stories
• Barely Sufficient Documentation

19
Analysis and DocumentationKnow your audience

• Know for whom you are describing the solution
• ASK THEM how they want to see it documented
• Be willing to revise approach based on feedback
  from audience
• Pick the appropriate approach for their needs

20
Analysis and DocumentationUser Stories

• One approach to documenting functional
  requirements
• Add detail in terms of acceptance tests
• Simple format adds discipline to requirements
  format

• As a ltUser Typegt
• I want ltfeaturegt
• So that ltbusiness valuegt
• Given ltPre Conditionsgt
• When ltConditiongt
• Then ltResulting Actiongt

21
Analysis and DocumentationBarely Sufficient
Documentation

• Documents team needs to do work
• Note team, not process
• Low tech tools (Whiteboard, post it notes)
• Use as a communication aid (not the sole form of
  communication)
• Documents customer asks for
• Product deliverables
• (Manuals, materials to support maintenance, etc)
• Tracked along with all other requirements

Ron Jeffries APM Yahoo Group
22
Communication

• Show me!
• The BA as Language Coach
• A word on reviews and signoffs

23
CommunicationShow Me!

• Gain approval thru showing bits of working
  functionality
• Benefit of iterative approach is the delivery of
  working software every 2 4 weeks
• Stakeholders find it easier to provide feedback
  after using software vs looking at documents
• Utilize this opportunity to reflect and adapt
  approach and solution design

24
CommunicationThe BA as Language Coach

• BA should help developers and stakeholders speak
  the common language
• When acting as translator, BA applies their own
  filters to the message
• Use data modeling tools to establish the common
  language discussed before

25
CommunicationA word on reviews and signoffs

• First level of review planning meeting
• Second level of review end of iteration demo
• Signoffs replaced by team agreement on iteration
  plan and release plan

26
Solution Assessment and Validation

• Business solution vs technical solution
• Release planning
• Supporting testing

27
Solution Assessment and ValidationBusiness
solution/technical solution

• Restatement Requirements describe the solution
  to the business problem
• Many different options for realizing the business
  solution technically
• Real options -gt Decide as late as responsible

28
Solution Assessment and ValidationRelease
planning

• Develop high priority functionality first (and
  see benefit from it)
• Prioritize functionality based on delivery of
  business value
• Group functionality in iterations and releases
  based on themes
• Minimum Marketable Features

29
Solution Assessment and ValidationSupporting
testing

• Write requirements as tests
• User story example from earlier
• Given ltPre Conditionsgt
• When ltConditiongt
• Then ltResulting Actiongt
• FIT and Fitnesse

30
Things to Remember

• Focus on business value
• Understand the problem before working on a
  solution
• Expand your toolkit not every problem is a
  nail.
• Requirements describe the business solution and
  are not an end themselves
• Be a Language Coach, not a translator

31
Questions?

• Kent J. McDonald
• kent_at_kentmcdonald.com
• http//www.kentmcdonald.com

32
Kent J. McDonald

• 10 Years Experience as Business Analyst
• Industries Health Insurance, Mortgage,
  Performance Marketing, State Government,
  Automotive
• Environments Rules Engine, Data Warehousing, Web
  applications
• Founder Agile Project Leadership Network
• Covert Agilist