Posts by Home Care Software Geek in this blog don't talk about Home Care Nursing Software, Private Duty Telephony, DME Delivery Software, Care Transitions or the other topics we focus on regularly at Ankota. Instead, these posts are intended to keep our readers up to date with technology trends that might be useful to your agencies, such as social media technologies, mobile devices, and what's happening with bigger companies like Microsoft, Google and Apple.
This is a pretty geeky post, even for our home care software geek column. It talks about how software is built and how that has changed over time. During my career, there's been a fairly radical change in the way that software is developed. This affects the way that the software is structured into small reusable pieces, and also the way that projects are structured.
The relevance of this to the home care and care transitions business is that it can help to explain why some software companies do major releases, such as once a year, and take you through a big and painful upgrade process. While other software companies, like Ankota, are able to make changes quickly and deploy them pretty quickly (most enhancements requested by our customers are released in our next two week cycle).
We'll do another post to talk about the way software needs to be designed, but for now, we'll talk about how projects can be structured for efficient deployment...The new way is called "Agile Development," but first we'll explain the old way, which is generally called the "waterfall" method.
The Old Way: Waterfall Software Development
We used to structure development like a waterfall, as depicted below. A project would be defined with a big list of requirements, then there would be a project phase to design the changes, and this would often involve restructuring the underlying data structures for the system.
Then there would be a development phase where all of the changes would be developed, generally in parallel. After that, there would be a testing phase where each piece would be tested individually, and then combined to see if they work together. Continuing on, there would be regression testing to make sure that the old functionality wasn't broken. The next step would be to set up a test environment and the users would be told about the changes and would retrain and test them. Finally, there would be a "Go Live" event, usually planned overnight or on a weekend.
The success with this methodology is dependent on having strong planning and strong project management. There is a training and certification program called "Project Management Professional" (PMP) that teaches from a very large book called the Project Management Book of Knowledge (PMBOK) and includes many levels of planning, risk mitigation, and other techniques. Planning like this has historically enabled very large projects to succeed (like sending people to the moon, for example).
The New Way: Agile Development
Most software development follows a new methodology called Agile Development. This methodology is based on some very practical thinking, such as the following:
- We might not really know today what we want the software to look like a year from now. We might change our mind along the way.
- Even if I think I know what I want, my best attempts to describe it might fall short and I'll know better if I got what I wanted when I see it.
- If I make small changes and demonstrate them or even deploy them when they're done, if I screw up, I'll only have a small effort to adjust the change or take it out and rework it.
- Related to the previous point, I'm best off if I always have working software, so every time I make a change I expect all of the software to still work.
- If I can define a series of bite sized changes added to the software in a logical sequence, I'll be able to validate with customers that I'm moving in the right direction along the way.
Based on these highly practical thoughts, the agile methodology works as follows:
The requests are broken into small pieces defined from the vantage point of the user. These are put into a backlog (a list) and prioritized. The team takes the highest priority things on the list that they think they can deliver (developed and tested) in a short period of time, perhaps two weeks. The team makes a plan for those two weeks and may add or subtract from the list if needed to get the work done.
Everyday when changes are made, the changes have to be well-contained and put into the software and tested to make sure that they worked and didn't break anything else. If it's a new feature, it should be made "configurable" so that customers who don't want it, don't see it. After the two weeks, everything is retested and some "smoke testing" is done to make sure that nothing was broken. Then the software is deployed.
In our experience, agile works really well and our customers love getting changes quickly and never need to do any extensive testing or upgrades.
If you're tired of the old way, maybe it's time for some new software. We'd love to show you our home care software, care transitions software, or other solutions. If you love most of what we offer but would like some changes, give us 2-4 weeks, and perhaps we can meet your needs.
You can also download our free informational content, including our white paper, The Seven Habits of Highly Effective Private-Duty Home Care Agencies
Ankota provides software to improve the delivery of care outside the hospital, focusing on efficiency and care coordination. Ankota's primary focus is on Care Transitions for Reeadmisison avoidance and on management of Private Duty non-medical home care.
To learn more, please visit www.ankota.com or contact Ankota.
Your Comments :