More Business in the driver’s seat

Rainer Wendt

President of the IIBA Chapter Germany

Business Analysts working in the Product Owner Role

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

Agenda

• Introduction

• Agile Practices are Imperative!

• How to engage Business

• How can I sell “Agile”?

• The Product Owner Dilemma

• The Agile Business Analyst

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

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

Roles and Responsibilities in Agile Context

ScrumMaster

Product Owner

Scrum Team

Stakeholders Sponsor

Business Analyst Project Manager

Source: Watermark Learning

What does Business understand under „Agile“?

?

?

? ?

?

? ?

Agenda

• Introduction

• Agile Practices are Imperative!

• How to engage Business

• How can I sell “Agile”?

• The Product Owner Dilemma

• The Agile Business Analyst

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

• 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

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“

Agenda

• Introduction

• Agile Practices are Imperative!

• How to engage Business

• How can I sell “Agile”?

• The Product Owner Dilemma

• The Agile Business Analyst

How can I sell „Agile“ successfully?

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

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

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

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?

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

Agenda

• Introduction

• Agile Practices are Imperative!

• How to engage Business

• How can I sell “Agile”?

• The Product Owner Dilemma

• The Agile Business Analyst

The key person in the Business: The Product Owner

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

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

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

Agenda

• Introduction

• Agile Practices are Imperative!

• How to engage Business

• How can I sell “Agile”?

• The Product Owner Dilemma

• The Agile Business Analyst

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

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

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

More Business In The Driver Seat!

Any Questions?