How to improve your OnBase upgrades with Agile methodology
With the increasing pace of technology, there’s no reason to wait years between upgrades. Worse, if you wait until an upgrade is absolutely necessary, it becomes all too easy to misplace documentation, miss a step or two, and in doing so, doom yourself to repeat a past mistake. And you know what Albert Einstein supposedly said about that.
Thankfully, this doesn’t have to be the case. You can fix it by following three simple suggestions:
1. Roadmap your organization for frequent upgrades
In our documentation, we recommend upgrading every two years. This will almost always ensure compatibility between OS, SQL version and framework requirements. It also keeps upgrading in the back of your mind.
2. Keep project documentation in a shared, central location
Eliminate single points of failure or the possibility of losing documentation on a non-backed-up workstation. An online secure file sharing solution can help you do accomplish this quickly and easily!
3. ABR (always be retrospecting)
Looking back helps you move forward, correctly.
My goal for this post is to explain the benefits that project retrospectives can have to an OnBase upgrade, and to an organization. But before we discuss retrospectives, we will briefly discuss the framework from which they were derived: Agile software development.
Stay flexible with Agile
Hyland Software is … well, a software company.
Because of this, we have become deeply committed to Agile software development frameworks, principles and methodologies. Agile methodology was formally established in 2001, and its adoption and use cases have expanded to the point that now it has become something of a technology buzzword.
People may ignore a buzzword, but usually, it’s producing that buzzing sound because it has wings.
If you’re unfamiliar with the concept, Agile is “a set of principles under which requirements and solutions evolve through the collaborative effort of self-organizing cross-functional teams. It advocates adaptive planning, evolutionary development, early delivery, continuous improvement, and it encourages rapid and flexible response to change,” according to Wikipedia.
Most typically, Agile is used for software development. However, as more people and organizations learn about and adopt the Agile methodology, the further its adherents see its potential as a useful tool for improving all sorts of business processes.
We established OnBase’s incremental parallel upgrade process (IPUP) on the foundation of Agile. Because of this foundation, IPUP ensures you do not get too far down an upgrade path without testing and validating key processes before moving to upgrade another piece of your solution.
“Change, test, verify, deliver, repeat” is the mantra of IPUP. If you’ve ever upgraded using IPUP, you’ve been following an Agile process without even knowing it.
But it’s important to always remember that Agile is not just about processes; it’s also about people.
Incremental software development was around long before Agile, but it brought back to the foreground a key component that was often being overlooked in short-delivery product creation: people.
Leveraging people to get the best working software
I’ve written before about assembling your upgrade team. A key component of putting together any team is establishing roles, building collaboration and learning to work in harmony. No upgrade can be successful without strong teamwork. This requires trust, honesty and open communication.
Agile framework calls for close feedback loops and meetings at regular intervals to discuss the work performed over recent iterations, called retrospectives. These retrospectives are opportunities to look back, reflect on what occurred and why, and to create action items to improve working processes and fix any missed opportunities.
The simplest way to have one of these meetings is to include all members of your upgrade team, join a conference space, and look back over the most recent period of work and discuss what the team should Stop, Start, or Continue doing.
Who knows better about improving a process than the people who have most recently been there?
For the purposes of upgrade planning, iterations can be as short as a week or two, and as long as a month. Stop/Start/Continue can start to get stale after a couple of meetings, but there are a lot of online resources to help keep these meetings fun, light, and productive.
These OnBase upgrade retrospectives will work best for IPUP, since a synchronous upgrade typically occurs over a long night or weekend. However, even synchronous upgrades will benefit from Agile retrospective meetings, as they help identify things to improve the next time you upgrade.
Agile retrospectives for OnBase upgrades are a quick win, help ensure steady improvement, and can prevent Einsteinian bouts of definitional insanity by preventing the same issues from cropping up during your upgrade process. Use these ideas the next time you upgrade, and you’ll never stop improving.