Infection Control Surveillance Within a Hospital

MAKING HEALTHCARE MORE AGILE

Abstract

This paper summarizes the use of Agile methods to improve the development and delivery of applications. The strengths and weaknesses of using the Agile software development methods versus the “waterfall” method are examined. The paper concludes with recommendations for the best uses of either Agile or

Waterfall methods, based on the organization’s culture and the type of project being planned.

Introduction

Information technology (IT) projects often involve some amount of software development and / or tailoring as well as systems implementations to automate workflow process(es). No system stands alone these days, so some amount of integration work is usually required. For complex implementations, there may be a significant amount of integration and interfacing work. These types of activities are generally tracked and managed using a standard, “waterfall” type of project development/management method, since the requirements are well known and the delivery date are probably known.

Copyright Midwest Informatics, LLC John Cange Page 1 of 17 MAKING HEALTHCARE MORE AGILE

Agile Background

The “Manifesto for Agile Software Development”, referred to as the

“Agile Manifesto” or just “the Manifesto” by Agile practitioners, was the basis for what we now consider the Agile methodology. As described by Highsmith

(2001), this seminal work was the result of a ‘summit’ meeting between competing thought-leaders in software development. These 17 software experts were all experienced practitioners of one or more of the leading software development methodologies and practices, including: Extreme Programming,

SCRUM, Adaptive Software Development, Crystal, Feature-Driven

Development, Pragmatic Programming, and others “sympathetic to the need for an alternative to documentation driven, heavyweight software development processes convened.” The Manifesto pulls together the common themes from all these software development methods. The accompanying “12 Agile Principles” describes the differences between Agile and “Waterfall” development methods in more detail. See Page 4 for the list of these Principles.

The Manifesto signatories were also had extensive experience using standard “Waterfall” methods of developing and managing software projects.

The Manifesto was, in essence, the consensus view of experts on how to improve the development process, by creating a more agile software development processes. Their efforts have fundamentally changed the way that software is developed at many leading software and technology companies. CIO.com lists the

100 Most Agile Companies on their website at: http://www.cio.com/article/368313/100_Most_Agile_Companies_Honored

The companies listed span multiple industries: Aerospace, Automotive

Manufacturing, Banking/Investment, Business/Consumer Services,

Communications, Computer Manufacturing, Education, Media, Hospitality,

Financial Services, Government, Health Care/Health Insurance, Insurance, Legal

Services, Manufacturing/Process Industries, Pharmaceuticals, Retail/Wholesale,

Technology Services, and Transportation/Distribution. In the Healthcare industry, 8 companies are listed and the exemplar applications listed for each commonly list reduced cycle times and quick growth. Some of the best practices utilized at these companies will be explored in more detail later in this paper.

The Manifesto begins with a statement of purpose, lists the four core Agile values, and is signed by the seventeen original software development experts and thought-leaders who attended the meetings where the Manifesto was drafted. It should be noted that the authors of the Manifesto are some of the leading software developers and methodologists in the industry. Several were the thought leaders behind the Xtreme Programming and other techniques and methods that are now considered Agile methodologies. Due to its short length, the Manifesto appears in its entirety on the following page:

Manifesto for Agile Software Development

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Kent Beck James Grenning Robert C. Martin Mike Beedle Jim Highsmith Steve Mellor Arie van Bennekum Andrew Hunt Ken Schwaber Alistair Cockburn Ron Jeffries Jeff Sutherland Ward Cunningham Jon Kern Dave Thomas Martin Fowler Brian Marick

As stated earlier, the Manifesto was accompanied by the “12 Agile

Principles,” which describe new ways to think about software development:

Principles behind the Agile Manifesto We follow these principles:

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. 2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. 3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. 4. Business people and developers must work together daily throughout the project. 5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. 6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. 7. Working software is the primary measure of progress. 8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. 9. Continuous attention to technical excellence and good design enhances agility. 10. Simplicity--the art of maximizing the amount of work not done--is essential. 11. The best architectures, requirements, and designs emerge from self-organizing teams. 12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

These principles demonstrate the contrasts between Agile software development and traditional “Waterfall” method of managing and developing software projects. Typical Waterfall phases described by Dennis (2012) are:

Waterfall Development

In Waterfall projects, each phase of the project, e.g. Design, must be completed and ‘signed off’ before the project can proceed to Implementation. In contrast,

Agile projects are developed in short increments, typically 2 week intervals, that contain most of the activities in the Planning, Analysis, Design, and the development and testing activities of the Implementation phase. In Agile projects, there is some initial planning that includes capturing the high-level requirements, grouping requirements into logical sequence of development, and creaing the initial list of requirements for the first few interations. In Scrum, the most common type of Agile methodology, these initial requirements are stored in the Product Backlog and the requirements that will be addressed in the first/next

Copyright Midwest Informatics, LLC John Cange Page 5 of 17 MAKING HEALTHCARE MORE AGILE iteration (called a “Sprint”) are stored in the Sprint Backlog. During the Sprint, requirements are selected from the Sprint backlog and designed, developed, and tested during that Sprint. The end of the Sprint, the working software is demonstrated to the business owner and stakeholders, who decide if the software meets the documented “Definition of Done” for that Sprint. The business can also decide if the software is ‘shippable’ as is, or if more features and more Sprints are needed. The following demonstrates the iterative nature of Agile / Scrum:

This process is directly related to the Deming Plan-Do-Check-Act model:

Source: http://en.wikipedia.org/wiki/PDCA

The PDCA management method/“cycle” is seen worldwide as the scientific way to manage any process and is the core of the Lean/Toyota manufacturing process.

As demonstrated in the best practice methodology selection grid from

Denis (2012) that follows, the Waterfall is best when the requirements and technologies are clear and you have plenty of time to complete the work. In comparison Agile is best when you are not sure about the requirements and have a short window to complete the work, i.e. when requirements evolve over time.

Selecting the Appropriate Development Methodology

It is argued by proponents of Agile that Agile best fits the current, dynamic business world where time to market and evolving requirements are key business drivers. And though the grid above indicates that Agile Development is

‘Poor’ when the system to be built is complex, Mike Cohn, co-founder of the

Agile Alliance and the Scrum Alliance, and author of User Stories Applied for

Agile Software Development, Agile Estimating and Planning, and Succeeding with Agile argues in his blog at: http://www.mountaingoatsoftware.com/blog/its- effort-not-complexity/ that it is “not about the complexity of developing a feature,” but rather it is “about the effort required to develop a feature.” The nature of Agile developments is that the work is completed through short iterations where the requirements, design, and the application itself evolve until the business owner agrees that it is “done”. Complexity is a matter of effort, i.e.

Copyright Midwest Informatics, LLC John Cange Page 8 of 17 MAKING HEALTHCARE MORE AGILE the number of iterations it will take to complete the work, not whether the work can be completed utilizing Agile methods.

There are drawbacks to Agile not noted in Denis’ grid that need to be considered: Scalability and Provisioning. From a hardware provisioning standpoint, Douglass (2013) describes challenges when trying to use Agile for

Embedded Systems, such as having more “difficulty effectively testing evolving software features, because the corresponding hardware may not be available in time” and “less freedom to make changes, due to the fact that the corresponding hardware change may have an unacceptably high cost”. He asserts that

“considering the hardware construction may demand a more upfront style of planning and design.”

From a Scalability perspective, one classic problem with Agile/Scrum is ensuring that multiple Scrum teams that are working on one part of a large development project may make design or development choices that do not work well (or at all) with teams working on a different area. Several Agile methods have been created to address this problem. Levinson (2008) harvests ideas from

Mike Cohn’s original conceptual work in 2007 on “The Scrum of Scrums” where clusters of teams meet to discuss their work, especially on areas of overlap and integration. Improvements noted by Levinson (2008) to the Scrum of Scrum method has resulted in frequent, but short meetings between “ambassadors” from each team to set standards (APIs, SLAs, code repository structures, etc.), conduct daily integration testing (automated), conduct architecture reviews, and discuss obstacles that are blocking one or more teams.

Another method to managing scalability of large Agile/Scrum projects that is gaining popularity is called the Scaled Agile Framework, available at: http://scaledagileframework.com/, also known as SAFe. The SAFe framework consists of 3 organizational layers to coordinated Team, Program, and Portfolio activities and deliverables, and responsibilities.

SAFe utilizes typical Scrum iterations as its base - the Team layer.

Scaling is managed at the middle, Program layer, where higher level requirements, the Program Backlog, are managed and work is coordinated

Product Managers, Release Managers, Architects, Dev/Ops personnel and some special-purpose roles like the Release Train Engineer ensure that Scrum teams’ work and objectives are managed in service of the larger product release.

The Portfolio layer is managed by Program Portfolio Management and

Enterprise Architects, who establish the priorities for Program Managers at the

Program level. The common complaint about SAFe is that while complete as a framework, it doesn’t provide how-to instructions for organizations trying to implement it, but as a process framework, it is less than 3 years old, so more progress in those regards can be expected.

One fundamental difference between Agile and Waterfall projects is related to testing. In Agile, working, tested software is delivered frequently, e.g. in two-week increments, so testing must be completed in the same timeframe.

Waterfall development projects require that planning, design, and development phases to be completed and “signed off” before the testing phase can begin.

The great disadvantage of Waterfall method is that testing often uncovers missing or misunderstood requirements, which informed design decisions and therefore what and how the application was actually developed. Consequently, problems found during the testing/Implementation phase can force the development team to redesign and rewrite large sections of the application, which can cause the project to incur long delays and cost overruns. The related advantage to Agile is that these types of discoveries are found more quickly, in days or weeks instead of months and the costs in time and money are greatly reduced.

Late, budget-busting projects are very common in the software development world, resulting in the way business people think about IT per the applications they receive:

 It doesn’t do what we need.  It’s not what we expected.  It’s missing crucial features.  Why can’t we submit requirements anymore?  We can’t wait a year for a new release.

Another fundamental difference in requirements management is that in

Waterfall projects, all of the project’s requirements must be understood and documented at a very detailed level up front. Also, the way that project requirements are gathered and the level to which they are documented is different in Agile as compared to Waterfall projects. In Agile projects, requirements for the project are generally gathered at a high level initially, and then decomposed just during Sprint planning and during the Sprints themselves. These requirements are

Copyright Midwest Informatics, LLC John Cange Page 11 of 17 MAKING HEALTHCARE MORE AGILE generally called User Stories, where the format for their capture requires the business owner/representative to fill in the blanks, thusly:

1) As a ___(user type)___, e.g. “As a Pilot…”

2) I want to __(capability)___, e.g. “I want to be able to control the aircraft’s

angle of climb with one hand”

3) So that __(business value)__ is obtained. E.g. “so that I can adjust

airspeed with my other hand.”

In Alexander & Stevens’ (2007) Writing Better Requirements, which is made to fit a more traditional, waterfall approach to requirements, the format is based on sentences that get to similar end products:

1) User type: The (user) shall be able to ... e.g. “The Pilot shall be able to”

2) Result type: (verb), e.g. …“controls”…

3) Object: e.g. …the aircraft’s angle of climb…

4) Qualifier: e.g. …with one hand.

As you can see, the additional component to the requirement in Agile is to state the business value upfront. This is important difference in 2 regards. First, it demonstrates the linkage between Agile and Lean, where the fundamental drive is creating Value and/or eliminating waste. The second important aspect of stating the business value is during story/requirement decomposition, where other options to obtaining that value can be considered, which may change the story/requirement, spawn a new requirement, or help the developers understand the requirement better. Ultimately, as Alexander & Stevens state in their book’s summary, writing requirements is a “process of dialog and negotiation between

Copyright Midwest Informatics, LLC John Cange Page 12 of 17 MAKING HEALTHCARE MORE AGILE requirements engineers and stakeholders.” That much is the same between Agile and Waterfall methods. The difference is that the dialog continues throughout an

Agile project.

Summary

Developing software is a very complex process, regardless of the method used to accomplish the work. The key differences between Agile and Waterfall developments are related to how they handle 7 key aspects of any project:

1. REQUIREMENTS: gathering a big requirements document up front in

Waterfall vs. iterative review and elaboration in Agile

2. SCHEDULES: milestone dates & upfront delivery schedules in

Waterfall, vs. biweekly “Sprints” and regular releases to production in

Agile/Scrum

3. PLANNING: plan-driven Waterfall developments vs. just-enough

planning to get started and continual planning in each iteration/Sprint

4. TESTING: big, late testing phase in Waterfall vs. continual testing

throughout each iteration/Sprint

5. COLLABORATION: Agile teams conduct regular, daily/weekly

meetings with a dedicated business representative. Waterfall projects

require intense, upfront collaboration on requirements, but may not

collaborate with their business owners and stakeholders again until

acceptance testing at the end of the project.

6. ESTIMATION: According to Dennis (2012), industry averages for the

time spent on different project phases:

There is no comparison to Agile methods in this regard. Agile does not include industry metrics or estimates like these, nor does it manage to the phases shown as milestones. The metrics utilized in Agile developments are particular to

Agile processes, e.g. Team Velocity. These differences in estimation and monitoring could be seen as a weakness to business people who are used to milestone dates and are comfortable with the estimates. Agile promoters would say that business people will become even more comfortable with the Agile way of doing things and their key role in the process, once they see that they are receiving value with every iteration/Sprint and can choose to go to market whenever they feel that there is sufficient value to the customer.

Discussion

With today’s more dynamic world, requirements change during the course of the development more than ever. Waterfall makes the most sense for those projects where the requirements are very unlikely to change, like in a conversion from one system to another, where the potential waste of missing requirements, developing unneeded features, and ultimately failing user acceptance tests is low.

Again, back to the Lean concept of avoiding waste, building and testing anything

Copyright Midwest Informatics, LLC John Cange Page 14 of 17 MAKING HEALTHCARE MORE AGILE that is unnecessary is a waste, including the effort to document unneeded requirements, catalog them, and store them. Toyota proved the value of Lean in terms of quality and cost containment in manufacturing. Many industries today are utilizing Lean principles to improve their bottom line and their quality ratings.

For those reasons, Agile is often referred to as the Lean way of doing software development. With so many advantages to using Agile, it will likely continue to spread and Agile software development and project management methods will become the new, de facto standard way to develop software. Even the Project

Management Institute, long a bastion of Waterfall processes, now offers an Agile training and certification program now.

In healthcare settings, being Agile and using Lean methods to manage your workflows and technology development projects. Never has there been more pressure on healthcare to reduce waste, reduce costs, and increase quality.

Being Lean, being Agile – these principles are even more important in healthcare than in other industries if we are to drive out waste and drive down costs.

Conclusions and Future Study

Agile embodies the scientific principles of Deming, the flexibility and quick results demanded of the modern business world, and it addresses the classic project management problems of describing the work to be done, estimating the work, and getting the work done as quickly and with as much quality as possible.

More real-world experiential data from different organizations implementing

Agile/Scrum is needed to confirm these conclusions in the minds of business leaders before Agile becomes the new standard way of developing software. The

Waterfall method will persist for some time due to the amount of investment in current project processes, Project Management Offices and resources, and for its ability to handle large software development projects. For cooperative work between engineers and business people, Agile provides the best collaboration and development environments for most projects, but interteam coordination and scaling problems will limit the changeover from Waterfall to Agile as the standard method for developing and managing software projects.

References

Highsmith, J. (2001) History: The Agile Manifesto. Source:

http://agilemanifesto.org/history.html

Dennis, A. (2012). Systems analysis and design. John Wiley & Sons.

Cohn, M. (2010) It’s Effort, Not Complexity. Source:

http://www.mountaingoatsoftware.com/blog/its-effort-not-complexity/

Bruce, D. (2013). Chapter 21: Agile Development for Embedded Systems.

Software Engineering For Embedded Systems, 731-766.

doi:10.1016/B978-0-12-415917-4.00021-9

Levinson, M. (2008) Scrum of Scrums - Issues and Value. Source:

http://www.infoq.com/news/2008/11/scrum-of-scrums

Copyright Midwest Informatics, LLC John Cange Page 17 of 17