Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Custom agile approach for atf analytics


Published on

Sometimes, teams are faced with projects that don't align with Scrum or the Agile Guides. Whether because of organizational restrictions, or unique circumstances of the project, teams sometimes need to improvise in order to deliver. In this talk, Dave Pradko talks about a custom agile approach developed for a government agency.

Published in: Government & Nonprofit
  • Be the first to comment

  • Be the first to like this

Custom agile approach for atf analytics

  1. 1. Custom agile* for ATF Analytics *yes, it’s “little a agile” on purpose
  2. 2. Overview • Common Difficulties Implementing Agile • ATF and its Mission • Agile at ATF • The ATF Analytics Project - Overview • Pros & Risks of an Agile Approach • The ATF Analytics Custom agile Approach • What We Achieved • What We Learned • Changes Moving Forward
  3. 3. Common Difficulties Implementing Agile • No Buy-in from senior leadership • Extra visibility / fear of failure • No idea how to start • Mindset & Self Organization • Wagilefall, Scrumfall, Bi-modal IT
  4. 4. ATF and its Mission • Federal law enforcement division with Dept. of Justice • Regulation of Firearms and Explosives • Recently challenged by DOJ to be more “evidence based”
  5. 5. Agile at ATF • Agile is recognized and promoted as a preferred software development methodology at ATF • Other separate, but related projects have been recent Agile successes
  6. 6. The ATF Analytics Project - Overview • Part of related IT developments within ATF: • Modernizing multiple IT platforms and systems • Developing an Enterprise Data Warehouse (EDW) • Migrate to a new reporting tool for ATF Analytics • Coordinate with Modernization effort to “keep the lights on” • Figure out if consumers of current reports were having their needs met • Use improved technology and understanding of business needs to develop better, more data-driven reporting
  7. 7. Pros & Cons of an Agile Approach Pros • Focus on delivering value over delivering on a plan • More flexibility with schedule changes of others • Team members experienced at self-organizing Risks • Might be seen as not having a schedule or a plan • Might find other high priority issues that users wanted addressed
  8. 8. ATF Analytics agile Overview
  9. 9. Product Teams • Each product team meets regularly • Product Owner and product team members • 2-3 times / week to start • May reduce as time goes on • Create user stories using templates • Prioritize user stories within product team • Product Owner takes user stories to Governance Board meetings • Agile Coach available for assistance
  10. 10. Governance Board • Determines overall look and feel of dashboards and reports • Weekly meetings to review and prioritize user stories • Each Product Owner, Agile Coach, other key stakeholders • Review user stories • Prioritize user stories across product teams • Backlog grooming and sprint planning
  11. 11. Development • User stories are groomed via the Backlog; top priority user stories get developed first • Conversion Checklist helps estimate amount of development work needed • User stories categorized as: • To-Do • In Progress • Done • Team grooms the backlog based on: • Priority • Dependencies • Questions / Blockers
  12. 12. Validation • Demonstration • Demo of developed user story • Enhancements • Elicit end user feedback • Feedback captured; create new tickets • Retrospective • Lessons Learned • Suggestions for improvement • Questions / Blockers • Deploy
  13. 13. What We Achieved • Met the reporting needs of 4 major user groups to “keep the lights on” • 124 existing reports replaced • Dozens of enhancements and improvements • 0 defects – all report data matched production report data* *unless the user requested changes that would affect the data outcomes
  14. 14. What We Learned • It’s really hard to meet with several major user groups and dozens of SMEs • People take vacation in the summer • Too much development time before feedback • We needed to ID dependencies and duplication better
  15. 15. Changes Moving Forward • Much more communication to user groups / SMEs • Recognize people also take vacation during winter holidays • We need to take more advantage of developing / making changes “on the fly” • More full-team analysis – create tasks sooner
  16. 16. Questions