The document discusses the role of business analysts in agile software development. It argues that in traditional approaches, requirements are gathered at the start of a project by business analysts who then leave the project. However, in agile approaches, requirements gathering is an ongoing process and business analysts need to stay involved throughout to have a dialogue rather than just produce documents. The business analyst role evolves from an "order taker" to an internal consultant, facilitating discussions between business and development teams.

1. More important than ever:
The Business Analysts’ role in
Agile software development
IIBA Conference, September 2009
IIBA Nottingham, May 2010
Allan Kelly
Big Airline, June 2010 allan@allankelly.net
Skills Matter, July 2010
http://www.allankelly.net
Software Strategy
http://www.softwarestrategy.co.uk1

2. Allan Kelly, BSc, MBA
 Consulting, Training & Coaching
for Agile adoption and deepening
 Author:
 Changing Software Development:
Learning to be Agile, Wiley 2008.
33 Business Strategy
Patterns for Software
97 Things Every Programmer Creators
Should Know, Henney, 2010
Context Encapsulation in Pattern
Languages of Program Design
volume 5, 2006

3. Agile
 What is it?
 and Lean?
3

4. “Agile processes promise
to react flexibly to
What is Agility? changing requirements,
Jim Highsmith, thus providing the
2002 “Agility is the ability to highest business value
both create and to the customer at any
respond to change in point in time”
order to profit in a
turbulent business
environment.”
Jutta Eckstein 2004
 Today: Agile as Better
 Respond to changing (business) environment
 Faster, more productive, higher quality
 Tomorrow: Agile creates new business models
 Opportunities for those not confined by traditional IT4

5. Agile
 Its the business need, stupid
5

6. Agile in context
More
prescriptive
XP
Scrum
…
Kanban
Agile
More
Lean thinking philosophical:
value, idea
Organizational Learning based
Applicability

7. 1999-2004: Agile = XP
 Extreme Programming
 First
Agile method to gain popularity
 Developer centric practices and literature
 Business need from onsite Customer
 Customer on C3 was a Business Analyst
 “Customer” view too simplistic
 Short sighted
 Assume customer knows
 No discussion on how the customer knows
7

8. 2005-today: Agile = Scrum
 Scrum
 Aproject management method
without a project manager
 Product Owner specifies need
 Scrum silent on how the
Product Owner knows
8

9. Who is the
Product Owner?
Business
Subject Analyst
Matter /Domain
Expert
Product Manager 9

10. Traditional approach
Business Analysis /
System Analysis
Royce, 1968, “Managing the Development
of Large Software Systems” 10

11. 11

12. BA/Product Owner
Traditional approach
Agile approach works ahead of
team - scouting out
requirements
6+ months
 Slice through
work
Decide requirement Decide requirement
 Everything in
iteration
 End-to-End
Analysis / Design Analysis / Design
 Deliver business
functionality
Code & Unit Test Code & Unit Test
Merge & Release
Merge & Release
Iteration 1 (2 weeks) Iteration 2 (2 weeks)

13. BA/Product Owner
works ahead of
team - scouting out
requirements
 Slice through
work
Decide requirement Decide requirement
 Everything in
iteration
 End-to-End Analysis / Design Analysis / Design
 Deliver business
functionality
Code & Unit Test Code & Unit Test
Merge & Release Merge & Release
Iteration 1 (2 weeks) Iteration 2 (2 weeks)

14. Close quarters requirements
 Goals and objectives
 replace Big Requirements Documents
 under continual review
 Requirements gathering is ongoing process
 rather than only at the start
 BA needs to stay involved
 rather than leave after initial stages
 Delivered functionality changes and evolves
 in direction of the goal and objective
 More to it than requirements gathering
 Dialogue over document
14

15. Business Analysts, move on up
 Filling
the Product Owner
role well BA need to: Business Analysis
Maturity Model
 Move up Maturity Model r
tOwne
 From Order taker duc
Pro
 To Internal Consultant
 Improving business
effectiveness
Source and more details on BAMM:
http://www.assistkd.com/bamm/bamm.html
15

16. Less (software) is more
Potentially 80% of software Only about 20% of
development work is waste features & functions
• Better requirements can reduce
in typical custom
demand by 80%
software are used
If 30+% of requirements
change then We often encounter
• Why bother doing work on them in requirements churn
the first place? of 30% to 50%
Solution: Mary & Tom Poppendieck
Implementing Lean Software
• Just In Time Requirements Development 2007
• Identify, implement, deliver in
quick succession 16

17. But....
 There is a time and a place for everything
 ....
Requirements come second when
changing to Agile
17

18. The Alignment Trap
IT Highly aligned
‘Alignment trap’ ‘IT Enabled growth’
Challenge 1: 11% companies 7% companies
Doing the right thing
• Get Agile • IT spending +13%
higher than average
• IT spending 6% less than
average
• From Maintenance to • Sales -14% over 3 • Sales growth +35% over
Well-oiled years 3 years
• Delivery focus
‘Maintenance zone’ ‘Well-oiled IT’
74% companies 8% companies
Challenge 2:
• Average IT spending • IT spending 15% below
• From Well-oiled • Sales -2% over 3 average
• To Growth years • Sales growth +11% over
• Requirements focus Less
aligned
3 year
IT Less Doing things right IT More
Effective Effective
Source: Shpilberg, Berez, Puryear, Shah: MIT Sloan Review, Fall 2007

19. When adopting Agile
Sequence the changes
1. First Do it right
 Management focus on the development team
2. Do not emphasis requirements or BA role
3. Get developers more effective
Then
4. Do the right thing
 Focus on the what
5. Long term benefits in BA role 19

20. Project constraints
Product
Resources
Owner
needs to Features (People)
make these
trade offs
Fixed in
the short run
(Brooks Law)
Scope creep Time
(run backwards)
Time boxed
Agile projects negotiate over requirements
rather than resources or time 20

21. More work for Product Owners
Less work for Project Managers
• Negotiate over feature delivery • Self organizing teams
• Not when • No task allocation
• Flexible release plan Project • Tracking by delivery
• Not Gantt chart Manager • Not % complete
• Measure value delivered • Commitment over
• Not time spent estimates
• Changing requirements
• Not work packages
BA/Product
• Sustainable pace Development
• No whip cracking
Owner team
21

22. More work for Product Owners
Less work for Project Managers
• Negotiate over feature delivery • Self organizing teams
- Not when - No task allocation
• Flexible release plan Project
Manager
• Tracking by delivery
- No Gantt chart - Not % complete
• Measure value delivered • Commitment over
- Not time spent estimates
• Changing requirements
BA/Product - No work packages Development
Owner • Sustainable pace
- No whip cracking team
22

23. More work for BA’s
 More work for BA’s
 More/better analysis can reduce work load in time
 More responsible for value delivered
 More conversations with Developers
 Writing/Creating acceptance tests
 Slack for Just in time requirements (Queuing theory)
 Move from requirements push to needs pull
 Therefore... 1 BA for every 3 to 7 developers
 Stable product: 1 BA -> 7 developers
 Rapid change: 1 BA -> 3 developers
23

24. Take aways
1. Being Agile means delivering business needs
2. Product Owner is often a BA
 Agile process does not remove need for needs
3. BA take a back seat in early transition
 Step forward as team becomes effective
 Key in reducing work to be done
4. Product Owner role is larger than BA role
 Need greater staffing
 Shift from Requirements Push to Need Pull
24

25. Thank you
allan@allankelly.net
http://www.allankelly.net
http://blog.allankelly.net
http://www.softwarestrategy.co.uk
1 3 -1 BA t
5 Se rainin
24-2 p g
6 No – www course
v–w .skil s
ww.s lsma
killsm tter.co
atter m
.com
25