BA and Beyond 19 - Jan Legtenberg - How to make an agile project succeed
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.
Recommended
Recommended
More Related Content
More from BA and Beyond
More from BA and Beyond (20)
Recently uploaded
Recently uploaded (20)
BA and Beyond 19 - Jan Legtenberg - How to make an agile project succeed
- 2. HOW TO MAKE AN AGILE PROJECT SUCCEED Brussels, March 28, 2019
- 3. HOW TO MAKE AN AGILE PROJECT SUCCEED? Brussels, March 28, 2019
- 5. AGENDA ■ Agile Principles ■ Take small steps to transform ■ Cocreation ■ Conclusion
- 6. 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
- 8. 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
- 9. 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
- 10. 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
- 11. ITERATIVE DEVELOPMENT AND INCREMENTAL DELIVERY ■ New ticket vending system Problems ■ no progress to show ■ Stakeholders losing interest Solution ■ Goal decomposition (not functional)
- 12. 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”.
- 13. TAKE SMALL STEPS Circle of concern Circle of influence Circle of control Covey
- 14. TAKE SMALL STEPS Circle of concern Circle of influence Circle of control
- 15. COCREATION ■ Customer determines value ■ Product owner is not the only customer ■ BA cocreates with: ● Customers ● Developers ● Testers ● Other BA’s
- 16. COCREATION Planning ■ Product Owner for each subsystem ■ Key user on site ■ Inexperienced PO supported by BA
- 17. CONCLUSION ■ Apply the agile principles ■ Take small steps ■ Cocreate (not only) with the business
- 18. Business Analyst and Trainer jan.legtenberg@leblancadvies.nl JAN LEGTENBERG