Analysis techniques for agile software development
By Spencer Schneidenbach
Prepared for IS 6840
Dr. Sauter
11/8/2012
What-a-fall… from grace
Can I cram anymore puns into that heading?
When discussing the advantages of agile analysis techniques and their advantages, it becomes necessary to talk about the rise and fall of the waterfall technique. Waterfall is a process driven software development methodology, which “views the optimal process for software development as a linear or sequential series of phases that take developers from initial high-level requirements through system testing and product shipment” (Cusamano et al.) In other words, each step involved in the design process becomes compartmentalized. Emphasis is placed on completing one aspect of the project before all others – analysis is done separately from the design, which is done separately from the design and implementation, and so on. This model behaves much like an actual waterfall, in that once you flow from one step to the next, you cannot (or should not) flow backwards.
Figure 1 - Waterfall model image (Haughey)
Many projects set on the path of waterfall are doomed to failure; indeed, projects using the waterfall methodology are three times more likely to fail than projects using the agile methodology (Cohn.) There are several main reasons why waterfall is no longer a sufficient model with which to analyze and develop software.
The gap between requirements analysis and delivery is usually too long.
Especially in today’s fast-paced business world, there is a significant demand to build things quickly and efficiently. Waterfall lends itself to taking time to develop full requirements for the software, then beginning the development phase. However, in many cases the requirements have changed by the time the software has been built, tested and deployed, which means that the developers and the analysts have to go back and redesign/rebuild the specific processes anyways. Perhaps most critically, the “delivery of a new system changes the basic requirements of the business and the behavior of the system, so the actual act of delivering a system causes the requirements on the system to change” (Leffingwell.) In other words, the delivered system changes the nature of how the business will operate, which means that it will change the requirements of the system. If you are in waterfall, your requirements analysis AND software delivery is already done, making it difficult to go back and make larger, game changing alterations.
Customers often don’t know what they need when they think they know the solution
Often, when performing requirements analysis, customers will think they know what they want, but usually fall to the “yes, but” syndrome – a user sees a feature in the software and often says “yes, but wouldn’t it be great if it could also do this?” (Leffingwell, Widrig) Besides not completely meeting the original business need, the feature also is now subject to scope creep, since the feature may be expanded or enhanced to meet the actual needs of the users. Additional analysis must then be done to further vet the requested enhancement. Because these requirements shift so much, it can be more difficult to add or enhance features because the infrastructure of a waterfall-based system has typically already been fairly well-defined, and changes to this code can often mean changes to the underlying infrastructure.
Scope definition documents will expand
Because the users will change their minds and the business will change its needs, a scope document that will stand the test of analysis time is impossible to create. Waterfall, by its very nature, is quite restrictive in terms of the scope of a given project – the project will be successful, given what we think we know about the business and the problems we are trying to solve. In reality, change to the scope is inevitable, especially considering the factors above (“yes, but” and the delivery time problem) and a waterfall-like scope definition is insufficient when attempting to design a system that will be used by a business run today, simply because the system is very likely to no longer meet the needs of the business after delivery.
Why agile is so successful
Agile has been around for a while in various forms since the 1990’s and has even been used since the mid-20th century (Larman.) However, set of agile principles became well-defined when seventeen developers met at the Snowbird, Utah resort and produced a document known as the Agile Manifesto. In this document, these developers outline a common set of practices that fall under the agile umbrella.
Agile analysis methodologies share several different distinguishing characteristics that set them apart from waterfall, as detailed in the Agile Manifesto. Highlighted below are just a few of the most critical ones.
People before process and programs
Because people make up the heart of any organization, it is a crucial agile commandment that states that the people always be considered before anything else, including the business processes and software. Everyone from organizational leaders to the front line workers must be considered for a software project to be truly successful, and everyone must be involved from the start of the project to the end. In short, the software must be developed for the people, not the other way around.
Iterative delivery of usable software
This principle includes involving the end user in every step of software development, from the very beginning to the very end. Development will sometimes start even before initial requirements analyses are completed. Because of a typically bad reputation that comes alongside of new software development projects (they are typically thought of as going over time, over budget, with an incomplete feature set) it is essential that the end users of the product see all stages of development for several reasons, including showing customers that software is being developed quickly and efficiently.
From an analysis standpoint, this is important because the customer will often provide useful feedback of requested features. Constant prototyping will ensure that the customer is not only continually satisfied with the progress of the project, but that the features that they are seeing are of value to them and to their organization. Critical features that need work can be worked on and refined, features that are less valuable can be taken out of the critical path, and features that the customers decide are not useful to them can be evolved or removed entirely.
Change is encouraged
In agile, change is not simply just an inevitable part of software development – “agile processes harness change for the customer's competitive advantage” (Beck et al.) Because customers are so heavily involved, the requirements for the software are bound to evolve. Unlike waterfall, which often falls into the trap of delivering software “too little too late,” agile encourages change so that the software product is improved, along with the end user’s experience.
Agile analysis techniques
Identify stakeholders immediately
Since people are at the core of agile, it is essential to begin with identifying the stakeholders involved in your software project at all levels of the organization. These people will be the main driver behind system functionality and will serve as a good measuring stick for how developers are progressing. It is also important to bring stakeholders and developers together to begin creating software immediately and to begin team building, so that everyone feels like their opinions are valued and therefore become more productive contributors to the entire development team. Further, the type of interaction is critical as well. In agile, it is preferred to communicate face-to-face, as opposed to communicating exclusively over email, and in meetings where interaction is encouraged – like using a whiteboard to work out problems, as opposed to design documents.
Get user stories from these stakeholders
Afterwards, it is important to begin gathering and prioritizing user stories, which are job functions performed by stakeholders, often in the form of “as a (role), I want (desire/goal)” (Cohn.) Often, these user stories are written on something as small or trivial as an index card. The use of small media such as this emphasizes face-to-face interaction over comprehensive documentation, which is a landmark of waterfall development.
Figure 2 - An example of a user story
It is important to manage this information so that the user stories can be properly prioritized. For example, in Scrum, the role of user story management is given to the Product Owner, who represents the group of stakeholders. The Product Owner receives user stories, prioritizes them, and adds them to the product backlog, which is a list of requirements for the system.
There is some discussion as to whether or not the business value for the requested feature should be included in user stories (“as a (role), I want (desire), so that (business need fulfilled).”). Mike Cohn, an agile methodology expert, does not believe that they are necessary, but still uses the template often because he believes that it has value and helps the product owner prioritize the backlog. Without it, “the product owner has to work harder to understand what the feature is, who benefits from it, and what the value of it is” (Cohn.) Many agree that the “so clause” is essential for identifying the core need of the user’s request, which is sometimes not apparent without it.
Bridge developers and stakeholders early
While performing requirements gathering activities, interfacing developers with users from start to finish is essential. Part of agile’s thought process is encouraging developers to be good analysts, which helps encourage both users and developers to be stakeholders in the product being developed and gives them ownership of all levels of the analysis process. Both developers and users become accountable to each other – one must provide good feedback while the other must show that they are responding to the feedback given. This also encourages both parties to act more as a team, as opposed to two separate entities with differing interests, which helps ensure that requirements gathering becomes a responsibility not just for the developers/analysts, but the whole team at large.
Functionality analysis should be done incrementally
Agile analysis is not about knowing all of your requirements up front. In agile analysis, all added functionality is broken into digestible chunks that can be completed within a couple of weeks, but typically no longer than a month at the very most. These modules, after being prioritized, are completed during iterations or a stretch of time where the planning, analysis, design, implementation, testing, and evaluation are done, typically within a month as well. After an iteration is complete, a working product is presented to the stakeholders. The functionality is then re-evaluated and analysis is done again to see how the functionality adds value, does not add value, or needs to be changed in order to fit into the business. This adds value to the analysis and the final product, as you are getting constant, consistent feedback on the product the team is developing, which will greatly increase the likelihood that the customer will be satisfied with the end result.
Figure 3 - Iterative development model
The analyst is not just an interface
The “pure” business analyst, in waterfall, is often the bridge between the customers and the developers. In agile, the analyst instead works directly with the customer and is very much akin to a coach, helping the customer to better communicate their needs to the developers. In agile, the developers play a large role in analysis, which ultimately leads to a better product through constant customer interaction and a sense of ownership of the end product. However, business analysts continue to have value, because skilled analysts will continue to help provide direction and vision to the product and can better extract information from the customers by asking essential questions (what if, what if not, and why?) A good rule of thumb is to ask a customer “why” six times, a technique which will help the analyst get to the core of the problem quickly.
Be sensitive to the user experience
A positive, simple user experience is emphasized in agile development, and is not only the responsibility of the developers. When presenting a solution to the stakeholders at the end of an iteration, it is important to gauge customer reactions to the product. Listen to their concerns and, as analysts, pick up on nonverbal cues during these presentations. Analysts should always be sensitive to whether or not the presented feature is actually meeting a customer’s need. Be sure to foster open discourse so that there is constant communication between all members of the team. This will ultimately help ensure that customers are continuously satisfied with the product and that the needs of the business are being met sufficiently.
Be informed
This one is non-scientific, but I believe it is important to stay informed of agile analysis techniques used today. This can be accomplished by reading case studies, journal articles, books, watching videos, or simply performing searches on the Internet. The choice is yours, but keeping your mind open and your ideas fresh will ultimately contribute positively to the entire team.
Conclusion
Agile continues to be the dominant analysis and design
methodology used today, and with good reason – agile projects continue to be
far more successful than their waterfall counterparts by a factor of three.
Continued application of agile analysis techniques will help ensure that your
project is not only successful, but that the customers are satisfied with the
process and the end product.
Citations
Cusumano, Michael A., and Stanley A. Smith. "Beyond the waterfall: Software development at Microsoft." (1995). http://hdl.handle.net/1721.1/2593
Haughey, Duncan. "Waterfall v Agile: How Should I Approach My Software Development Project?" Project Smart. N.p., 28 Sept. 2009. Web. 05 Nov. 2012. <http://www.projectsmart.com/articles/waterfall-v-agile-how-should-i-approach-my-software-development-project.php>.
Cohn, Mike. "Agile Succeeds Three Times More Often Than Waterfall." Succeeding with Agile. N.p., 13 Feb. 2012. Web. 05 Nov. 2012. <http://www.mountaingoatsoftware.com/blog/agile-succeeds-three-times-more-often-than-waterfall>. (no, it’s not technically a non-web source, but it does cite the Standish reports. Sue me! :)
Leffingwell, Dean. Scaling software agility : best practices for large enterprises. Upper Saddle River, NJ: Addison-Wesley, 2007.
Leffingwell, Dean and Widrig, Don. Managing software requirements : a use case approach. Boston: Addison-Wesley, 2003.
Craig Larman, Victor R. Basili, "Iterative and Incremental Development: A Brief History," Computer, pp. 47-56, June, 2003
Iver, Vidya. "Agile Programming and System Analysis." Agile Programming and System Analysis. N.p., 29 Nov. 2006. Web. 08 Nov. 2012. <http://www.umsl.edu/~sauterv/analysis/f06Papers/Iyer/>.
Cohn, Mike. User stories applied : for agile software development. Boston: Addison-Wesley, 2004.
Frank Cervone, H. "Understanding Agile Project Management Methods using Scrum." OCLC Systems and Services 27.1 (2011): 18-22. ProQuest Technology Collection. Web. 8 Nov. 2012.
Martin, Robert. "On Analysis." Agile Alliance (2002): n. pag. Web.
http://www.stellman-greene.com/2009/05/03/requirements-101-user-stories-vs-use-cases/