Adapting During Adapt Week

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 Media Adapts During Adapt Week
• User Acceptance Testing
• Copyright

How Acme Media Adapts During Adapt Week

In this section, Acme will do the following:

• Review the work that was completed during the iteration

• Demonstrate the work and gather feedback on it

• Perform user acceptance testing on the work

• Review the identified issues

• Reprioritize the work based on their findings

• Re-estimate new features identified

• Review velocity and determine capacity

• Modify the iteration plan for iteration 2

Acme has outlined the following schedule for the adapt week:

• Monday. Team cleanup on features; complete testing

• Tuesday. Structured demonstration to customers, stakeholders, and the team at large

• Wednesday/Thursday. UAT with Jay

• Thursday. Review discoveries from UAT; review team velocity

• Friday. Review and re-plan; update plan for iteration 2

Let’s rejoin Acme Media to see common of ways of adapting at the conclusion of an iteration.

Reviewing the Work Completed

Acme Media assigned features to iteration 1, as shown in Figure 20.3.

Most of the features have been completely unit tested and are going through final testing in QA. The auction engine is running late, and the team needs to find out if it’s in a state where it can be demonstrated to customers and stakeholders.

Matt the developer has just completed the final unit tests on the auction engine, and he’s confident it will demonstrate all the functionality. The feature was delivered late because he had to make architectural changes to support caching. (Caching is required to support up to 100 concurrent bidders.)

Note

A Retrospective Now?

It’s a good idea to perform a quick retrospective between iterations. These meetings are typically informal, and the team can quickly identify areas to improve before the next iteration kicks off. To take this even further, you may find that you need to stop during an iteration and review what is going on, especially when feature delivery is running late or when major process issues are being encountered.

Figure 20.3 The status of the work for iteration 1. Most of the features are going through their final tests, but the auction engine is running late. It isn’t uncommon for a feature to run late during an iteration, even with daily management. The main question is whether you can demonstrate all the features.

The first day of the adapt week involves reviewing all the features to make sure they’re in a demonstrable state. Acme Media has been integrating and stabilizing the code during the iteration, but it’s hard to envision the entire system until all the features are complete.

Demonstrating the Work

Acme Media dedicates half a day to presenting the iteration work to the customer, stakeholders, and anyone in the company who wants to see the how the project is going. Stakeholders include anyone with a vested interest in the project. (Typical stakeholders include executives, support organizations, investors, and technical partners such as analytics.)

Acme outlines a demonstration schedule during day 1 of their adapt week (see Figure 20.4).

Acme creates a tentative schedule for the demonstrations so that stakeholders can choose when to come by if they aren’t available for the entire day.

You should note two items when reviewing Acme’s demonstration plan. First, the plan is somewhat formal and structured. Acme decided to go with a more structured demonstration because the project affected several areas. Second, this is a high-level demonstration for stakeholders and customers. The team will perform a more detailed demonstration when they perform UAT with the customer, Jay.

Figure 20.4 Acme Media demonstrates the iteration features during the team’s demo day. The demonstration synchronizes the company on the current state of the project and provides an opportunity for feedback. The entire team participates in the demonstration, with developers, designers, project managers, and testers describing status from their perspective.

One Agile principle states, as complexity increases, the project will require higher levels of ceremony. If the Auctionator project was smaller, the demonstration process could be informal and include the UAT at the same time.

Demonstration day is a special time for a project team. The team knows their work is valuable because people want to see it and ask questions about it. The demonstration also adds transparency to feature status. True status is evident to everyone.

Personality Types and Demonstrations

In the early days of software development, the only people who spoke in front of customers were managers and leads. Everyone else was a worker bee and did their job silently back at their desk. Because these team members didn’t do presentations, management usually worked with leads if they had feature questions.

In the last few years, we’ve seen a change in this area. More and more worker bees enjoy talking about their work and presenting to the team at large. This bodes well for a collaborative environment. High interaction is required and desired in a high-performance Agile team.

But sometimes a reclusive worker really doesn’t want to present. We’ve seen these folks forced to present, and they stutter, sweat, and stumble through their presentations. Such individuals may become physically ill when asked to present. What do you do if you’re trying to become Agile and a team member isn’t cut out for high social interaction?

You can work around a team member who doesn’t want to present. Another person who worked on the feature can present the feature, or two people can co-present. Another team member can lead the discussion, and they can both respond to questions. Co-presenting frequently works well for people who dread public speaking—it takes the pressure off them to lead the discussion, but they can still contribute value.

Demonstrating Incomplete Features

There are two types of incomplete features: planned and unplanned. In a planned scenario, you start the iteration knowing that you aren’t going to complete a feature but that you’ll take the feature to a certain state. For example, Greg once worked with a team that was creating a dynamic organizational-chart feature for their intranet. The team released new software every 7 weeks, and they didn’t think it was possible to deliver a solid product within that window of time. The team broke the feature into three sub-features that they delivered across three releases. In the first release, they created mockups and performed usability testing. In the second release, they delivered the product to the production environment. In the third release, they did refactoring based on what they learned in the production environment. This refactoring work included creating a web service to distribute the load across more servers and improve the performance of the feature.

In the unplanned scenario, you don’t complete your work by the end of the iteration date and the feature isn’t in a demonstrable state. What can you do? Here are some options we’ve seen teams use:

• If the feature infrastructure is complete but the interface is missing, create a test harness to exercise the feature’s inputs and outputs. A test harness can demonstrate the status of the feature and verify that the coded logic is working correctly. There is a good chance you can use existing unit tests to demonstrate the feature to the customer.

• If the UI is complete, present it to the customer and simulate the fields being populated. This demonstration can help identify usability issues.

• Demonstrate in the development or system integration environment. You may not consider a feature complete until it’s tested in a user acceptance environment, but you can still use other environments to demonstrate and obtain feedback.

Acme Media uses the last option with the auction engine feature. The feature isn’t built into the user acceptance environment when the demonstrations begin. Acme demonstrates the feature from the system integration test (SIT) environment while they build to the user acceptance environment.

The most important thing to remember is that you need to demonstrate, period. It’s easy to fall into a behavior where you never demonstrate features unless they’re complete. You may worry that the customer can’t comprehend an incomplete feature and will only ask questions about the missing components: if you take this approach, you may erode sponsor and customer support. Everyone needs to see that you’re making progress toward delivery.

User Acceptance Testing

Acme Media chooses to do more detailed demonstrations with the customer after the public demonstration. The additional testing allows the customer to ask more detailed questions and try the features hands on. The testing is another validation of feature completeness.

When smaller project teams perform UAT, the whole team participates. Everyone can hear the customer’s feedback and questions. This is the ultimate way to perform the testing so you keep everyone on the project synchronized on the state of the system and issues the customer may be encountering or the discovery of new requirements.

As projects increase in size, it becomes more difficult to have everyone participate in the testing. Team members may be pulled away for production issues; and it can be hard to coordinate the testing with a large group in the room, even in a large team room.

What Acme does—and what we’ve seen many larger teams do successfully—is have an analyst lead the UAT. The analyst leads the customer through testing all the features and includes the team members who worked on each feature. For example, the Auctionator has one analyst assigned to it: Rich Jenkins. Rich spends 2 days going over the features with Jay as Jay tests them. As they test each feature, Rich invites the team members who worked on the feature to join them; this usually includes the designer and the developer.

Although not everyone is required to attend UAT, the meeting is an open invitation to everyone on the team. The acceptance testing is performed in an open area adjacent to the team, and everyone is welcome to stop by and listen in on the testing discussion.

Acme Media’s UAT Approach

Some teams treat UAT as a free-for-all. These teams turn the customer loose and let them do whatever they like with the system in whatever sequence they desire. Other teams are more formal with UAT and go through the features one by one to verify functionality.

Acme Media chooses a hybrid model. Rich leads Jay through testing and analysis of each feature, but then he turns Jay loose on the system to look at any area he desires.

On some features, such as the auction engine, Rich also uses a light functional specification to help with the testing.

Output from Acme Media’s UAT

Acme schedules 2 days for UAT, but the team wraps up their work with Jay after a day and a half. The issues shown in Figure 20.5 are recorded at the end of the session.

Acme Media identifies several potential issues but nothing that prevents the iteration from being releasable. Issue 2 could be a distracting user experience, but the system is functional and Acme can put text on the posting screen that tells sellers it takes 10 minutes for items to display.

Figure 20.5 Acme Media identifies five issues during UAT. The team doesn’t identify any showstoppers for the iteration, but they do identify areas that require additional research and potential features for iteration 2.

Acme will also consider resolving the search-engine issue in iteration 2. The issue is a potential feature for iteration 2 because they haven’t yet compared it to the other priorities for the iteration.

Team agility comes into play in the way the team manages issues during an iteration. The team uses their experience to determine whether an issue can be fixed quickly and immediately or if the scope of the work is large enough to qualify as a new feature that should be pursued in a subsequent iteration. In the instance of issue 2, Roy thinks the work and research may take a day or so, and he asks that the work be treated as a new feature.

Previous article: Common Reasons for Adapting

Continue on to the next article: Changes in the Business Climate

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.