How to foster Engagement and Understanding using Agile principlesDavid MorrisProgram Architect, Salesforce

Lloyd HomerSenior Consultant, Methods Digital

David MorrisBackground

Currently

@dsmorris85

• 14yrs+ in Software Delivery• Experienced in:

• Agile Project Management• Technical Design / Architecture• Custom Development

Program Architect @ SalesforceLondon, UK

Lloyd HomerBackground

Currently

@iamlloydhomer

Senior Consultant @ Methods DigitalLondon, UK

• 10+yrs in Project Delivery• Experienced in:

• Digital transformation (incl. CRM)

• Service & Engagement modeling

• Agile Project Management

An example situation…!

They don’t understand how hard

this is!

I’m overloaded and can’t

get anything finished!

How am I going to

get everything

done?

Salesforce is supposed to be easy! I

saw it work at

DreamForce!

Why do the

delivery dates

always slip?

Why doesn’t it work like I wanted it

to?

Your Stakeholder(s)!! You!!

Do not despair!! While there is life, there is hope…We are going to look at how some ideas from Agile delivery practices can be used to help, namely:

Product Backlogs

User StoriesAcceptance Criteria

Complexity Points

We are going to look at these with the help of a few scenarios.

But first… what it means to be “Agile”…

“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

• Individuals and interactions over processes and tools• Working software over comprehensive documentation• Customer collaboration over contract negotiation• Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.”

For more information see: “The Agile Manifesto” - www.agilemanifesto.org/i

Examplex150+ open items.xBig items treated the same as

small ones.xVarious lists maintained.xDue dates never hit.xPriorities constantly shifted.xLots of work ‘half-done’.xLots of inertia in tickets.xLots of unhappiness!

Scenario AScenario A – “We are overloaded, nothing gets done!”

Your Stakeholders

Our Awesome Admin!(you)

Lists of work to do..

Scenario A – “We are overloaded, nothing gets done!”

One Product Backlog, controlled by admin.

Items prioritised against one another with stakeholders.

Difficulty measured by ‘Complexity points’ not ‘Days’.

Stakeholders gained deeper understanding.

ExampleHow to do it:1. Create your own Product

Backlog in Excel and track all work in it;

2. Estimate ‘Complexity Points’ for each item (see next slide);

3. See how many points you can finish in a week;

4. After 3 weeks, calculate the average points done per week;

5. Let your stakeholders choose what items you work on. They can choose whichever items they want, as long as the total points selected do not exceed your average.

6. Repeat

A little bit more about Complexity Points

50 – a big project! Need help!!

0.5 – no problem!

5 – Ok, it’s a bit hard but I can get it done!

13 – Might need help on this one!

Every request is sized…

20 – need to break down this into smaller items.

… and the points you deliver can become a valuable metric.

These metrics can show productivity over time, and can be used to estimate the impact of improvements (e.g. getting new resources / people) on overall

delivery.

Now – does this seem at all familiar?The lesson is…

We are all different, and think different, thus our interpretations vary from person-to-person.

Scenario BScenario B – “That’s great, but where is what I wanted?!?”

Examplex Tickets delivered did not

match what was asked for.x Bugs and Quality issues in

what was being built.x Areas of requirements missed

during build, that would require re-work and extra development to fix.

x Disagreement about if something was done properly, was common.

Our Admin Heros!

Work Item

What the?!?

New Initiative!

Example

Scenario B – “That’s great, but where is what I wanted?!?”

How to do it:1. For each work item, break it down

into ‘Stories’ that need to be completed.

2. For each story, make sure it is written in user-friendly and clear language that could be understood by most people.

3. For each story, ask the business stakeholder to write a list of ‘Acceptance Criteria’

4. When doing the work, do not return it to the stakeholder until it passes their Acceptance Criteria.

5. Repeat

‘Stories’ written, not documents.

Each story had ‘Acceptance Criteria’, written by the business.

Stories were not ‘Done’ unless they passed the Acceptance Criteria.• As a: Service Agent

• I want: to quickly open a new closed Case from the Account screen

• So that: I can more efficiently log completed cases.

A little bit more about Stories / Acceptance Criteria

User Stories makes things easier to understand…

Acceptance Criteria makes things easier to get right…

Note: Acceptance Criteria can be short / sharp, or complex – whatever is most useful.

1. Service Manager can change the cold call priority order to be based on highest customer value first.

2. Service Manager can change the cold call priority order to be based on when the next call is due.

3. Service Agent does not have access to change priorities

4. Service Agent cannot cherry-pick the cold call tasks they want.

• As a: Customer Service Manager• I want: to be able to change the

priority of new cold call tasks regularly, based on customer value or next call date.

• So that: I can ensure my agents are working on the most effective opportunities.

If a change meets the Acceptance Criteria, then the story / task can be considered completed.

RecapUsing Agile Principles, you can create a Product Backlog that consists of easy to understand User Stories, prioritised by your stakeholders. These are sized up with Complexity Points and their quality is assured with Acceptance Criteria written on their terms.With this in place you can estimate, plan and articulate metrics that can change your companies understanding of software delivery.

If something doesn’t feel right, remember, you can always look to ask, speak to or engage someone about what can improve.Part of practicing Agile is understanding we are all in a continuous learning experience.

Remember 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.

Thank you