Welcome back to the vRad Technology Quest. Today we’ll cover our development approach to maintaining vRad’s radiology platform.
At vRad, our development team uses the Agile Methodology, with most teams adhering more or less to Scrum.
If you aren’t familiar with software development, don’t fret; understanding how vRad develops software doesn’t require in-depth knowledge of various methodologies.
Let’s start with a couple of definitions for the uninitiated:
| An Agile Development Methodology is the umbrella term describing an incremental, iterative development process utilized to make the development cycle efficient and responsive. |
| Scrum is a specific approach to agile development, viewing goals holistically and involving business units collaboratively to make the cycle responsive to business requirements in near real-time. |
Now let’s take a high-level look at the agile software development lifecycle:
Now that we’re on the same page, let’s dig in!
Most development starts with an idea, and vRad is no different. Take our Teleradiology Metrics Reports as an example: it started as an idea to provide more transparency into our performance and insight to our clients, and today it’s a key component of our analytics expertise. Some teams utilize product managers or business analysts to gather ideas for features and funnel them into development; other companies believe that products should derive more organically from the development team itself.
vRad finds itself somewhere in the middle.
vRad doesn’t have a rigid usage of business analysts or product management that drives all new features. We have the benefit of being a tightly knit company and a significant number of our features start out as hallway conversations that bloom organically. These ideas come from sales, our operations center, technical support teams – from anywhere or anyone with a good idea!
And of course several ideas come from the close collaboration of our President and COO, Shannon Werb and our Chief Medical Officer, Dr. Benjamin Strong. Dr. Strong leads weekly meetings where team members across departments and disciplines come together to provide updates on current projects as well as to bring forward new ideas—which are discussed and prioritized, or sent back to the drawing board to consider further. We have enough ideas in our pipeline to keep our development team busy for a few years!
The software engineering department takes all the approved ideas and funnels them into our product teams. Our teams have certain specialties, but for the most part, each of them is trained on the platform as a whole. We do this training through a series of videos and wiki articles we’ve developed, and each of our engineers has experience coding in a variety of the components that make up the platform.
Once a project is funneled into a product team, the team will meet with product owners (the people who have the idea) and begin breaking the request into user stories.
“Wait, what’s a ‘user story’?” you might ask.
Good question! But before I answer, let me digress for a moment.
Many years ago, vRad used a different methodology often called ‘waterfall’. In waterfall, a business analyst or product manager gathers many features and ideas and spends months creating a large document referred to as a Software Requirements Specification (SRS). Next, she hands the SRS to a development team who estimates out the project and develops a project plan that is usually months long. The team gets to work on the project and perhaps it takes 9 months to deliver the product. Then the product manager takes a look, doesn’t like it – and the entire work is scrapped; and the team starts on the next SRS. Like a big giant circle of being too late.
Of course, the waterfall approach can go better… but the risk of wasted time is very real.
That’s where agile development comes in. There are many resources (http://agilemethodology.org/, https://en.wikipedia.org/wiki/Agile_software_development) to learn about agile and the tenets of agile development, so we’ll focus on vRad’s approach. The most important benefit vRad sees in agile is the iterative and responsive process. We strive to get the person with the idea talking to the person writing the code – they talk and share, and even argue occasionally – and by staying in touch on a frequent basis we can change priorities on the fly.
Ultimately, the end result of agile is a better product, sooner.
OK, let’s get back to Scrum user stories:
| In Scrum, a user story is a small feature written up in a structured format: “As a [user type] I want to [action] so that [reasoning]”. User stories break up ideas into smaller chunks; everyone involved can work on smaller pieces simultaneously, then quickly get back together, review and iterate. |
In the above definition:
vRad’s MEDIC team, the team responsible for a significant amount of development on our Clinical applications, recently developed features that support the Mammography workflows in the vRad RIS.
Here’s an example user story from that work:
“As [a radiologist], I would like [any breast imaging studies that are for the same patient, taken on the same day, bundled together] so that [the same radiologist reads all of the studies for that patient].”
When the request is broken down into these parts, we can easily identify who the feature is for, what the feature needs to accomplish and why the feature is important. This consistent format serves as a reminder to our development team that the features we build are more than just the code we write, but support our business units, radiologists – and ultimately the patients that vRad and our clients collectively serve.
Tackling these user stories happens during two-week ‘sprints’:
| A sprint is the timeframe allotted for working on a batch of user stories, typically 2 – 4 weeks long. |
Agile and scrum methodologies have various rituals (meetings) that help the process flow – demos, backlog grooming, sprint planning, retrospectives, and others. At vRad, each team is self-organizing and determines their own set of rituals to hold.
Although each team is self-organizing, most teams start a sprint by having a planning session. During this planning session the team will discuss what can be fit into a sprint by sizing stories, they will ask the product owners (the people with the ideas) any questions they might have, and when sprint planning is complete, the sprint is started.
During the sprint, most teams hold “standup” meetings on a regular basis (usually daily or 3x per week). And During a scrum meeting, each team member describes what she did yesterday, what she’s going to do today, and any blockers she currently has. This quick meeting helps everyone stay focused, collaborating, and progressing forward.
At the end of each sprint, teams generally have a retrospective meeting. This meeting is to discuss how the sprint went, provide a demo of the features created during the sprint, and suggest any changes to the process. Many teams dovetail directly from this meeting into the next sprint’s planning session.
At vRad, all of our teams work separately, but together. We all work in the same code branch; we all release on the same schedule (you can read more about that in an upcoming post: Planning Downtime (#7)). For each team, every sprint is comprised of the design, develop, and test parts of the process in the agile development lifecycle above. Then each month we enter into a ‘regression’ week: the week that our software quality assurance team members re-test any changed functionality and areas of the platform that might be impacted by those changes. During this time, the developers are available to help test, troubleshoot, and fix bugs. They also quite frequently are developing new features for the next release.
Finally, we get to the end, the grand finale, the release: the deployment of the software to our users. We do this over the course of two weeks with three separate release events for each of our major sub systems. (Our Suite of Practice Management tools (Biz), Radiology Information System (RIS) and Picture Archival and Communication System (PACS)).
We rigorously plan out these releases; and we also plan time for any other changes we need to make to our platform, such as networking changes or infrastructure changes. We focus on only taking one 15-minute period of downtime each month (you can read more about that in an upcoming post: Planning Downtime (#7)).
Finally, after each release cycle, the process starts again: taking in new ideas, turning them into delivered features, and constantly improving upon the vRad radiology platform and tools our clients rely on.
I hope you enjoyed this look into the vRad approach to the agile development methodology; stay tuned for our next article on the vRad Development Pipeline (#2). We’ll be tracking all 7 keys to unlocking a DevOps Culture, as they’re released, in the vRad Technology Quest Log.
Until our next adventure,
Brian (Bobby) Baker