Agile Implementation

Agile Implementation Entering a New World What exactly is Agile? What does it mean and stand for? Read more…

Ravi Warrier [email protected]

August, 2007

Introduction The intent of this document is to help readers understand “Agile methods” and how to change the philosophies of existing traditional software development and align them to the agile movement. While the agenda of the agile movement is clearly defined by various groups in terms of values’, principles’ and practices’ definition; it is not very clear with respect to selecting the right approach to adopt. This document will try and propose an objective approach to decide what the right agile methodology for your organization is.

Creating a Model

Practice(s)

Principle(s)

Value(s)

Intent

Figure 1: Evolution

Identifying the Intent As with any paradigm shift, the first task is to understand the reason for the shift. It could be just one or a matrix of reasons that would make an organization or project teams want to change the way they work. Irrespective of the count, it is important to go deep into these reasons since these reasons will further down model the approach that is best suited to the execution of the project. The way to do this is similar to a typical task of analyzing business or delivery problems. One needs to identify what are the key areas that raise most concerns. Categorizing them into buckets such as ‘Customer Satisfaction’, ‘Requirements Management’, ‘Quality of Deliverables’, ‘Meeting Deadlines’, etc helps.

Asking the right questions is really important here as without the direction the questions (and answers to them) provide, narrowing down and coming up with key problems would become a difficult endeavor. These questions might help you gain perspective: • How many times has this problem occurred (in a defined period)? • Has this problem caused us to stop on or deviate significantly from our proposed path? • How much has this problem cost us (quantified as money units)? • Is this problem likely to occur again? • What is the real cause of this problem? • Is it something we can fix? Based on the answers to the above questions, you will be able to judge which of the problems have been a real pain in the neck for your project(s). By doing this exercise, you will also realize the root cause of the problem, which in turn becomes one of the intent (key reasons) that attribute to the need to adopt an existing delivery model or create a new one.

Identify the Right Values Agile values define the beliefs that are most important for developing software. In brief, these strongly correlate to the four-fold philosophy of the Agile Manifesto:    

Individuals and interactions over processes and tools (value: communication), Working software over comprehensive documentation (value: simplicity), Customer collaboration over contract negotiation (value: feedback) and Responding to change over following a plan (value: courage).

All the intents identified earlier can be attributed to one of the values that are mentioned above. And each agile value has a set of principles and practices that extend it.

Selecting Principles This is the easy part of this tumultuous journey. It’s a straight road ahead until the next bend. Agile Manifesto has laid down 12 principles 1 based on the four philosophies (or values) mentioned above. Each of the twelve principles may satisfy one or more values. And it is not rocket science to map each of the principles to related values. For example, the following principles satisfy (either directly or not) the agile value “Communication”. Remember, this can be entirely different based on your experiences.

1

See Appendix A

Table 1

Agile Value Communication

Agile Principles Business people and developers must work together daily throughout the project. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. The best architectures, requirements, and designs emerge from self-organizing teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Principles are meant to have deeper underlying meaning which can of course be implied in satisfying more than one value.

Choosing the right methodology or creating a new one for yourself A lot of software development methods have been defined over the last many years. The list includes: • • • • • • • • • • • • •

Extreme Programming (XP) Scrum Feature Driven Development (FDD) Dynamic Systems Development Method (DSDM) Adaptive Software Development (ASD) Agile RUP Crystal Family of Methodologies (Crystal) Lean Software Development (LSD) XBreed Internet Speed Development (ISD) Agile Modeling (AM) Pragmatic Programming (PP) and Many more are added to the list as we speak

Each of these methodologies has defined a set of practices 2 dependent on the four agile values. Based on the values that are important to your software development projects, you may choose to inherit and practice what has been laid down by the methods listed above. Or you might want to create a hybrid method on your own based on these practices or the ones defined by you. Either approach is fine. But there are a few things that you would need to know while creating a hybrid method for yourself. 2

See Appendix B for list of practices for Scrum, XP and DSDM

Each of the methods listed above satisfy all the four values of the agile manifesto. What you need to consider when you implement only a few of the practices of any methodology, is that while you are free to adopt selectively, you might not earn the acknowledgement of adopting the method. For e.g., if you partially practice XP, leaving out practices that do not cater to solving your problems; you cannot claim to be executing XP projects.

AGILE

Likewise, if your hybrid method does not satisfy all the four values of agile manifesto, then to claim your method as an “agile method” would be wrong. While you have a choice of practices/methodologies to select from, the agile values are not on a platter to choose from. It is all or nothing. In-betweens are your choice too, but then it cannot be called “agile”.

Implementing the Model Once you have selected or created the model(s) that you wish to incorporate as your organization’s software development method, you have to set it into motion. This is very much like driving your car for the first time as a teenager. You need to be cautious and meticulous of the things that you do, lest you jerk or bang into an innocent bystander. These are a few things that I’d suggest on your first venture into this new world of agile software development.

Identify a committed team If this is a pilot that you are doing, I’d suggest that you ask for volunteers within the organization to be a part of an agile team. Forcing something new down people’s throats will result in a higher chance of failures. Ask people to step forward. Give them assurance that this project is a pilot and the failure of which will not result in individual’s appraisal. Give adequate training on the new process to the ones who have volunteered and once again ask them if they want to still be on the agile team. The ones who say “Yes” will be committed enough to the cause. Make sure that the team is well balanced in terms of experience and skills. A cross-functional team with varied levels of experience works best.

Select a non-critical project Do not select a critical project. Adopting agile values and practices takes time and the team will need breathing space to slowly mould itself to the changing development environment. Having a pilot on a critical project will tend to pressurize the team on deliverables which will leave no time for the change required. Most pilots fail due to the fact that these practices are new to people and that they have to change years of mindset which might not be easy at times. In such a case, you do not want a critical project as a guinea pig for your experiments.

Give the team a breather Do not breathe down the necks of team members of a pilot agile project. In fact, do not do this even with the experienced teams. One of the core practices of agile is to have a self-organizing/managing team. Don’t ask for daily or lengthy reports which will move the focus from development activities to ‘pleasing the management’ activities.

Do not strike out early Changing to a newer development method will tend to fail initially due to a variety of reasons. Do not strike out agile, just because the pilot failed. Instead, retrospect on why it failed and try again. Another side to this coin (if you fail all the time) maybe to introspect and re-evaluate your need to go agile or the method (especially if it is self-concocted) you are implementing. You might not have selected the right methodology or set of practices. If after everything it still fails, you might want to dawn on a realization that agile might not be for you.

Inspect the adoption periodically Keep inspecting the process periodically during the pilot; but do not do it so frequently that it undermines the values of agile. The purpose of this inspection is to visualize break downs early on and getting heads up on fixing issues before or as soon as they occur.

Evolving the model(s) One of the key attributes of agile is continuous improvement. Once you have had successful pilots and have rolled out the new paradigm of software development to the entire organization; you will need to improve and evolve your processes. Repeat the activities stated in the article to find newer problems to solve and newer practices that can be implemented to solve them.

Conclusion Understanding agile or various methods based on it is not difficult. Implementing practices laid down by such methods have their own complexities, but even that is not difficult. The most difficult part of shifting is figuring out what works for you and how to start implementing it – paving the actual path. Once the road is paved in the right direction, driving down it is never that big a problem.

Appendix A Twelve Principles of Agile Manifesto •

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

•

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

•

Deliver working software frequently, from a couple of weeks to a couple of months with a preference to the shorter time scale.

•

Business people and developers must work together daily throughout the project.

•

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

•

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

•

Working software is the primary measure of progress.

•

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

•

Continuous attention to technical excellence and good design enhances agility.

•

Simplicity – the art of maximizing the amount of work not done – is essential.

•

The best architectures, requirements, and designs emerge from self-organizing teams.

•

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Appendix B Practices of Scrum, XP and DSDM Scrum

Extreme Programming (XP)

Self Organizing Teams Deliver Frequently Plan to Learn (Retrospect) Communicate Strongly Test Everything

Small Releases Continuous Improvement Test Driven Development Planning Game Whole Team

Measure Clear the Path

Pair Programming Design Improvements Simple Design System Metaphor

Collective Code Ownership Coding Standards Sustainable Pace

Dynamic Systems Development Method (DSDM) Active User Involvement Empowered Teams Frequent Delivery Fitness of purpose Iterative and Incremental Development Reversible Changes Base-lining of High Level Requirements Integrated Testing throughout the lifecycle Collaborative/Co-operative approach between all stakeholders