One of the most misunderstood aspects of agile software development is the first few days, or weeks of a new project. Little has been written about this subject, perhaps because it's a "phase" that we just get through on the way to starting the interesting development work, or perhaps because it's fairly straightforward to people with agile experience.
Agilists refer to the initial iteration of a project as "Cycle 0", "Iteration Zero" or "Sprint Zero" during which you determine whether the project is feasible, setup the technical environment, start building the team, and do sufficient modelling to support these activities. Sounds like what you do on a traditional project? The difference, however, is agilists achieve the same goals with a lot less effort - Iteration Zero is typically a week or two at most.
An Iteration Zero does not deliver any functionality to the customer. Instead, the team focuses on high-level analysis, configuring the environments, and the simple processes that will be required for the adoption and use of most agile practices.
Planning the Iteration Zero
Keep Iteration Zero time boxed. Avoid gold plating of the work, or having long Iteration Zero to cover all things totally. Later iterations might also include some infrastructure work, there will be changes in product vision, architecture, and so on. Do the minimal work that will help you to understand the product and start delivering working features.
Consider to hold an iteration planning meeting just like with any iteration.
Put all activities that you know about into the iteration. Set as good time estimates as you can. During the iteration, constantly refine the backlog by adding additional activities discovered by the initial investigation activities. Set time estimates for those too.
If you have more time before starting the project (because of necessity to spend some time to form the team or to agree some paperwork), consider using Kanban to prepare for the project, but still planning is needed to get the things done.
An important consideration during Iteration Zero is the economic, technical, operational, and political feasibility of the project. So we ask ourselves if the system will pay for itself; if you have the ability to build the system (or to manage the project if you're outsourcing the effort); if you can keep the system running once it's built; and whether your organisation can tolerate the successful delivery of this system.
Build the Team
You begin to build your team during Iteration Zero. You don't need everybody on the first day, but you do need your key people if available. This can be a bit different from what traditionalists are used to—there is very little "ramp up time" on an agile project because we start doing the work right away. On an agile project, there aren't weeks or months of modelling, documentation, and reviews to get through. Instead, there are hours or days of it—and then you start to work on building working software.
Ideally, agile teams are typically made up of generalist specialists who have one or more specialties (for example, they're great at both use-case modelling and Java coding), a general knowledge of the software process, and at least a general knowledge of the domain. If you don't have such people yet, don't worry—as long as you can find people who are willing to work towards becoming a generalist specialist, you should be okay.
One or more stakeholders will be active participants on the team, and now is the time to start identifying who these people will be, negotiating their availability, and actually getting them going. You want to start building relationships with critical stakeholders, such as the people paying for the system, who might not be active participants.
You also need to setup your working environment. This includes obtaining a workspace for the team and getting them moved into it. Don't underestimate the importance of shared tools such as whiteboards on which to sketch and dedicated wall space to post important diagrams. Furthermore, it is critical to setup the technical environment, including test databases, integration machines, testing tools, development tools, and your configuration management environment.
Create Product Vision
The starting point for discussing the product requirements could be the Product Vision. The document describes critical functionality of the product, target audience, business and user needs. It is used to create alignment and shared understanding of the product for everyone involved in the development effort: stakeholders and production team.
The Product Vision will be used to break the product down to features, user stories or Product Backlog Items, depending on the Agile practices you are using.
Create Product Roadmap
After you have a shared vision of the product, break down the product to smaller requirements items (epics, user stories, features, etc.).
Identify the value and complexity for each item, prioritise them and build the roadmap for delivering the scope.
In Scrum you can hold the Release Planning session with breaking down top-priority stories, estimating the stories in the Product Backlog in story points, prioritising the stories, estimating the velocity of the team, and calculating the number of sprints and dates or releases to deliver the product scope.
A good practice for creating a roadmap of the product is the User Story Maps.
During Iteration Zero you will likely be required to do some initial requirements and architectural modelling for several reasons:
First, the prioritised stack of requirements that you implement during development iterations/cycles has to come from somewhere.Second, you need a basis for your initial cost and schedule estimates.Third, you need to have at least an initial consensus as to the architecture to build your project team. It's of little use staffing your team with Java experts if you're building the system using mainframe COBOL.
Initial requirements modelling effort needs to focus on the development of a high-level usage model, a slim domain model, and a user interface (UI) model. The process that you're following drives the choice of your usage model — an XP team creates user stories, whereas an Agile Unified Process (AUP) team writes point-form use cases.
The domain model should identify the main business entities (Customer and Account in a bank, for instance) and the relationships between them. During Iteration Zero, you don't need to identify either the data attributes or the behaviours of the entities — this level of detail will be identified on a just-in-time (JIT) model-storming basis during development cycles.
For the UI model, you may just need to draw a few whiteboard sketches of critical screens or you may need to do some UI prototyping, something you want to do after identifying the actual platform you'll be deploying to. The UI is the system to your stakeholders, and you need to convince them that you are able to understand their needs and deliver something usable that meets those needs. For complicated systems, a UI flow/navigation diagram may also be needed.
The goal of your initial architecture modelling effort is to try to identify an architecture that has a good chance of working. This is often done by the technical people on the team working together around a whiteboard, sketching and discussing what they believe will work. At this point, your goal is to come to a shared understanding of a reasonable architectural strategy, it is not to create mounds of documentation. As we identify the initial architecture, we'll try to ensure that it reflects the realities of the enterprise architecture, something that is much easier to accomplish when one or more enterprise architects roll up their sleeves and get actively involved with our project.
Start Stand Up Meetings
Start the stand up meetings in Iteration Zero to keep the team on the same page and reach the goals effectively.
After the Iteration Zero
After activities are finished, start normal iteration following the Agile methodology you are using. In Scrum it will be the Sprint that is started from Sprint Planning. During first Sprints pay attention to Backlog Grooming, Sprint Review and Sprint Retrospective events. They are the main tools for receiving and using feedback, adjusting the roadmap and release dates, tailoring the development process.
From a programming point of view the features delivered in an iteration zero may include:
Source control system installed and operational;
Initial build script written and checked into source control;
Initial promotion and deployment scripts written and checked into source control;
Automated test framework selected and implemented with an empty test suite;
Coding standards are agreed and shared;
A high-level application architecture is created;
Construction of a rudimentary continuous integration process.
One good method of validating the delivery of these activities is to wrapping them around a “Log In” feature. (If the application does not have log-in functionality then a simple “Hello World” screen will do.) “Logging in” can then be the first piece of functionality to pass a test in the unit test framework. It can be the first thing to be automatically compiled, run through the continuous integration process, checked into source control, promoted to the testing environment, and automatically deployed.
From a management point of view, iteration zero outputs may include:
Identification of and agreement upon a team customer, essential stakeholders and business users;
Agreement on the initial approach to the iterative planning process (for example, the time of the planning meetings and the length of iterations);
Product Vision is created and shared;
Initial Definition or Ready and Definition of Done checklists are agreed and shared;
Initial list of features identified, estimated, and prioritized;
Initial release plan that assigns each feature/story to an iteration/sprint is created;
Issue-tracking mechanism is set up;Wiki is set up.
An acceptance criteria for this actions can be the initial artifacts (Product Vision, working agreements) published to Wiki, and identified features added to issue-tracking system and organised.
The activities performed in an iteration zero are analogous to learning the letters and numbers of a foreign language. Before learning to read a foreign language we need to know how to pronounce the letters in that language. Similarly, before writing tests we need to have a unit test framework, and before prioritising and planning features we need to have a simple system to track and organise those features.
Finally, assigning this foundation-level activity to a single short iteration time boxes the work, which guards against gold-plating, analysis paralysis, and a host of other project villains.