I will be approaching my analysis of this proposed change using methods suggested by Andrew Pedigree, starting with understanding who we are and where we are now, progressing with defining where we need to end p, determining the need for change and the change that Is needed, and ending with a conclusion and proposed course of action that corresponds to Deltas particular circumstances. Situation Analysis Current State of Delta Delta currently offers a combined clinical and financial software solution for home health agencies. Ender the covers are two separate systems connected by a information, clinical measurements, demographic information, etc. ) in the home using a device (laptop or tablet) running Microsoft Window” operating system The financial system receives data from the clinical devices and prepares Medicare, Medicaid and private pay billings for the data. The clinical system is a collection of modules. Each module performs clinical data collection for a specific home healthcare discipline (Skilled Nursing, Physical Therapy, etc. ).
Delta currently uses a planned software development methodology that is a variant or the waterfall approach. I will explain this methodology in the following section and compare it to agile methodologies when we consider the migration to agile software development. Delta’s organizational structure is a rational-legal bureaucracy as describe by Weber. There are separate development units for Clinical and Financial products. As such, the leadership is hierarchical and there are silos separating the clinical and financial groups.
The power with respect to product direction/specification lies in the hands of the product owners – one each for clinical and financial. The product lines were cash cows for over a decade and until recently there has been little desire or perceived need for change. Impetus for change So what has caused our executive team to suddenly feel such a strong desire for change that they have bypassed all analysis steps and are suggesting we make the received technical change to agile development?
Recently, we have been experiencing decreased sales due to loss of market share. This is due primarily to two factors. The first is the advent of a change in government regulations called Perspective Payment System. This new system is designed to match reimbursement with patient progress and patient demographics. The calculations are frequently updated as standards continually change. This means that there will be constant changes to our coding algorithms in the clinical software to accommodate these regulations.
This has resulted in a decrease in our ability to introduce new features o the clinical application due to competing resources. The second factor is technology change and the introduction of millennial into the home nursing workforce. New, smaller devices are now available and as Morley Safer warns us, the new workers are adept at using them and expect the software to be available on them (Safer, 2007). Software packages like ours that are tied to an operating system are losing favor in the market because they do not support these devices.
In addition to the devices that run our software, there has been a great increase in the intelligence of clinical devices. Everything from thermometers to blood pressure cuffs to diabetic testing devices are now electronic and capable of sharing data. The more devices a clinical system can interface with, the more popular it is as this saves the nurses time and reduces risk of liability caused by a transcription error. Where do we need to be? In order to regain our position as market leader and ensure that we stay there, we need to address the above issues.
We need to create an environment where we can support multiple platforms and interfaces and be able to rapidly introduce upgrades to our clinical system to multiple device platforms. The financial side of the house seems relatively stable for the foreseeable future as Medicare billing is heavily regulated and very slow to change. Unlike the clinical customers who want to drive billing process and make sure their bills go through and they get paid.
They view our software as providing a service and do not want involved in figuring it out…. That is what they pay us to do. Executive Team’s Proposal Based on the above situation, the suggestion to move to agile development is definitely worth exploring because the advantages of agile software development are in line with our needs. They include: customer involvement through collaboration, acceptance of changes throughout the development cycle, rapid adaptation to change, and frequent delivery of working software (Cookbook, 2003).
These features would allow us to better meet the changing needs of our market. I will stay with Pedigrees methods and make sure we understand what we are changing. To do this we will first look at planned software development. The primary characteristics of planned software development are ( Camel, 2010): Projects implemented in phases: Requirements, Design, Development, Testing, Delivery Emphasis is on planning, time schedules, target dates, budgets and implementation of an entire system at one time.
Tight control is maintained over the life of the project via extensive written documentation, formal reviews, and approval/signori by the user and information technology management occurring at the end of most phases before beginning the next phase. Examining these characteristics we can see that from a management perspective, this methodology aligns well to mechanical organizations like Weeper’s rational-legal bureaucracy. It is structured, with a clear hierarchy and supports order. Thus, Delta’s current software development methodology aligns well with its rent organizational structure and culture.
What Does Agile Look Like? We next need to define what an agile software development environment looks like. The agile approaches employ self-organizing collaborative teams and use lightweight processes. They encourage individuals and interactions over processes and tools, responding to changes over following plans, and paying more emphasis on collaborating with customers over negotiating contracts with them, and providing working software over providing a comprehensive documentation (Fowler, 2001).
Unlike planned software development, the characteristics of the agile development environment do not initially appear to fit into the mechanical organizational structure currently used by Delta. Many of the agile characteristics such as self-organizing teams, collaboration and valuing people and interactions over process seem to be much more aligned with the organisms organization described by Tom Burns (Pugh and Hudson, 2007). Analysis Our next Step following the process proposed by Pettier is to identify and understand the change that is proposed.
In a comprehensive thesis, Scubas Miser identifies the most important changes needed to migrate from Planned to agile software development. Based on the results we have obtained, we have seen that the most important of all changes is the changes in the management style, followed by, in decreasing order of importance, the changes in organization culture, changes in development processes, and changes in knowledge management strategies. ” (Miser, 2007) So exactly what changes need to occur in management style?
Management styles must change from command-and-control management to leadership-and-collaboration, from authoritative to collaborative and pluralist involves shifting the decision making power from management to self -organizing elaborative groups that work with the customers to define what software will be produced. This release of control is a challenge for upper and middle management alike. In planned software development, contracts are set up with the customer defining expectations and delivery schedules. Plans are developed and success is measured by progress.
This provides for high levels of control(Boone, 2005). In agile development, this control gives way to collaboration, change is welcome throughout the process, and success is measured by rapid delivery of software and customer satisfaction (Cohn, 2003). This requires a change in management style from aerographical control to collaboration, where the managers are expected to guide the teams to ensure company goals are met, but not to micromanage. The second change identified by Miser is change in organizational culture.
Changes in culture that are required include culture to work in teams rather than developing solidarity with individually assigned roles, culture which considers satisfying customers as the most important and doing all development centering around that goal, culture which provides freedom to the developers for choosing which modules to develop and how to develop (Newer et al. , 2005). I believe these changes are both significant and widespread throughout the organization. The most visible change needed in organizational culture is changing the organization from a hierarchical structure to a collaborative structure.
This means removing interdepartmental physical and functional barriers, redefining roles and reallocation of power. Product owners who were used to having complete say in product decisions will have to learn how to work collaboratively with the other team members and customers. Everyone will need to work in the interest of the team instead of the interest of their particular position or apartment. Other changes that must be considered are the change from using contracts to using customers’ dynamically-define content.
The change from using plans to determine progress to measuring progress by the delivery of software and customer satisfaction, and moving from heavy documentation to embedded functionality and intuitive designs to provide usability knowledge to the customers and development team alike. The third major change to be considered according to Miser is development process. This is the only change that Delta originally thought needed consideration, but the changes to the development process cannot be implemented without the supporting changes mentioned above (McMahon 2004).
Changes required to the development process would include: “Close interactions between individual team members themselves and between the team members and the customers (collaboration versus working assigned tasks), responding to change continuously throughout the process, having a working software rather than following fixed plans, processes, and tools, and documenting them. The agile approaches encourage development in short iterations (time frames) that are driven by (automated) test plans. The development processes in agile approaches part away from following traditional lifestyles such as the Poem’s spiral model.
The development in agile approaches is evolutionary meaning that a small piece of functionality is developed first, and then it is revised incrementally by collaborating with the customers. Qualitative measures of success such as the delivery of software 2005), (Boone and Turner (2003). Changes to the development process at Delta would include working in a collaborative team and pair programming instead of taking an assignment and running with it. Dynamically determining requirements ND approaches instead of working from design specifications, and communicating directly with customers to understand product needs.
In order for these changes to occur, the cultural changes mentioned above must be in place. In addition, the developers must be willing to work collaboratively , rely more heavily on their face to face communication skills, and be willing to accept the new management style where they will not be fed clear task lists, and their performance will not be measured on quantitative progress measures, but rather qualitative measures like their ability to work with and satisfy the customer. The final significant change identified by Masc.. Is the change in how knowledge is managed.
Since the agile approaches lay more importance to delivering working software over documenting, the tacit knowledge should be captured and managed in agile approaches, so that valuable information is not lost and/or successes are pursued, and failures are not repeated (Miser, 2007). At Delta this would require a shift from a documentation based knowledge system where requirement specifications, design documents, standard operating procedure manuals, product manuals and lesson’s learned analysis documents are used to old the knowledge of development process and products (Riotousness, 2004).
By examining the change necessary to convert from a planned software methodology to a agile methodology, it is apparent that the changes necessary are not confined to the development department as in migrating from one planned method like waterfall to another planned method. The changes are very similar to those described by Tom Burns in moving from a mechanical organization to an organisms organization (Pugh and Hudson 2007) . Therefore, as shown above, these changes must involve management, cultural and functional changes to the organization.
According to Burns, migrating from a mechanical organization to an organisms organization is extremely difficult if not impossible for some organizations (our text). I believe we must consider the challenges to be faced in making this transition. The most significant challenge to the adoption of agile development methodology is resistance from primarily upper management followed then by resistance from middle management, customer commitment, and geographical distribution of teams (Miser 2007). The resistance from managers is primarily due to proposed changes in management style and corporate culture.
Managers used to developing software using traditional, plan-driven approaches tend to favor “fixed price, fixed scope” approaches. They want to demonstrate success in progress. They are much less tolerant of risks of failure in undertaking new approaches, more so for the ones that are new, unproven, and do not have adequate track records of success. (Boone and Turner 2005) . At Delta, I would expect similar resistance due to the fact that we have been operating in a mechanical bureaucracy for over 30 years.
I would also expect particular resistance from individuals in positions of power like the product owners ho have final say in all product decisions. Once we overcome any resistance challenges in management, I believe the resistance from our customers to becoming collaborative partners will be mixed. I believe the end users of the clinical systems because the clinical environment and technologies are constantly changing, and our long project cycles do not provide software to them as rapidly as they would prefer. Additionally I think they would like to provide more input into our choice of enhancements and technologies that we support.
The financial users, however, will most likely be less interested in collaboration. This is because their side of the industry is well defined and heavily regulated. They want us to research and understand the regulations, and provide them software to allow them to bill and keep them compliant. They view the requirements and design of the software as part of the service we are providing them. I believe it is important to address the above challenges before we attempt to implement any of the recommendations given in the next section.
This is because conceptual buy-in from all key participants is very important prior to an agile methodology’s implementation (McMahon 2004). Conclusion/Recommendations In this paper we have looked at where Delta is now and where we need to be to be a leader in our market. One of the key factors to getting us there is a fast adapting clinical product that can stay at the leading edge of the market. Our current mechanical development methodology does not allow is to keep pace with customer demands. Adopting an agile methodology would give us the speed and flexibility to address these needs.
Upon examining and understanding the changes that will be necessary to adopt agile software practices, we have discovered that they are not emitted to changes that can be implemented by the development department within our existing organization. The changes needed to implement agile practices involve changes to management style and organizational culture as well as significant changes to development process. Additionally we will need commitment from our customers to working collaboratively with us to define our products.
Based on Delta’s current organizational and industry environments, I believe there are three possible ways to proceed. One possible way would be to embrace Meg Hatless power of chaos, and force the entire organization to transform from a mechanical organization to and organisms organization that has the attributes needed to support an agile development process. The positives to this approach would be that once the transformation is complete, Delta would be organized in a way that supports its function and would be capable of adapting to future changes.
The downside to this approach is that Delta’s products are large and it would take considerable time to recreate or convert Delta’s existing software suite using Agile development. This is particularly true because Agile development is most effective creating small applications and then building on them. There is a high amount of risk that Delta would not be able to fund the company during the transformation process. Other considerations would be: 1. Would the customers be willing to buy in? Particularly the Financial customers who are not really interested in collaborating on the product. . Since we would be forcing the entire organization to move to an organic structure and adopt agile development methodologies, there will be a segment of the staff that will not be able to successfully transform and we will likely have to deal with staff replacement issues which could also be costly especially for technical staff. The second possibility would be to keep the financial product’s suggestion. The positives to this approach are that we are transforming the product that will benefit most from agile methodologies.
We would not have the challenge of getting our financial customer base to engage in collaboration, and we would have some flexibility in staffing. We could assign the half of the developers most aligned and interested in agile development to the clinical application, and allow others who are more aligned with planned development to move to financial. This would allow us to have less staffing issues with the transformation. The drawback to this plan is similar to the ones from the previous plan.
We would still be trying to convert or re- write a large application, and since the customers must use our clinical system to use our financial system, sales and revenue will continue to fall until the new agile version of clinical is available. The third solution would be more of an evolution than a revolution. Instead of invoking Meg Hatless power of chaos, we could develop a new agile development department that would start from nothing and develop a new clinical product starting with a single module, say physical therapy, and slowly rowing and replacing the entire clinical product.
This department would start with a small group from all departments and slowly migrate staff as it grows. The benefit of this approach is that we could still keep updating selling our existing solution to finance the migration. We could have an initial module available fairly quickly, and by delivering it to our customers, we may be able to convince them to stick with us once they see how well adapted the new module is, have had a chance to participate in its development, and realize where we are headed.
This approach also allows us o surgically target the areas that most need change, and provides a clear migration path for our staff. If we added some of the more popular interfaces to our new clinical module, we could sell our clinical product into organizations that do not use our total solution, giving our sales force a new opportunity to attack markets that were previously unattainable. There are additional approaches we could consider, like funding option one or two above with venture capital, but our company is privately held and has been resistant to such suggestions in the past, so I will dismiss them.
