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.

BAFS 2015 Genève : Rainer Wendt - More business in the driver's seat : BA works as PO

1,049 views

Published on

BAFS 2015 Genève : Rainer Wendt - More business in the driver's seat : BA works as PO
http://germany.iiba.org/

Published in: Leadership & Management
  • Earn Up To $316/day! Easy Writing Jobs from the comfort of home!  http://ishbv.com/easywriter/pdf
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Be the first to like this

BAFS 2015 Genève : Rainer Wendt - More business in the driver's seat : BA works as PO

  1. 1. More Business in the driver’s seat Rainer Wendt President of the IIBA Chapter Germany Business Analysts working in the Product Owner Role
  2. 2. Your Speaker today Rainer Wendt, PMP, CBAP, PMI-PBNA, SCT Study of Electrical Engineering in Aachen 25+ years of international IT Experience - Software development in the Nineteenths - Project Lead in Telecommunications and Banks & Insurances - Requirements Engineering, Business Analysis - Risk Management - Change Management - Training, Coaching - Etc. Managing Director masVenta Business GmbH President IIBA Chapter Germany
  3. 3. Agenda • Introduction • Agile Practices are Imperative! • How to engage Business • How can I sell “Agile”? • The Product Owner Dilemma • The Agile Business Analyst
  4. 4. Agile Practices are Imperative! • As the customer (Business) does not know what is needed or they do not have the skills to document it appropriately • As much knowledge necessary to formulate and analyze requirements starts to exist during development It is close to impossible to understand all requirements before a development start • Longer project duration cannot be avoided • Project cost and TCO are increasing, cannot be predicted and deviate significantly from planning In case you need to stick to the Waterfall model, expensive change requests cannot be avoided
  5. 5. The 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. We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: That is, while there is value in the items on the right, we value the items on the left more. http://agilemanifesto.org
  6. 6. Roles and Responsibilities in Agile Context ScrumMaster Product Owner Scrum Team StakeholdersSponsor Business AnalystProject Manager Source: Watermark Learning
  7. 7. What does Business understand under „Agile“? ? ? ? ? ? ? ?
  8. 8. Agenda • Introduction • Agile Practices are Imperative! • How to engage Business • How can I sell “Agile”? • The Product Owner Dilemma • The Agile Business Analyst
  9. 9. Is „Agile“ good or bad for my project? Some typical concerns from Business perspective • More work for us! • Developer anyway do what they want to do – Business can hardly steer them • Documentation mostly „too lean“ and this insufficient for Compliance and Audit purposes • Deliverables are not exactly specified in the contract • Not all bespoken deliverables will make it • High risks with T/M as well as Fixed Price • More involvement for us! • Business will always set priorities – for each sprint • „Changes are always welcome“ – we can change - whenever we want • Ready-to-use features will be available after each Sprint • Fail Fast: If the results of a sprint are not good, the loss is limited • We will be working in one team without boundaries between customer and vendor
  10. 10. • More involvement for us! • Business will always set priorities – for each sprint • „Changes are always welcome“ – we can change - whenever we want • Ready-to-use features will be available after each Sprint • Fail Fast: If the results of a sprint are not good, the loss is limited • We will be working in one team without boundaries between customer and vendor What attitude will the stakeholder have? Which influence factors set the initial mindset re. „Agile“ • More work for us! • Developer anyway do what they want to do – Business can hardly steer them • Documentation mostly „too lean“ and this insufficient for Compliance and Audit purposes • Deliverables are not exactly specified in the contract • Not all bespoken deliverables will make it • High risks with T/M as well as Fixed Price
  11. 11. Typical influence factors are: • Trust in the Agile Team • Trust in the capabilities and skills of the Agile Team • The risk of the project (Impact x Probability) • Experiences with former agile projects • Dominant power of opinion of the colleagues, especially of the boss • Open-mindedness towards new things • Striving for success vs. angst for failure • Training and education, knowledge sovereignty What attitude will the stakeholder have? Which influence factors set the initial mindset re. „Agile“
  12. 12. Agenda • Introduction • Agile Practices are Imperative! • How to engage Business • How can I sell “Agile”? • The Product Owner Dilemma • The Agile Business Analyst
  13. 13. How can I sell „Agile“ successfully?
  14. 14. Open mindedness and honesty (1/2) • Requirements are no longer fixed upfront, but resources and time • Changes or Re-work might have consequences – like non-implementaion of low-prio requirements
  15. 15. Open mindedness and honesty (2/2) From Ryan Matena, Ready for Agile, Projects@Work.com, 9/28/06 Ressources & Time are uncertain Finale Scope is uncertain
  16. 16. Transparency • Explain the Agile Way and adaptations, e.g. how ceremonies like Daily Stand-Ups are taking place in real-life • Simplify, get rid of complexity like over-engineered reporting Excels • Simple Backlog, Burn-Down Chart, Issue Tracker, Risk Register • Communicate plan deviations in a clear and transparent way • Make reporting artefacts easily accessible to stakeholders
  17. 17. References • Show-case about successful „Lighthouse-Project“ • Try to engage a well-known agile team • Walk through reporting artefacts of the project • Describe authentic actions taken on plan deviations • Report real cost saving due to Agile • Errors and Lessons Learned • What has not been implemented?
  18. 18. Knowledge Transfer • Professional Trainings for the Business, e.g. Product Owner in SCRUM • Help Business in writing exemplary Backlog Items (User Stories) and Acceptance Criteria • Ensure that Business stakeholders will have the capabilities and the responsibility for the continuous prioritization of the Backlog items
  19. 19. Agenda • Introduction • Agile Practices are Imperative! • How to engage Business • How can I sell “Agile”? • The Product Owner Dilemma • The Agile Business Analyst
  20. 20. The key person in the Business: The Product Owner
  21. 21. The Dilemma of the Part-Time-PO A Product Owner from Business can hardly dedicate 100% of his capacity to the project The day-to-day Business has normally priority Product Owners from the Business are often lacking experiences and skills in agile Projects Orientation is difficult
  22. 22. A PO-Team as solution Several team members with BA skills can work with the Lead Product Owner on the following tasks: • Defining user roles and personas • Eliciting requirements from stakeholders and users • Defining user stories and acceptance tests • Helping the PO prioritize and manage the Product Backlog • Facilitating user story workshops • Building requirements runway for upcoming iterations • Identifying themes for releases • Contributing to release and iteration planning • Identifying and estimating business analysis tasks • Analyzing business and technical impacts of requirements Source: Watermark Learning
  23. 23. The PO-Team (An Example) I am the Lead PO I am a Business Analyst I am a Dev SME The Lead PO from the Business has the final say re. the value-oriented prioritization The Business Analyst manages the Backlog The Business Analyst formulates User Stories and Acceptance Criteria The Development Subject Matter Expert gives advice re. technical dependencies, feasibility and risk
  24. 24. Agenda • Introduction • Agile Practices are Imperative! • How to engage Business • How can I sell “Agile”? • The Product Owner Dilemma • The Agile Business Analyst
  25. 25. The Agile Business Analyst (BA) • The Product Owner (PO) is often focused on strategic, product and release-level activities • Preparing the business case, analyzing the market, defining the product roadmap, and defining release plans • A Business Analyst can supplement the PO with a focus on tactical, iteration-level activities Source: Watermark Learning
  26. 26. Applied SCRUM • Typically in real life, the Business Analyst has the role of the Product Owner or (s)he supports the PO, especially if the contribution of a Business-PO is not sufficient • Requirements from the Product-Backlog are being planned according to criteria like priority, stability etc by the PO/BA „on behalf of Business“ • The Business Analyst in his PO role is mostly a „Communication Facilitator“ Business Analyst / Product Owner Source: German Wikipeda Business
  27. 27. Summary • Trust is the foundation for Agile Practices • Trust can be built through Honesty, Transparency and Knowledge • The Product Owner in Business needs support for the continuous elicitation and prioritization of the requirements (User Stories) • Business Analysts from IT can provide this support which helps bridging the gap between Business and IT
  28. 28. More Business In The Driver Seat! Any Questions?

×