Agile Workflow

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.

• Completing a Feature
• Key Points
• Copyright

Completing a Feature

Development begins by reviewing the features in the iteration plan. Team members come together to determine the most logical place to start. If your team has a large enough staff, you may be able to begin work on all features concurrently.

In Acme Media’s instance, the team isn’t large enough to begin all features at the same time, so they focus on features that are at the core of the functionality. They start with Ability to place an item up for bid, Ability to bid on an item, and the Auction engine. The tasks associated with these features are started one by one as the team begins doing the work.

Note

Where Are Your Functional Specifications?

An Agile team and their coach choose the processes needed to support each project. They use their team experience and coaching to determine which tools and practices to use. Acme Media decided to create a functional specification for one feature in iteration 1, the Auction engine.

Acme Media’s team viewed the auction engine as complex, and they wanted to have a deep understanding of each use case, the actors involved, and the business rules. They didn’t think a feature card and accompanying story could store all the information they would want to reference and share during development.

When the team created the functional specification, they decided to embed the feature-card information into the specification. This information was still valuable, and it would be great to reference it while reviewing the deeper functional requirements. The team also took digital pictures during their whiteboarding sessions and embedded the photos into the specifications for reference.

Acme Media’s approach is in line with a major Agile concept. Greater levels of documentation are expected if the project or feature requires greater ceremony. This means you should create documentation if it helps the team get the job done or if you have a customer for the documentation. Agile teams must be careful to make sure they don’t skip creating documents because they consider paperwork anti-Agile.

We’ve noticed one other thing during development, and you probably have, too: many features are so dependent on each other that they must be built in parallel. For example, it may be hard for the Acme team to create logic for search if they don’t know the attributes of an auction. Conversely, they may want to change the data structure of an auction if it impedes search engine performance. It’s common to iteratively build out features in parallel as team members discover feature dependencies.

What the Work Looks Like

Agile development begins when a developer pulls a task from the iteration plan and then works with other team members to complete a feature. This work can take many forms:

• Reviewing design and technology options. Every requirement can be addressed in several ways from a technical perspective. Developers can choose a framework they have experience with or experiment with a technology that may support the need. The development team will review their options and reach agreement before proceeding.

• Working a problem. We’re confident more time is spent working on issues than on any other task during development. When the code is open, you’ll frequently discover constraints. Developers spend a lot of time reading blogs and posts about issues they encounter. They also spend time discussing issues with other developers and soliciting second opinions.

• Continuing to scope and refine the work. Even though the developer discusses the requirements with an analyst or the customer, scope discussions continue. Similar to Acme’s issue with search categories, the developer sees details that the analyst couldn’t anticipate or places where two requirements contradict each other.

• Working on alternatives with the customer. Frequently, the customer will have a requirement that can’t be met without a major expense. For example, Greg once worked with a customer who wanted a guarantee that the system would be available 99.95 percent of the time. Greg’s team estimated that the additional architecture and hardware needed would cost around $500,000. The customer decided to go with an up-time requirement of 99.50 percent instead, for no additional expense.

• Creating content to test the application. This part of development is frequently underestimated. Good content needs to be established to provide an accurate test of the application, and the content must be consistent across environments. You get a jump-start on this work in iteration 0 and then finalize the content needed during the development iterations.

• Creating unit tests. Developers will create unit tests to verify their individual functions are working correctly. In a test-driven environment, the unit tests are created before construction begins.

To continue this discussion, let’s look at the model of feature development in Figure 18.2.

Figure 18.2 Following a feature through development. An iteration plan sets you up for development, and you pull tasks and complete them as a team. The team needs to work together to ensure consistent understanding and to be aware of how tasks interact with each other.

After the team completes their work, the developer performs a unit test to make sure the feature is working as requested and then integrates their code into the mainline code stream.

As the team is completing their work, a tester is preparing test cases for feature testing. This work starts during initial planning. Acme Media’s tester, Gina Wallace, was in the room during the feature-card exercise and began envisioning the tests needed at that time. Gina also asked the customer questions about nonfunctional necessities such as performance requirements.

As features are completed, Gina pulls a feature and tests it. If a feature passes, it’s labeled test complete and put into a queue for demonstrations at the end of the iteration. If a feature fails the test, it’s put back into the list of features and tasks.

Other Considerations for Development Iterations

Here are a few items to note when reviewing this workflow:

• The developer will probably create unit tests incrementally for the code they’re creating. Unit tests are usually created at the function or class level.

• It’s common for the customer or analyst to work with the tester to create the functional tests. In an Agile environment, the tester is sitting with the team and can ask clarifying questions quickly.

• There are several ways to manage features that fail. You can put bugs on the iteration backlog or hold a separate bug-triage meeting before putting the bug into the work queue. We personally like the triage meeting. Much of the time, we find that a bug isn’t a bug but a misinterpretation of the requirement or an issue with the testing environment. Working bugs as a team can get to the root cause quickly.

• Unit and functional tests are more common, but frequently we do other tests for features and applications. We also do acceptance testing during the adapt phase, and we may do usability and performance testing if we see the need.

• You’ll formally reserve time to demonstrate the features after the iteration, but you can also preview your work as you’re building it. An Agile team plays this by ear. If you spend too much time demonstrating, you can hurt your productivity. We find that the best balance is to demonstrate or discuss areas that have high requirements uncertainty, or when a feature is turning out to be technically expensive. In these instances, you can demonstrate and discuss alternatives with the customer.

Key Points

The key points from this chapter are as follows:

• Projects can be measured in terms of percentage of tasks complete, but the ultimate metric is the demonstration of working code.

• Books like this one can help you understand what Agile is about through a case study, but the main goal is to make sure the processes and exercises you use support the Agile principles.

• A mature organization can pull tasks from the project backlog as team members are available. Teams with specialists will have to do more planning for task assignments.

• Features are often dependent on each other, and you may need to iteratively construct features in parallel.

• Work is a subjective term in an Agile environment. Many times, you’ll spend more time resolving issues and researching technology than you’ll spend on coding.

Previous article: Supporting the Agile Principles During Development and Testing

Continue on to the next article: Testing: Did You Do It Right?

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.