Hospitals facing financial squeeze
As the United States transitions from a volume to value-based reimbursement system, payments to hospitals are expected to decline. Given that hospitals are already surviving on a thin margin (on average 3.1% according to Modern Healthcare), uncovering opportunities for savings is more important than ever before.
Realizing that the next wave of cost reduction will come from improvements in operational efficiencies, a large healthcare consulting company in Texas knew it had to get its own house in order to be able to pass along savings advice to its national network of healthcare organizations.
Forty-three legacy applications deemed “critical care”
At stake was the performance of a suite of 43 different applications related to clinical, financial and operational management. Some of the legacy applications were nearly 20 years old and badly in need of enhancements, bug fixes, upgrades, and in some cases, complete rework.
Internal IT developers had undertaken an Agile development initiative, but constantly switching directions was making it nearly impossible for the teams to get work completed in a timely manner. Each of the applications had a different business owner, often with conflicting priorities.
MATRIX was brought in to help add some needed direction---to assist in organizing the application support team into a Scrum team, and to provide Scrum coaching for the four project teams consisting of 38 developers, business analysts and testers.
Successful start to a “classic” Scrum project
The kickoff went very smoothly. After several meetings with the managers, product owners and a business analyst, the team agreed upon the scope and began building the product backlog.
A two-week “Sprint 0” was conducted, during which all parties oriented themselves to Scrum (through Scrum training and Scrum ceremonies and practices), agreed on the “team norms,” and identified and estimated the product backlog.
Distinguishing between “new” and “sustaining” work
It didn’t take long before problems began to crop up. During Sprint 1, Day 1 planning, it became more apparent that the backlog was informally categorized into “new” development work --- new features and enhancements to existing features, and “sustaining” work --- defects and changes to applications in production.
While the “new” development work fit nicely into the Scrum model of sprints and sprint closing ceremony (working software demonstrations for stakeholders), the “sustaining” work did not, largely due to the nature of the work and the requirement to implement as quickly as possible.
The decision was made to create two teams --- to retain the “new” development team as a Scrum team but to make the “sustaining” team a Kanban team. Like Scrum, Kanban is a process designed to help teams work together more effectively, but with an emphasis on continual delivery while not overburdening the development team.
The backlog was divided into two entities with the content of each entity targeted at the “nature” of the work of each of the teams.
Both Kanban and Scrum require highly-collaborative and self-managed teams. There are, however, differences between the approaches. Organization, culture and team dynamics often determine which method is the best fit.
Applications not integrated
Both Kanban and Scrum teams faced the same obstacles with separate applications for requirements (user story) management, test cases, project management and defect tracking, not being very well integrated.
“Some of the team members were distributed, so we conducted standup meetings via conference calls in one application,” said the lead MATRIX Agile Coach. “During some discussions, we found ourselves switching between three or four applications to update user stories, work item status, test plans and test cases, and defect status.”
As a result, it was a very time-consuming and challenging exercise each evening to get ready for standup the next day. Updates to user story functionality and acceptance criteria did not always get imported correctly, so test plans and test cases were not updated, and defect status was not always current for each user story in the sprint.
Teams rally around a tool - Rally’s Enterprise Edition
As these challenges began to manifest, team morale began to erode. Recognizing a new tool was required for the Kanban team and that the tools being used for the Scrum team were “awkward”, MATRIX outlined and defined the need for an integrated tool that complimented the Kanban process and allowed the teams to be more organized and better informed.
After a successful trial with Rally Software, the Kanban team and Scrum team immediately adopted the Rally product. The addition of the Rally Software tool into the project team environment was a major factor in an increase in team morale, workflow optimization and increased solution delivery.
As Scrum is to the Agile team, SAFe is to the Agile enterprise
After a year of working at the “team” level and becoming successful with Scrum and Kanban, the organization decided they were ready for the next step in their Agile journey -- SAFe® (Scaled Agile Framework) -- which provides a recipe for adopting Agile at enterprise scale.
MATRIX was selected to “lead the way” to SAFe implementation. Once again, MATRIX teamed up with Rally Software for the SAFe training. When Rally completed the SAFe training for the project teams, MATRIX Agile coaches started coaching the teams and the business managers. With the coaching complete, MATRIX was appointed to the dual roles of the Release Train Engineer and Program Manager.
Agile Journey well on its way
Throughout their nearly two-year Agile journey, the client has recognized substantial benefits from Scrum and Kanban including more frequent releases, higher project team productivity, and more engagement from the business owners in the entire software development life cycle.
With mature implementations of Scrum and Kanban underway and a successful initial implementation of SAFe, the client is well on their way to successfully adopting a standardized Scrum/Kanban methodology across its enterprise.