Week Three – Case Study:
Agile Software Development
- This case study provides a framework for learning about different software development strategies. Consider a situation where you, as the manager of a workgroup, are asked to provide input to your IT department who is considering what software development strategy to adopt. As a customer of the IT department what are your objectives and concerns? What do you recommend and why?
As a customer of the IT department I have four objectives that describe what I want from any development. First, I want the end product to meet or exceed my stated needs. In the planning stages I have an idea of how something may be improved from a process or efficiency standpoint. This is identified as the need and then, if it seems feasible and is approved, it becomes a project. If the software changes or improvements do not meet my needs or make the process more difficult, my needs were not met. However, if IT was able to integrate more of the process into the software and reduce the time or improve the quality, my needs have been surpassed.
Secondly, I need open lines of communication between the stakeholders and myself. If the project is behind schedule or some parameters need to be changed I want to know what is happening. Not just because I am a micro-manager but because I may be able to solve some of the issues if they were brought to light. For example the programmers are running into roadblock after roadblock trying to accommodate a request from my department, but I know that the issue they are having was only a “it would be nice if…” type of request. If that were the case I could save everyone and the company a lot of heartache and remove that as a requirement.
Next, I want flexibility. As the project progresses other requirements may come to light so I need the flexibility to bring this new information to the IT folks without fear of retribution for not having perfect knowledge at the inception of the project. “One of the biggest problems with waterfall is that it assumes that all project requirements can be accurately gathered at the beginning of the project” (Danube 2004). A perfect understanding at the front of the project is obviously impossible, or at least improbable.
Once the project is near completion I want support for pre-implementation training, a smooth transition process including implementation and support after it is up and running. Training and support are critical to the successful transition. Knowing what to expect beforehand and knowledgeable people to answer questions throughout the process will improve speed, give credibility to IT department and create a good environment for future change.
My recommendation to the IT department is to utilize ‘Agile’ software development strategies. This process has been shown to allow for requirement modification much smoother than the traditional approach. Features are created independently and changed often, which allows for easier modifications if new requirements are brought to light late in the project (Bose 2006). This quickly changing code and testing of the process requires that communication be open and often. Any small change will require several people to relate and approve the modifications including me, the customer. This open communication with users should have a side effect of giving the software additional features that were not originally asked for (Serena 2007). With a good process for training and support ‘Agile’ can accomplish the implementation smoothly because the users have actually been part of the development process which will reduce the training needed to bring everyone up to speed.
For the business as a whole, ‘Agile’ is reported to have many advantages that would indirectly benefit my department. According to Frye (2008), 66% of companies utilizing ‘Agile’ have seen an improved time to market; 62% have seen higher productivity; 45% have reduce defects in final products; 34% have lowered development costs. These benefits can be compared to the traditional method that has less than 30% success rate (Serena 2007). That means that the company will see the benefits of the new software sooner, which translates into more money saved or higher quality work implemented earlier. The costs for development are down which may be small in comparison to the reduced cost associated with fixing bugs in the final product. Kemp (2004) states that a bug may cost (in time and money) 100 times more to fix after release, than during development. With these improvements the company and my department will be able to utilize the savings for other changes from additional efficiency gains to pay increases.
- Are there conditions that favor one software development strategy over another? How might this impact your thoughts and analysis of #1 above.
There are several outside forces that may make it difficult to implement ‘Agile’ software development. ‘Agile’ is by nature less formal than the traditional software development ‘Waterfall’ method. In some organizations the entire business strategy is built upon the formal, command and control style, process based culture. Making a switch to the less formal, collaboration based ‘Agile’ method can be painful or in some cases a cause for corporate collapse (Bose 2006).
Another potentially decision changing condition is weather the IT department working on this development is located in the same place as the customer. If IT is located half a world away in severely different time zones, communications become a huge obstacle for ‘Agile’. The same survey that reported huge benefits using ‘Agile’ also show that communication is the largest problem faced by 52% of companies using it. Having stakeholders in different locations only exacerbates the communication problem (Frye 2008).
The third condition that may give pause to making the change to ‘Agile’ is if software documentation is critical within the organization. The second largest problem faced by ‘Agile’ development is that "the reality is, no matter how much you try, documentation is never up to date" (Frye 2008). This could be a huge problem if turnover is a problem within the company. Most of the knowledge or lessons learned in ‘Agile’ is walking around in developers heads. If that developer were to leave or transferred it would be difficult and time consuming to glean and transfer that knowledge to their replacement (Bose 2006).
Looking at these problems associated with ‘Agile’ should cause pause if any one of these are present within the organization. Consider methods that may be used to overcome these problems before making the switch to ‘Agile’ strategy. However, if all of these circumstances exist, the company should re-evaluate if the benefits are worth the potential problems of switching. It is likely to be more beneficial to make small changes in the traditional method that would make improvements in the areas were improvement is needed. This may result in some kind of hybrid version of software development that fits perfectly into the organization.
References:
Bose, Indranil (2006). Jharna software: the move to agile methods, Asia Case Research Center. Retrieved from Harvard Business School, HKU613P2.
Danube (2004). An introduction to agile software development. Danube Technologies, Inc. Retrieved July 4, 2008 from: http://www.danube.com/docs/Intro_to_Agile.pdf
Frye, Colleen (2008). Agile practitioners face challenges, but see process improvements. Software Quality News. Retrieved July 5, 2008 from: http://searchsoftwarequality.techtarget.com/news/article/0,289142,sid92_gci1318820,00.html#
Kemp, Sid (2004). Project management demystified. New York: McGraw Hill.
Serena (2007). An introduction to agile software development. Serena Software, Inc. Retrieved July 4, 2008 form: http://www.serena.com/docs/repository/solutions/intro-to-agile-devel.pdf
Posts
No comments:
Post a Comment