Iteration 0

Iteration 0 refers to the work done before incremental development begins. This includes early product planning, getting the development team started up and setting up their physical and tooling environment, and making an initial architectural definition. All this work is preliminary and most of it is expected to evolve over time as the project proceeds.

Purpose

The purpose of Iteration 0 is to prepare the way for the successful launch and ultimately the completion of the product.

Inputs and preconditions

The only inputs are initial product and project concepts.

Outputs and postconditions

By the end of Iteration 0, initial plans are in place and all that they imply for the product vision, the product roadmap, the release plan, and the risk management plan. This means that there is an initial product backlog developed by the end of Iteration 0, at least enough that the next few iterations are scoped out. Iterations further out may be more loosely detailed but, as mentioned, their content will solidify as work progresses. Additionally, the team is selected and enabled with appropriate knowledge and skills to do the work, their physical environment is set up, and their tools and infrastructure are all in place. In short, the engineering team is ready to go to develop the first increment and plans are in place to provide a project trajectory.

How to do it

Iteration 0 is “the work that takes place before there is any work to do.” That is, it is the preparatory work to enable the team to deliver the product.

There are four primary areas of focus:

Focus	Work to be done	Outputs
Product	Create an initial vision, product plan, and release plan	Product vision Product roadmap Release plan Risk management plan Initial product backlog
Team	Ready the team with knowledge, skills, tools, and processes	Assembled team
Environment	Install, configure, and test tooling and workspaces	Team environment set up
Architecture	Define the initial high-level architecture with expectations of technology and design approaches	Architecture 0

Table 1.10: Four primary areas of focus

It is important not to try for high precision. Most traditional projects identify a final release date with a finalized budget but these are in error. It is better to plan by successive approximation. Realize that early on, the error in long-range forecasts is high because of things you do not know and because of things you know that will change. As the project progresses, you gain knowledge of the product and the team’s velocity, so precision increases over time. These initial plans get the project started with a strong direction but also with the expectations that those plans will evolve.

It is important to understand that you cannot do detailed planning in Iteration 0 because you don’t have a complete backlog, and you haven’t yet learned all the lessons the project has to teach you. That doesn’t mean that you shouldn’t do any planning; indeed, four of the outputs – the product vision, the product roadmap, the release plan, and the risk management plan – are all plans. However, they are all incorrect to some degree or another, and those plans will require significant and ongoing modification, enhancement, and evolution. This is reflected in the Law of Douglass #3 (https://www.bruce-douglass.com/geekosphere):

Plan to re-plan.

Law of Douglas #3

We discussed earlier in this chapter the product roadmap, release plan, and risk management plan. Their initial preparations are the key ingredients of Iteration 0. The workflow for Iteration 0 is shown in Figure 1.28:

Figure 1.28: Iteration 0

Create an initial product vision

The product vision is a high-concept document about the product scope and purpose and the design approach to meet that purpose. It combines the company’s business goals with the specific needs of the customer. It identifies how this product will differentiate itself from competing products and clarifies the value to both the company and the customers.

Create an initial product roadmap

The product roadmap is a strategic plan that defines how the product will evolve over time. See the Product roadmap recipe in this chapter for more detail.

Create an initial release plan

The release plan is a tactical plan for how features will be developed in the next several product iteration cycles. The Release plan recipe discusses this in more detail.

Create an initial risk management plan

The risk management plan is a strategic plan that identifies project risks and how and when they will be addressed by allocating spikes (experiments) during the iteration cycles. See the Managing risk recipe for information on this plan.

Select the team

The team is the set of people who will collaborate on the development of the product. This includes engineers of various disciplines (systems, software, electronics, and mechanical, typically), testers, configuration managers, integrators, a product manager, and a process lead, sometimes known as a scrum master. There may be specialized roles as well as a safety czar, reliability czar, security czar, biomedical engineer, or aerospace engineer, depending on the product.

Provide the team with domain knowledge

Unless the team has prior experience in the domain, it will probably be useful to expose the team to the customer domain concepts and concerns. This will enable them to make better choices.

Provide the team with skills and tools

Any new technology, such as the use of Java or SysML, should be preceded by training and/or mentoring. The introduction of new tools, such as Jira for project tracking or Cameo Systems Modeler for SysML modeling, should likewise involve training.

Provide the team with process knowledge

The team must understand the procedures and practices to be employed on the project to ensure good collaboration. The recipes in this book identify many such practices. The project may also employ a process that incorporates a set of practices, such as the Harmony aMBSE or OOSEM processes.

See Agile Systems Engineering by Bruce Powel Douglass, at https://www.amazon.com/Agile-Systems-Engineering-Bruce-Douglass/dp/0128021209 and https://www.incose.org/incose-member-resources/working-groups/transformational/object-oriented-se-method.

Install and configure tools

The tooling environment should be set up and ready for the team to use. This might include project enactment tools such as Jira in addition to modeling tools, compilers, editors, and so on.

Test tool installations

This step verifies that the tools are properly installed and the infrastructure for the tools works. This is especially important in collaborative environments such as team clouds.

Set up team workspaces

This action refers to the physical and virtual workspaces. It is common to co-locate teams where possible and this ensures that the teams have spaces where they can do individual “thought work,” as well as collaborative spaces where they can work together.

Identify architectural goals

Architecture, as we will see in the recipe Architecture 0, is the set of large-scale product organization and design optimization decisions. Goals for architecture are often focused on simplicity, understandability, testability, stability, extensibility, robustness, composability, safety, security, and performance. Frequently these properties are in conflict; something easy to understand may not be scalable, for example. Thus, the architectural goals identify the relative importance of the goals with respect to the success of the project and the product.

Define the initial high-level architecture

This action defines the high-level architecture, congruent with the architectural goals identified in the previous step. This is known as Architecture 0, the subject of the recipe Architecture 0.

Example

For the example problem outlined in Appendix A, the road map, release plan, risk management plan, and Architecture 0 are developed in other recipes in this chapter and need not be repeated here. The other aspects are discussed here.

Create an initial product roadmap

The initial product vision and roadmap are discussed in more detail in the Product roadmap recipe.

Create the initial release plan

The release plan is discussed in more detail in the Release plan recipe.

Create the initial risk management plan

The risk management plan is discussed in more detail in the Managing risk recipe.

Select the team

In our project, we select the systems, software, electronic, and mechanical engineers for the project. The team consists of three systems engineers, two mechanical engineers, three electronics engineers, and 10 software engineers. They will all be co-located on the fourth floor of the company’s building, except for Bruce who will be working from home and come in when necessary. Each will have an individual office and there are two conference rooms allocated to the team.

Provide the team with domain knowledge

To provide the team with domain understanding, we bring in SMEs to discuss how they train themselves and others. The SMEs include professional cyclists, personal trainers, amateur cyclists, and triathletes. Members of the focus group lead the team through some workouts on existing trainers to give them an understanding of what is involved in different kinds of training sessions. Some classwork sessions are provided as well to give the team members a basic understanding of the development and enactment of training plans, including periodization of training, tempo workouts versus polarized training, and so on.

Install and configure tools

In addition to standard office tools, several engineering tools are installed and configured for the project:

• Systems engineers will use DOORS for requirements, Cameo Systems Modeler for SysML, and Groovy for simulation along with the Teamwork Cloud for configuration management.
• Mechanical engineers will use AutoCAD for their mechanical designs.
• Electronic engineers will use SystemC for discrete simulation and Allegro Cadence for their designs.
• Software engineers will use Rhapsody for UML and code generation and Cygwin for C++, along with the Rhapsody Model Manager.
• The collaboration environment will use the Jazz framework with Rational Team Concert for project planning and enactment.

Test tool installations

The IT department verifies that all the tools are properly installed, and can load, modify, and save sample work products from each. Specific interchanges between DOORS, Cameo Systems Modeler, Rhapsody, and both the Cameo Teamwork Cloud and Rhapsody Model Manager can successfully store and retrieve models.

Provide the team with skills and tools

• System engineers will receive week-long training on Cameo Systems Modeler and SysML.
• Software engineers will receive week-long training on Rhapsody and UML.
• All engineers have used DOORS before and require no additional training.

Provide the team with process knowledge

The team will use the Harmony aMBSE process and attends a 3-day workshop on the process. In addition, A Priori Systems will provide agile and modeling mentoring for the team through at least the first four iterations.

Set up team workspaces

Systems engineers are provided with a configuration computer environment that includes installed Cameo Systems Modeler, DOORS, the company’s network, and Cameo Teamwork Cloud.

Software engineers are provided with a configured computer connected to the company’s network, and can connect to the local Jazz team server to access the Jazz tooling – Rhapsody, DOORS Next Generation, Rational Team Concert, and Rhapsody Model Manager.

Define initial high-level architecture

Both of these actions are discussed in more detail in the recipe Architecture 0.