“As a..I want..so I can...” these words are the basis of an Agile User story and were designed to facilitate communication leading to great software. This presentation will explore some advantages and limits to using the Agile approach to software development. We will see how the user stories for a Medical Billing and Payroll system changed over time and how these changes illustrate some of the underlying issues and challenges faced in many software development projects. Once identified; approaches to overcoming these challenges and issues will be examined for efficacy and limitation all within the framework of the Agile Methodology. Speaker : Josh Cowan has worked with companies in the for-profit, non-profit and public sectors throughout Canada and the U.S. With 14 years of experience with administrative software including; medical billing, accounting, payroll and budgeting systems. Josh has worked on the sales, purchasing, design, implementation, and modification of administrative software systems. In addition to software, Josh brings years of experience as a performer and writer with a commitment to making any presentation not only informative but also engaging and fun.

1. 1
Falling down and getting back up
How one project started to go off the rails
but saved itself... for the most part.

2. What is PMG
Pediatric Medical Group (PMG)
Billing Group owned by 200 MCH MDs
5.5 FTE Billing Analysts (BAs)
$32 Million in billing
400,000 billable acts/yr
2

3. Why PMG needed a new approach
Manual data entry
Inadequate software
Inadequate communication with MDs
Opaque business processes
High MD and BA dissatisfaction
3

4. Typical approach to improvement
4

5. Tools used for Initial Analysis
Vision and Scope
Workflow and Risk analyses
Business objectives and success criteria
Scope Agreement and Budget
Development Roadmap
Market analysis and RFI
5

6. Billing Analysts’ Self-Assessed Core
Competencies
Accurate and fast data entry
Power Users of MediRam software
Knowledge of MCH and MDs
6

7. Key Factors in Deciding to Build
Idiosyncratic Business Rules
Estimates for modification >= building
Pyxis Presentation
7

8. Why Pyxis?
Leader in Agility
Respect for each other when speaking
Commitment to avoiding “us vs. them”
Strong references
8

9. Agile at its core
Individuals and interactions over processes and
tools
Working software over comprehensive
documentation
Customer collaboration over contract
negotiation
Responding to change over following a plan
9

10. Expected Workflow
MD uses mobile device to enter billing
PMG Reviews, Fixes, Bills Ins. and Pays
MD
MDs review all billing and pay info.
10

11. How it would work out!
11

12. When will heaven be here?
Lack of interface with MUHC
Data review ---> Data Entry
BAs feel under siege!
SMEs not so “E”
Change management is ALWAYS hard
12

13. Heaven? What’s that?
BAs won’t take ownership
Users won’t test = bugs
Users ignore rules engine = bad billing
MDs see billing problems = complaints
I don’t say “no” enough
New functions over quality = bugs
13

14. The Frantic Angry Phone Call Demanding
Immediate Attention and how Josh felt
14

15. My 2nd weirdest meeting ever
Pyxis’s President’s approach: Things are
going bad, so let’s talk about how we
“feel” about the project.
Josh’s thoughts: WTF! Bugs! Too many
Bugs! What about the BUGS!!!
15

16. Why I trusted rather than screamed
“There can be no friendship without
confidence, and no confidence without
integrity.”
---Samuel Johnson
16

17. How we got “past” blocking emotions
Check ego… be present... REALLY listen
How do they feel?
Why do they feel that way?
Check ego… put myself in their shoes
Give them what they REALLY need
See “Everything is Workable” by Diane Hamilton
17

18. Pyxis Team Building
(weirdest meeting)
Why aren’t we doing what we think we
want to do?
What do you think you want to do?
What are you doing that stops you?
What do you gain by NOT doing it?
Big assumptions at the root of your actions?
See “Immunity to Change” by Robert Kegan and Lisa Lahey
18

19. Now what?
Transparency: Own our responsibility
Inspection: Find and fix the problems
Adaptation:
Developer and PO are more present
Pyxis pays to fix some bugs
PO changes his approach
19

20. Key Lessons learned
Be present
Let anxiety be your guide not your master
The conversations will happen, when
should they happen?
Ownership doesn’t just happen
Agile blindspot?- PO needs things
developers don’t
20

21. Tools that worked
Team maintenance meetings
Proving to Customer you get them
User led Demos
Taking responsibility minimizes blame
game
Ultimately...The software!
21

22. Not all peaches and cream
Over budget
Lack of full functionality
Ver.2 = 25% of $ but 40% of total value
Longer to complete than expected
Time to market never key constraint
22

23. Software’s current status
6 month ROI to Partners (not partnership)
Cost overruns = political problems
Ver. 2 is coming?
Billing transparency lowers MD
confidence in BAs
BAs own software
23

24. How the PMG is doing now
BAs feel under siege & resistant to Ver. 2
2 new MD groups want to use software
Support costs expected under budget
Director of BAs believes system =
“dramatic improvement!”
24

25. Just between us
25

26. Josh’s Contact Info.
If you need help with a project or have
questions or thoughts you’d like to share:
jshcwn@gmail.com
or
514.816.8706
26

27. 27