Start Your Engines: Iteration 0

  • Article

Applies to: Agile

Authors: Greg Smith and Ahmed Sidky

Referenced Screen

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

This topic contains the following sections.

  • Initial Vision for the Architecture
  • Completing Contracts with Third Parties
  • Preparing Environments and Support Tools
  • Obtaining Funding
  • Finalizing and Dedicating the Project Team
  • Cheating: Starting the Work Early
  • Key Points
  • Copyright

At this point, the Acme team has performed feasibility and planning work for the pilot project. Many people in the Agile community label this pre-development work iteration 0. Iteration 0 work is foundational work that is performed prior to development starting.

For our purposes, iteration 0 is the foundational work performed after initial planning but before development begins. Iteration 0 work usually runs for about a week, but it can take less or more time depending on project complexity. Let’s look at some of the typical tasks performed during this timeframe.

Initial Vision for the Architecture

The Acme Media team performed a high-level analysis of the architectural needs for the Auctionator when they performed their feasibility work. They will take one more look at the architectural needs before they begin development. This makes sense, because they just came through the feature-card exercise. They have more information about each feature, and they can use that knowledge to outline an initial architectural model.

Assessing and modeling your architectural needs offers numerous benefits. Here are a few:

  • Confirmation of costs. You get a better feel for hardware and licensing needs, and you thus minimize surprise expenses during development.

  • Better understanding of third-party needs. You can identify dependencies with other departments and begin planning with them early.

  • Better communication. Documenting your initial model gives you a tool for interacting with other departments, vendors, and software providers.

  • Reduced technical risk. Outlining your initial architecture identifies areas where you may lack technical skills or technology needed to support the project.

You might think that this exercise would slow you down and prevent you from jumping into the code. In reality, you outline an architectural vision to ensure quick delivery. Your architectural work helps identify areas of risk that could prevent deployment at the end of development. You also focus on making the architecture flexible, so you can be Agile in supporting future needs and requirements.

Here are the technical artifacts that may be created during architectural assessment:

  • Infrastructure diagrams

  • Application flow diagrams

  • Logical component diagrams

  • Security model/requirements

  • Performance requirements

  • Availability requirements

  • User interface flow

What is your source for this technical information? Usually, an architect gets all the developers in a room to discuss the architectural approach for a project. A customer advocate is usually involved, too, to provide clarity on business needs.

We’ve seen some companies perform architectural modeling without a customer advocate in the room. This is possible, but it’s critical to have the requirements drive the architecture, not the other way around.

Completing Contracts with Third Parties

We can’t remember the last time we worked on project that didn’t require services or software from a third party. Iteration 0 is a great time to take care of contracts related to obtaining these services. Here are some examples:

  • Additional licenses. We see this a lot when working with Microsoft products. You may need to obtain additional application or SQL server licenses to support additional users or processes.

  • Data feeds. Ahmed once worked on a Do Not Contact marketing application, and his team had to obtain the Do Not Contact names from several vendors. We’ve also worked on directory-type applications where we had to obtain business listings from Yellow Pages providers and load them into a database.

  • Email services. Some companies will manage user alerts for you. Acme Media uses eLertz for its various alert needs; eLertz will notify users when an item they desire comes up for bid. Many companies will also manage online subscriptions and pass articles or other information to your users based on their profile.

  • Search services. So many good search options are on the market that it frequently makes sense to buy this functionality instead of creating it. We’ve worked at companies that purchased the Google Search Appliance or another off-the-shelf search application and installed it in their environment.

  • Contract help. You may work on projects where you need to beef up your team to address a skill set that you don’t typically require. We recently helped a team with a project where they needed to create a web-based training module for users. This wasn’t a normal need for their projects, so the team hired a contractor who specialized in creating training modules.

  • Specialized applications. Similar to search, it doesn’t make sense for you to create some other kinds of applications, because good, affordable products are already on the market. These include stock tickers, weather widgets, blog applications, mapping software, content-management systems, and online forms.

When you’re squared away with third parties, you can make sure your development environments are ready to go.

Preparing Environments and Support Tools

As you come out of initial planning, you’re thinking about the customer, their feature requests, and how you’re going to design and create the features. It’s easy to get so caught up in this moment that you forget to prepare the environment from a technical and project-management perspective. Iteration 0 is the perfect time to make sure you’re ready to develop, build, test, manage, and track code.

Let’s start with the development aspect. What do you need to do to make sure you’re ready to build code? You should set up some of the following areas:

  • Version control. Set up a new branch or project in your version-control system such as Subversion or Perforce.

  • Automated builds. Get CruiseControl or your tool of choice to support daily builds and continuous integration. Make sure all developers can monitor the builds.

  • Workstations. In addition to build tools, make sure the developer workstations are good to go. Be sure framework and development products are installed and configured correctly for the project you’re pursuing.

  • Defect tracking. If you use a bug-tracking tool, create a new project in the tool before you begin recording issues.

When the development environment is prepared, you must consider all the ancillary tools and processes required to support the project. Here are the ones we frequently see teams use:

  • Automation testing. Prepare your build-verification tools for the forthcoming builds. This usually involves reviewing your latest release and seeing what additional scripts must be created to regression-test the application.

  • Load testing. If your initial planning indicates that some features may have high volume or place a heavy load on the system, you need to plan for load testing during development. This involves using load-testing tools such as LoadRunner to simulate many users hitting the system concurrently. You must create scripts that will test your features and verify that the system will perform at the required level.

  • Content testing. What kind of content or data do you need to test the features?

You’ll probably need to create the content before testing, so try to create it during iteration 0. Even more important, make sure you have a process for refreshing the data during testing and keeping data consistent across all test environments.

After ancillary tools, you need to make sure all the project-support tools are set up or established. You may be using these types of tools:

  • Time tracking. Time tracking is needed to measure how much of a project budget has been used or to bill a client for time and materials. Time tracking seems like an anti-Agile activity, but it frequently has to be done on a project and it’s one of the constraints many teams have to accept.

  • Status tracking. How will you track risks, code completeness, build notes, and iteration status? These tools also need to be set up during iteration 0. Tools such as burn down charts and iteration plans can be posted on your project wall, configured in your wiki tool, or both.

If you have your tools and environments set up, what else do you need? Money!

Obtaining Funding

One of the things we enjoy when working for small companies is having little overhead. We usually have only one product, one project, one project team, and one budget. It’s easy to focus on the goal of delivering value to the customer.

When we work for larger companies, we see more overhead, bureaucracy, and rules for initializing a project. One of those hurdles is obtaining funding.

Acme Media doesn’t have many hurdles in funding the Auctionator project. The company has a dedicated project budget for the team, and the Auctionator doesn’t require additional funds beyond the team’s annual budget.

Funding becomes more difficult when a significant capital investment is required to support a project. If you need to buy more servers or expensive licenses, your company may require the completion of financial forms and spreadsheets. Greg currently works in such an environment.

In Greg’s workplace, several groups compete for capital dollars needed to support their projects. The teams all present their business cases to an executive review group, and the executives make the call about which projects to fund. As you can imagine, this process can take some time: completing forms, going to review meetings, waiting for the executive decisions, and finally waiting for an account to be opened so orders can be placed.

Greg’s company has realized that this formal process can jeopardize projects that need to be delivered quickly to ensure benefits. To remove this issue and become more Agile, Greg’s company has created a process that lets a team receive early funding before a project is formally approved. The team doesn’t receive enough funding to pay for the entire project, but they get enough money to keep working on the project while the final decision is being made and the value is validated.

Finalizing and Dedicating the Project Team

Let’s take a moment to review the current state of Acme’s project team and how the team got where it is:

  • Acme started with a project idea from the product manager (who acts as the customer advocate).

  • The product manager and project manager worked together to determine what type of employees were needed to perform feasibility. They added a developer and a UI resource at that time.

  • After feasibility, the team had a better feel for the types of employees that would be needed to bring the project home, and they brought several more people into the project: an additional developer, a QA resource, an operations resource, a business analyst, and an architect.

Now that development is about to start, how does the team change? First, Acme lets the representative from the Operations team, Tom Klein, return to his job. Tom won’t be involved in development, but the team will invite him to demonstrations so he can provide feedback and share any concerns he sees from an operations perspective.

The team also lets the architect reduce his involvement with the project. We typically see architect involvement reduced by half after a project goes through initial planning. The architect will come back for several design sessions and to help Acme’s team resolve issues related to performance or scalability. This also frees the architect to work with other project teams that may just be getting started.

The remaining team members need to be dedicated to the project. In a perfect world, you’ll have a product-development team and a production-support team. The development team shouldn’t have any issues focusing on the project work at hand.

In the not-so-perfect world—and in the situation we see the most—the development team is also in charge of supporting the production environment. This means they’re dedicated to the project unless a high-priority production issue interrupts them. We say high priority because we encourage Agile teams to wait until the adapt period between iterations to look at noncritical issues that may have occurred in the production environment.

The main thing to remember is that collaboration and communication are critical during an iteration. Make this the number-one priority for all team members. Try to put off competing projects or issues until after the iteration is complete.

Cheating: Starting the Work Early

We’re avid supporters of project cheating. We’re always looking to take advantage of opportunities to start an activity early, test early, demonstrate early, adapt early, and deliver early. Iteration 0 is a great time to cheat. In theory, you aren’t officially working on an iteration, but you can still use this time to remove risk and increase understanding.

Development environments may not be ready yet, but you can still pursue activities that reduce risk and increase feature understanding. Some of the tasks you can start during iteration 0 are as follows:

  • Continue scoping. It’s doubtful that you got all the information needed to develop features during the feature-card exercise. Continue interacting and modeling with the customer to refine feature requirements and understanding.

  • Start modeling and prototyping. In our experience, the development environment isn’t required to create prototypes. You can outline prototypes with pure HTML, Photoshop, whiteboards, and even sketches on a piece of paper.

  • Test interfaces and APIs with vendors. If your project involves any type of interface, you should begin testing it as soon as possible. Interfaces usually represent the highest risk to project timelines.

  • Initialize test cases. Related to scoping, you probably didn’t come out of the feature-card exercise with a crisp definition of how you’ll test each feature. You can get a jump on this work in iteration 0.

  • Work issues and risks. What items could potentially derail or delay the project? Will you need sign-off from a compliance group before deploying? Will you need support and maintenance processes in place before you go live? Do you need to reserve shared resources for the project, such as a load-test environment? Use iteration 0 to get started on these items.

  • Training. Will you need to deliver training materials at the end of the project? Iteration 0 can be used to jumpstart these.

  • Communication planning. Who will be affected by your project? Iteration 0 is a great time to identify your audiences and the messages you need to send to them during development, deployment, and (potentially) migration from the old system to the new one being delivered.

  • Marketing plan. Your product or project may require a marketing plan to roll it out. For example, Acme Media needs a marketing plan to support the Auctionator. Acme has faith in the product, but the company needs a way to advertise to the customers they’ve lost to eBay and Craigslist.

When the development environments come online, you can stop cheating and begin your development iterations in earnest.

Key Points

The key points from this chapter are as follows:

  • One-time projects may require set-up and foundation work before development can begin.

  • Initial architecture modeling can bring the team together on a design vision and speed up development.

  • Many projects require the services of third parties. You may need to complete contracts or obtain vendor licenses before beginning development.

  • You may need to set up your environments before work begins. This pre-work could include setting up machines, organizing load-test environments, and preparing test content.

  • Larger projects may need tools set up to support the project. These can include time-tracking systems and status tools.

  • Many projects require funding to get started. You may have to present your feasibility findings to a funding body and obtain approval before proceeding with development.

  • Although your development environments may not be ready to go, you can still do other value-add work for the project. This can include feature modeling, estimating, training preparation, and working on your communication plan.

  • Work for a project does not have to start at a prescribed date or time. If team members have capacity, they can begin design and investigation work before an iteration formally begins.

Previous article: Determining the Hours Available in an Iteration

Continue on to the next article: Delivering Working Software

©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.