Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

BA and Beyond 19 - Jan Legtenberg - How to make an agile project succeed

1,263 views

Published on

An agile approach delivers better solutions faster. With that promise in mind a lot of organizations form agile teams that work with backlogs in 2- or 3 week iterations. It is accepted that here are no immediate results because some time is needed to learn this new approach. However, the attempt to become agile becomes a deception when the benefits still don't show after a while. People fall back into old habits and the agile approach seems to have failed. To prevent this kind of deception a business analyst like you can play an important role. Focus on three key factors when transforming to an agile approach:
- Learn the agile principles and live by them (before using the agile methods and techniques)
- Start small and change slowly.
- Involve the business from the start.
In the presentation I will discuss the agile principles and what they mean for the BA, explain why the transformation should occur slowly and stress the importance of cocreation with the business representatives.

Published in: Business
  • Be the first to comment

  • Be the first to like this

BA and Beyond 19 - Jan Legtenberg - How to make an agile project succeed

  1. 1. HOW TO MAKE AN AGILE PROJECT SUCCEED Brussels, March 28, 2019
  2. 2. HOW TO MAKE AN AGILE PROJECT SUCCEED? Brussels, March 28, 2019
  3. 3. AGENDA ■ Agile Principles ■ Take small steps to transform ■ Cocreation ■ Conclusion
  4. 4. AGILE MANIFESTO • Individuals and interactions over processes and tools • Working software over comprehensive documentation • Customer collaboration over contract negotiation • Responding to change over following a plan
  5. 5. 12 AGILE PRINCIPLES Principles MethodsTechniques
  6. 6. 5 AGILE PRINCIPLES FOR THE BUSINESS ANALYST ■ Collaborative working ■ Self organizing teams ■ Continuous improvement ■ Iterative development and incremental delivery ■ Plan for and build in change
  7. 7. COLLABORATIVE WORKING ■ Team 1: Project manager is “scrum master” ■ Team 2: Supplier with own scrum master ■ Located on different floors ■ No collaboration at all Solution: ■ Teams merged and located together
  8. 8. SELF ORGANIZING TEAMS AND CONTINUOUS IMPROVEMENT Scrum master used to be program manager ■ Team wasn’t trusted ■ Tasks were assigned ■ No corrective actions in the PDCA cycle Solution: ■ goals were defined, teams defined the tasks themselves ■ Corrective actions were carried out after a retrospective
  9. 9. ITERATIVE DEVELOPMENT AND INCREMENTAL DELIVERY ■ New ticket vending system Problems ■ no progress to show ■ Stakeholders losing interest Solution ■ Goal decomposition (not functional)
  10. 10. PLAN FOR AND BUILD IN CHANGE Replacing old system ■ 4 scrum teams ■ 1 preparation team ■ Changes weren’t anticipated ■ Backlogitems were planned more than a year in advance Solution ■ Working from the backlog ■ Planning no more than 2 or 3 sprints ahead ■ Time reserved for dealing with changes in “overall planning”.
  11. 11. TAKE SMALL STEPS Circle of concern Circle of influence Circle of control Covey
  12. 12. TAKE SMALL STEPS Circle of concern Circle of influence Circle of control
  13. 13. COCREATION ■ Customer determines value ■ Product owner is not the only customer ■ BA cocreates with: ● Customers ● Developers ● Testers ● Other BA’s
  14. 14. COCREATION Planning ■ Product Owner for each subsystem ■ Key user on site ■ Inexperienced PO supported by BA
  15. 15. CONCLUSION ■ Apply the agile principles ■ Take small steps ■ Cocreate (not only) with the business
  16. 16. Business Analyst and Trainer jan.legtenberg@leblancadvies.nl JAN LEGTENBERG

×