Supporting the Agile Principles During Development and Testing

Applies to: Agile

Authors: Greg Smith and Ahmed Sidky

Get this book in Print, PDF, ePub and Kindle at manning.com. Use code “MSDN37a” to save 37%.

This topic contains the following sections.

• How Acme Embraced Agile Principles
• Where to Begin?
• Copyright

If the Acme Media team decided to track their pilot project in a project tool, they would say that the project is around 50 percent complete. Fifty-percent complete sounds good. You’re halfway there. You can tell your stakeholders that you’re on schedule and they don’t need to worry about anything. But this is where things change in an Agile environment.

In an Agile environment, you measure status by working code. Knowing if a project is feasible is a good thing. Doing initial planning is a good thing. But to this point, you haven’t delivered any value to the customer. From a customer perspective, you have a project status of 0 percent.

In Agile, you get to working code quickly by using iterative development and building to the minimum specification. You deliver the most valuable software in prioritized batches. You do your best to make each batch contain enough functionality for it to be a deployable subset of features.

Iterative development works because it supports the realities of software development. You can’t forecast all the variables, but you can make sure you deliver critical functionality as quickly as possible.

This chapter begins with a discussion of the Agile development principles and how Acme Media has embraced them. You’ll see the principles in action as we follow Acme through its development iterations. We’ll contrast these principles to Acme Media’s legacy processes.

The game of rugby provides a nice visual example of how the process works. In rugby, one of the team formations is called a scrum. The scrum formation involves many players meeting at the same point on the field and literally interlocking their heads. The same thing is true during Agile development. All team members, regardless of title or area of expertise, work together to deliver working software. Their minds are interlocked with a singular purpose: to deliver high-value functionality to the customer as quickly as possible.

In the past, Acme Media delivered all software, both highand low-priority features, in one delivery at the end of the project. The entire team didn’t help during development; it was solely up to the programmers to bring the features home. In this chapter, Acme will use its new iterative approach and deliver the highest-value features first. The team will deliver working software in batches until they run out of time or the customer need is satisfied.

How Acme Embraced Agile Principles

Acme Media moved to an Agile process because the company wasn’t delivering projects quickly. The development team had a history of constantly moving out milestones and missing deadlines. With the newfound popularity of web advertising, the team was overwhelmed, and customers were taking their advertisements to other websites that could turn them around quickly.

Acme Media made the correct choice in deciding to move to Agile. The following ten Agile principles discussed in this chapter focus the team and the company on delivering early during the construction phase:

1. Satisfy the customer through early and continuous delivery of valuable software.

2. Have business people and developers work together daily throughout the project.

3. Whenever possible, communicate face to face.

4. Pay attention to technical excellence and good design.

5. Focus on simplicity and the art of maximizing the amount of work not done.

6. Welcome changing requirements, even late in development.

7. Test early, and test often.

8. Continuously integrate code changes.

9. Obtain customer feedback as early as possible.

10. Minimize team distractions during development iterations.

Let’s look at each principle separately.

Satisfy the Customer through Early and Continuous Delivery of Valuable Software

Acme Media never delivered early in the past, but the company’s new iterative approach will let it get key features out to the customer early. The team will deliver more quickly because they didn’t have to create functional specifications before they created their iteration plan. They saved time because they didn’t document requirements for features that won’t be pursued.

Have Business People and Developers Work Together Daily Throughout the Project

In Acme Media’s previous process, the business analysts worked with the customer to document requirements. Frequently, an internal product manager communicated the needs. After the requirements were documented, the analyst passed them to the developer and determined whether there were any questions.

In Acme Media’s new process, the developers have already had direct interaction with the customer. The entire team participated in the feature-card exercise, and the developers gained clarity on some customer needs by asking questions directly. The customer (in this case, the product manager) will also be available during the development iterations and can clarify their needs and be consulted if issues are encountered.

Notice how the principles stress business people, not just customers. In our experience, several individuals beyond the customer and the development team care about a project, including people in marketing, legal, security, implementation, support, documentation, and training. In an Agile environment, the development team interacts with these teams throughout a project.

Whenever Possible, Communicate Face to Face

This principle is difficult for Acme Media to embrace. The team enjoys using email and Instant Messenger. They rarely do face-to-face discussions during development. The repercussion from this style is that team members frequently get into email hell, where a message goes around and around with as many as 20 responses.

We live in an age of Blackberries, texting, instant messaging, and blogs. Some people like to wear headphones when they work. There are more and more ways to communicate indirectly. Basically, we’re allowed to communicate on our own schedule, at our leisure. The convenience of communicating whenever you want to can be helpful, especially when a team member has to travel or be away from the work area for a while. But during development, these methods should be the exception, not the norm.

This is where an Agile coach or manager can help. A good coach will always be observing the process and looking for ways to ensure collaboration, quick decision making, and common understanding within the team.

Acme Media’s Agile sponsor, Steve, saw this issue at Acme after he received his training on Agile. Steve worked with the management team to create a physical environment at Acme Media that supports face-to-face communication:

• A few team members weren’t in the main development area, and these team members were relocated to be with the main group.

• Acme had standard cubicles with walls 5 feet high. When team members wanted to chat, they had to get up and walk around to see each other. Steve had the cubicle walls lowered to 3½ feet so the team can communicate face to face without taking a walk.

• Steve cleared out a large area next to the development area and called it the bullpen. It’s dedicated to the development team, and team members can meet there at any time and post anything they want on the walls. Wendy, the project manager, uses the wall to post status information for the features that are in progress.

• Steve purchased several rolling whiteboards so the team can have quick discussions within the cube areas.

These changes don’t force the team to work face to face more often, but you’ll find that it happens naturally. Team members may find it a bit silly to IM or email a person who is visible to them.

Pay Attention to Technical Excellence and Good Design

Acme Media has the classic issue that most teams do: they need to deliver early, but they also need to make sure their design and architecture are scalable. How do you solve this problem? You don’t.

This struggle continues in an Agile environment. If you rush a product and deliver it without any reflection on future needs, you may have to start from scratch to support a simple enhancement. Your lack of foresight may prevent you from delivering value quickly.

Conversely, it’s easy to spend a lot of time pursuing the perfect design: one that is scalable for any situation; that can’t be critiqued for any flaws; and that takes so long to create that you ship your product late, after the opportunity is gone.

Technical excellence involves balancing these two areas and delivering valuable software frequently while minimizing the cost of future change. This isn’t simple to do, but it’s a reality of software development. Developing software is complex, and for many of us this is the challenge and joy in doing our work.

Acme Media had this issue before they pursued Agile. The main difference for them now is that designers and architects know that a perfect design can cost the team

a delivery. After several missed deliveries, the company and their careers could be in jeopardy. Consistent delivery ensures customer satisfaction and income.

Focus on Simplicity and the Art of Maximizing the Amount of Work Not Done

Some days, Ahmed gets under the skin of his clients. They know that sooner or later they will hear his trademark questions: “Why are we doing this feature, and what happens if we don’t?” Ahmed works with his teams during the feature-card exercise, and he usually remembers what the customer requested during the session. When Ahmed sees the team pursuing feature richness beyond that vision, he questions it.

It’s easy to have scope drift within your team. It’s natural to want to create great software and go beyond a customer’s minimal requirements. Greg once worked for a company whose mission statement said it would “meet and exceed customer requirements in an effort to delight them.” This is a dangerous approach to take in software development. Getting code to a state where it can be deployed is challenging enough without adding bonus functionality.

Focusing on simplicity also lets you demonstrate to the customer sooner. The sooner you demonstrate, the sooner you know if you’re in synch with their needs. This prevents waste and minimizes rework.

Acme Media never thought about this principle in the past. The developers received a functional specification, and they determined feature richness. The developers could even use a feature request to test new technology or add functionality they thought the customer might request in the future. In the new Agile world, the development effort is time-boxed, and the team is encouraged to surface their work as soon as possible for customer review.

Welcome Changing Requirements, Even Late in Development

We can’t lie. We don’t welcome changing requirements. We embrace Agile, and we know the roots of this principle, but we haven’t been able to convert to a mode of welcoming changing requirements. What we do welcome is a process that expects change and doesn’t add to the issue by pretending change doesn’t exist in a software project.

We’ve worked in environments where we had to create a change request for every variation during a project. The change request was associated with guilt and poor project management. In reality, all projects have changes in requirements. These changes typically come from the customer seeing a working product and identifying an oversight, or from a technical discovery after programming begins.

Acme Media has lived in the guilt world. It thought other companies didn’t have these issues. It thought it had wishy-washy customers and a poor project manager. In the new environment, the company may not embrace changing requirements, but it understands that they’re inevitable and can’t be planned out of a project.

Test Early, and Test Often

Acme Media used to perform its testing at the end of development. The company thought this was a good approach. If the team ran short on time, they could cut back on testing and still finish development.

The issue with this approach is that when you do find bugs, it takes longer to trace them. The magnitude of a bug can be greater too, potentially requiring a rewrite of code in several areas.

To mitigate this risk, an Agile team tests as soon as possible. In some sense, testing begins during the feature-card exercise. A QA employee should be in the room during the exercise to identify inconsistency in requirements, potential integration issues, validation of performance needs, and other technical constraints.

Advanced Agile teams take this concept even further by using a process called Test Driven Development (TDD). A TDD process has the developer create a unit test before writing any new code. The test is executed to validate that it failed, and then the developer begins writing code until the test passes. This approach usually shortens the overall delivery cycle.

Acme Media won’t pursue TDD out of the gate, but the team will begin testing early and pursue a goal of daily builds and a build-verification test.

Continuously Integrate Code Changes

Related to testing early and often is the principle of continuous integration. Developers need to continually integrate their code changes to verify that their latest change hasn’t broken the code. Continuous integration also ensures that the entire team is working from the same version of base code.

Historically, integration has been an infrequent event during development, and integration issues have been discovered late in the cycle, making them harder to find and jeopardizing ship dates. Acme Media didn’t integrate often in the past, and this added to the company’s issue of missing delivery dates. Integration of every change requires discipline, and Acme Media’s developers didn’t want to be that disciplined. Acme will move to daily integration during the pilot, with a long-term goal of integrating every code change.

Obtain Customer Feedback as Early as Possible

In the past, Acme Media sought feedback from the customer after development was complete. Using this approach, Acme Media’s team frequently found the customer had functionality issues with the code that was developed. The issues went beyond bugs: they frequently tied to the customer saying the code didn’t meet their needs. Acme tried to address as many issues as possible before going live, and if major issues couldn’t be fixed quickly, they delayed shipping the product.

Acme Media’s new approach is to demonstrate to the customer as soon as the team has functioning code. The customer won’t have to wait for the final product to provide feedback. Issues will be discovered early, before layers of code are applied.

Note

Does Scope Creep Exist in an Agile Environment?

Acme Media’s development team has never enjoyed change requests. Whenever the customer asks for a change, team members go back to their desks and mumble about “scope creep.” After their Agile training, team members have a new perspective. Let’s look at an example.

If a customer asks for an alarm clock, and during a demonstration they notice that they forgot to ask for a snooze button, then they have experienced a natural occurrence in software development. Sometimes you miss a feature detail during a requirements discussion, and a demonstration exposes what was overlooked. This type of change should be embraced.

On the other hand, if a customer asks for an alarm clock, and after a demonstration they request that the alarm clock also be usable as a coffeemaker, then you have a radical change in requirements and potentially a new project. Some might call this scope creep, but we think the issue ties to the need to ask “why?” during the featurecard exercise. If the root business need is known, it’s doubtful that a major functionality shift like this will take place during development.

As we’ve mentioned, we do embrace change, and if the customer truly needs an alarm clock/coffeemaker we’ll deliver it. But we want to make sure we understand the fundamental need.

Acme Media’s new development model has a formal adapt phase between iterations, during which the team demonstrates to the customer. These demonstrations will occur every 2 weeks. The team has also adopted an approach of surfacing work in advance of the adapt window if pieces are ready early or if the feedback will help them make design decisions.

Minimize Team Distractions during Development Iterations

During development iterations, the team needs to be 100 percent focused on the work at hand. Everyone must be available to clarify requirements and to collaborate on and solve solutions. In our experience, issues discovered during development can be solved in a multitude of ways, and involving the team at large makes this possible. Customers can modify or reprioritize requirements, developers can code around an issue, a product can be configured differently, or hardware can be modified.

Because you’re on a tight schedule for an iteration (usually around 2 weeks), you can’t spend time trying to trace down team members and orchestrate a meeting in the next day or two. You don’t send emails and wait for people to respond. You need to work issues promptly and stay on schedule for delivery at the end of the iteration.

In a perfect world, the team would have no distractions and could focus solely on the project at hand. Some companies have development groups that work only on projects. But most teams we work with have to deal with distractions. Many teams are also in charge of maintaining the current production environment, and if a production issue occurs they must work on it. This is true for Acme Media.

Acme Media’s development team works on projects and maintains the three existing websites. In addition, they have daily maintenance activities, and they frequently work on mini-enhancements that don’t require a project team. These supporting activities have contributed to Acme Media’s failure to deliver in the past.

The development team must continue to perform their support activities, but in their new development model they will try to defer maintenance and support activities until the adapt week. During development, they will be interrupted only for critical production issues.

Acme also realized that the company had become people dependent in several areas. Experts existed for every area, and developers didn’t cross-train with each other. When a production problem occurred, frequently only one person had the skills to work the issue. Acme identified this problem when the company outlined its new Agile process and created a plan to cross-train the developers. The cross-training will spread skills throughout the team and let the developer with the most free time address the issue, which will minimize project interruptions.

Now that you have a feel for the Agile principles, let’s see them in action.

Where to Begin?

When we left Acme Media, the team had just completed their iteration plan. They outlined one item for iteration 0, modifying the contract with eLertz to support an additional alert needed for the Auctionator. With this work out of the way, it’s time to focus on the features that are assigned to iteration 1.

The work backlog, shown in Figure 18.1, contains both features and tasks. The team first identified tasks during their feature-modeling exercise, when they identified the high-level work required to support each feature. The team identified additional tasks during iteration 0; now that they’re in a development iteration, they will finalize and complete the tasks. Even in an Agile environment, you can’t anticipate all of the tasks until you begin working on the features. We’ve often heard people say, “Development doesn’t really start until we open the code.” In our experience, we’ve found this to be true. Let’s look at an example with Acme Media.

Figure 18.1 Acme Media’s backlog of work for iteration 1. In a perfect world, team members grab a task and begin working. In Acme Media’s world, the team is constrained by specializations, and some tasks can be completed only by certain team members or groups. Acme Media will cross-train, but it will take time for the team to mature to a point of no specializations.

In a perfect world, team members grab a task and begin working. In Acme Media’s world, the team is constrained by specializations, and some tasks can be completed only by certain team members or groups. Acme Media will cross-train, but it will take time for the team to mature to a point of no specializations.

When Acme did the initial planning for Search by category, the team identified four major tasks:

• Create a screen to enter search criteria.

• Create a screen to display search results.

• Create a screen to display an item up for bid.

• Define the process for crawling and indexing items up for bid.

When Ryan, the user experience designer, starts working on the search screen, he notices that the search categories haven’t been discussed with the customer. The customer, Jay, the product manager, gives Ryan the categories, and they have a quick discussion about searching in general. It occurs to Jay that Acme Media serves a wide geographic area and that buyers will want to filter by location when performing a search. Ryan can add that functionality to the search screen without a significant change in his effort, so they agree he should do so. They share this decision with the entire team to see if it has any effect on designs for the other features.

Sequence within an Iteration

We frequently hear team members ask, “In what order should we pursue the features during an iteration?” The answer is twofold. First, you’ll often need to deliver all the features assigned to an iteration to take the application to a state where it provides value. From an end-user perspective, all features are equal—the customer needs them all for a minimal functioning system.

Second, from a coding perspective, it comes down to technical dependencies. Do some parts of a feature have to be in place before a related feature is pursued? For example, the Acme team members who create the search functionality will probably need some level of the auction functionality in place first. They must know what attributes are associated with an auction and then build out the correct search logic and indexing process.

In our experience, the sequence we build in is rarely serial. Team members evolve features together as everyone normalizes on what the system is. We frequently hear a team member say, “I’ve completed my first pass” at a task or feature, acknowledging that work on other features may require them to revisit their work. This approach is normal. Just be sure you don’t label a feature complete until everyone agrees it is.

Making Assignments

In the past, Acme Media made assignments at the start of a project. The team hammered out the tasks they thought they could do, and department leads assigned people to the tasks.

Acme Media has made a subtle change with the new process. The department leads assigned people to participate in the planning phase based on the information that came out of the feasibility work. The planning team identified tasks during the modeling exercise, and Wendy, the project manager, recorded the tasks on her iteration plan (Figure 18.1). Team members follow their areas of expertise and experience and put their names on the tasks that they identified.

The planning-team members also got a feel for the features and which tasks each one of them will probably perform. Wendy recorded this information with the tasks and went over it with the department leads at the end of the initial planning phase.

In our experience, a team that works together for a while develops a feel for who should do what on a given feature. Team knowledge and experience with each other allows team members to make quick decisions and interact with each other in an Agile way. Acme Media’s development team has had some interaction, but that interaction hasn’t matured to a point where they’re self-directed. The managers at Acme Media will be tasked with taking the team to a more self-directed level in the coming months and year.

It’s also important to note that assignments aren’t permanent—they can be changed on a daily basis if needed.

Previous article: Start Your Engines: Iteration 0

Continue on to the next article: Agile Workflow

Copyright

©2009 by Manning Publications Co. All rights reserved.

No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by means electronic, mechanical, photocopying, or otherwise, without prior written permission of the publisher.