Agile methods are a collection of innovative, user-centered approaches to systems development. You will learn the values and principles, activities, resources, practices, processes, and tools associated with agile methodologies in the upcoming section. Agile methods can be credited with many successful systems development projects and in numerous cases even credited with rescuing companies from a failing system that was designed using a structured methodology.
Values and Principles of Agile Modeling
The agile approach is not based just on results. It is based on values, principles, and practices. Essential to agile programming are stated values and principles that create the context for collaboration among programmers and customers. In order to be agile analysts, you must adhere to the following values and principles as developed by Beck (2000) in his work on agile modeling that he called “extreme programming” or “XP.”
Four Values of Agile Modeling
There are four values that create an environment in which both developers and businesses can be adequately served. Because there is often tension between what developers do in the short term and what is commercially desirable in the long term, it is important that you knowingly espouse values that will form a basis for acting together on a software project. The four values are communication, simplicity, feedback, and courage, as shown in the figure illustrated below.
Let’s begin with communication. Every human endeavor is fraught with possibilities for miscommunication. Systems projects that require constant updating and technical design are especially prone to such errors. Add to this tight project deadlines, specialized jargon, and the stereotype that programmers would prefer to talk to machines rather than people, and you have the potential for some serious communication problems. Projects can be delayed; the wrong problem can be solved; programmers are punished for even bringing up problems to managers; people leave or join the project in midstream without proper updates; and so the litany goes.
Typical agile practices such as pair programming (two programmers collaborating, described later in the chapter), estimating tasks, and unit testing rely heavily on good communication. Problems are fixed rapidly, holes are closed, and weak thinking is quickly strengthened through interaction with others on the team.
A second value of the agile approach is that of simplicity. When we are working on a software development project, our first inclination is to become overwhelmed with the complexity and bigness of the task. However, you cannot run until you know how to walk, nor walk until you know how to stand. Simplicity for software development means that we will begin with the simplest possible thing we can do.
The agile value of simplicity asks us to do the simplest thing today, with the understanding that it might have to be changed a little tomorrow. This requires a clear focus on the goals of the project and really is a basic value.
Feedback is the third basic value that is important when taking an extreme programming approach. When you think of feedback in this context, it is good to consider that feedback is wrapped up with the concept of time. Good, concrete feedback that is useful to the programmer, analyst, and customer can occur within seconds, minutes, days, weeks, or months, depending on what is needed, who is communicating, and what will be done with the feedback. A fellow programmer may hand you a test case that breaks the code you wrote only hours before, but that feedback is almost priceless in terms of being able to change what is not working before it is accepted and further embedded in the system.
Feedback occurs when customers create functional tests for all of the stories that programmers have subsequently implemented. (See more on user stories later in this chapter.) Critical feedback about the schedule comes from customers who compare the goal of the plan to the progress that has been made. Feedback helps programmers to make adjustments and lets the business start experiencing very early on what the new system will be like once it is fully functional.
Courage is the fourth value enunciated in agile programming. The value of courage has to do with a level of trust and comfort that must exist in the development team. It means not being afraid to throw out an afternoon or a day of programming and begin again if all is not right. It means being able to stay in touch with one’s instincts (and test results) concerning what is working and what is not.
Courage also means responding to concrete feedback, acting on your teammates’ hunch when they believe that they have a simpler, better way to accomplish your goal. Courage is a high-risk, high-reward value that encourages experimentation that can take the team to its goal more rapidly, in an innovative way. Courage means that you and your teammates trust each other and your customers enough to act in ways that will continuously improve what is being done on the project, even if they require throwing out code, rethinking solutions, or further simplifying approaches. Courage also implies that you, as a systems analyst, eagerly apply the practices of the agile approach.
Analysts can best reflect all of the four values through an attitude of humility. Historically, computer software was developed by experts who often thought they knew how to run a business better than the local customers who were the true domain experts. Computer experts were often referred to as “gurus.” Some of the gurus displayed large egos and insisted on their infallibility, even when customers did not believe it. Many gurus lacked the virtue of humility.
However, maintaining a humble attitude during systems development is critical. You must continually embrace the idea that if the user is expressing a difficulty, then that difficulty must be addressed. It cannot be ignored. Agile modelers are systems analysts who make suggestions, voice opinions, but never insist that they are right 100 percent of the time. Agile modelers possess the self confidence to allow their customers to question, critique, and sometimes complain about the system under development. Analysts learn from their customers, who have been in business a long time.
The Basic Principle of Agile Modeling
In a perfect world, customers and your software development team would see eye to eye and communication would not be necessary. We would all be in agreement at all times. We know that the ideal world doesn’t exist. But how can we bring our software development projects closer to the ideal? Part of why this will not happen is that so far we are trying to operate on a vague system of shared values. They’re a good beginning, but they are really not operationalized to the point at which we can measure our success in any meaningful way. So we work to derive the basic principles that can help us check whether what we are doing in our software project is actually measuring up to the values that we share.
Agile principles are the reflections and specifications of agile values. They serve as guidelines for developers to follow when developing systems. They also serve to set agile methodologies apart from the more traditional plan-driven methodologies such as SDLC as well as object-oriented methodologies.
Agile principles were first described by Beck et al. and have evolved ever since. These principles can be expressed in a series of sayings such as:
- Satisfy the customer through delivery of working software
- Embrace change, even if introduced late in development
- Continue to deliver functioning software incrementally and frequently
- Encourage customers and analysts to work together daily
- Trust motivated individuals to get the job done
- Promote face-to-face conversation
- Concentrate on getting software to work
- Encourage continuous, regular, and sustainable development
- Adopt agility with attention to mindful design
- Support self-organizing teams
- Provide rapid feedback
- Encourage quality
- Review and adjust behavior occasionally, and
- Adopt simplicity.
Often you will hear agile developers communicate their point through sayings like those mentioned previously or even simpler phrases such as “model with a purpose,” “software is your primary goal,” and “travel light,” a way of saying a little documentation is good enough. Listen to these carefully. These sayings (some call them proverbs) are further discussed in Chapter 16 under an analysis and document tool called FOLKLORE. Catchy phrases are easy to understand, easy to memorize, and easy to repeat. They are very effective.
Contents
- Prototyping: Kinds of Prototypes
- Developing a Prototype: Guidelines
- Users’ Role in Prototyping
- Rapid Application Development (RAD)
- Comparing RAD to the SDLC
- Agile Modeling : Values and Principles of Agile Modeling
- Activities, Resources, and Practices of Agile Modeling
- The Agile Development Process
- Lessons Learned from Agile Modeling
- Improving Efficiency in Knowledge Work: SDLC Vs Agile
- Risks Inherent in Organizational Innovation
