Monday June 8 Session #5 – 2:00 – 3:15 PM

Using ‘Agile’ Methods to Manage Advancement

System ChangesJames Johannesson

Director, Advancement Operations

Overview• Setting Context• Values & Principles behind agile methods• What methods are available• What has been our experience• Tools that have helped along the way• Questions

Context at UofS• U of S has a home grown system for

Advancement, but interacts with Banner and Peoplesoft ERPs.

• Team of application development staff report professionally to central IT but functionally to Advancement – small team (5 staff).

• Team of application development staff physically located with Advancement staff.

• Technical staff supporting database and system solely central IT staff and not located with developers.

Context at UofS• Usually have one to three projects in a

year (3 months to at least a year in duration)

• Ongoing operational requirements – need to keep the system going

• Technical requirements (software version and hardware upgrades)

Why did we change?• We were not focused on a method – just get the

work done that was deemed ‘important’ unless it was a big project.

• Big projects used ‘waterfall methods’ – requirements & design documents, test plans, etc. to mark progress. Very structured and a lot of documentation.

• Some ‘cowboy’ coding in between projects – programmers did what they felt was right or needed – may not align with business need

Can I use ‘Agile Methods’?• Can apply to both ‘build’ and ‘buy’ models• Can apply to IT staff that are solely within

Advancement.• Can apply to central IT staff.• Can apply in a federated model like the

UofS.• Important point: Understand the VALUES

and PRINCIPLES and LIVE THEM.

‘Agile’ Values• Individuals and interactions over

processes and tools• Working software over comprehensive

documentation• Customer collaboration over contract

negotiation• Responding to change over following a

plan

Agile Principles• Customer satisfaction by introducing rapid,

continuous change of useful software• Cooperation between business and developers• Face to Face communication• Look to motivated and engaged users• Technical excellence• Respond to change over ‘sticking to the plan’• Self organizing and simplicity required – focus

on need, not want

Our Use of Agile Methods• Scrum• Iterative Development - Sprints• Use Cases• Product Roadmap• Agile Project Management• Tools that helped along the way

Scrum• Daily Meeting – same time, same place – 15

minutes• Scrum leader facilitates – usually lead person in

area but could be anyone• Each team member answers three questions:

• What did I do yesterday?• What am I doing today?• What impediments are getting in your way?

Scrum• Impediments are action items for scrum

leader• Focuses on coordination through

information exchange

Is this micro-managing?• No. Not telling anyone how to do work in

15 minutes. • Team is required to solve problems, not

manager.• Items that are for further discussion are

done by team after scrum is completed.

What does Scrums allow you to do?

• Deal with emergent issues.• Deal with personal issues between staff.• Help the team connect the ‘dots’ to

improve effectiveness

Our Experience• Daily meeting at 9 AM in team room.• Have been running them for two years.

They can work both in ‘projects’ and in dealing with ‘operations’ and are very effective in balancing them.

• Only works if as a leader you work hard to remove impediments to get buy-in to process.

Iterative Development• Work is broken into a time block or iteration – we

have chosen two weeks – called the Sprint• Work required to be done is given an estimate of

time to complete by a programmer in ‘effective days’

• Estimate a iteration has 6 to 7 ‘effective’ days of work in it (10 work days)

• If a change is said to take more than 6 or 7 effective days (65 %), break the task down to smaller tasks.

Sprint • Iteration Planning Meeting – Determine

what will be done.• Daily Scrums – talk about it daily• Release Planning Meeting – Determine

what is going to which environment (TEST or PRODUCTION).

Iterative Development• Three tasks that take two days each – all

that is assigned that developer• Why do it this way?

• More realistic• Allows you to respond to changes or

operational issues• Planning to 100% is NOT effective and

usually means you are ‘over-planning’

Estimation – Critical Skill• Seems the most difficult task in IT• Breaking down tasks to small timeframes is easier to

comprehend and makes team think more modular• Allows staff to gain experience to plan bigger tasks.• Gets away from the concept that all programmers

are ‘pathological liars’• Holds staff accountable because they are the ones

giving the estimates.

Our Experience• Have done iterations with releases to

PROD every two weeks for a year and a half

• User Community use to having something new every two weeks – has become more engaged

• Programming staff much better at estimating time to make changes

Use Cases• Description of a system’s behaviour• “Who” can do “what” with the system in

question – captures behavioural requirements

• Aids greatly with users to describe how they want the system to act

Example Use Cases• A donor had indicated a bequest to the U of

S previously. This donor has recently become deceased and U of S will be receiving the estate disbursement. The family members have expressed the wish to continue to receive mailings from the U of S on behalf of their father and receive updates with regards to how their father’s gift is being used.

Use Cases• Use cases gives the requirements the

system needs to fulfill.• The goal in requirements and design

become how to allow the ‘system’ to meet the use cases outlined and as the business develops new use cases have the system able to cope with it.

Our Experience• Have been using these as the formation of our

development over the last year.• Very helpful in having the users document what

they expect from the system. Added benefits are that as business use changes over time, you examine how you make the system work within the new use cases.

• Very helpful in ‘Buy’ systems where you look to use the system to meet business needs

Product Roadmap• Roadmap is plan looking forward in time to

determine changes to the system based on business priorities.

• Using iteration planning Advancement has a roadmap out to 4 months the future to indicate system changes planned.

• Published to our user community and ius based on the discussion and decision from our executive leadership.

Product Roadmap• Process allows for feedback and ‘juggling’

of priorities as we go through each iteration.

• Executive buy-in is key in stating priorities.

Our Experience• Extremely helpful in getting executive buy-

in and establishing priorities. • Roadmap is executive’s statement of

change, not IT’s statement.• Understand trade offs of resources for

work.• We have used this the last six months with

great success.

Agile Project Management• Its just using all of the previous methods

and placing them in the context of a project.

• Key point in this are to use a model that looks like:

Envision Speculate

Explore/Adapt Close

When do you use Agile PM?• When requirements or scope are uncertain• Committed customers and experienced

development team• Application evolution over build to

specification• Changes are ‘cheap’ – more thought

required in ‘buy’ systems.

Agile Project Management

Functionality

Schedule

People/Money

Schedule

Functionality

People/Money

Fixed

Variable

IT Problem Customer Problem

Our Experience• Changes to tracking of planned giving

donors• Created charter to set scope and set up

iteration plan to achieve work based on estimates

• Developed use cases and set roadmap• Altered based on feedback in process• Total time to completion – 8 weeks

Tools that helped• Bug & Version Tracking – JIRA (

http://www.atlassian.com/software/jira/)• Templates for Use Cases• Wiki for documenting changes – users can

add comments to documentation.• Code Management• Testing software (on our wish list)

Questions

James Johannessonjames.johannesson@usask.ca