Mega Code Archive

 

Categories / Delphi / Examples

 

The Dynamics of Agile Software Processes, Part II

Title: The Dynamics of Agile Software Processes, Part II Question: This is in continuation with Herbert Poltnik's article The Dynamics of Agile Software Processes, Part I (article_3544). Borland has now exclusive community site for Agile Software Development (community.borland.com/soapbox/agiledeveloper). Here is Randy Millers The Dynamics of Agile Software Processes, Part II. Answer: The Dynamics of Agile Software Processes, Part II: Creating the Right-Weight Process - by Randy Miller Abstract: This article describes how to create your own agile software development process. In our first article in this series, we discussed the characteristics of agile software development processes. These characteristics help us to recognize an agile software development processes when we see one. They can also help us create the agile software development process that is right for our organization, our business environment, our project, and our team. Creating agile software development processes is not a trivial thing. One size does not fit all. Different industries have different process landscapes. The degree to which an industry is regulated, has well defined requirements, or is hyper-competitive can dramaticly shape this landscape. In other words, a software development process that produces amazing results for one project may prove disasterous for another. We call the agile software development process that meets the needs of its stakeholders a "right-weight" process. Traditional Processes There are many ways that traditional software development processes are created. Some companies utilize an evolutionary approach, where processes are a combination of what has worked in the past and updates which reflect current technological advances. These processes often take into account elements required to transcend organizational boundaries and to achieve approval from upper management. This form is often found in established companies who seek to maximize a successful outcome. Should anything go wrong, these companies want the communication vehicles in place to show how the project deviated from this intended outcome. Some of these companies have formally captured their development processes; other have not. Many folks have the misconception that if a software development process isn't written down, it doesn't exist. However, you can find out if a process really exists, and is being used, by asking a team to step through the activities that they perform. If each member responds similarly, there is definitely a process at work. These teams can often give you explicit detail on how to perform their activities. This detail is necessary, written down or not, for modularity (characteristic #1) or a well-defined process. Modularity is a good start to creating your agile software development process. There are two ways to create an agile software development process if you have an existing process. The first is to start with your existing process and transform it into a more agile one. There are ways to make your existing process exhibit the characteristics of a more agile one. However, some established processes are too far gone to be transformed. They may have resulted in one failed project after another. It may be best to take a revolutionary approach and start fresh with a base agile software development process such as Extreme Programming [Beck 2000], Feature Driven Development [Coad 1999], or an agile version of the Unified Process. Agile Processes from Existing Processes To create an agile process from an existing process requires a top-down approach. The existing process, if not agile already, must be streamlined and perhaps restructured to create a more efficient version capable of meeting the needs of the organization and project. The idea is to reshape the existing process so that it exhibits the characteristics of an agile process. The area that often requires the most restructuring is the weight. Heavy weight is often the reason that many software development processes cannot be made agile. Excessive weight prevents a process from being incremental, iterative, and time-bound with a reasonable iteration cycle. Therefore, this area is the one that we often concentrate on with existing processes. Here are three techniques for putting an overweight process on a diet. Beck's Algorithm for Streamlining Software Development Processes Take the amount of time spent on an activity and cut it in half. If the effect of halving the amount of time shows no ill effects on the project, repeat until the activity is reduced to nothing or found to be essential. Many projects are not aware of the real risks that they face. There are certainly perceived risks such as the risk of the project being cancelled. Therefore, for these types of projects, it is unclear what the effect of removing activities would be. Beck's algorithm provides a nice way to move toward a more lean software development process while slowly phasing out those activities which may take time but add no value. Process Reengineering Algorithm for Streamlining Software Development Processes Divide the process into activities. Identify a risk or necessity for each activity in the process. Associate a cost and probability to each risk. Throw out any activities which cannot be justified by necessity or risk (low probability or nonexistent risk). Make the remaining activities the basis for your new process. The re-engineering approach requires a justification for each deliverable. Therefore, unnecessary activities, activities which are not a necessity or are not attacking a known risk, are removed from the process. This approach also takes "a big picture" view of the agile process. The Organic Approach to Streamlining Software Development Processes Divide the process into activities. Attach one of three possible categories to each activity based on its necessity: mandatory, recommended, or suggested. Make sure that the distribution is not skewed to mandatory. Let the team members decide which activities in the recommended or suggested category are necessary as they develop the system. The organic approach allows team members to decide if they want to do any non-mandatory activities. Activities which are recommended should be completed unless there is a good reason not to do so. Activities that are suggested may be used to augment the iteration. Success using the organic approach depends upon educating the team members in the potential risks that the project faces. This approach fosters a certain amount of risk assumption by the team itself. Starting with a Base Agile Process There are two reasons to begin building with a base agile software development process. The first reason is the existing process does not provide a good basis on which to build. The second reason is there is no existing process. Starting with an agile base software development process also works for those who have not developed their own process. There are still a number of organizations who create software without any software development process at all. Many of these organizations want the benefits that an agile process provides without sapping the creativity and freedom that they currently enjoy. Some organizations may find that a base process, such as Extreme Programming, Feature Driven Development, and the Agile Unified Process, completely meets their needs. Others will need to augment and evolve these processes. The base process serves as a basis to build their own process. Instead of a top-down approach, these organizations must follow a bottom-up approach of constructing a software development process. Often, this constructive approach involves the addition of practices and activities to combat risks. For example, a system that deals with human life, such as an automated pilot, may need additional testing activities. In this climate, the development process may be created by identifying risks and adding activities to mitigate these risks. We must be sure that the risk is worth the addition of these activities. It is often worthwhile to explicitly identify the risk that casues us to add activities to our process. Doing so allows the process to be optimized as people find better ways to mitigate the risk. There are many other documented processes available which are agile or whose activities may be used to form better, agile processes. Activities become the tools of the agile software development team. Learning different processes increases the number of tools at your disposal and ultimately to your ability to adapt the challenges that many software projects can face. If these new activities complement (characteristic #10) your existing activities, so much the better. One last point, which should be absolutely clear by now. Simply adding or removing activities does not make an agile software development process. An agile process is modular, iterative, and incremental. It is also convergent, people-oriented, complimentary, and collaborative. Finally, it is parsimonious, time-bound, and adaptive. All ten of the characteristics must be present for a process to be agile. Conclusion No single process will work for every project. Yet, most projects would agree that they would like to be more agile. Developing a more agile process for your project requires an understanding of the dynamics of these projects. It also requires a certain amount of common sense. There is a maxim that lets you know when you have gotten it right. A right-weight process provides enough process so that it does not take extraordinary people to do ordinary things (lower bound). However, the right-weight process ensures that extraordinary people can still do extraordinary things (upper bound). In our next installment, we will talk about the cultural requirements for an agile software development process and development team. Creating the right cultural environment is important for the adoption of these software processes. It also ensures maximum productivity from your team. Therefore, this becomes the third leg in the development of an agile software development organization. Bibliography [Beck 2000] Kent Beck. Extreme Programming Explained, Addison Wesley Longman. [Coad 1999] Peter Coad, Eric Lefebvre, and Jeff DeLuca. Java Modeling in Color with UML, Prentice Hall.