More important than ever:
  The Business Analysts’ role in
    Agile software development
IIBA Conference, September 2009
...
Allan Kelly, BSc, MBA
  Consulting, Training & Coaching
   for Agile adoption and deepening
  Author:
     Changing Sof...
Agile
  What   is it?
   and   Lean?




                   3
“Agile processes promise
                                                   to react flexibly to
   What is Agility?      ...
Agile
  Its   the business need, stupid




                                     5
Agile in context
More
prescriptive
                        XP
                       Scrum
                         …




...
1999-2004: Agile = XP
  Extreme   Programming
   First
        Agile method to gain popularity
   Developer centric pra...
2005-today: Agile = Scrum
  Scrum
   Aproject management method
   without a project manager
  Product Owner specifies ...
Who is the
Product Owner?

                                   Business
Subject                            Analyst
Matter /...
Traditional approach
                           Business Analysis /
                           System Analysis




Royce, ...
11
BA/Product Owner
 Traditional approach
 Agile approach                              works ahead of
                       ...
BA/Product Owner
                                    works ahead of
                                    team - scouting ou...
Close quarters requirements
  Goals    and objectives
     replace Big Requirements Documents
     under continual revi...
Business Analysts, move on up
  Filling
        the Product Owner
  role well BA need to:                Business Analysi...
Less (software) is more
Potentially 80% of software            Only about 20% of
development work is waste             fea...
But....
   There   is a time and a place for everything
                         ....


 Requirements come second when
 ...
The Alignment Trap
                         IT Highly aligned

                                                          ‘...
When adopting Agile
 Sequence the changes
1.  First Do it right
   Management    focus on the development team
2.  Do not...
Project constraints
Product
                                 Resources
Owner
needs to     Features            (People)
mak...
More work for Product Owners
   Less work for Project Managers
•  Negotiate over feature delivery                      •  ...
More work for Product Owners
  Less work for Project Managers
•  Negotiate over feature delivery              •  Self orga...
More work for BA’s
  More    work for BA’s
   More/better analysis can reduce work load in time
   More responsible for...
Take aways
1.  Being Agile means delivering business needs
2.  Product Owner is often a BA
     Agile process does not re...
Thank you
allan@allankelly.net
http://www.allankelly.net
http://blog.allankelly.net
http://www.softwarestrategy.co.uk


  ...
Upcoming SlideShare
Loading in...5
×

The Business Analysts Role in Agile Software Development

12,130

Published on

Latest version of this popular talk given at Skills Matter 22 July 2010

Published in: Technology
0 Comments
6 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
12,130
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
0
Comments
0
Likes
6
Embeds 0
No embeds

No notes for slide

The Business Analysts Role in Agile Software Development

  1. 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. 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. 3. Agile   What is it?   and Lean? 3
  4. 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. 5. Agile   Its the business need, stupid 5
  6. 6. Agile in context More prescriptive XP Scrum … Kanban Agile More Lean thinking philosophical: value, idea Organizational Learning based Applicability
  7. 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. 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. 9. Who is the Product Owner? Business Subject Analyst Matter /Domain Expert Product Manager 9
  10. 10. Traditional approach Business Analysis / System Analysis Royce, 1968, “Managing the Development of Large Software Systems” 10
  11. 11. 11
  12. 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. 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. 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. 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. 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. 17. But....  There is a time and a place for everything  .... Requirements come second when changing to Agile 17
  18. 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. 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. 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. 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. 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. 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. 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. 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

×