Applying evo to a project

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

2. Value should drive the planning http://www.gilb.com/tiki-download_file.php?fileId=462

3. Deliver value earlier http://www.gilb.com/tiki-download_file.php?fileId=462

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

5. Continually deliver results

6. Learn from deviations

7. Use worksheets and handouts

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

9. 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)?

10. 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!

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

12. Emphasis on clear communication Value 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

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

14. Read the mission statement Determine main strategic goals of the organisation. Write them out.

15. Know the business goals Nancy, 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.

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

17. 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. ‘

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

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

20. Determine scales and meters Scale – 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

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

22. 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).

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

24. Step 7: measure the value realised in the iteration

25. Repeat the steps until objectives achieved, or time ended, etc