1 / 32

Using ‘Agile’ Methods to Manage Advancement System Changes

Using ‘Agile’ Methods to Manage Advancement System Changes. James 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.

sen
Download Presentation

Using ‘Agile’ Methods to Manage Advancement System Changes

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Using ‘Agile’ Methods to Manage Advancement System Changes James Johannesson Director, Advancement Operations Session #5 – 2:00 – 3:15 PM

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

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

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

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

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

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

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

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

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

  11. Scrum • Impediments are action items for scrum leader • Focuses on coordination through information exchange

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

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

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

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

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

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

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

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

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

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

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

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

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

  25. Product Roadmap • Process allows for feedback and ‘juggling’ of priorities as we go through each iteration. • Executive buy-in is key in stating priorities.

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

  27. 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:

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

  29. Agile Project Management Fixed Variable Customer Problem IT Problem

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

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

  32. Questions James Johannesson james.johannesson@usask.ca

More Related