Applying evo to a project An Agile and EVO Workshop Based on the article Measuring Agile Value in Overload 89, by Ryan Shriver, and used with his permission.

Applying evo to a project

An Agile and EVO Workshop

Based on the article ‘Measuring Agile Value’ in Overload 89, by Ryan Shriver,

and used with his permission.

Value should drive the planning

http://www.gilb.com/tiki-download_file.php?fileId=462

Deliver value earlier

http://www.gilb.com/tiki-download_file.php?fileId=462

Give developers freedom to work with stakeholders

• Control projects by quantified critical-few results. 1 Page total !• (not stories, functions, features, use cases, objects, ..)• Make sure those results are business results, not technical• Align your project with your financial sponsor’s interests!• Give developers freedom, to find out how to deliver those results• Estimate the impacts of your designs, on your quantified goals• Select designs with the best impacts for their costs, do them first.• Decompose the workflow, into weekly (or 2% of budget) time boxes• Change designs, based on quantified experience of implementation• Change requirements, based on quantified experience, new inputs• Involve the stakeholders, every week, in setting quantified goals• Involve the stakeholders, every week, in actually using increments

Continually deliver results

Learn from deviations

Use worksheets and handouts

Agile doesn’t always keep track of business value

Agile doesn’t say ‘option a brings us closer to our goal, than option b by x compared to y percent’.

Agile doesn’t check ‘how well’ we’re meeting the performance or bringing ‘value’ to the business through our features.

Value for the business

What is value? What do we mean when we say agile delivers business value?

How do you measure value?

What do you measure it with (and when)?

Deliver the right things, and deliver things right

Teams can perform agile flawlessly only to find out they were doing the wrong project all because they didn’t understand the real business objectives.

The result is an investment that may result in running software that delivers no business value despite the (apparent) success of the agile process. Whoops!

Check the business value

Agile assumption that client has explored the options to meet their needs, instead of double-checking that there isn’t a better way to meet the goals.

Emphasis on clear communicationValue delivery advocates measuring value

using quantified business objectives in alignment with business strategies.

Value delivery advocates a systems-thinking approach that encourages teams to think holistically about the problem space using numbers to assess the impact of designs on objectives

The example scenario is a non-profit volunteer association

Currently use scrum method of agile, sprints, and backlog, etc for delivering software. This will fit in smoothly to our value approach.

Read the mission statement

Determine main strategic goals of the organisation. Write them out.

Know the business goalsNancy, has personally asked us if we could help her

and the organization:

1. Establish a set of strategic objectives so value can be measured and managed

2. Make smart funding decisions with web site improvements so budget and risk can be managed

3. Identify the improvements with the best ‘bang for the buck’ for doing first so quick progress can be demonstrated to everyone.

Step 1: identify stakeholders, objectives, & resources

• Who are my stakeholders?

• What are their objectives?

• What resources are available?

• Go through statements to see if can identify answers to these questions.

Step 2: quantify objectives to clarify requirements

Gilb: ‘The fact that we can set numeric objectives, and track them, is powerful; but in fact is not the main point. The main purpose of quantification is to force us to think deeply, and debate exactly, what we mean; so that others, later, cannot fail to understand us. ‘

Templates help determine information

HANDOUT a template and guide on targets, constraints and benchmarks plus HANDOUT of documents that contain the ones associated with the ones that we need.

Step 3: identify targets, constraints and benchmarks

• Targets, as the name suggests, are the performance levels the team is striving to achieve.  

• Constraints are the levels that must be avoided.

• Benchmarks are the levels achieved today or what’s been achieved in the past.

Determine scales and metersScale – What’s measured (units)

Meter – How it’s measured (method)

Targets – Levels aiming to achieve

Constraints – Levels trying to avoid

Benchmark – Current or past performance levels

Qualifiers – Dates, places or events useful for clarification

Sources – Origin of information for transparency and credibility

Step 4: brainstorm design ideas

Find ideas to meet all of the objectives, not just one or two of them.

Look at the handout and identify ones that will work, and come up with others if you can.

Step 5: select the next best design

• Go over IE table format – template for use – documents that support effectiveness for designs and show their cost. EXPLAIN how to complete template

• This is a simple ratio of the sum impact of objectives divided by the sum impact on resources (i.e. sum objectives impact / sum resources impact).

Step 6: build the iteration with agile

Teams develop user stories for functional requirements to document what system will do

Teams prioritize non-functional requirements, and use planguage for clarity

Teams estimate stories as normal, and to determine amount that can be accomplished in each iteration

Step 7: measure the value realised in the iteration

Repeat the steps until objectives achieved, or time

ended, etc