Activities, Resources, and Practices of Agile Modeling

Agile modeling involves a number of activities that need to be completed sometime during the agile development process. This section discusses these activities, the resources, and the practices that are unique to the agile approach.

Four Basic Activities of Agile Development

There are four basic activities of development that agile methods use. They are coding, testing, listening, and designing. The agile analyst needs to identify the amount of effort that will go into each activity and balance that with the resources needed to complete the project.

Coding is designated as the one activity that it is not possible to do without. One author states that the most valuable thing that we receive from code is “learning.” The process is basically this: have a thought, code it, test it, and see whether the thought was a logical one. Code can also be used to communicate ideas that would otherwise remain fuzzy or unshaped. When I see your code, I may get a new thought. Source code is the basis for a living system. It is essential for development.

Testing is the second basic activity of development. The agile approach views automated tests as critical. The agile approach advocates writing tests to check the coding, functionality, performance, and conformance. Agile modeling relies on automated tests, and large libraries of tests exist for most programming languages. These tests need to be updated as necessary during the progress of the project.

There are both long-term and short-term reasons for testing. Testing in the short-term provides you with extreme confidence in what you are building. If tests run perfectly you can continue on with renewed confidence. In the long-term, testing keeps a system alive and allows you to make changes longer than would be possible if no tests were written or run.

The third basic activity of development is listening. In Chapter 4, we learned about the importance of listening during interviews. In the agile approach, listening is done in the extreme. Developers use active listening to hear their programming partner. In agile modeling there is less reliance on formal, written communication, and so listening becomes a paramount skill.

The developer also uses active listening with the customer. Developers assume that they know nothing about the business they are helping, and so they must listen carefully to businesspeople to get the answers to their questions. The developer needs to come to an understanding of what effective listening is. If you don’t listen, you will not know what you should code or what you should test.

The fourth basic activity in development is designing, which is a way of creating a structure to organize all the logic in the system. Designing is evolutionary, and so systems that are designed using the agile approach are conceptualized as evolving, always being designed.Good design is often simple. Design should allow flexibility as well. Designing well permits you to make extensions to the system by making changes only in one place. Effective design locates logic near the data on which it will be operating.Above all, design should be useful to all those who will need it as the development effort proceeds, including customers as well as programmers.

Four Resource Control Variables of Agile Modeling

Completing all the activities in the project on time within all the constraints is admirable, but, as you probably have realized by now, in order to accomplish this, project management is crucial. Managing a project doesn’t mean simply getting all the tasks and resources together. It also means that the analyst is faced with a number of trade-offs. Sometimes cost may be predetermined, at other junctures time may be the most important factor. These resource control variables (time, cost, quality, and scope) are discussed next.

Time

You need to allow enough time to complete your project. Time, however, is split into many separate pieces. You need time to listen to the customers, time to design, time to code, and time to test.

One of our friends is an owner of a Chinese restaurant. Recently, he found himself short-staffed as one of the members of his reliable crew returned to Hong Kong to get married. The owner placed himself in the kitchen so the food was served on time, but stopped greeting his customers out front in the usual way. He sacrificed the listening activity to achieve another, but in this case he found out it was hurting his business. Customers wanted the attention.

It is the same in systems development. You can create quality software, but fail to listen. You can design a perfect system, but not allow enough time to test it. Time is difficult to manage. If you find yourself running short of time, what do you do?

The agile approach challenges the notion that more time will give you the results you want. Perhaps the customer would prefer that you finish on time rather than extending the deadline to add another feature. Customers, we often find, are happy if some of the functionality is up and running on time. Our experience shows that often a customer is 80-percent satisfied with the first 20 percent of the functionality. This means that when you complete the final 80 percent of the project, the customer may be only slightly happier than he or she was after you completed the first 20 percent. The message here is be careful not to extend your deadline. The agile approach insists on finishing on time.

Cost

Cost is the second variable we can consider adjusting. Suppose that the activities of coding, designing, testing, and listening are weighing the project down, and the resources we put into time, scope, and quality are not sufficient, even with a normal amount devoted to cost, to balance the project. Essentially we might be required to contribute more resources that require money to balance the project.

The easiest way to increase spending (and hence costs) is to hire more people. This may appear to be the perfect solution. If we hire more programmers, we’ll finish faster. Right? Not necessarily. Picture hiring two people to repair a roof and increase that number to four. Soon the people are bumping into one another. Furthermore, they need to ask each other what still needs to be done. And if there’s a lightning storm, no one will be working. Going from two to four doesn’t mean it will take half of the time. Consider the required increase in communication and other intangible costs when you are considering hiring more people. Remember that when new people join a team, they do not know the project or the team. They will slow the original members down, because the original members must devote time to getting new members up to speed.

Overtime doesn’t help much either. It increases the cost, but the productivity doesn’t always follow.Tired programmers are less effective than alert programmers.Tired programmers take a long time to complete a task, and they also make mistakes that are even more time consuming to fix.

Is there anything else we can spend our money on? Perhaps.As you read later chapters you will read about a variety of tools that support analysts and programmers. These tools are often a wise investment. Analysts, for example, use graphical packages such as Microsoft Visio to communicate ideas about the project to others, and CASE tools such as Visible Analyst also help speed up projects.

Even new hardware could be a worthwhile expenditure. Laptops and smartphones improve productivity away from the office. Larger visual displays, Bluetooth-enabled keyboards and mice, and more powerful graphics cards can also increase productivity.

Quality

The third resource control variable is quality. If ideal systems are perfect, why is so much effort placed in maintaining systems? Are we already practicing agile development by sacrificing quality in software development? In Chapter 16 we will see the importance of quality and methods (such as TQM and Six Sigma) that help ensure software quality is high.

The agile philosophy, however, does allow the analyst to adjust this resource, and perhaps put less effort into maintaining quality than otherwise would be expected. Quality can be adjusted both internally and externally. Internal quality involves testing software for factors such as functionality (Does a program do what it is supposed to do?) and conformance (Does the software meet certain conformance standards and is it maintainable?). It usually doesn’t pay to tinker with internal quality.

That leaves us with external quality, or how the customer perceives the system. The customer is interested in performance. Some of the questions a customer may ask are: Does the program act reliably (or do software bugs still exist)? Is the output effective? Does the output reach me on time? Does the software run effortlessly? Is the user interface easy to understand and use?

The extreme philosophy of agile development allows some of the external quality issues to be sacrificed. In order for the system to be released on time, the customer may have to contend with some software bugs. If we want to meet our deadline, the user interface may not be perfect. We can make it better in a follow-up version.

Commercial off-the-shelf software manufacturers do sacrifice quality, and it is debatable whether this is the correct approach. So don’t be surprised when your PC software applications (not to mention your operating system and Web browser) are updated often, if developers are using extreme programming as one of their agile practices.

Scope

Finally, there is scope. In the agile approach, scope is determined by listening to customers and getting them to write down their stories. Then the stories are examined to see how much can be done in a given time to satisfy the customer. Stories should be brief and easy to grasp. Stories will be described in more detail later in this chapter, but here is a brief example showing four short stories from an online air travel system. Each story is shown in bold type:

Display alternative flights – Prepare a list of the five cheapest flights.
Offer cheaper alternatives – Suggest to customers that they travel on other days, make weekend stays, take special promotions, or use alternate airports.
Purchase a ticket – Allow the customer to purchase a ticket directly using a credit card (check validity).
Allow the customer to choose his or her seat – Direct the customer to a visual display of the airplane and ask the customer to select a seat.

Ideally, the analyst would be able to determine how much time and money was needed to complete each of these stories and be able to set the level of quality for them as well. It is obvious that this system must not sacrifice quality, or credit card purchases may be invalid or customers may show up at the airport without reservations.

Once again agile practices allow extreme measures, so in order to maintain quality, manage cost, and complete the project on time, the agile analyst may want to adjust the scope of the project. This can be accomplished by agreeing with the customer that one or more of the stories can be delayed until the next version of the software. For example, maybe the functionality of allowing customers to choose their own seats can be put off for another time.

In summary, the agile analyst can control any of the four resource variables of time, cost, quality, and scope. Agility calls for extreme measures and places a great deal of importance on completing a project on time. In doing so, sacrifices must be made and the agile analyst will find out that the trade-offs available involve difficult decisions.

Four Core Agile Practices

Four core practices markedly distinguish the agile approach from other approaches: short releases; the 40-hour workweek; hosting an onsite customer; and using pair programming.

Short releases means that the development team compresses the time between releases of their product. Rather than releasing a full-blown version in a year, using the short release practice they will shorten the release time by tackling the most important features first, releasing that system or product, and then improving it later.
Forty-hour workweek means that agile development teams purposely endorse a cultural core practice in which the team works intensely together during a typical 40-hour workweek. As a corollary to this practice, the culture reinforces the idea that working overtime for more than a week in a row is very bad for the health of the project and the developers. This core practice attempts to motivate team members to work intensely at the job, and then to take time off so that when they return they are relaxed and less stressed. This helps team members spot problems more readily, and prevents costly errors and omissions due to ineffectual performance or burnout.
Onsite customer means that a user who is an expert in the business aspect of the systems development work is onsite during the development process. This person is integral to the process, writes user stories, communicates to team members, helps prioritize and balance the long-term business needs, and makes decisions about which feature should be tackled first.
Pair programming is an important core practice. It means that you work with another programmer of your own choosing. You both do coding, you both run tests. Often the senior person will take the coding lead initially, but as the junior person becomes involved, whoever has the clear vision of the goal will typically do the coding for the moment. When you ask another person to work with you, the protocol of pair programming says he or she is obligated to consent. Working with another programmer helps you clarify your thinking. Pairs change frequently, especially during the exploration stage of the development process. Pair programming saves time, cuts down on sloppy thinking, sparks creativity, and is a fun way to program.

How core agile practices interrelate with and support agile development activities, resources, and values is shown in the figure shown below.

The core practices are interrelated with agile modeling’s resources, activities, and values.

Contents