The SystemAnatomyEnabling Agile Project Management

Contr ibut ions f rom:

Jack Järkv ik

Chr is ter Bengtsson

Andreas Borg

Er ik Blom

Pär Car lshamre

Helena Gäl lerdal Högfeldt

Inga-Li l l Holmqvist

Joakim Li l l iesköld

Er ik Lundh

Ulr ik Pet tersson

Joakim Pi lborg

Kr is t ian Sandahl

Er ik Schumann

Lars Taxén (Contr ibut ing Edi tor)

Foreword

Christer Bengtsson, Swedsoft

The success of Swedish industry is well documented with de facto global brands and market shares that are disproportionate to the relative size and resources of this small nation. What is often not well documented are the innovations and individuals that the successes may hinge on.

Being able to handle ever-growing complexity, while ensuring proper functionality and reliability, is a challenge in itself. Developing these systems in a global competitive market, where time-to-market and cost of development are of ultimate importance, and development failure is not an option, adds further magnitude to the challenges. New processes and tools to support development are needed.

The system anatomy approach described in this book has been tested for over a decade mainly by – but not only by – the telecom industry, developing some of the largest, most complex and demanding systems known to man.

Introducing this way of seeing a large system is one of the innovative means spawned by engineers in Swedish industry. Perhaps it is here, in novel ways of seeing the challenge that real innovation lies. Concepts like anatomy, the inner picture, and complexity maximum are signs of an openness to trying other angles and of an underlying, deeper understanding of engineering work and its challenges.

When large systems of today and the future may comprise hundreds of millions points-of-failure, it is clear that the system anatomy images may be worth magnitudes more than the proverbial thousand words!

2

Introduction

Lars Taxén, Linköping University

The situation is all too well-known: the number of spectacular development failures in, for example, large software projects remains at an alarmingly high level. In spite of frantic ongoing efforts to come up with new methods and tools to support such tasks, there seems to be no radical improvement in sight. While the complexity of systems increases at an ever-accelerating pace, our innate human cognitive capabilities for managing such development tasks remain the same as they were in historical times.

This book takes an alternative route to the development of complex systems. Technology, methods, and tools are still important, but human-centric aspects like common understanding, coordination, visualization, and reduction of complexity, are here brought to the forefront.

The core of the alternative approach is the system anatomy, a means that was conceived in the early 1990s by Jack Järkvik, one of the contributors to this book. The system anatomy is a simple but powerful image showing the dependencies among capabilities in a system, from the most basic to the “money-making” ones, thereby representing a novel way of describing what a system is. This out-of-the-ordinary image has since then been used extensively in various forms at Ericsson for managing extremely complex system development tasks.

When an innovation such as the system anatomy sees the light of the day, it soon becomes evident whether or not that innovation is feasible; otherwise, it will disappear silently into the darkness of history. The anatomy concept has certainly turned out to be extremely viable. Moreover, it is quite likely that the potential of the anatomy-based approach is not nearly fully exhausted, either in practical applications, or as an object of research.

The time has come to make the system anatomy innovation known to a wider audience. Therefore, the purpose of this book is to provide a snapshot of where the anatomy-based approach to system development stands today, by looking backwards at the first attempts to use the anatomy, by examining current usage of the concept, and by contemplating what might lie ahead.

The Chapters

The book is a collection of chapters from authors who have all worked, in one way or another, with the anatomy concept. The intended audience

3

includes both practitioners facing complex development tasks and researchers who are interested in exploring new perspectives and theoretical frameworks for managing complexity in areas such as information system development, organizational sciences, project management, and more.

As with any powerful concept, the anatomy concept has been interpreted over time in different ways in different places. When a concept has “stuck” in a particular context, it is extremely difficult to reconcile different interpretations into a common understanding that all concerned can agree on. This has made it necessary to organize the book as follows.

In Chapter 1,“Why Do We Need an Anatomy?”, Joakim Lilliesköld gives the historical background of large-scale projects and how these have been managed since the 1950s. In this way the reader gets an overview of the challenges that exist. Three different approaches to handling large complex projects are described: the “traditional”, the “super project manager”, and “self-organizing teams”. The chapter concludes with an account of what is needed in order to manage complex system development projects.

Chapter 2, “What is a System Anatomy?”, by Lars Taxén and Jack Järkvik provides a characterization of the system anatomy through a number of statements describing its necessary properties. In other words, Lars and Jack are not trying to give a detailed definition of the system anatomy, since this has turned out to be difficult. Rather, they want to delimit the range of possible interpretations of the anatomy concept in such a way that the concept makes a meaningful and unique contribution to already-existing modeling approaches to systems development.

This chapter also provides a point of reference to which all of the other contributions relate. The authors have been given full freedom to write their own chapters in any way they like. However, whether they are using particular variants of the anatomy concept, or perhaps just a different denotation, the authors are required to make clear how their use of the anatomy concept differs from the reference description found in this chapter. In this way, the reference anatomy description provides a common thread throughout the book.

Chapter 3, “The Origin of the Anatomy”, is written by Jack Järkvik, the “father” of the anatomy concept. He describes how the anatomy concept was born in the 1990s when Ericsson was in the middle of the transition from the 1st to the 2nd generation of mobile systems. Jack was called in to take over a project in trouble that was developing a radio base station for the new GSM standard. At that time, this was by far the most complex system ever developed by Ericsson. The idea Jack brought to the project was simply to ask system engineers to describe the different capabilities the new base station would have and, in addition, to show how these capabilities could be tested/changed/corrected independently of one another. This first attempt was subsequently elaborated into the anatomy-based approach to system development.

With this we leave the historical scene, and move into a rich landscape of various usages of the the anatomy concept today. In Chapter 4, “The Inner Picture”, Joakim Pilborg describes how anatomies can be used to achieve a

4

growth of common knowledge in projects, resulting in more efficient product development. Joakim sees this as a journey from an individual inner picture carried by a few people, via something called the Complexity Maximum of the project, to a product ready for the market. The end result – the product – can be seen as the common picture shared by the people involved in its development.

Chapter 5, “Anatomies for Project Management – the Project Anatomy”, written by Erik Blom, introduces the project anatomy as a complement to the system anatomy for effective visualization of progress in the project. The project anatomy can be used for re-planning, progress reporting, risk management, and even as a means to steer the project in a desired direction by motivating teams to commit to the objectives. Erik also emphasizes the importance of having access to a flexible tool supporting the definition and maintenance of the project anatomy itself; otherwise, redrawing an anatomy during a project can easily become a burden.

Chapter 6, “An Agile Guide to Anatomy Planning”, by Erik Lundh, is the first in a group of chapters that link the anatomy concept to agile development. Erik provides guidance for the agile community in adopting anatomy-based planning. Agile planning can be very successful on the team level. However, planning with multiple teams, multisite development, and building large systems with many contributors is not currently well understood by the agile community at large. Approaches in the agile literature to doing multi-team agile release planning are simply not good enough. On the other hand, it has been observed that even seasoned agile teams can benefit from creating an anatomy as a first step in a new development increment. Anatomy-based planning fills a gap for both a single agile team and the larger development organizations who want to go agile.

Chapter 7, “Working with Anatomies in an Agile Environment” is written by Inga-Lill Holmqvist and Helena Gällerdal Högfeldt. The agile way of working encourages teams to work more independently and to plan more individually. This requires that dependencies between teams and products are known and visible. In this chapter, Inga-Lill and Helena describe how, in such a context, anatomies can be enablers for managing dependencies. They show how a variant of the anatomy, called the program anatomy, can be utilized for planning and re-planning in an agile environment.

In Chapter 8, “Developing Large Systems in Small Steps”, Ulrik Pettersson outlines an integration-driven development approach that combines plan-driven, incremental development with agile methods for large-scale systems. The planning, which is based on a visualization of dependencies between needed system changes – the so called ∆ anatomy – is an ongoing process that results in regular releases at predetermined intervals. These system changes are implemented and tested by teams using whatever agile techniques they prefer. The main point is that if many agile teams work simultaneously in the same system, it is necessary to spend some time on determining how to coordinate these teams.

5

In the following chapter, Chapter 9, Erik Schumann describes “How Teams Become More Motivated and Effective When Working with Anatomies”. The way teams work in software and systems development projects has changed drastically during the last ten years, from rigid control to an agile and team-centric paradigm. What happens in development teams when you give them the authority to make their own decisions according to a previously agreed-upon schedule? How is it that the planning games and anatomy workshops often bristle with energy and creativity? Why do people working in autonomous development teams in fact work more effectively? In his chapter, Erik discusses these and other issues related to teams and anatomies.

The purpose of Chapter 10, “Executive Guide to Anatomy-Based Planning” by Erik Lundh, is to provide a management view on anatomy-based planning to managers and executives who need to be convinced in order to lend their approval and support. Therefore, the text argues from the perspective of someone who runs a department or business, rather than from someone who works in development. To deliver on the “Convince Your Boss”-promise, this is a relatively short chapter, intended for busy decision makers.

The book concludes with three chapters that go beyond the core of the anatomy-based approach. In Chapter 11, “Anatomies in Requirements, Processes and Research”, Kristian Sandahl, Andreas Borg, and Pär Carlshamre extend the usage of anatomies to other capabilities of importance for system development. They propose anatomies as a natural way of supporting humans in solving so-called wicked problems in many phases of systems development. A wicked problem has no perfect solution, is based on incomplete information, and requires human expertise and trial-and-error to find a proficient solution. This use of anatomies is illustrated by examples from industry and academia in the areas of requirements release planning, non-functional requirements, and process improvements.

Chapter 12, “Why is the System Anatomy Useful in System Development?”, by Lars Taxén and Joakim Lilliesköld, is an attempt to understand why the images in the anatomy-based approach are so effective for managing complex projects. To this end, Lars and Joakim use a particular theoretical perspective, called Activity Domain Theory, for investigating both traditional images used in project management (such as Gantt, WBS, PERT, and CPM), and the anatomy-related images. They find that anatomy images emphasize common understanding and comprehensibility over the formalism and rigor of traditional images. Moreover, the anatomy images seem to be resonant with our cognitive faculties for coordinating actions, which would indicate that they are more apt for managing complex development tasks than are the traditional ones.

With the last chapter, the circle is, in a way, closed. In Chapter 13, “Where Do Ideas Come From?”, Erik Lundh gives an account of conversations he had with Jack Järkvik, the originator of the anatomy concept. In these conversations, Erik and Jack try to locate the roots of the thinking that eventually led to the breakthrough of the anatomy-based approach in system development. Which were the major events in the Jack’s

6

personal background that molded his thinking on the way to the anatomy concept? How is it that some experiences are more formative for innovative ideas than others? What does it take to transform such ideas into something that is powerful enough to make a difference in practice? These and other questions are certainly of prime importance for anyone interested in the historical evolution of ideas.

With this, I cordially invite you to an exciting exploration of the hitherto unknown territory of anatomies in system development. I wish you happy reading!

Lars Taxén

7

Why Do We Need an Anatomy?

Joakim Lilliesköld, Royal Institute of Technology (KTH)

The management of projects is probably among the most important economic and industrial activities in modern society. Projects are used to create, shape, and change the structure of society and the activities of many organizations. The scope of this chapter covers the projects of developing complex products and systems. Such development projects play a significant role in maintaining competitiveness in most industries today.

The dominant approach to managing complex development projects originated in the fields of civil engineering and, later, in the defense industry. The approach was developed during the 1950s and the 1960s by practitioners, but it wasn’t until management researchers became interested in the area of project management in the 1970s that methods were rigorously developed. The idea behind the original approach was to establish a consistent method of meeting the new demands of delivering a large amount of goods and services in a short period of time.

Throughout the years, numerous methods and techniques have been developed, covering various aspects of managing projects from initiation to completion. Despite the enormous attention project management has received during this period, the track record of projects is fundamentally poor, particularly for the larger and more difficult ones. Studies of project failure, such as the CHAOS-report by the Standish Group, have indicated that a project’s early phases do not get enough attention, meaning that companies have been unable to make satisfactory requirement specifications, rigorous plans, and/or adequate system designs before the execution of the project is initiated.

Despite the intensified focus on engineering and planning requirements through the years, performance has failed to meet expectations. The larger and more complex the product development task is, the poorer the performance seems to be. Even in the best managed companies, initial targets concerning time, costs, and performance are often not achieved – in fact, only on rare occasions is even a single one of the initially-set targets met.

Today’s most powerful customers not only expect that initial targets are met, but also that the targets that emerge during the development process are achieved. This complicates the process of managing complex product development, making it a successively more difficult challenge. Some typical challenges companies face are listed below.

8

• Many companies have, in the past, been in control of the pace at which new products are released onto the market. Today, the market in many industries sets the pace for product development.

• The globalization of markets has led to more competitors and an increased need to excel in order to survive. One way to compete is to shorten development time, i.e., the time to market.

• Standardization of products and components. Many system solutions of today are built upon standard components (COTS) instead of components specially developed for the system at hand. On the other end, customers expect system solutions from different manufacturers to integrate smoothly with one another.

• The globalization of markets (meaning more competitors) and standardization has reduced time to market and the profit margins for complex products. It was not uncommon ten to fifteen years ago that development efforts had large budgets. Overruns were not considered a problem since the profit on a product, once it was out on the market, was very high.

• Adding to the reduced profit margin, many products suffer from shorter life cycles than in the past, implying that not only do companies earn less per sold product, they are also not able to sell the product for as long a period of time as they were used to in the past.

• Customer demands and requirement specifications change constantly. The rapid development of technology has created a situation where customers expect products to be state-of-the-art when released onto the market after years of development. They also expect not having to specify all requirements at the beginning of a development process.

• In order for development efforts to be more dynamic, working groups need to work together as teams, making the management of projects even more challenging. However, working as a team is further challenged by the fact that projects are spatially distributed, and most consist of several different organizations with different professional disciplines from different countries.

In this environment, project managers in system development companies invent or try different methods to improve the results of projects. Most system development efforts, however, do not need more descriptions of what is to be developed, but better descriptions. However, even if it were possible to achieve better requirement specifications initially, the changes that will come into play during a project may alter them.

Managing Mega-Projects Projects are unique by definition and are, of course, managed and coordinated differently. One way of classifying different approaches to managing projects is based on Marmgren and Ragnarsson (2001), who define three hypothetical approaches: Weber, Rambo, and Gaia. A similar

9

classification can also be found in a thesis by Adler (1999), based on similar material.

Type 1 – The Traditional Approach

In short, the basic idea with the traditional approach of managing projects is that complex projects can be managed and controlled by breaking down a task into smaller and smaller pieces and planning each one rigorously. It is based on the assumption that the more detailed the planning, the more control it provides. This approach is found in most project management literature and is the preferred approach to running projects. In complex and perpetually changing projects like many of today’s mega-projects, however, this approach often becomes insufficient. These projects might last for a few years and they should be state-of-the-art when delivered; this makes it basically impossible to create a rigorous plan during the start-up phase, because of rapidly evolving technological developments.

Type 2 – The Super Project Manager Approach

The super project manager approach is fundamentally different from the traditional approach. It is based on the insight that advanced rigorous planning and project optimization only provides an illusion of being in control of complex system development projects. The traditional approach does not support the actual work or provide any reduction of complexity or ambiguity in the project. Instead, more focus is put on dynamics and the acquisition of new knowledge created in the project.

The basic idea behind this approach is to have the development and design work driven by integration and verification so that it can be delivered on time. This means that the actors are encouraged to focus on the most troublesome boundaries from the beginning in order to avoid surprises in later phases of the project. In order to achieve this, two issues need to be addressed: “What should be delivered to the customer?” (a simplified system architecture) and “How should the parts be integrated into a system that can be used by the customer at the end?” (an integration plan). The approach is thus based on the processes of product build-up and of integration and verification. In order to begin all parts of the project early, all entry criteria are heavily downplayed in contrast to development methods following corporate stage-gate models.

The super project manager approach presumes that everyone involved consider the project and the system as whole, and focus not only on his or her own sub-part of the project. However, problem solving and coordinating the interfaces among subprojects, and between the project and its surroundings, are managed solely by a small team surrounding the project manager. Therefore, if one or a few of these persons disappear from the project, it can cause serious problems.

10

Type 3 – Self-Organizing Teams

The last approach, self-organized teams, is the least common. It has several similarities with the super project manager approach. The main difference is that the project groups organize and coordinate themselves instead of being dependent on the small team around the project manager. The organization or the groups are viewed as a system. In this case, not just a few have knowledge of the project and the system as a whole, but a larger group. Changes that occur throughout the project can be coordinated at the proper level since more people have knowledge and input about the project. In order for this approach to work, the project has to be managed through easily-understood pictures of the goal and the resulting system in order to create a common understanding of the project.

None of the approaches described are sufficient in all cases, but neither

are they useless. One major difference between the traditional approach and the two other approaches is that the super project manager and self-organized teams are based on the actual needs of the design process and are not derived from managerial needs, such as decision support. This means that these approaches mirror actual work processes and therefore become an integrated part and a shared map of the actual development work and its progress. The traditional approach is useful when leading large projects where the prerequisites for or the circumstances surrounding the project do not change or fluctuate. If changes occur, the traditional approach creates a substantial additional amount of added work due to re-planning. This is often described in the literature as the main problem with traditional tools like network plans; they become unmanageable when there are many changes. The super project manager works adequately when management has the knowledge, skills, and capacities that are required for this approach.

All challenges make the traditional approach inadequate when developing complex systems or products. However, most literature, courses, and project management certification systems focus on the type 1 kind of projects. Therefore, there is a gap between the support provided to project managers and the reality they face. As a result, if they want to be successful, they are forced to find new ways to address the needs they are facing. This book describes one approach used in successful type 2 and type 3 kind of projects.

What Are the Needs of Complex System Development Projects? Studying successful development projects of complex systems, we found several crucial aspects that need to be addressed by the project management team. These include the following:

11

• an understanding of the customer and the customer’s needs; • thought-through ideas in terms of products that can be delivered and

demonstrated to customers early; • neutral and easy tools to improve communication between the different

actors involved in system development; • an additional project support group, in addition to the normally-used

steering committee, that can make rapid decisions when necessary; • an engineering process that can adapt to changing requirements; • implementation of a push-and-pull concept, where responsibilities

become clear and where there is a receiver for every internal delivery from the beginning of the project to the final system solution;

• a common understanding of project goals; and • a means by which the actions of the actors involved can be coordinated,

while still allowing them to employ the tools and methods they normally use.

Briefly, it can be said that over the years technology has changed tremendously. The speed of our processors has developed exponentially, and the capacity of communication technology has undergone a similar rapid development. However, our ability to cope with the complexities that these technological developments raise has not increased at the same pace. Thus, there is a gap between the possibilities that technology offers us and our capability for taking advantage of this development.

In studies of successful system development projects, the use of holistic models and tools capturing the dependencies between different parts of the system seems to be a common success factor. In other words, to get an overview of a project and make sense of how all the pieces fit together is intricate and complicated. Vital interdependencies may be lost in myriads of details.

However, such models have not been included in project management manuals at these companies. In the manuals and literature, methods developed many years ago, before the boost of complexity, are still central in coordinating and communicating actions. The approach focuses on a work breakdown structure and all parts of the system are described in detail. The most common set of tools are WBS (Work Breakdown Structure), Gantt charts, PERT (Program Evaluation and Review Technique), and the CPM (Critical Path Method). These tools are still useful, but it is also reported that they can become almost unmanageable in projects facing a lot of changes.

In complex development projects, alternative tools have emerged via practice. These are referred to as anatomies (Söderlund, 1998; Adler 1999; Lilliesköld et al., 2005; Lilliesköld & Taxén, 2006), dependency diagrams (Ericsson et al., 2002), release matrices (Taborda, 2004), information flow diagrams (Taxén & Svensson, 2005), and the like. These alternative tools, and the fact that project manager’s actions often differ from what is said in the literature and project models, demonstrates that there is a deficiency and a need for something more. In this book, you can read about one approach which addresses many of the challenges mentioned above.

12

The anatomy concept has proven to be a very useful tool under these circumstances. It has been in practice for more than fifteen years. It has been tested in different companies and in different sized projects, and has proven itself useful. It is, as discussed in this book, not a new way to describe things, but rather compels project stakeholders to see the project in a different light. You could say that it makes developers think more in terms of products and product development, thereby also making it easier to include the customer in the development process. As you will learn from this book, we need tools like the anatomy concept in our development efforts if we want to survive in the competitive climate of modern business. Some people call this being Agile.

References Adler, N. (1999). Managing Complex Product Development – Three

Approaches. EFI, Stockholm School of Economics. Eriksson, M., Lilliesköld, J., Jonsson, N., & Novosel, D. (2002). How to

Manage Complex, Multinational R&D Projects Successfully. Engineering Management Journal, 14(2), 53-60.

Lilliesköld, J., Taxén, L., Karlsson, M., & Klasson, M. (2005). Managing Complex Development Projects – Using the System Anatomy. In: Portland International Conference on Management of Technology and Engineering. PICMET ’05, July 31 - Aug 4, 2005.

Lilliesköld, J., & Taxén L. (2006). Operationalizing Coordination of Mega-projects – a Workpractice Perspective. In: IRNOP VII Project Research Conference, October 11-13, Xi’an, China.

Marmgren, L., & Ragnarsson, M. (2001). Organisering av project. Stockholm. Sweden: Fakta Info Direkt (in Swedish).

Söderlund, J. (2000). Time-limited and Complex Interaction – Studies of Industrial Projects. PhD thesis. IMIE, Linköping University.

Taborda, L. (2004). Generalized Release Planning for Product Line Architectures. In Proceedings of the 3rd Software Product Line Conference: SPLC 2004 (pp. 238-254). Boston, Massachusetts, August 30-September 2.

Taxén, L. & Svensson, D. (2005). Towards an Alternative Foundation for Managing Product Life-Cycles in Turbulent Environments. International Journal of Product Development (IJPD), 2(1 / 2), 24–46.

13

What Is a System Anatomy?

Lars Taxén, Linköping University

Jack Järkvik, Cajack Management AB

The purpose of this chapter is to characterize the system anatomy by a number of statements that describe necessary properties of this concept. In other words, we are not trying to give a detailed definition of the system anatomy, since this has turned out to be difficult. Rather, we want to delimit the range of possible interpretations of the system anatomy in such a way that the concept makes a meaningful and unique contribution to already-existing modeling approaches to systems development.

A system anatomy is, as the name suggests, a description of a system. The anatomy is characterized by at least the following properties:

• Purpose: The purpose of the system anatomy is to provide a common understanding among system experts about the system. In development tasks, the anatomy is a means for communicating about the project, and it provides a basis for making decisions.

• Motivation: A common understanding of the system is necessary for coordinating development activities. The system anatomy is simple enough to achieve such an understanding, yet it is powerful enough to show the most important factor when dealing with complex projects – how things depend on each other.

• Gains: When using the system anatomy as a basis for project planning and follow-up, the risk of a delayed or failed outcome of the project is reduced.

• System model: The system anatomy is a model of a finalized system. It describes how we conceive of the system when it has been developed. “System” should be understood in a wide sense to include products, processes, organizations, organisms, or any other arrangement of interest where parts, including humans, interact to form a whole.

• Visual: The system anatomy is an image of related things drawn on a single page. Thus, the anatomy is basically visual in character, although text can be used to enhance comprehensibility.

• Capabilities: The things shown in the system anatomy are capabilities in the system. Sometimes these capabilities are referred to as anatoms to emphasize the anatomy perspective. The part, module, or any other object implementing a capability is not shown in the anatomy.

14

• Dependencies: There is an inherent order in the system anatomy, signified by the relative vertical positions of the anatoms in the image. The most fundamental capabilities are placed at the bottom of the image. At the top, those capabilities offered to the users of the system (the “money-making” ones) are shown. Thus, the anatomy illustrates dependencies (and independencies) among capabilities. The dependencies are shown as lines (sometimes arrows) indicating the presence or absence of a dependency, but nothing more. The capabilities can be grouped roughly into start-up capabilities (how can the system be started), configuration capabilities (distribution of resources), supervision and error handling (discovering errors and taking proper actions when these occur), and services offered to the users of the system.

• Static: The system anatomy is at any moment a static image; it shows only related things. There is no indication of time in the anatomy, of things changing as time passes. However, during system development the anatomy may evolve due to changed requirements, knowledge gained during development, or any other reason. It is quite natural that the would-be system changes, since the usual procedure is to build a version of the system, let the users of the system evaluate it, build another version, evaluate this in turn, and proceed in this manner. In this way, the most useful services can be retained, while less valuable ones can be “amputated”. As a consequence, the users of the system will gradually understand what they will receive.

• Social: The system anatomy is developed by people involved in a development task. This means that the anatomy is a social accomplishment. Thus, given the task of describing a system, two separate groups of people will arrive at different anatomies of the same system (in a particular project, of course, only one anatomy is used). Consequently, the anatomy is not meant to be an exact, formal description of the system. Rather, it is an instrument for achieving common understanding about the essential capabilities in the system and how these depend on each other.

• Delta: In a system development task, the system anatomy shows capabilities that are to be developed. These can be conceived of as deltas, capabilities that are to be added to an already existing system. When the task is ready, the anatomy shows the capabilities in the finished system. It is important to make sure that the final system anatomy really corresponds to the developed system, since this anatomy may be used as a basis for subsequent developments of the system.

In Figure 2.1, an example of a system anatomy is given:

15

Power regulation Busy channel supervision

HW malf . log

LocatingTime alignment

BS detectors, measurement administration

TRAB MS-MS

SACCH, FACCH TRAB speech path

Mobile access

EMRPS Start

Output power settingBlocking

TX on

SupervisionIPCH activation

Change of BCCH Set f requency

SCCHPCH activeTRAB synch

Deblock IPCH

Deblock TRX

Deblock TIM, CTC, RFTL

External alarms

Deblock CPHC

Conf ig LCH

C-link comm.

Adm LCHLoad TIM, RFTL

Deblock ALM

Load CTC, TRX

Conf ig Site RCG, CEOTRAB Control

Ring-back tone

Load ALM

Figure 2.1: A system anatomy for a radio base station

Each box (the details of which are less important here) should be read as a capability provided by one or several modules (subdued in the figure). The dependencies (lines) proceed from the bottom to the top of the anatomy. For example, the capability “EMRPS Start” is a fundamental capability. If this capability fails, the whole system will fail. In line with this, the gist of the anatomy-centric approach is to test the system in the same order as the capabilities are invoked. In a metaphorical sense, this can be seen as the order in which the system “comes alive”; hence the term anatomy.

The particular form of a system anatomy is deliberately chosen to convey a feeling of “struggle”; of “climbing up” from the bottom to the top. It is an endeavor to reach the “top”, and one might make a mistake and “fall down”. Thus, the anatomy is more than just a description of the system; it is also meant to convey a sense of humbleness concerning the efforts and obstacles that the project participants will encounter.

16

The origin of the anatomy

Jack Järkvik, Cajack Management AB

In the spring of 1990 Ericsson was discovering that the project developing their radio base station for the new GSM standard was in trouble. The plan was to launch the GSM system July 1, 1991. The first customer was in Germany. The first network would contain 149 radio base stations in ten cities in Germany.

The name of the radio base station project was Rzero. I was asked to take on the task of saving the project. I accepted although I knew little about the challenges. I quickly understood that in the area of radio base stations this one was by far the most complex one ever developed by Ericsson.

I have always thought that a development plan has to be based on a thorough understanding of the product/system to be developed. We gathered a small team of very good system engineers to work out an intelligent view of what was left to do and how to do it, what we normally call a logical plan.

I asked them to describe to me what different capabilities the new base station would have. I asked them to describe which of them could be tested/changed/corrected independently of one another. I asked them what order would be useful to follow when testing/correcting the different capabilities. In only a few days these brilliant engineers came up with what became the logical integration plan. I could not contribute much since I did not understand mobile telephony and even less the GSM standard.

It has to be said that we never made a system anatomy in this project. We only made a plan. But this top level plan contained capabilities of the finished base station, not modules or work packages or anything in the normal project domain. The plan contained all the parts of a true system anatomy. We just never called it an anatomy.

I called this way of running system integration "ORGANIC INTEGRATION".

The plan as such had two parts, one logical plan and one time plan. The top level plan showed only integration, which is not only testing. By integration we meant testing each capability on the system level and correcting all the faults we found. Integration meant deciding what to test and how to test; deciding which "faults" to correct and how to correct them plus of course checking that the result of correcting was acceptable. The integration plan was what we would now call “an anatomy based integration plan”, implemented in many projects thereafter.

17

I think it is important to stress that in many projects, before and after, integration has meant something quite different.

In this project the anatomy based integration plan had little effect on system design or implementation planning, since the anatomy based integration plan was introduced very late. The existing development plans were just adapted to the new integration plan. However this proves that introducing anatomy based integration and thereby project planning can help also if it is done late.

It can be said that the introduction of the anatomy based integration plan had a profound impact on the project. Other new ways of working were introduced in this project together with anatomy based integration. The important ones were LAGOMISING and the SYSTEMAKUT. Without these we are sure the project would not have delivered a well working radio base station on time. LAGOMISING and SYSTEMAKUT will not be described here.1

However the anatomy based planning was the foundation. Given the lack of time, the quality of the delivered system must be said to have been surprisingly good.

The second implementation of anatomy based integration and project planning was a Japan project which was started at the end of 1991. The contract promised a complete mobile system based on a new telecom standard to be delivered to Tokyo two years after signing the order. This was tight!

Based on the success of the first GSM radio base station project it was decided early to base the entire project on ORGANIC INTEGRATION. An expression often used these days was “Integration driven development”! Integration driven development does not have to be the same as organic integration. It is the same only if the integration plan is based on a system anatomy.

I was engaged to help with the radio base station project, which was considered to be the greatest challenge. The other parts of the system would reuse significant parts of existing systems.

In this project I suggested drawing what I called an anatomy, being not a plan but a description of the radio base station with all its capabilities and their relationships. We used a rather large group of people who understood the future product to draw the anatomy.

After many iterations we agreed on the system anatomy to use. Thereafter we started integration planning based on the system anatomy. Our integration planning was not about testing modules working together but about testing base station capabilities.

During the many iterations of the integration plan the system anatomy stayed the same. This is one of the advantages of having a system anatomy. When the future product is changing, this will probably show up in changes in the system anatomy. However, when the timing of activities changes, only the integration plan will be affected; never the system anatomy. Issues about the availability of people will change the integration plan but not the 1 A description of these concepts can be found in Berggren, Järkvik & Söderlund (2008).

18

system anatomy. The system anatomy shows the future product, not how we set up and run the project.

The integration plan of the base station was then interlinked with the integration plan of the entire mobile system plan.

The Japan project delivered to customer in a timely manner in spite of the tight schedule. Product quality was good, without doubt the best new system ever delivered by Ericsson. The system started commercial operation as planned and with very few problems noticeable by subscribers.

The Japan project was not a success only because anatomy based planning was used. It was a success because of a dedicated and hard working very skilled team but we all think that the anatomy based planning was of great help. LAGOMISING and SYSTEMAKUT were used also in this project.

These were the two first projects where the ANATOMY and ORGANIC INTEGRATION were successfully used. The methods were accepted by top management, not because they had proven their value in many projects, but because in the cases described above conventional methods were considered not good enough. Top management believed in me, and the teams I got the opportunity to work with believed this might work. Together we made it work!

It is worth noting that when attempting such huge changes in ways of working you run into lots of people who do not like changes or who do not believe the new ways of working will work well. These are mostly managers on different levels. Implementing projects based on anatomy thinking and organic integration changes and threatens existing/conventional responsibility areas.

The way the system anatomy and organic integration were implemented as a basis for project management was not characterized by compromises. With all the opposition we met we had to drive the needed changes hard. I am convinced that we would have failed if we had compromised any more than we did (which was not at all). This was possible only because we had very strong support from top management.

References Berggren, C., Järkvik, J., & Söderlund, J. (2008). Lagomizing, organic

integration, and systems emergency wards: Innovative practices in managing complex systems development projects. Project Management Journal, Supplement, 39, 111-122.

19

The Inner Picture

Joakim Pilborg, Know IT Technology Management AB

This part of the book is about how Anatomies can be used to achieve a growth of common knowledge in projects so that more people have a better understanding of the whole product and how their own part of development fits into the big picture.

Successful product development is, however, dependent on many things. Besides competent and motivated personnel, a way of working is needed that is supported by different forums where the members of the project can meet and work together. The results of their work must be documented in artefacts that are thought to be intuitive and meaningful. This is simply a question of creating a framework for project work that in an efficient way supports the work all the way from idea to a product that is ready for the market.

To develop a new product or enhance an existing product can be described as a journey from an individual inner picture carried by a few people, via the Complexity Maximum of the project, to the product ready for the market. The product that is ready can also be seen as the common picture of the results shared by the people involved in the development of the product. The Anatomy has been shown to stimulate this journey. It is not the Anatomy-picture itself that is most important for success. Instead, it is the work that is done by groups of people in different forums to create and maintain the Anatomy.

Working actively with Anatomies in projects creates the growth of common knowledge needed to be able to develop complex products in large projects with few errors. This is even more important when developing products in an agile way.

Visualizing and Monitoring of Projects In every project there are people in many different roles in the organization that need to understand the status of the project, realize what the risks are, and know how much work remains to be done. In addition to the sponsor of the project, this can be not only, e.g., the main project leader, a product manager, or a product owner, but also line managers who have personnel in the project. In traditional project management models like, e.g., PROPS and

20

PPS, the number of artefacts and their status are measured at different milestones and gates in the project. Is it really possible to see the status of the project by only studying the documents and models available at a certain milestone or gate? − “It is not possible to know the status of a project by only looking at the

available artefacts.” − ”But, the artefacts are the results of the work that has been performed.

Without the artefacts there is nothing.” − “Yes, there is. The growth in knowledge among the project members.” − “But what is that knowledge?” − “A picture of how the results will evolve in the project.”

The dialogue above took place in a seminar on May 16, 1997 in the area of project management in one of the companies within the SAAB Group (as described in Hoberg, 1998), but similar discussions are heard everywhere, regardless of domain or company.

Why do most companies choose to measure only the status of artefacts, and what are they missing by doing that? Through the years there have been discussions regarding whether the development of software can be seen as an industrial process or not. There is even a name for it. It is called the Software Factory. If you have a Software Factory approach to software development, it is natural to measure only the visible input to, and the visible output from, the Software Factory. But these visible results do not tell the whole truth about the status of a project. Something more is needed.

If we look at the dialogue above again, it talks about knowledge as a picture of the expected results of the project. There are no methods for measuring the individual inner pictures of what will be the results of the project except by organizing forums where people meet and are “forced” to create commonly accepted pictures, where the status and risks of the project become obvious. In the work of creating common pictures, it becomes very clear whether there is a common view on what to develop and whether the members of the project have the necessary knowledge to develop the product.

To stimulate the work with common pictures one can, besides using Anatomies, actively work with project kick-offs that focus on visual planning, requirement kick-offs with a focus on identifying what requirements or requirement areas that affect the architecture the most, and also visual integration planning.

It is not possible to execute these workshops and obtain results that the workshop participants accept and support if there is no common view on what is to be developed in the project. During workshops like these, in the early phases of a project, it soon becomes obvious whether the common view is common enough or not. It also becomes very clear who knows what he/she is talking about and who doesn’t. This is a very good indicator of how far the project actually has come and where the biggest risks are to be found. To be able to really monitor the progress of a project, visualization of different areas, like, e.g., the Anatomy of the product, is needed.

21

Is It Possible to Pass On a Picture? In the previous chapter we discussed work with pictures such as Anatomies. In this chapter we will describe what happens when individual people or small groups of people within the project develop pictures that are passed on to other people who are supposed to use these pictures as input to their own work. This is the traditional way of working in large companies.

There are two types of pictures. First, we have the individual inner pictures (the pictures that each individual has in his/her head of what the results will be) and, secondly, the explicit pictures (such as, e.g., different pictures of the architecture, Anatomies, and possible time-plans to be printed out) that are developed by the project. It is important to realize that the individual inner pictures are different for each person in the project. As the project work continues and the explicit pictures evolve, the individual inner pictures of the project members also become clearer, more detailed, and closer to unanimous.

The reason why the individual inner pictures differ among project members is that the individual inner picture is based on the knowledge and experiences of each individual. When people create explicit pictures of existing products, or of products to be developed, they often do it on a high level of abstraction in order to make a thought more concrete or to communicate an idea without having to deal with all the details. The real world is always more detailed than the explicit pictures we create – the goal for the explicit picture is not to describe exactly a future reality (or product); instead, it is used to make sure that the individual inner pictures of the people involved in the work slowly converge.

The best thing about the work on the common (explicit) pictures is that they themselves are a forum for discussion, and that they form a stable base from which the project can continue its work. What happens in a project where the explicit picture itself is more important than the work needed to create it? In the traditional large company that develops products containing software, this is normally the case. There it is the product manager who hands over high-level requirements to a system department which makes the detailed requirements and the architecture that are later on used as input to the software and hardware design. In such organizations, the normal way of working is that a number of explicit pictures and documents are developed in small, closed groups and then handed over in several steps. Why is this not an effective way of working, and what is the alternative?

An explicit picture is not something that a small group of people or an individual person can create and then pass on to others. The reason is that the picture itself has no depth; it lacks its own history and will always be interpreted differently depending on who is looking at it.

Let us use the Anatomy as an example. It is not a problem to let a few very experienced people create a good Anatomy of the product to be developed, but when this good Anatomy is handed over to other people it actually lacks most of its information. If you instead let the smallest possible group of key persons, covering all the areas of competence needed to develop the product, develop the Anatomy together, you have automatically

22

made sure that all of these key persons in the project have a more common picture of what functions the product will contain and how they relate to each other.

Every person in a project creates his/her individual inner picture of what product to develop – it is during the work in the project that these pictures slowly converge. Actually, a 100% common picture does not exist until the product is ready.

The differences in how the work is done in the project are enormous, but if you measure the progress of the project in a traditional way, no differences can be seen. To develop products in an efficient way is not a question of first developing and then handing over explicit pictures in several steps. It is more a question of creating a way of working where the members of the project slowly let their individual inner pictures converge. The common picture of the project exists as the sum of the individual inner pictures of all project members. The Anatomy work is a facilitator allowing this to happen.

Growth of Common Knowledge What happens in projects that are driven at a very high pace and where the project-members are not offered the possibility of making sure that they have a common view of what they are developing?

To develop a product is to make a journey from complete disorder via the Complexity Maximum1 to complete order – which is the product ready for the market (see Figure 4.1, below). The Complexity Maximum is the explicit point in the project where the project members feel that they have passed “the crest of the project”.

Figure 4.1: The way from complete disorder to complete order via complexity maximum

The more pressure there is on the project, the more important it is to let the project reach its Complexity Maximum. Working with Anatomies is one important component of the process of reaching the Complexity Maximum. 1 A model created by B. Huberman, T. Hogg, and C. Bennet.

Disorder Order

Complexity Complexity Maximum

Analysis & Design

Implementation

23

Working with the architecture and visual planning are other important components. The single most important step to take is allowing key persons, from all the areas of competence needed to develop the product, to participate in such activities during the early phases of the project. This means that representatives who are normally not involved in the early phases should be invited to participate actively already in the analysis and design work. Examples of such representatives are people from system integration, system test, production, and aftermarket. During this work, each of these key persons creates an individual inner picture based on personal knowledge and experience.

In the sub-projects or teams that are normally created when the project grows, new project or team members are assembled around the key persons who have been involved in the early phases. In this way, the work of letting the individual inner pictures converge continuous automatically.

Complexity Maximum is reached when the individual inner pictures of all project or team members have converged sufficiently. Normally only a project manager with long experience can realize when the Complexity Maximum has been reached. This is one of the most important decisions a project manager has to make during the whole project. It is often a hard struggle for the project manager to buy time to let the project reach its Complexity Maximum when the project sponsor puts pressure on the project, especially if it is running a bit late. There is a big difference between the judgement made by an experienced project manager and an inexperienced one in this situation. The experienced project manager has a good feeling of how convergent the individual inner pictures are at any time during the project. This ability is a part of the tacit knowledge of the project manager (Göranzon, Ennals, & Hammarén, 2006).

Unfortunately, the normal case is that the analysis and design work (on the way from complete disorder to complete order) is interrupted before the Complexity Maximum is reached. By doing this, the project is forced into the implementation phase before the conditions for success with that work are in place. This creates a project risk and is illustrated as a short-circuit in Figure 4.2, below.

Figure 4.2: A short-circuit on the way from complete disorder to complete order

Disorder Order

Complexity Complexity Maximum

Short-circuit

Implementation

Analysis & Design

24

In the figure above, this looks like a short-cut, but what actually happens is that the creative process is interrupted before the project can fully benefit from the investments made in the growth of common knowledge during the early phases of the project. Note that there is no time-scale in the figure above, so that even though the short-circuit looks like a short-cut, it is not one.

The author of this chapter has seen several times, in different large companies, what happens in projects where the individual inner pictures have not converged enough. Things are misinterpreted, there are numerous misunderstandings, and things are handled differently in different parts of the project. Decisions taken at project meetings mean different things to different people even though they have attended the same meetings. All this happens because the individual inner pictures have not converged sufficiently, a situation that leads to a substantially higher number of errors in the product – both during product development and after the product has been shipped to the market – than would have been the case if the project members had been given the opportunity of reaching Complexity Maximum.

Of course, problems in projects can come as an effect of the fact that it is technically difficult to develop the product, or because the project members lack the knowledge needed to develop the product. However, these problems would have been obvious early in the project if the way-of-working had focused on letting the individual inner pictures converge. As an example we can again use the Anatomy. It is not possible to create an Anatomy in a group of people if their knowledge of the product is poor.

How to Work with Anatomies in Real Projects? Even though we use formal process descriptions to produce a number of artifacts in the same way in every project, there is no guarantee that the product that is finally developed by the project will meet the requirements stated on that product. Processes and methods do not create the product, they are just a framework for how an organization wants to develop products. Can it be done in a better way? How? What is needed to establish a successful way of working using Anatomies, and what have organizations which have done this achieved?

Anatomies were introduced in Ericsson in parts of the organization developing radio base stations at the beginning of the 90s. Below, one method of developing and documenting the Anatomy of a product in just over twenty-four hours is described. The author of this chapter developed this method in the late 90s to fit the requirements from the Japanese customer NTT DoCoMo.

Since then, the method has spread to other parts of Ericsson and, via companies partly owned by Ericsson, to other companies. The way of

25

working described in this chapter is used today within Ericsson, Saab EDS (formerly Ericsson Microwave Systems), and RUAG Aerospace (formerly Saab Ericsson Space). The method is unique in the way it makes it possible for the project to wait with the Anatomy work until there is enough knowledge among the project members to make sure that the Anatomy will be accepted and ready in time for the work with the integration plan.

The work is done during a full-day workshop involving (normally) six to twelve people. The method is called “Anatomy Day”.

In organizations not familiar with the method, it is recommended that the method be gone through prior to the Anatomy Day workshop.

Why work with Anatomies? The goal of Anatomy Day is that a group of representatives (key persons),

from all areas of competence needed to develop the product, should be able to create and describe a common view of the functions of the product and their relationships from development, integration and, test perspectives. More specifically:

1 The group of people having a common view of the product should increase.

2 It should give people who need to know each other an arena in which to meet.

3 It should make clear who knows a lot and who knows too little. When working with Anatomies it becomes apparent which people will be the key persons during the project.

4 It should create a common understanding of what functions in the product are of most value to the end-customer. These functions should be visible at the top of the Anatomy. The Anatomy also visualizes how the supporting functions relate to each other and to the “money making functions” that the customer is paying for.

5 The relationship between functions of the product from a development point of view should be visualised.

6 After the Anatomy Day there should exist an Anatomy that is good enough to be used as the basis for a stable Integration Plan.

EXAMPLE: Agenda for the Preparation Meeting

Invited: The participants of the Anatomy Day

10 am - 11 am What is an Anatomy?

Why work with Anatomies?

Experiences from different domains

26

Examples from real projects

Q&A

EXAMPLE: Agenda for the Anatomy Day

Invited: The smallest group of representatives (key persons) from all competence areas that are needed to develop the product, together with the project manager (normally six to twelve people).

8.30 am - 8.40 am Introduction

8.40 am - 9.10 am Technical Introduction to the Product with a Focus on Functional Requirements (System Leader)

9.10 am - 9.30 am Repetition: Anatomies and the Method

Coffee Break

9.45 am - 11.30 am Identify Function Groups (in two parallel groups)

11.30 am - 12.00 pm Evaluate the Function Groups

LUNCH

1 pm - 4.30 pm Develop the Anatomy (in two parallel groups)

4.30 pm - 5 pm Distribute the Homework and Evaluate the Day

What to Bring to the Anatomy Day

All participants should bring all artefacts that they believe can contain functional requirements for the product.

The workshop leader brings yellow stickers in different sizes, together with broad-tipped pens. The pens should be broad-tipped so that only simple names of functions or function groups fit into the size of the yellow sticker. By doing this, it is possible to read the function names from a couple of meters distance, which is important for keeping everyone in the group active throughout the whole day.

The Anatomy Day − start with the identification of function groups:

o base your work on use case models, function blocks, requirement specifications, implementation proposals, etc.

27

o divide use case into realizing functions o identify functions that have a logical connection to each other

from a development point of view (these form function groups, in some organizations called anatoms)

o agree on what each function group contains and give each function group a clear and significant name

o create one post-it per function group o try to keep the number of function groups between thirty and

sixty, regardless of the size of the product. If the product is small we can work with a higher resolution, while for a larger and more complex product we need more of an overview when planning the development.

− When the function groups are identified, it is time to start identifying and describing the relationships among them

o sort the function groups based on how fundamental they are to the system

o start with the most fundamental functions o build the Anatomy bottom-up and top-down in parallel o draw your arrows from function groups higher up in the

picture to function groups lower down (i.e., a depends-on relationship in UML)

Anatomy Checklist

When there is an Anatomy-draft ready, it is time to ask the workshop group the questions below to make sure that the Anatomy will be useful.

Note that it is important that the work with the Anatomy is not limited to the questions below! They should only be used as a checklist when there is an Anatomy-draft in place.

• Does the Anatomy show clearly what the “money-making functions” are and what the supporting functions are? The “money-making functions” should be at the top of the Anatomy depending on support-functions. This is not always easy to get right. As an example we can look at the money-making function “basic call” in a mobile base station and the support function “call supervision”. It is easy to think that to be able to verify “call supervision”, “basic call” must be in place first, but it is actually the other way around. To be able to make sure that the money-making function “basic call” is working as expected, the support-function “call supervision” must be in place first, and this should be visualized in the Anatomy.

− Are the dependencies you have described in your Anatomy possible when you have a look at the architecture? It is important to stress that the Anatomy work and the Architecture work must go hand-in-hand.

− Will the implementation of the product be possible according to existing plans when you look at the Anatomy? If not, is it the Anatomy or the existing plan(s) that need to be changed?

28

− Will it be possible to efficiently integrate the product in the order described in the Anatomy? Organic Integration (Järkvik & Kylberg, 1994), is the natural way to integrate a product when working with Anatomies, but integration in a non-organic order can be necessary or sometimes even desired. In such cases the decision must be well-motivated and well-communicated.

− Is it realistic to test the product in the order shown in the Anatomy? − Is it possible to test each function group in the Anatomy separately,

provided that all function groups upon which it depends are tested and ready?

What Happens After the Anatomy Day?

At the end of the Anatomy Day each participant will take with him/her a number of function groups to describe and then e-mail the description to the workshop leader before noon on the day after the Anatomy Day. The descriptions should be four to eight rows of explanatory text, together with references to more information. In this way the workshop leader can have a complete Anatomy document ready for review already the day after the workshop.

Notation for the Elements of an Anatomy

A

B

C

>=1

A B

Function Group A

Function Group B depends on Function Group C

There is an outstanding question regarding the dependency

AND-symbol

OR-symbol

Function Group A and Function Group B both depend on each other

Figure 4.3: Notation used to describe the elements of an Anatomy

29

EXAMPLE: An Anatomy from Real Life

Figure 4.4: Neutral Anatomy

Figure 4.4, above, shows an Anatomy developed and documented during an Anatomy Day that the author of this chapter led at Ericsson in 2004. The name of the function groups are removed for security reasons, but the example still shows the different function groups of the product and how they are related.

Note that in some organizations the arrows in the Anatomy graphs show the integration flow, as in the picture above, while in others UML is used and the arrows instead show the “depends-on” relationships.

30

Discussion & Conclusion When the Anatomy was introduced within Ericsson in the 90s, it was a pre-condition for successful project planning and visualisation of development work conducted in an integration-driven order. The way-of-working when using Anatomies has evolved continuously since then.

Now, more and more companies developing products that contain software are introducing different ways of agile development. When developing large and complex products in an agile way, the Anatomy has been proven to support self-conducted and self-organizing teams within the framework of the assignment of the project and the architecture. In an agile world, it is even more important to understand how knowledge and experience can be communicated among people so that the different parts of the project do not begin to diverge in ineffective and expensive ways.

Developing a new product or enhancing an existing one can be described as a journey from an individual inner picture carried by a few people, via the Complexity Maximum of the project, to the product ready for the market. When the product is ready, it can be seen as the common picture of the results shared by the people involved in the development of the product. The Anatomy has been shown to stimulate this journey. It is not the Anatomy-picture itself that is most important for success; instead it is the work that is done by a group of people in different forums to create and maintain the Anatomy.

References Göranzon, B., Ennals, R., & Hammarén, M. (2006). Dialogue, Skill and

Tacit Knowledge. Chichester, England: John Wiley & Sons Ltd. Hoberg, C. (Ed.) (1998). Precision och improvisation: om

systemutvecklarens yrkeskunnande. (In Swedish), Stockholm: Dialoger Järkvik J., & Kylberg, L. (1994). Om att lyckas – lite tur behövs också. (In

Swedish), EN/LZT 1231987.

31

5 The Project Anatomy

Erik Blom, FindOut Technologies AB

The project anatomy is similar to the system anatomy, with the main

difference being that anatoms contain the work needed to produce the

capabilities, rather than the capabilities themselves. The project anatomy

can also include other types of properties and dependencies, making it

ideal for visualizing different aspects of a project, such as integration plans,

risks, progress, and the impact of changes. It can even be used as a

means to steer the project in the desired direction and motivate the team to

commit to the objectives.

The project anatomy has several benefits that are independent of the level

of complexity in the product. Even if the project could be planned without

anatomies, the advantages in the execution phase alone justifies the

anatomy approach.

This chapter begins with a short definition of the project anatomy, then

continues with a description of how to use it in a project and how it can

affect team motivation. Finally, a number of visualization possibilities are

described.

Terminology and conventions specific to this chapter

The project anatomies in this chapter are drawn top-down (i.e., basic functionality on top), but the ideas presented are relevant in a bottom-up anatomy as well.

The notation in this chapter is that the work package at the end of the arrow is a dependant of the package at the beginning.

32

What Is a Project Anatomy? A project anatomy is an anatomy that describes the project activities needed

to develop a system, rather than the system itself.

The anatoms of the project anatomy, called work packages, should reflect

the capabilities in the system anatomy, which makes the project anatomy a

capability oriented view of the development project.

Figure 5.1: A project Anatomy for a simple issue management system.

33

The work packages, ideally, should have a definition of done that includes

integration in the latest build.

Since the project anatomy’s anatoms differ from those of the system

anatomy, the dependencies between the anatoms can also be different from

those defined in Chapter 2. For instance, resource conflicts can be shown as

dependencies in the project anatomy.

Because of the capability orientation, the project anatomy is not the ideal

tool for detailed follow-up of teams or individuals. There are numerous

other tools for that, such as Gantt charts, scrum boards, project velocity

charts, etc. The project anatomy does not replace those, but is a complement

and easy-to-grasp view of the whole project’s progress, especially useful in

complex system development.

Also, the project anatomy is more changeable than the system anatomy.

Since the work packages represent work needed to develop capabilities, they

may be split, combined, and moved due to circumstances other than those

that can affect a system anatomy.

Example of when work packages are be split and moved:

Assume that you are developing an embedded system with power supply from either

AC, During planning you realize that while power supply is, of course, necessary for

the whole system to run, you actually only need one of the three power sources

implemented to test most other system capabilities.

Since 12 V is going to be the common internal system voltage that the other two are

converted to, it makes sense to split the power supply work package and put the other

two power supply alternatives in later shipments12V DC or –48V DC.

Figure 5.2: Splitting of a work package.

34

Another major aspect of the project anatomy is that you can use it to record

progress, for instance by adding colors to the work packages.

After some time, the project anatomy may differ quite a bit from the

system anatomy, due to splits, new dependencies, movement of work

packages to new shipments, etc. This has the effect that it cannot replace the

system anatomy as a common view of the system to be developed. Instead,

it should hopefully become the common view of the project that develops

the system.

How to Use Project Anatomies A good rule when visualizing information in general is to consider what

behavior the information presented will be driving. There is a risk that by

measuring or presenting certain information, you unintentionally promote

undesired behavior.

The information that can be derived from a project anatomy, however,

actually promotes quite a few desired behaviors, if the anatomy is actively

used throughout the project. The next section will discuss a few of these,

related to Risk Management, Project Re-planning, and Progress Reporting.

The section after that discusses team motivation aspects of using project

anatomies.

Integration and Release Planning

By grouping work packages in an intelligent way, aided by the visible

dependencies, the project anatomy becomes an increment plan. The

increment plan shows the major steps towards a complete product. It is the

basis for the integration plan, which is a plan for how and in what order

integration of all system parts should be done.

35

Figure 5.3: Work packages grouped to form shipments/increments

In Figure 5.3 an initial increment plan is created. This may be done on a

whiteboard or in any drawing tool. However, to make it easier when making

changes to the anatomy and increment plan, it may be a good idea to use a

dedicated tool. You can then add different levels of shipments or releases

and end up with a plan like the one in Figure 5.3. That view is created from

an anatomy and provides a more time-oriented view of internal and external

deliveries. It is nothing more than the same work packages rearranged into

builds and shipments (shipments and builds can be seen as major and minor

internal releases of the system).

36

Figure 5.4: Integration plan with two release levels (PaipeTM) (text is not important).

Figure 5.5: A spider, with seven dependencies (marked with a red frame)

37

Risk Management and Project Re-planning

Finding Risks – Look Out for Spiders!

The obvious way to find risks is to simply look at the anatomy and identify

the yellow or red work packages. If yellow means “At risk” and red means

“Off track” you have your priorities ready.

There are, however, ways to identify project risks even in the planning

stage.

A spider is a work package with many dependencies.

Spiders are risk objects for a couple of reasons:

If there are many dependencies to a work package, there are also many

potential work packages that can delay it

If there are many dependencies from a work package, there are also

many potential work packages that can be delayed because of it.

Mitigating Risks – In the Planning Phase

If you have identified your spiders, it will be easy to reduce the risks right

there, in the project anatomy.

Try to split the spiders. Maybe the work package can be divided into

several, each with fewer dependencies? Then there won’t be any spiders

anymore.

When grouping work packages into shipments, try to place the

successors of spiders in a later shipment. That way, if the spider is late

you can move it to the next shipment without any other consequences

for the current shipment.

If you have to plan the spider in the same shipment as its successors (not

uncommon), try to put load-balancing work packages in the next

shipment. Load-balancing work packages (load balancers) are work

packages that, from a dependency point of view, can be developed and

integrated earlier or later (few or no dependencies). If you put such work

packages in the shipment after the spider, you can, if you later have to

38

move the spider and its successors to the next shipment, use the load

balancing work packages to even out the workload when you do the re-

planning. This kind of risk mitigation usually requires consideration of

numerous factors, since there may be a lot of reasons other than

integration order for work packages to be planned in different

shipments.

Mitigating Risks – When a Work Package Is Late

So what if, once the project is ongoing, a work package is at risk of being

late and the whole shipment is jeopardized? First of all, you are lucky to

know that there is a problem, aren’t you?1 But in what way can the project

anatomy help you solve this problem?

One powerful method is to have the system engineers look into the late

work package and its successors. Maybe the work package could be split

into two or several, where only one is actually a prerequisite for those

which come after. That way the responsible team can focus on the one

critical work package and the others can be moved to a later shipment.

Of course, there may be dependencies from the new work packages as

well, but hopefully those are to work packages that were already planned

in later builds or shipments.

Another method – less attractive but sometimes necessary – is to accept

the consequences of the delay and re-plan the project. Since the

dependencies between work packages have been visualized, the outcome

of any change will be easy to see and understand. The project manager

and the system engineers will be able to experiment with the splitting of

later work packages to increase parallelism, in order to either find work

package development that can be started in advance to enable integration

earlier, or to just move load balancer work packages with no close-in-

time dependencies, to fill up the space. Note that this mitigation tool is a

1 How to know is discussed below in the section “Adding Color, Form and More to the

Project Anatomy”.

39

lot simpler to use if the precautions mentioned in the section about

Mitigating Risks – In the Planning Phase have been taken.

Then, as will be discussed below, just the fact that the team members can

see that their work package is at risk, and the consequences of a delay, may

actually trigger local actions, such as developer-to-developer discussions on

what is of first priority, or even voluntary overtime.

New Requirements

Not only risks may force you to re-plan the project. There could also be new

or changed requirements.2 The anatomy allows you to show the impact of

new, changed, or removed requirements in a very intuitive way to the

steering group, the development team, and the customer. Instead of

receiving a change request from the customer, analyzing the consequences,

going back to the customer and trying to explain why that small change will

cause so much delay, you will be able to analyze the consequences together

with the customer.

By actually collaborating on the project anatomy together, the customer,

project sponsor, or whoever will understand the options and consequences

of a scope change. He or she can then decide if it is worth the extra cost or

project delay.

The opposite, of course, is also interesting. When your project is running

late and you need to remove functionality in order to deliver in time, your

customer can understand and suggest changes to the scope that can be done

without unwanted consequences.

Progress Reporting

Steering groups, customers, and other stakeholders expect concise, but

comprehensive, updates on project progress and status. However, spending

2 This is actually almost the same situation as when a project is to add features to an

existing system, as described in Chapters 7 and 8.

40

valuable time in steering group meetings, listening to all that has been

achieved since the previous meeting, is a waste of time, even if it is

interesting (and actually a good sign that the project manager wants to show

all the team’s achievements).

As you probably have guessed, a project anatomy is a great way to

quickly show achievements and problems and relate those to the project

plan.

Look at the anatomy in Figure 5.6

Figure 5.6: Project anatomy with off-track work packages (text is not important)

It is easy to see that the first shipment is already delivered (blue), that the

second shipment has several late work packages (red), and that one of those

seems to have delayed work packages in the third shipment as well. You

may also notice that there is one white work package in shipment two. That

41

could either mean that the work has not yet started, or that there is no

information about the status of that work package. Both should be worth

investigating. You can also determine that, e.g., the work package at risk in

shipment three (yellow, in the middle) will not affect any other work

packages, since there are no dependencies from it. If you were in the

steering group for this project, you would know exactly what to focus on.

Team Motivation – the Power of Visualization So far this chapter has discussed the project anatomy as a tool for traditional

project management tasks, such as risk and change management. There are

however, other, more implicit aspects of project management that also

benefit from the collaboration and visualization that come with anatomies.

Some are discussed in other chapters and some – related to team motivation

– will be discussed here.

Anyone understands that for people to commit to a project or a task, they

need to be motivated. Motivation is also one of the more common subjects

discussed in project management literature. As will be seen below, project

anatomies support a number of factors generally considered important for

team motivation3, such as: Delegated Authority, Empowerment, A Clear

Purpose, Information, Skill Recognition, Recognizing the Individual,

Positive Feedback, A Collaborative Climate and A Sense of Progress.

A Clear Purpose

To be motivated, and to be able to prioritize correctly, you need to

understand why you are performing your tasks. You must feel that your

efforts are meaningful.

3 For discussions about why these areas are relevant, see, e.g., Lean Software Development

by Mary and Tom Poppendieck or Intrinsic Motivation at Work by Kenneth W Thomas.

42

As stated before, projects with clear, understandable, and well-

communicated goals tend to be successful. This is not only because people

know what to do, but also because they understand the purpose of their

efforts. The latter can be difficult in large and complex projects where a

particular sub-project of thirty individuals is only responsible for a small

part of the whole. Not to mention the even smaller team, typical in agile

projects. The project anatomy visualizes how each contribution fits and in

what way it contributes to the final goal.

Information

If the number one project enabler is a clear purpose, information is surely

number two. Most project managers have probably noticed that even if you

do send out progress reports to the whole team, or arrange stand-up

meetings regularly, your project members will still complain about not

knowing what’s going on.

Now, anatomies won’t satisfy all information needs, but when it comes to

understanding progress, priorities, and what should be ready when, a project

anatomy posted on the wall or displayed on a large computer screen does a

lot of the work – because it is simple and intuitive.

You may have daily scrums or the equivalent to take care of the

information needs in each development team, but the project anatomy can

help you communicate the next level to everyone.

Progress

People want to feel that they are making progress. In long projects it is easy

to get the feeling that you are working and working, but that the same old

issues prevail and there isn’t much progress. In contrast to, e.g., Gantt

charts, project anatomies show progress in terms of developed system

capabilities (even if they are only system internal) rather than performed

work tasks (of course developing the capabilities is a task, too). The very

43

easy-to-grasp view of the whole project offered by the project anatomy adds

even more to the sense of progress.

In the Agile world, the progress in achieving a specific objective may be

visualized on a Scrum or Kanban Board, but these are not very good at

showing over-all progress together with the objective’s impact on other

objectives. Project anatomies are an obvious planning and reporting

complement to those tools.

The two anatomies below illustrate how obvious progress can be in a

project anatomy. Publishing of the second example shows that the lagging

work package is completed, leading to the whole shipment being ready and

one of the risk work packages in the next shipment now being on track. Isn’t

that worth celebrating?!

Figure 5.7: Blue work packages are completed. Time to celebrate!

Delegated Authority and Empowerment

Empowered teams are dependable teams. Skilled individuals need to feel

that they are empowered to plan and execute tasks by themselves. But to be

able to delegate authority, you first have to make sure that the delegatees

fully understand their objectives – which also include any dependencies to

other teams’ objectives.

As every experienced project manager probably knows: With clear and

well-communicated goals, half the job is done. If people just fully

44

understand what to accomplish, they can usually figure out how. The

problem is that, as project size and complexity grow, the what becomes

more fuzzy and distant, and it is tempting to express the what in how terms;

i.e., instead of defining clear goals and breaking those down into graspable,

deliverable pieces, you break down the project into activities, which are

usually allowed to be less precise. This may be an easy way forward during

project planning, but avoiding the difficult breakdown of objectives will

bring about its own punishment.

As an example, breaking down the development of a SW sub-system into

Analysis, Design, Implementation, and Testing looks like a breakdown of

the objective, but it is no good if you want teams to really commit to the

project. Developers will still ask “So what are we going to Design or Test?

When are we ready?” Or even worse: “Don’t patronize us! We know how to

do our job – but you don’t know what you want.”

There is obviously a need to break down the goals into smaller

intermediate objectives and, as you probably have figured out by now,

anatomies are nothing but the final product broken down into small

implementable pieces – exactly what you need! By assigning the capabilities

– in the project anatomy represented by the work packages – to teams or

individuals, you have accomplished the task of defining intermediate goals

for the project, without interfering with how to do the job. Because

anatomies split a project into system objectives rather than activity

objectives, and they also show how one objective relates to the others and

(optionally) when in time they are planned, the foundation for delegating

authority is in place. If the anatomy has been created in collaboration, the

understanding of the work package’s purpose will be deeper and the

responsible team will be able to make the right prioritizations and

synchronize efforts with appropriate other teams, when necessary.

Empowerment and Agile

You may argue that delegation and empowerment is already taken care of if

you work with agile methods, but a pre-requisite for being able to work with

45

smaller agile teams in a large project is that you can define “features” for

each team that are clear, result-oriented, and with a “definition of done”.

The problem in complex system development is that it sometimes takes

months before there are any customer features ready for demonstration, so

you need some way to define “internal features” that can be assigned to a

team. The system capabilities/work packages contained in the anatoms are

exactly what you’re looking for.

Skill Recognition - Recognizing the Individual

If no one notices when you succeed or fail, what’s the point of pushing

yourself?

People want to be seen. Showing progress in an anatomy will reward

teams that succeed and will push teams to avoid having a red work package,

thereby causing a whole build or shipment to be late. Some call this

“management by shame”, but a better term would be “management by

recognition”, since the important motivator is that it matters to others what

you do.

If you were responsible for the one red work package in the anatomy in

Figure 5.8, wouldn’t you be even more motivated to finish it? If you were

responsible for any of the green work packages – wouldn’t you feel good

about the fact that everyone can see that your team is performing well?

46

Figure 5.8: Project anatomy with one late work package (text is not important)

A Collaborative Climate

The project anatomy and the system anatomy, as described in other

chapters, are highly interactive ways of planning and running a project, and

the visualization of the system being developed gives everyone a clear view

of how their contribution is an important part of the whole. This common

view and sense of common approval supports team commitment – not only

to one’s own team, but to the whole project.

Adding Color, Form and More to the Project Anatomy

In the previous sections of this chapter, some extra visual elements have

been used to enhance the project anatomy. This section will dig a little

deeper into the different possibilities of “anatomy ornamentation”.

47

Color

Color coding can be used for many purposes but the most obvious for a

project manager is probably to show progress. Green for work packages that

are on track, yellow for those at risk, and red for work packages that are off

track are intuitive choices for most people. To show that a work package is

not only on track, but actually completed, yet another color can be used,

e.g., blue.

Relation lines could be made yellow or red to indicate that predecessors

are at risk or off track.

Figure 5.9: Colored work packages.

48

Form

Use different forms of objects and relation lines to indicate, e.g., whether a

work package is special in some way (critical, delivered from an external

party, preliminary, etc.).

Relation lines could be dotted or dashed to indicate that they show

something other than integration order (e.g., resource conflicts). Lines could

have arrows at both ends to show, e.g., that two work packages cannot be

developed at the same time, but that the order of development is irrelevant

(again, typically, the reason could be resource conflicts).

Remember, however, that too many forms may just confuse the observer.

While some colors are intuitive, most forms are not, and one of the key

features of the project (and system) anatomy should be its simplicity.

Figure 5.10: Forms added

49

Grouping

Grouping can be used for different purposes, such as showing that packages

are developed by the same team, belong to the same sub-system, or

preferably should be executed in close sequence.

Or, you can group work packages that are planned in the same shipment

or release, which automatically adds a time limitation to the work packages

included.

A third way of grouping work packages is to put a frame around all

internally developed work packages and put external dependencies (external

work packages) on the outside of that frame. That is a very intuitive way to

show whether a work package is under this project’s control or not.

One grouping above must not necessarily exclude the other, but, as

before, a moderate use of grouping is recommended.

If grouping is used, and especially if shipments are grouped, colors may

very well be added to groups as well, to simplify understanding project

progress.

Figure 5.11: Grouping added

50

More information

Other information that could be added – in text, with symbols, forms, or

colors – includes:

Responsible team or individual (see the section “Empowerment and

Agile”)

Build, Latest System Version (LSV), or ready date

Identification code (in order to be able to refer to the work package in

other documents)

Size or effort

As before, watch out for the risk of over-informing. More than two or three

of the above are probably going to clutter the anatomy and make it less

readable.

Figure 5.12 shows a project anatomy example with a few of the extras

implemented.

Figure 5.12: Text information and highlighting frame added

51

Filtered Information

One way to avoid cluttering the anatomy with too much information is to

add data to the objects that can be visualized only when needed, by filtering

or other mechanisms to create customized views.

If, for instance, you want to plan work packages in time, and avoid having

all work packages of a team in the same shipment, you could either look at

the text information, as in Figure 5.13 …

Figure 5.13: Teams shown with text only

52

… or you could (for this purpose only) give each team a color, as in Figure

5.14, which makes it really easy to find any clusters of one team’s work

packages in the same shipment. The colors should probably be removed

when using the anatomy for other purposes.

Figure 5.14: Teams shown with text and color – some work packages need to be distributed in different shipments

53

SW Tools

Most of the color additions in this section are dynamic and would be rather

tiresome to manage if you had to update sticky notes on a whiteboard every

time something was changed. Fortunately, there are software tools available

that, to different extents, can simplify the management of the project

anatomy. Then you can change one attribute of a work package, or a group

of work packages, without having to re-create it all over (as would have

been the case if you used paper and pen). Moving work packages around

will also be easier in a SW tool than with sticky notes.

SW tools could also add opportunities for creating new views from the

information in the anatomy, exporting information to other formats, and

even synchronizing with other SW tools for, e.g., requirement management,

scrum, or Gantt charts.

It is still a good idea to create the original anatomy with sticky notes on a

board, but it will then have to be copied into the SW tool for the execution

part of the project.

Conclusion By letting the anatoms contain “the work needed to develop, integrate, and

test a capability”, rather than just “the capability”, more attributes and

relationship types may be added that can be used for project management

purposes. The project anatomy has explicit uses in planning and managing

the project, but there are some more implicit benefits for the project, too,

such as team motivation and providing a common picture (as described in

Chapter 4).

Adding more visualization to the anatomy increases its usage, but with

the risk of over-complicating something that has simplicity as one of its

strengths. To some extent, that risk can be managed by using a SW tool with

filtering possibilities for anatomy management. A SW tool can also enable

export and import of information to other SW tools in order to avoid

inconsistencies in the project.

54

The process of creating the system and project anatomy is, in itself, a way

to achieve a common view and understanding of the project, and the

anatomy is also a great help when planning system development. After

reading this chapter, you should be aware that the project management

aspects alone can motivate the use of project anatomies.

References Poppendieck, M., & Poppendieck, T. ( 2003). Lean Software Development:

An Agile Toolkit. Pearson Education.

Thomas, K. W. (2009). Intrinsic Motivation at Work: What Really Drives

Employee Engagement Intrinsic Motivation at Work. Berrett-Koehler

Publishers.

55

An Agile Guide to Anatomy-Based Planning

Erik Lundh, Compelcon AB

An anatomy is a kind of entity-relationship diagram that maps out the desired capabilities (“moneymaking features”) of the system to be developed. The anatomy further maps what capabilities are needed to enable the desired moneymaking capabilities. A full system anatomy almost always starts with some very down-to-earth but often forgotten capability, like “surviving power-on without crashing”. The practice of creating anatomies was not designed in ivory towers by software methodologists, it grew out of necessity. Other chapters in this book tell you more about the origins of the anatomy idea and some different ways it has been used in many projects the last 20+ years.

An anatomy is way for everyone involved in a development project to, in a very short time, create a shared view of what needs to be done. It is not a plan; it is a fundamental map of necessary capabilities and their relationships intended to base planning on. The anatomy is a deceivingly simple concept, its simplicity and spirit is much like the wiki that Ward Cunningham1 brought us. Like the wiki, the anatomy is a surprisingly effective way to get a diverse group of people to contribute to a common shared understanding. Anatomy-based planning has been used to successfully develop very large systems, independently of agile, since 1990.

Anatomies, the agile planning game and the wiki are all examples of the Blackboard strategy, a proven approach to collaborative problem solving. (The Blackboard strategy is also captured as an architectural pattern. “The Blackboard architectural pattern is useful for problems for which no deterministic solution strategies are known.” (Buschmann, 1996))

1 Ward Cunningham www.c2.com, inventor of Wiki, inventor of Fit, coinventor of eXtreme Programming. Motive force behind Design Patterns.

56

Figure 6.1: Both architectural design and planning can be based on the anatomy’s shared understanding.

Anatomies help Agile grow better Agile planning in the form of time-boxed 1 hour Planning Games can be very successful on the team level. But even successful agile teams end up in a trashing/treadmill situation where focus is only on changing or adding marketable features, while the technical debt increases steadily. Having a common view of what is necessary to get the “moneymakers” to the market, a view that is understood across the company, very likely makes agile viable in the long-term. Many teams have seen their agile process slowly detoriate, become mechanical and error-prone over time, especially with agile methods that cater mostly to management’s needs, like Scrum, or adopt a blue-collar assembly-line mentality, like Kanban. What we now call Agile gained its initial momentum 10+ years ago as a reaction to waterfall methodologies and big-upfront design. Agile was the fruit of a mid-1990s widespread reaction against the industry’s utter failure in trying to reduce the art of software development to only a deterministic logistics exercise. Agile challenged all plans made in ivory towers, whether it was micromanaging project plans or detailed big upfront architectural design.

Agile questioned the conventional wisdom of that time by promoting simplicity over gold plated speculative designs, encouraging designs to grow ‘organically’ aided by extensive but often automated refactoring. But

57

the lack of explicit technical planning sometimes backfires when teams can’t motivate laying necessary groundwork. Similar, the product management sometimes skips over upfront product planning, and end up changing the product in a seemingly aimless series of reversed decisions iteration by iteration. Getting all stakeholders together to create an anatomy in, at most, a day will help lay enough of groundwork for both product and technical planning. At first I learned of the anatomy practice from its originator Jack Järkvik, then at Ericsson. I later found the Ericson tradition of anatomies helpful when you introduce agile practices to Ericsson units. Lately, I have introduced the concept and practice to highly successful teams outside Ericsson, some of them with 5+ years of experience of hard-core successful agile, but without prior knowledge of anatomies. Despite their success with full throttle agile, the teams found anatomies really helpful; both complete product or system anatomies, as well as tactical anatomies that describe an increment of development. A tactical anatomy can be used to capture the capabilities that need to be added to an already functional system to enable the desired moneymaking capabilities that are the business goal of an increment or project. Another use of tactical anatomies is to clarify a dependency: A certain task needs to be done to get the capability that either of several user stories depends upon, regardless of which of these user stories the product manager prioritizes as must-have in this iteration.

Scaling up Agile Planning with multiple teams, multisite development and building large systems with many contributors are currently (October 2010) not well understood by the agile community at large. Approaches in the agile literature to do multi-team agile release planning with things like ‘Scrum of Scrums’ is simply not good enough. Many organizations revert back to big upfront non-agile planning for larger projects. Anatomy-based planning fills the agility gap for larger development organizations who want to go agile.

A number of other team-level agile practices are necessary to make executing of agile plans effective and responsive to change, with or without anatomy-based planning practices: test-driven development on several levels, simple design, pair programming, continuous integration, stable teams, to mention a few. The software craftsmanship23 movement captures this trend with statements like “In this day and age: Not using test-driven development is just unprofessional.”

2 http://en.wikipedia.org/wiki/Software_craftsmanship 3 http://manifesto.softwarecraftsmanship.org/

58

Creating an Anatomy together, in an Agile setting To create an anatomy brings people together, giving them hope that they actually can cooperate over borders and between stovepipes. It gives people a hope that it pays off to cooperate and not just cover your own back. It is a bartering process much like the Planning Game. People let down the guard when they see a format that brings lot more hope to collaborating than just doing their own thing.

Anatomy-based planning in an agile context also means that the anatomy becomes the base of an agile release plan for multiple teams, sites and contributors. The anatomy have one or several “moneymaking” leafs that can end up in different releases. In traditional waterfall projects, a practice of defining release levels or swim lanes in the anatomy. One drawback with defining release levels in the anatomy is that those levels, often called work packages, give birth to similar dysfunctions as Scrum burn-down charts. The originators of anatomies and most agile methods share common values of balanced work at a sustainable pace. An anatomy should be used to follow the growth of the system, and give the project management opportunities to balance the workload by refactoring the plan and possibly rearrange/refactor the anatomy. There is usually more than one way to skin a cat, and a changing anatomy reflects what we learned so far and what now seems to be the best strategy to reach the business goals. If the different people working on each capability has to fend for themselves in isolation to reach a release level in a fixed anatomy, we have lost a lot of the benefits of both agile and anatomies. It is much better to create an anatomy that describes the increment of capabilities for each major release, based on the overall anatomy.

An alternative agile approach is that the anatomy basically stays the same but the acceptance criteria become more challenging for each release. The first release might have “make a call” as one testable acceptance criteria. The final release in the plan has “make a thousand calls” as one of its testable acceptance criteria. Successful uses of anatomy-based planning are often a pragmatic mix of these approaches.

Over the years several different approaches to creating an anatomy for a system or product has evolved. At this time, the approach that agile people probably resonate best with is the one day anatomy creation workshop (see Pilborg, Chapter “The inner picture”, this volume) as practiced by Ericsson, RUAG Space and other companies. And it took just a few hours, when an agile team used this very approach to do a smaller tactical anatomy, a shared overview of just an increment, not the whole system.

59

The Anatomy Creation Workshop

The participants: The most knowledgeable, experienced people you can find in each team, site or contributor. The workshop becomes more dynamic when there are people enough to form two subgroups that compare notes (a process similar to the initial steps of affinity mapping [ref needed]) on their understanding of the items, dependencies and structure needed to build the final system or product.

Figure 6.2: The group is split in two subgroups to reduce “groupthink”. The subgroups start to think of and write down capabilities

The point with the exercise is to make all teams aware of necessary sequences to build the system, what can be parallelized and how to minimize dependencies. Since this the anatomy planning workshop brings people together from multiple teams, sites, maybe even different countries, this workshop usually need more time than the agile Planning Game. Each subgroup starts to write down all items they think is necessary to build the system. Each necessity becomes an item on its own post-it note. The initial discovery activity is time-boxed to one or two hours.

60

Figure 6.3: End of first round: Joining up to give both groups a copy of the combined set of capabilities, each one written on a post-it.

The two groups convene and figure out what items both groups sort through their post-its and eliminate doubles that both teams thought of. Then a second set is made of these unique items, also on post-its. The group is split again in two subgroups that each gets one identical set of items on posit-its. Each group tries to figure out what is the root item that needs to be built first. The two subgroups might not have agreed on the anatomy plan’s final leaf item(s), the finally marketable feature(s) are.

61

Figure 6.4: Second round: The group split again in two. Each subgroup builds an anatomy. Many groups find that they need to create additional post-its with capabilities when they start building the anatomy tree. Groups often find that they do not need all the capabilities that were created in the first round.

Each subgroup now builds kind of an entity-relationship diagram starting with the root item (‘Survive Power On without crashing’ as Jack Järkvik often puts it. ‘Let there be light’ is another metaphor for the birth of the infant system ) and order all other items in orders of dependency out from the root item towards one or several final leaf items that represent the marketable features of the final product.

Figure 6.5: At the end of second round, each group explain their anatomy

Figure 6.6: Third round: The final anatomy is built by one combined group.

The actual plans (project plan, integration plan, and systems architecture) are created next with the anatomy as a base for understanding the constraints and relationships when developing the desired technical system.

62

The anatomy is not the plan, it is a way to the necessary shared understanding we should base feasible plans on.

Team-level Agile Planning 101: The Planning game. Proper agile planning enables stakeholders like development team, customers, product manager and project managers to collaborate on building the best product in many small steps (iterations). Each step is planned in a time-boxed planning dialogue between people who want solutions to problems they state, and people who can transform solutions into actions specified as tasks. People who want solutions express their problem/challenge/wish as a user story. They also have to specify one or several acceptance criteria, acceptance tests for each of the user stories that they want implemented. The acceptance tests can be formulated in a dialogue with the development team.

If tasks are formulated as independent or atomic as possible, the plan is more responsive to “re-think” when the larger group discovers new aspects of the growing product.

A task (actionable item, often called ‘engineering task’) should, as a rule, be small enough for one or several to be completed within a working day by two people working together.

The group gathered to plan consists of ALL members of the combined test and development team, not just a developer ombudsman. We need at least one from product management, one from project management and some representation of all other stakeholders. No one is there just to pass time.

63

The Agile Iteration Plan: US = User story, AT = Acceptance Test, ET = Engineering Task

Enter the Planning Game:

The gathered planning group has just seen a demonstration of the result of the last iteration. It demonstrates not only new features but viable proof that the result of all previous iterations is still intact, e g given through visual live summaries of all automated acceptance tests. The time-box to produce the plan for the next iteration is fixed (one hour in some of the best performing teams). The resulting plan details tasks for a fixed iteration time-box of work, usually 1-2 weeks.

The product managers (sometimes called “product owners” in agile) own the “what and when” of the plan. The developers own the “how” they are going to make the “what and when” happen. The product managers express features they need in the product as “user stories”, in general something that can be experienced and that the customers pay for. The developers express “how” in the form of

64

sequences of engineering tasks.

The product managers bring user stories to the planning game. The already agile product managers have ordered their user stories in 3-4 columns/categories: “Must Have Now”, “Can Wait”, “Nice To Have”, and when necessary the fourth column “Won’t”. (This practice originates from the MoSCoW practice in DSDM (Stapleton, 2003)).

The user stories in the “Must Have” column is internally ordered according to priority, with the most important topmost. The “Can Wait” column contains user stories that should be in the product, but can wait. The “Nice To Have” column collects the user stories that would have been nice, but seems unrealistic to get into this product. If certain user stories seems to float around but never gets done, and is often debated but never put beyond “Nice To Have”, they can end up in the “Won’t” column, which means that an active decision has been made that we won’t work on the user stories in that column. Every column is prioritized within that column. That means that anyone that wants to think about estimates and solutions for upcoming user stories know which user stories are most likely to be suggested at the next planning game.

In the beginning of the planning game, the product managers ask the developers in the team to do rough estimates based on the user stories in “Must Have Now” and “Can Wait”. When the developers estimate, they pick and think about user stories from the top and downwards both on “Must Have Now” and “Can Wait”, in parallel. In the best teams this is an ongoing process where developers keep an eye on the changing priorities and keep updated estimates for all user stories that is likely to come up at the next planning game. This is not too hard, as longs as the product managers keep all columns in priority order.

When the product managers go through the estimates during the planning game, they have an opportunity to change category and priority.

The next step is interesting. As we know constraints is an important ingredient in all creative work. We now sum up how much we can do in the next iteration, either in ideal time or story points. Then we look at how many user stories we can do in the next iteration (2 weeks or shorter). The product managers are then asked to reduce the “Must Have Now” column to just the stories that we can do in the iteration of one or at most two weeks.

The hidden magic here is that product managers tend to move user stories between columns, this is caused by the introduced constraint of what we realize is the limit of what we can accomplish in an (two week) iteration! If the capacity constraint is in place from the beginning, we only get a limited-queue effect, which does not invite to the same degree of re-evaluation and re-categorizing of user stories.

65

When we finally agree as a team on the selected set of user stories that we aim to implement in the iteration we plan for, user stories has often traveled back and forth between all 3 (or 4) columns. This is an important step of refinement and re-evaluation. We now have a series of user stories that we want to put into an iteration plan.

A popular form of MoSCoW in Agile: Must Have Now, Can Wait and Nice To Have. The categories and the late constraint that product management must reduce and fit estimated user stories for roughly an iteration in the Must Have Now-column act as a distillery. It is not like a backlog with a cut-off point. The time constraint is introduced late in each planning game, triggering serious reconsideration by product management.

But the user story is only one part of a full requirement. The other part is one or several acceptance tests.

The developers create “engineering tasks” as series of activities that fulfill the user story the extent expressed in its acceptance tests. The ideal engineering task is a small building block that is one logical step to fulfill the acceptance tests of a user story. An engineering task is placed under the

66

first user story that needs the result of the task. It is sometimes difficult for developers to explain to business why a time-consuming task needs to be done first, regardless of which of a subset of user stories they select. A system anatomy or if that is not available, a tactical anatomy can help explain these dependencies to business. The capability has to be realized by the same series of engineering tasks regardless which of the two stories gets prioritized as the first to be implemented.

[Fig Two user stories that depend on the same capability]

Writing atomic engineering tasks is a skill to be developed, like writing clear user stories that are not taking away the “how” from developers. Creating acceptance tests can be a conversation, a bartering, and a discovery that involves both product managers, developers, and when available, testers. Most teams learn to automate acceptance tests well before repeated manual test execution of the growing set of tests steal too much time.

Figure 6.7: The anatomy help creating and justifying user stories, acceptance tests and engineering tasks

67

Starting with user Stories. Back in 1999 a SPIN-SYD workshop led by Lund University tried to write “user stories”, then a novel concept to most of us. Most participants had a hard time writing user stories, not requirements. A user story needed to be open and suggestive, inviting to discovery, conversation and innovation. The requirements that we were used to write back then was closed from the start and tried to preempt any interpretative discussion. But user stories became proper requirements only when you put the user story side by side with its related acceptance tests. We quickly learned to open up the mind with user stories and then get down to earth in an agreement between requirement writers and developers. The agreement was expressed as acceptance tests, tests that we tried to automate as early as possible.

We found user stories a helpful concept to reduce the lead time and risk of traditional frontloaded detailed requirements engineering. Several member companies later tried user stories in its original agile context, with successful implementations of the first popular agile method, Extreme Programming (XP).

The important working principle is that the stakeholders do not reconsider the iteration goals and objectives once the iteration has started. The developers deliver on time a functioning system which is improved in accordance with all stakeholders agreed priorities. If the iteration cadence is weekly or biweekly, it is usually better to not disturb these short stretches of disciplined, purposeful, well prepared work. Most sudden insights and reconsiderations benefit from having to wait for the next scheduled timeslot for iteration planning. Again, the most successful teams use 1 hour in an all-hands meeting per iteration to finalize their iteration plan. They have no other all-hands meetings to plan each iteration.

The product management, project management and other stakeholders present their final prioritization for the next iteration. User stories for the next few iterations in constantly kept updated in priority order and available to all developers to prepare for planning, but the stakeholders have the right to change from what they learn until the next iteration plan is set by the end of the Planning Game hour.

The general rule is to break the iteration and re-plan in a new Planning Game if stakeholders deem it absolutely necessary to change priorities or introduce new requirements. Even online services benefit from these practices, even though the widespread practice of Scrum has led some online players in too deep trouble, prompting them to adopt a limited-queue emergency continuous development stream approach now popularly known as Kanban. The current agile Kanban approach might be somewhat successful as a more stable contrast to disorganized Scrum. However even some devoted Kanban practitioners report long-term challenges with endless requirements trashing and less of a sense of accomplishment.

68

Some online services with seasoned agile teams have grown, long before Kanban became an agile buzzword, to use a hybrid of Planning Game and a limited-queue of unplanned short high-priority engineering tasks. The principle is to keep the limited emergency queue empty by always picking those tasks first. When the emergency queue is empty, the developers pick the next planned engineering task.

Picking the next task in the plan, and ask the team for the best pair programming partner makes sharing of knowledge natural. If seasoned veterans stand back a little and let the less experienced pick the task, the experienced can do more good by pair programming rotation with several that needs their help.

Creating a tactical anatomy, to help team-level planning Seasoned agile teams that already have a system in development have found it helpful to create a “difference” anatomy as a way to kick-start the anatomy practice. A tactical anatomy does not need to describe the whole system, only an increment. It only captures capabilities that are added or affected and their dependency relationship to the “moneymaking capabilities” that is the business goal of the increment.

69

Agile Methods The Agile movement has several roots. Most of the agile methodologists came out of the design patterns movement of the early 1990s. The approaches to development that we now call agile methods appeared independently in several places.

Dynamic Systems Development Method

DSDM was the first widely known. The adopters of Rapid Application Development (RAD) in UK saw that the waterfall development approach was too rigid to make sense when RAD tools reduced the edit-compile cycle to moments, instead of 15 minutes. DSDM has more of a lifecycle model than other agile methods. The method has clearly influenced other agile methods.

Scrum, the strictly licensed and certified agile method

Scrum was the only agile method that grew out of the needs and minds of managers, rather than technical people. Jeff Sutherland needed a framework to manage his developers without being a developer himself. Jeff was influenced from best practices observed at the Quattro group at Borland. Quattro was a technically excellent product aiming to compete with Microsoft Excel. Jeff’s consultant Ken Schwaber later joined the effort. Jeff and Ken wrote up Scrum as an organizational pattern that was published at a large conference in 1996. But Scrum never took off until after Extreme Programming had woken the enthusiasm among developers in 1999. Scrum was largely ignored in the agile community until Ken Schwaber in 2003 started to offer two-day certifications classes with no skills-test, on a non-technical low-level management role: the scrum master. Two years later, Scrum classes and services dominated and the agile landscape had changed, maybe forever.

Feature Driven Development

FDD started as a consultancy assignment by a methodology and tools vendor, Peter Coad´s TogetherSoft. Consultants from TogetherSoft were experts in object-oriented software design. One group was invited to help a large Malaysian banking project. They quickly discovered that the banking project was in far deeper trouble than just with improper object-oriented design. They formulated an iterative agile method that grew out of their design expertise. Thus FDD grounds everything in OO design activities.

70

Extreme Programming (XP)

In 1996 Kent Beck, then a Smalltalk and design patterns profile, was invited to consult on Smalltalk performance tuning at Chrysler. The hurting project had tried to deliver three months from now for several years. The system, written in Smalltalk, should handle the payrolls for the Chrysler workforce. Kent was asked to make the system faster. He curiously asked:”Does it give

you the right answers?” The reply was “We don’t know the right answers”. Kent replied “Then I can make it as fast as you like”, but later was asked for advice to restart the project. Kent reduced the team and combined technical practices, creativity practices and some influences from DSDM, Borland and possibly from the patterns form of Scrum. What later became the Extreme Programming method grew organically with significant improvements and experiences from the members of the initial Chrysler team. Kent and the team started to talk of their approach at OO conferences. A publisher wanted another book by the popular author Kent Beck, and Kent wrote up the XP method in the 1999 book “Extreme Programming Explained” (Beck, 1999), an instant bestseller that kick-started the agile movement with numerous conferences and books on the topic.

The Agile Manifesto

The majority of the originators of different agile methods came together at a US ski resort in early 2001. One of their emergent goals was to avoid an agile methodologies war. In a great spirit of collaboration they wrote of the views they shared in a kind of a peace treaty, the Agile Manifesto.

The manifesto is an excellent affirmative read for someone who has already been successful with agile. However, I myself have met more than a few who found ample justification for a lot of dysfunctional non-agile behavior in the well-intended heart-warming words of the agile manifesto.

Agile with Anatomies - Pulling It All Together Create an anatomy together with all stakeholders to gain an overview and a shared understanding. Keep it updated when you learn new things. It does not mean that you need to add thousands of details. Just keep it up to date with your understanding of necessary capabilities and their relationships.

Use a form of “Must Have Now-Can Wait-Nice To Have” or MoSCoW to distill out an series of agreements on what requirements should be

71

implemented in each iteration. Even if you have estimates, do not constrain the first category until you have entered the actual Planning Game. The introduction of the iteration scope constraint is a driver of the requirements distillation. Do not use large lists, like product backlogs. People usually become over-whelmed and give in to large list, and stop re-thinking and refining.

Create the iteration plan in a form where you don’t move around cards while you execute. Just mark each card with checkout signatures and done marks. This will help people see disciplined progress and discourages people from cherry-picking the fun tasks. Never allow user stories into the iteration plan without acceptance tests. Make engineering tasks small enough that you feel that you have accomplished something at least once a day.

The team should have the most experienced available for pair programming with many. Make them see the point in growing by helping instead of being lone heroes.

Remember: Use the anatomy not only as a roadmap to build a sequence of system capabilities. You can use your anatomy as map to find a single “skeletal” way to be able to show the simplest possible moneymaker in just one or a few iterations. Then you can improve and add capabilities iteration by iteration. You can express he improvements as increasingly demanding acceptance tests. You can view this as a plant that send up a single green strand towards the sunlight, in the very first iterations. Over time this thin green line will grow in strength into a string and impressive tree with a strong trunk, branches and leaves. Enjoy your growing garden of capabilities!

References Beck, K. (1999). Extrem Programming Explained. Reading: Mass: Addison Wesley. Buschmann, F. R. (1996). Pattern-Oriented Software Architecture: A System Of Patterns.

West Sussex, England: John Wiley & Sons Ltd. Stapleton, J. (2003). DSDM Business Focused Development 2003. Boston: Addison

Wesley.

72

Working with Anatomies in an Agile Environment

Inga-Lill Holmqvist, Ericsson AB

Helena Gällerdal Högfeldt, Ericsson AB

The definition of an anatomy, specifically a System Anatomy in Chapter 2, corresponds in this chapter to a Product Anatomy. The Program Anatomy in this case is a way to visualize the project plan.

The agile way of working encourages teams to work more independently and to plan more individually. This requires that dependencies among teams and products are known and visible. This chapter describes how in such a context an anatomy can be an enabler for managing dependencies. In real projects where a Program Anatomy has been used, the number of User Stories are often more than in the examples in this chapter. We have chosen to show a limited number of User Stories to enhance readability and understandability.

In large-scale agile product development it is hard to avoid dependencies among teams. The purpose here is to clarify how Program Anatomies can be used in projects to understand and handle dependencies among products and teams to avoid surprises in the sprints and to understand the impact of changes. A sellable feature is seldom built up by one team in one sprint, but rather by several teams over several sprints.

In agile development the use of Product Backlogs is common. A Product Backlog is very good at showing priorities among the items to be developed, but not so good at showing dependencies among these items. But anatomies are! The combination of these two methods is very good when scaling agile.

Central Artifacts and Terminology This section explains in brief central artifacts and terminology relevant for this chapter. Some terms used are based on terminology from SCRUM, see http://en.wikipedia.org/wiki/Scrum_(development) (Accessed 2010-10-18.

73

A Product Backlog is used for the project and lists items (e.g., User Stories) to be developed in a prioritized order, with the highest priority on top.

A Program Anatomy shows different types of dependencies among items (e.g., User Stories) to be developed, that is, new additions for the release.

A Work Package (WP) is a container for work to be done that can be tested (with a definition of done). In this chapter it is used as a container for User Stories.

A User Story is a software system requirement formulated as one or more sentences in the everyday or business language of the user. User Stories are used with agile software development methodologies for the specification of requirements (together with acceptance tests). (see http://en.wikipedia.org/wiki/User_story (Accessed 2010-08-25)

A Product Anatomy describes and visualizes the system and its capabilities, both already existing ones and new additions for the next release.

Velocity is how much Product Backlog effort a team or organizations are able to handle in one sprint, which is the speed of the team organization.

A Feature is a functionality or characteristic that satisfies a customer need. A feature is ideally a compelling sales argument, possibly generic but typically for a specific market or even a particular customer.

A Sprint is a fixed period of time for development, normally one to four weeks.

A Story Point is a relative estimate of the size of a User Story. It is used to measure the effort required to implement a User Story.

Project Context Description To be able to understand this chapter, it is important to know what the project set-up looks like and the context in which it is executed.

Planning and Release

A project is often established when there is a product to be developed. The results from the project in this chapter is a product release 2.0. The release consists of a set of features realized by several User Stories developed by several teams.

The Project is planned with a fixed release date and the total available time for development is ten weeks. The sprint length in the project is two weeks, and the velocity for all teams is forty Story Points/sprint. Ten weeks available for the development gives a total of 200 Story Points (40x5 sprints) to release.

74

Team work

The development is performed in ten development teams. Each team sits together and each has its own task board to monitor its velocity and progress.

A feature is developed by several teams. A feature is broken down into several User Stories and the goal is to define a User Story implemented by one team.

Project Roles

The following roles are used in this chapter:

• Project manager: Has the high level planning and follow-up responsibility and helps to remove impediments.

• Chief Product Owner: Is overall responsible for prioritizing among the features to be developed.

• Area Product Owners: Prioritize User Stories within a product area. • Area Technical Leaders: Have the overall technical knowledge divided

by areas. • Teams: Development work is performed by teams.

The project – How It Evolved! The coming sections describe briefly how an anatomy is created, how to manage dependencies, planning contents in sprints, manging changes, and how the Product Backlog relates to the Product Anatomy.

Using the Product Anatomy as Input to Product Backlog

When our Product Owner, Sophie, wishes to prioritize the items in the Product Backlog, the Product Anatomy is one important resource. User Stories affecting the “root” of the system are regarded as more risky (potentially affecting most of our system), and more costly (more regression testing might be needed), than stories affecting “outer leaves” in our Product Anatomy, see Figure 7.1. Therefore, stories affecting roots are given a higher priority. We do not want to discover near the release date that late additions have more or less “destroyed” our system and an already existing functionality. Therefore, we need to deal with this early in the project.

User Stories to be developed and integrated early can be (other than customer value, etc.)

• User Stories that another user story is dependent on

75

• User Stories that demand long testing times • User Stories that have a significant impact on architecture • User Stories that are difficult to develop

Figure 7.1: Feature/User story 1 affecting a "root" and Feature/User story 2 affecting a "leaf"

Creating a Program Anatomy

The area technical leader, Anna, has been appointed as responsible for the Program Anatomy. Because the work with an anatomy is not the work of a single person, she has setup a series of regular meetings to continuously work with the anatomy, and appointed an Anatomy Team. Participants are the project manager, Eric, the chief product owner, Sophie, the area product owners, and the other area technical leads. The first meeting(s) will create the first anatomy matching the Product Backlog for the release.

Working with the Program Anatomy is tightly linked with the work with the Product Backlog (including the Product Anatomy), and they influence each other. Therefore it is important to have the Product Owners in the team.

The Program Anatomy can be seen as just a view of the Product Backlog visualizing dependencies for a release.1

The Chief Product Owner, Sophie, briefly presents the possible scope for the 2.0 release of the product. Since the product has a fixed release date, the scope “interval” is based on the organization’s velocity.

What the Anatomy Team does first is to define the content of the release. The selected User Stories add up to 198 Story Points (of total velocity of 200). The input comes from the Product Backlog. Attributes like Priority

1 It is preferable if a tool can be used in the work with the Program Anatomy, using the same data as the Product Backlog, to avoid the presence of inconsistencies in the data.

76

and estimation of size are taken from the Product Backlog and added to each story.

Then they start to discuss and define dependencies among the User Stories in the Anatomy. The result is shown in Figure 7.2. If only the Product Backlog has been used, the dependencies would not have been seen as clearly as they are in an Anatomy. Now the Anatomy Team has support for managing dependencies.

Figure 7.2: Program Anatomy showing release content and dependencies

Managing Dependencies

Because some of the User Stories affect more than one team, the Anatomy Team wants to minimize dependencies not only among stories but also among teams. To increase flexibility, the Anatomy Team starts the work of managing dependencies by using the Program Anatomy.

User Story 6 is dependent on three other User Stories and is also rather large in size. The Anatomy Team discusses a possible split solution of this User Story. The User Story also affects two teams. The User Story is split into three parts, Work Packages 6a, 6b, and 6c, and new User Stories are defined, User Stories 17 and 19. The Product Owner, Sophie, prioritizes these new stories and also updates the Product Backlog accordingly.

They then look at some other User Stories. Anna thinks it would be a good idea to see if also User Stories 7, 8, and 13 can be split to reduce dependencies. One team member asks if User Story 5 should not also be considered for splitting, but the team agrees to not to split it because it is quite small and also affects only one team. The other User Stories suggested are split and Sophie determines new priorities and includes the new stories in the Product Backlog. There are some large stories with low priority that might be needed to split, but the team decides that work with those stories can wait. The resulting Program Anatomy can be seen in Figure 7.3.

77

Figure 7.3 Program Anatomy after the splitting of User Stories

Planning Content in Sprints

The number of sprints is defined by dividing the number of weeks available for development before release2 with the sprint length of two weeks. The result is five sprints available for development for our project.

How much effort should be put into the detailing of contents into sprints must be determined by the need for coordinating work among multiple teams, and by how far we need to look ahead. The project decides that it will detail the first three sprints and that the last two will, for now, be treated as a “bucket”. This is because the plan will undoubtedly change during the project and we do not want to invest more time and effort than necessary.

Based on the priority and the velocity for the organization per sprint (= 40 for our project), User Stories are put into the sprints with fixed dates. This results in the Program Anatomy in Figure 7.4. The size per sprint is 41/39/36/83 Story Points.

2 This number may differ from the number of weeks until release, depending on the time needed for release activities.

78

Figure 7.4 Content divided in sprints

The Anatomy Team is not satisfied because there are dependencies among teams and within sprints. A new attempt is made, focusing on avoiding dependencies within sprints. This results in the Program Anatomy in Figure 7.5. The size per sprint is 33/31/24/28 Story Points and an out of scope of 83. The Product Owner, Sophie, is not at all pleased with this.

79

Figure 7.5 Program Anatomy after avoiding dependencies within sprints

The team continues the work of managing dependencies among stories and teams and tries to split stories in an appropriate way to produce a plan that considers and provides balance among different aspects such as business value, integration order, resource utilization, etc. It is important in this work to avoid splitting (or merging) stories from an implementation perspective, and to make sure that the stories are possible to verify – “done and working”.

The Anatomy Team is concerned about the dependency between User Story 1 and User Story 2. Both have high priorities, the same team is involved in both Stories, and User Story 1 is large. To minimize the risk of not getting User Story 2 ready in sprint 1 if User Story 1 is not ready in time, User Story 1 is split into two: User Story 1, containing the most important parts, and User Story 23. Now only User Story 1 has a dependency to User Story 2. User Story 23 also gets a lower priority than User Story 2. Other User Stories are also split, e.g., User Story 6 (into User Stories 6 and 22), User Story 8 (into User Stories 8 and 25), and User Story 10 (into User Stories 10 and 24). The Product Owner is continuously involved in the work and re-prioritizes as needed. The result is shown in Figure 7.6. The size per sprint is now 38/36/39/76 Story Points and an out of scope of 10. The Product Owner, Sophie, is satisfied with this.

80

Figure 7.6 Program Anatomy after further splitting

A “theme”, i.e., determining the main goal with the first sprints, is also defined. It is a good idea to clarify what we want to achieve with the sprints, especially with many teams involved.

Changes in Scope

This section will illustrate how a Program Anatomy can be of use when changes in scope are necessary. It illustrates three different types of events that occur in real projects: something is removed from the scope, new features are added to the scope, and a delay in the project occurs.

Feature is Out of Scope

During the second sprint the Chief Product Owner, Sophie, communicates to the anatomy meeting a change in the scope for release 2.0. Sophie explains that she has met the customer and that Feature X will no longer be prioritized and must therefore be removed from the scope. She updates the Product Backlog according to this.

The new directives will have an impact on the project as a whole and on the teams. Work is ongoing in the current sprint and will continue undisturbed. Feature X, which is no longer prioritized, has not even been started so there is no impact on ongoing work. The new circumstances are considered during the next anatomy planning meetings and the Program Anatomy will be updated.

To get an understanding of how the scope impacts the project, the Anatomy Team uses the Program Anatomy. Feature X consists of User

81

Story 11 that has an effort of twenty Story Points. It is moved to the “Out of Scope” section. This is communicated to everyone at the meeting. The anatomy shows a dependency from User Story 20 to User Story 11 but this is considered at the meeting and does not have an impact on the overall product. There is also a dependency from User Story 11 to User Story 21 which is also out of scope. The Chief Product Owner, Sophie, is involved in a discussion to sort out whether User Story 21 will be included in the future. She must investigate this together with the customer and therefore leaves the question until the next anatomy meeting. Figure 7.7 shows the change in scope.

Figure 7.7 Program Anatomy after User Story 11 is placed out of scope

New Feature Included in Scope

The Chief Product Owner also communicates that a new Feature Y will be included in the scope for release 2.0. Feature Y is broken down into User Story 26 and User Story 27 by the Anatomy Team. The technical leaders and two team representatives notice a dependency between these two User Stories. User Story 26 also has a dependency from User Story 9. The prioritization is updated in the Product Backlog and visible in the Program Anatomy. The size is forty-two Story Points for sprint 3 after the addition of Feature Y. Total size for one sprint is estimated to be forty and therefore the User Story that is less prioritized, in this case User Story 12, is removed from the sprint to sprint 4. The total size is now thirty-seven Story Points for sprint 3. Sprint 4–5 has an estimated size of eighty-one Story Points (See Figure 7.8), which the team considers as acceptable.

82

Figure 7.8 Program Anatomy updated after new feature Y

Sprint Scope Not Fulfilled

One team discovers that they will not reach their sprint goal and will need to do work on User Story 25 in the next sprint.

The product owner, technical leader, project management, and team representatives are gathered for an anatomy meeting. They need to consider the delay in the previous sprint and use the Program Anatomy and the Product Backlog to see impacts on coming sprints and the dependencies to other work items to be done. They move User Story 25 to sprint 3 in the Program Anatomy. Once again the size, forty-two Story Points, exceeds the sprint velocity limit for the project. A quick look at the Program Anatomy shows that User Story 8 is the one with lowest priority, which is then moved to sprint 4–5. The total size for sprint 3 is now thirty-nine Story Points, and for sprint 4–5 the size is now eighty-four Story Points (see Figure 7.9). If the velocity of forty is retained, the scope for sprint for 4–5 needs to be reduced. This will be considered in coming anatomy meetings. The move of content in time was also communicated to the Product Owner, Sophie, and she updates the Product Backlog with this new information.

83

Figure 7.9 Program Anatomy updated due to delay

Communication Advantages Traditional project planning has often focused on activity planning rather than product growth and hence dependencies in the product have not been shown very clearly. For the most part, dependencies are omitted or sometimes expressed vaguely (e.g., references to a document). The big advantages with anatomies in general are the strength of visualizing the dependencies in one common picture (also different types of dependencies) and having a tool to manage changes very quickly and effectively. Anatomies make it possible to see the impacts of one or several changes of items in the Anatomy. Anatomies in combination with the Product Backlog provide great benefits. The Product Backlog shows prioritized items while the anatomies show dependencies.

The Anatomy is also used to communicate to other stakeholders about up-coming plans and when in time functionality is expected. It is also very common to add progress information to the items in the Anatomy to highlight a risk or a completed item. For more information about using the Anatomies for progress reporting, see Chapter 5, “Anatomies for Project Management”.

84

Conclusion and Summary To say that the anatomies will solve every planning issue is not correct. In this context, regular and frequent anatomy meetings, together with specified teams and roles with clear goals and responsibilities, support this way of working. The Program Anatomy is used as an effective complement to the Product Backlog and the Product Anatomy to minimize and manage dependencies. We will not be able to remove all dependencies among teams, but it is important to have the ability to understand and manage them with help from the different anatomies. To be able to follow progress and changes, the Program Anatomy needs to be accessible and visible every day to everyone involved in the project.

References Description of SCRUM from wikipedia. http://en.wikipedia.org/wiki/Scrum_(development) (Accessed 2010-10-18) Description of User Stories from wikipedia. http://en.wikipedia.org/wiki/User_story (Accessed 2010-08-25)

85

8 Developing Large Systems in Small Steps

Ulrik Pettersson, Saab Aeronautics

This chapter is an attempt to summarize experiences, useful practices, and lessons learnt from the development of large systems. These experiences have been gained mainly from the development of telecommunication systems at Ericsson, but also from the development of avionics systems at Saab Aeronautics.

Introduction Systems such as a node in a telecommunication network and an avionics system in an aircraft differ when considering function and techniques. But the things they have in common are very typical for large systems, and may actually be the things that make large systems so tricky to develop. Large systems:

• Evolve over many years, sometimes even decades, with a new release usually once or twice a year.

• Are made up from thousands of software and hardware components that exist in many versions and variants.

• Can be configured for many purposes and environments. • May be parts of even larger systems. • Are in operation and used by several demanding and influential

customers. • Are primarily judged and valued by the presence of qualities such as

speed, capacity, robustness, safety, and availability. • Require hundreds of people for the development of a new release

In this chapter some of the experiences and practices used to build these large systems have been brought together into a development strategy named Integration Driven Development (IDD). Although IDD is intended for large systems, most of the practices are valid and can be applied also when developing systems that are not so large.

86

The General Idea

Iterations and Increments

The traditional way of developing systems, also known as the “waterfall” approach, can be roughly characterized as distributing the work to be done to various modules and components which are individually developed and tested. Toward the end of the project, these components are integrated and tested in a so called “big-bang” activity. Consequently, the system qualities can neither be seen nor guaranteed until late in the project. The commonly-agreed cure for the big-bang integrations is called “Incremental and Iterative Development”.

The single most time-consuming and difficult task when developing large systems is integrating the components developed into a complete working system. Regardless of the time spent in advance on carefully specifying interfaces and trying to predict the characteristics of the developed system, the integration will typically lead to unpleasant surprises: the time it actually takes to get the system up and running will certainly be longer than expected, the initial system behavior will not be as predicted, and the total cost for the final integration will exceed the wildest guesses.

IDD is a development strategy that focuses on early and frequent integration of small system changes to avoid the single “big-bang integration” in the end. This is certainly the general idea of all modern iterative and incremental system development strategies. What makes IDD different is that it manages to apply the paradigm of incremental development to the development of large systems. This is done by:

• Focusing the incremental development paradigm on the top system level – the complete system – and also attempting to remove as many intermediate integration levels as possible.

• Recognizing that frequently doing new increments – for example each second week – requires development to be done in parallel. Sequential incremental development – having all teams working on the same increment - doesn’t work for large systems.

• Recognizing that the management of parallel and incremental development requires careful planning, preferably based on anatomies.

The term “incremental and iterative development” is a bit confusing since both “iteration” and “increment” mean different things in different contexts. Large systems are developed iteratively and incrementally on many levels at the same time.

87

System Level “each second week”

Sub-System Level“each day”

Component Level“each hour”

Figure 8.1 Three levels of integration and iteration frequency

A large system has several integration levels at which parts of the system are integrated into larger parts which are then tested (Figure 8.1). Each integration level holds a specific test environment and a set of test methods to check the correctness of the integrated item. Furthermore, each type of item – component, subsystem, and system – can be developed iteratively with different iteration frequencies and different activities included in the iteration cycles.

In the same way, the term “increment” means different things to different people. Some say that an increment is the new version of an integrated item resulting from iteration. Others use the term increment to mean the activity needed to develop a new item version. That is, increment and iteration can mean the same thing. And still others say that the increment is the difference, in terms of functionality and characteristics, between two consecutive versions of an item.

So, most development organizations can argue that they do, and always have done, incremental and iterative development in some sense. The same organizations seldom produce new versions of working systems – at the top-most integration level – more often than twice a year. At least not when we speak about systems including thousands of components, some twenty or thirty subsystems, and hundreds of people involved in the development.

True incremental development is meant to be done at the top level of integration – the complete system level – and with IDD we strive for a new complete system version at least twice a month.

Working System Versions and Deltas

The vague terms increments and iterations are avoided when describing IDD. Instead IDD is based on the two fundamental concepts “Working System Version” and “Delta”:

88

• Working System Version (WSV) – A WSV is a complete system version that has been demonstrated to work in at least one target-like environment without any major problems.

• Delta (∆) – A delta is a system change, or more precisely, a specification of a system change, including the test cases or scenarios that must be passed to consider the change done.

The fulfillment criteria for allowing the quality stamp “working” on a WSV must be carefully defined for each system and system version. What “working” means differs among systems and organizations depending on the availability of test environments and the willingness for risk-taking. The reason for always having working system versions is to always have a stable design base for which quality is under full control: We know exactly the things that work well, and the things that don’t.

A delta specifies a system change, but also the specific quality level for the resulting WSV. Different changes require different test activities to ensure a sufficiently good WSV.

In the reminder of this chapter we will sometimes use “step” to mean the same thing as a delta, and we will say that IDD is a strategy for stepwise development of large systems. Now, Figure 8.2 shows the general idea behind IDD and the stepwise development of systems.

21 272019181716 ...

Extended Test of Characteristics

∆ ∆∆∆ ∆Design, implementation & test of changes (∆)

∆ ∆

WorkingSystemQualities

....

< 2 weeks

Working System Version

Figure 8.2: The General Idea

New working system qualities – functions and characteristics – are increasing stepwise with each new WSV, and a new WSV is produced each second week. A new WSV is the result of adding or integrating a planned system change, a delta, to the previous WSV. That’s the idea behind IDD.

The time interval between two consecutive WSVs is set by the average time it takes to integrate new and modified components with an existing WSV, do all the necessary tests and corrections to reach the quality level “working”, and then make public a new WSV. Even for large systems this can be done in less than two weeks by, for example, having very small deltas, automating the regression tests, and having less strong and

89

comprehensive criteria for “working”. However, experience shows that each second week is a tough enough goal when we are required to “know exactly what works, and what doesn’t”.

It may be worth mentioning that the ambition with a WSV is not to have it shippable to a customer, or to put it directly into operation. The large systems we deal with can normally be configured in very many ways, and a WSV says something about only one or a few of these configurations. Furthermore, the time to ensure the expected level of robustness, capacity, scalability, safety, etc. is often several months for the official releases of these systems. The WSV should, however, be good enough to be used for measuring these critical characteristics. In that way it will be possible to check characteristics in parallel with the ongoing development of new WSVs.

Integration Driven Development

Overview

Figure 8.3 is an attempt to illustrate the key aspects of the IDD strategy. The picture is centered round the stepwise development of a system. New working versions of the system are produced every second week. Each WSV is developed by a cross-functional team – named ∆-teams – which has the end-to-end responsibility for its realization.

The typical size of a ∆-team is five to ten persons, and the development time may vary from a few weeks up to several months.

90

Formal Verification

R 4.0

MergeCorrections

Formal Verification

R 3.0

21 272019181716Working System Version: ...

WorkingSystemQualities

Time

....

2 weeks

Extended Test of Characteristics

12 .... 1511

∆-team

∆-team

∆-team

∆-team

∆-team

∆∆∆

∆∆

Where&

How?

What&

Why?

When&

Who?

∆

∆∆

∆

∆

∆∆

∆∆∆

∆∆

∆

∆ Anatomy

R 4.0

R 5.0

GO

1. Work is divided into verifiable system changes

2. Teams have an end-to-end responsibility

3. Teams do verification before integration

4. Formal verification in parallel with development

✔

✔

✔

✔

Figure 8.3: Integration Driven Development Overview

The task for a ∆−team is to design, implement, and test a specified system change – a delta. As can be seen in Figure 8.3, ∆-teams must work in parallel in order to keep up the bi-weekly pace of new WSVs. To avoid a situation of having several teams working with the same software components in parallel, dependencies between deltas must be clearly understood, and the order of realization carefully planned.

Management of system development is organised around the ∆-anatomy which shows currently-planned system releases, their content in terms of deltas, and dependencies among the deltas constraining their order of realization. The management part of IDD is illustrated in the upper left corner of the picture and is divided into three continuously-ongoing activities:

• “What and Why?” – The purpose of this activity is to specify the content of system releases – official system versions delivered to customers – in terms of new functions and capabilities.

• “Where and How?” – This is about transforming the new functions and capabilities into small, verifiable system changes (deltas), and clarifying their dependencies in a ∆-anatomy. This activity includes specifying each delta in terms of affected components and interfaces, and roughly estimating the size of the delta.

• “When and Who?” – This activity means scheduling deltas in a development plan which shows their order of realization and integration. The integration order is determined by the dependencies between deltas and the availability of developers. The activity includes “kicking off” the realization of deltas by coming to an agreement with ∆-teams ready for new tasks.

91

Before a ∆-team is allowed to deliver the realization of a delta, they must make sure that their new and modified components work in a complete system version, a version based on the latest WSV. That is, ∆-teams don’t deliver components or subsystems but always new and complete system versions that have been demonstrated to work in a target-like environment. This means that once a WSV is sent to “Extended Test of Characteristics” or “Formal Verification” we don’t expect to find any trivial software faults.

Note that formal verification is not done for each WSV but only for system versions representing the realization of a complete system release (for example, WSV 19 in Figure 8.3). Faults found during formal verification are corrected immediately in a separate verification track. Needless to say, these corrections must, sooner or later, also be merged into the main development track – the WSV track.

IDD embraces four key development principles listed in the left bottom corner of Figure 8.3. In the following sections we will dig into these a little bit deeper.

Work Is Divided into Verifiable System Changes

The first development principle is: The scope for a system release is divided into small and verifiable system changes, instead of being refined in detail and distributed onto subsystems and components.

The common way of starting development work is to capture and specify the requirements stakeholders have on the system release, and then refine and allocate detailed requirements onto the subsystems and components that make up the hierarchical system structure. After that, people are asked to implement the refined requirements in the components they own.

Needs

∆

∆∆

∆

∆

∆∆

∆∆∆

∆∆

∆

∆- Anatomy

∆

Needs

Hierarchical System Structure

Figure 8.4: Needs are divided into verifiable deltas

This approach of detailing and allocating requirements down to the lowest level of components comes from the “waterfall strategy” and the belief that it is both necessary and possible to specify everything in detail before the

92

implementation can start. And, of course, this approach must lead to a big bang integration in the end. It will not be possible to test the system, not even to build a running system version, until each and every component has been correctly implemented, delivered, and integrated.

First, before we take a look at system changes and deltas, let’s be clear about requirements. In IDD we try to avoid entirely the word “requirement” since its very existence tends to generate an overwhelming “requirements management process” with no or little value. Instead, we use the word “needs” for the needs stakeholders have on the top system level. That is, needs express desired system qualities – new functions and characteristics – only visible and of interest when considering a complete system version. The rest of the information describing the things developed is called “design information”: information describing the use and construction of existing and planned system versions.

The idea behind the first development principle is to transform stakeholders’ needs into a set of system changes that we call deltas. Stepwise implementing these deltas will in the end result in a new system release fulfilling the needs of the stakeholders. The key qualities we want deltas to have are the following:

• The realization and integration of a delta must always result in a new working system version.

• The description of the delta should include an identification of new and affected components and interfaces, together with the system test scenarios which will be used to verify an acceptable realization of the delta.

• Each delta should be minimal in the sense that it can not be divided into parts which, in turn, could serve as deltas.

Regardless of the way you choose to transform the needs into deltas, there will probably be deltas that depend on each other in different ways. We use the ∆-anatomy to visualize, communicate, and keep track of these dependencies (Figure 8.5).

The ∆-anatomy differs significantly from the system anatomy described elsewhere in this book, both in terms of content and usage. The elements in a system anatomy are the system’s key capabilities, whereas the elements in a ∆-anatomy are the currently planned changes needed to obtain some new system capabilities. Another important difference is that a system anatomy is rather stable compared with a ∆-anatomy. The ∆-anatomy constantly undergoes change. New needs and insights appear, deltas will be added, removed, and redefined, and there will typically be a new ∆-anatomy every week.

93

“Verification Dependency”

“Design Dependency”

∆ ∆ ∆∆

∆∆

∆ ∆

∆ ∆∆∆

∆

∆-Anatomy

A

BC

∆∆

∆∆

∆∆

R:2

R:3

Figure 8.5: The ∆-Anatomy

Figure 8.5 shows the key elements of a ∆-anatomy: releases, deltas, and dependencies among deltas. The next release, R:2, currently contains thirteen deltas whereof four of them can be implemented and integrated independently of other deltas. The dependencies constrain the order in which the deltas can be done, and determine the possible degree of parallelism. There are two types of dependencies that should be considered and managed in a ∆-anatomy:

• “Design Dependency” – In Figure 8.5: ∆A should be completed before the design of ∆B can start. The motivation for controlling this kind of dependency is to avoid, as far as possible, parallel development of software components, and by that, avoid the costly task of merging code.

• “Verification Dependency” – In Figure 8.5: ∆B should be completed before verification of ∆C can start. This dependency indicates that design of ∆C may start before ∆B is ready, but verification of ∆C can only be done after the completion and integration of ∆B.

If you find it difficult or unnecessary to distinguish between these two dependencies you can combine them into one general dependency or relation named “should be done before”: ∆A should be done before ∆B, and ∆B should be done before ∆C.

Teams Have an End-to-End Responsibility

The second development principle is: We have cross-functional teams with an end-to-end responsibility for the realization of a new system version, instead of specialist teams delivering parts to each other.

94

True teamwork is essential in IDD. Having stable, well-functioning teams may be the single most important key to successful systems development. However, good team work requires careful staffing, training, and encouragement. It won’t happen just by assigning people a common task.

Having good teams is eased by a reasonable team size (7 ± 2 persons), co-location and team rooms, full time members, long-lived teams, and by giving teams the opportunity for making a true commitment, that is, giving them time for analysis, planning, and negotiation.

In the original IDD strategy we promote stable, long-lasting teams that can take on the realization of an arbitrary delta. In practice, for large systems, it’s never an arbitrary delta. The teams will be specialized in deltas affecting specific parts of the system. There will also be deltas that require new team constellations. This must be dealt with when planning the development and integration order.

Test Team

Trouble Reports

Design Team

Components

Design Team

Specification Team

Specifications

Plans

Manager∆

System Development Team

New System Version

∆Needed System Change

Figure 8.6: Teams have an end-to-end responsibility

Figure 8.6 illustrates the intention behind the second development principle and the formation of ∆-teams.

Large organizations tend to form teams and competences around specific development activities. There may be a “planner” who plans the work, a “specification team” specifying conceptual solutions and doing overall design, “design teams” doing detailed design and delivering components, and finally, “test teams” who integrate components, run test cases, and deliver trouble reports. The many handovers this leads to have been shown to be rather inefficient. However, the striking thing is that there is seldom a team that actually has the explicit task of delivering the new, complete and working, system version.

A ∆-team includes all the competences needed to develop a system version; for example, planning and tracking, system design, software design, hardware design, configuration management, testing, and documentation. Each member of the ∆-team has the role of “system developer” and the team has not finished its job until it has delivered a new working system version. Hence, every ∆-team is a “system development team” in a literal sense.

How the development work is done is decided by the ∆-team. IDD does not prescribe any methods or tools to be used, and teams are encouraged to

95

use whatever practices they prefer. This includes agile practices such as SCRUM and “sprints” for development planning, test-driven development, pair programming, daily build, and refactoring.

There is, however, one agile practice that needs to be applied with extra care: time boxing. In the agile development method SCRUM, teams do their work by running subsequent sprints with a fixed time length, for example, two weeks. Every second week the team delivers a result that is evaluated by stakeholders. In contrast, a ∆-team is never allowed to deliver if things don’t work as agreed, even when the scheduled delivery date will be passed. We never accept non-working WSVs. In IDD, teams practice “quality boxing” rather than time boxing.

∆Commitment

StartSystem Test Delivery

WSV

Figure 8.7: Three mandatory milestones

There are three milestones that each ∆-team must pass (Figure 8.7):

• “Commitment” – The team has reviewed and analyzed the information specifying the delta, detailed the tests and quality assurance activities that must be done before delivery, clarified how the change will be implemented, and agreed on a delivery date.

• “Start System Test” – All new and modified components have been checked as agreed upon in the “Commitment”, and the team is now ready to start formal testing activities with a system build based on the latest WSV. These test activities should not exceed the maximum time span decided upon for two consecutive WSVs (for example, two weeks). Throughout this test period there can be no new WSVs delivered from other teams.

• “Delivery” – All quality assurance activities agreed upon at “Commitment” have been carried out, faults have been corrected, and no major problems remain. The quality mark “working” can be stamped on the team’s final system version, and the team can deliver a new official WSV. Regression testing – to assure that things that worked in the previous WSV still work – is always included as a mandatory part of the system test.

The fulfillment of milestone criteria is checked by the “When & Who”-team, which plans and tracks system development (see Figure 8.3).

Before ending the discussion about ∆-teams, it may be in place to sort out a general misunderstanding about ∆-teams and their relationship to Development Management concerning the three activities What & Why, Where & How, and When & Who, found in the upper left corner in Figure

96

8.3. The team running the “Where & How” activity – specifying and maintaining the ∆-anatomy – is staffed with members from the ∆-teams. There is no such thing as a “hand over” from an “anatomy team” deciding what to do, to a ∆-team doing what’s been decided. Structuring and specifying deltas, and sorting out their dependencies, must be done by persons that fully understand how the system is constructed; that is, by system developers.

Teams Do Verification Before Integration

The third development principle is: Teams deliver complete and working system versions, instead of insufficiently-tested components with unknown effects on the system.

If we want teams to deliver components that work, we must provide them an opportunity to check those components in the context of the latest working system version. This is what the third development principle is about.

1 2 1

2

3

4

copy

copy

copy

Figure 8.8: Teams do verification before integration

The situation we want to avoid, the left part of Figure 8.8, can be described as follows. We have a working system version (Version 1) and it’s time for the three development teams to deliver their components. When integrating the components with the working system version, we get a non-working system. The non-working system is handed over to an “integration and test team” which is supposed to make the system work. At the same time, the three development teams rush on to the next increment, basing their development on the defective components that have been delivered. The “integration and test team” need corrected components, but don’t allow any other additions or modifications to the components. Hence, the development teams must keep at least two tracks for each component, and correct each fault twice. In short, we get a messy and inefficient situation.

If we instead provide each team with a complete system test environment where they, by themselves, can make sure that their components work before they are delivered and “integrated”, we reduce a lot of waste.

The key to having “verification before integration” is to forbid development directly on the WSV branch. Development work is done on

97

separate branches isolated from the WSV branch. To get this to work, you need to invest some time and money in a good software build and configuration management system. However, the general idea is straight forward, as outlined in Figure 8.9.

∆

Working SystemVersion (WSV):

Sub-SystemBranches:

Test Build:

Integration & Build

SS1

SS2

SS3

Development System Test

Figure 8.9: ∆-team with subsystem branches

For complex software configurations it can sometimes be a good idea to centralize the creation of branches and software builds to a specific team serving all ∆-teams with “Integration & Build”. However, with a fast and well-functioning build and configurations management system, it is still preferable to have the ∆-teams creating branches and builds by themselves. With many ongoing teams, quick build procedures, and many target test environments available, there will undoubtedly be a need for many builds.

Consider a ∆-team with the job of implementing a delta affecting three subsystems: SS1, SS2, and SS3 (Figure 8.9). Three development branches are created from the subsystem versions in the latest WSV, and the team starts their development. In Figure 8.9 new subsystem versions are shown as small circles on the branches. After a while there is a new WSV available. If the WSV contains a new version of any of the three subsystems, the team must do a “rebase” and merge the new subsystem version with their own latest version. This will result in a new version on the corresponding subsystem branch. The team can, of course, as often as they like and until it is time to deliver, create system builds based on the latest WSV to check how their modified components work in the current system context. When the phase “System Test” starts, the team is guaranteed that there will be no new WSVs until they deliver their own WSV.

Formal Verification in Parallel with Development

The fourth and last development principle is: We do formal verification on a specific “verification track” in parallel with continued development, instead of halting development, and use the development track for verification and corrections.

98

Developing and maintaining large systems requires, in most cases, several types of “tracks”. A track is a sequence of system versions with a specific quality or purpose which we want to, or must, separate from other sequences.

Formal Verification

R 4.0

MergeCorrections

Formal Verification

R 3.0

21 272019181716Development Track ...12 .... 1511

MergeCorrections

Verification Track

Maintenance Track

Figure 8.10: Three types of tracks

Within the IDD strategy we define and use three types of tracks as illustrated in Figure 8.10.

The “development track”, sometimes referred to as the “main track”, is the one single official sequence of system versions we use for growth of functionality and characteristics. Within the IDD strategy, the development track is the sequence of WSVs.

For large systems formal verification often implies integrating and verifying the system with other large systems and checking several possible configurations of these systems. Therefore, formal verification normally takes several months, a time period during which we need to proceed with development.

The “verification track” is used only to correct faults found in the system, or, in other words, the verification track is a sequence of system versions where we only allow growth of quality. Formal verification ends when the quality of the system is considered to be good enough for a new system release. The verification track is closed when verification ends and, at that point, the latest system version in the verification track is the new system release. What remains to be done is ensuring that all corrections made in the verification track are also made in the development track.

Each system release will result in a “maintenance track” of its own. As with the verification track, the maintenance track is only used for quality growth. The maintenance track is closed when all customers and users of that release have upgraded their system to a more recent release. The big challenge for all system providers is to keep the number of releases being maintained to a minimum. The maintenance cost for a system provider is directly related to the current number of maintenance tracks.

To complicate this picture even further, each system release may be adapted towards the needs of a specific customer. This means that every release may result in several customer-specific tracks which need to be maintained, and sometimes even evolved, independently. But that’s another story, perhaps in another book.

99

Variants

Subsystem Teams

In core IDD we have ∆-teams (Figure 8.3). ∆-teams are expected to be long-lasting, cross-functional teams that can take on the realization of any delta regardless of which subsystems and components that delta will affect. This requires the ownership of code and design to be everyone’s responsibility; that is, each ∆-team has the right and ability to do all the changes needed to implement the current delta. In terms of responsibilities, the ∆-team is similar to so-called “feature teams”, although a delta is seldom a complete system feature or capability.

For large, complex, and technical systems, clear individual ownership for each and every component is considered crucial in order to preserve the architecture and design idea over time. Moreover, components normally exist in a large number of versions and variants being maintained. Changing or correcting a component requires a deep understanding of the dependencies among these versions and variants.

Thus, for some systems and organizations, it is more common to form teams and responsibilities around components and subsystems than having general development teams that are expected to do work everywhere in the system.

Formal Verification

R 4.0

Formal Verification

R 3.0

21 272019181716Working System Version: ...

WorkingSystemQualities

Time

....

2 weeks

System Test

12 .... 1511

Team SS 6∆

Where&

How?

What&

Why?

When&

Who?

∆

∆∆

∆

∆

∆∆

∆∆∆

∆∆

∆

∆ Anatomy

R 4.0

R 5.0

Team SS 5

Team SS 4

Team SS 3

Team SS 2

Team SS 1

∆ ∆∆ ∆ ∆ ∆

1. Work is divided into verifiable system changes

2. Teams have an end-to-end responsibility

3. Teams do verification before integration

4. Formal verification in parallel with development

✔

ø✔

✔

Figure 8.11: Subsystem Teams

100

In the “Subsystem Team” variant of IDD, we replace ∆-teams with subsystem teams (ss-teams) which develop and deliver new versions of the subsystems they own (Figure 8.11).

In this variant, the second IDD principle, “Teams have an end-to-end responsibility”, is not fully applied. The ss-team is of course cross-functional (cross-discipline), but, since a delta seldom affects only one subsystem, the realization of a delta becomes a responsibility shared among several teams. Still, an ss-team always delivers a WSV, not just a “good looking” subsystem.

The second development principle is the only one you need to compromise when you choose ss-teams. For example, the third principle, “verification before integration”, is still applied. In Figure 8.11, the delta resulting in WSV 17 impacts the subsystems SS1, SS3, and SS4. Before the corresponding ss-teams can deliver their modified subsystems, they must complete a common test to show that their subsystems work together; that is, they must show that the new system version works and that the delta is properly implemented.

As discussed earlier, in most cases a ∆-team works with several software branches, one for each subsystem being changed (Figure 8.9). An ss-team will work with one and only one subsystem, but will normally need to work with several deltas in parallel (Figure 8.12).

∆1

∆3

∆5∆-Branches

for SS 1

DeliverMandatory Rebase (Merge)Recommended Rebase (Merge)

Working SystemVersion (WSV):

a b c d e f

Team SS 1

Figure 8.12: ∆-branches for a subsystem

Figure 8.12 shows how an ss-team sometimes needs to work with two deltas in parallel. This is done by creating a new subsystem branch each time the realization of a delta begins. The branching is done from the latest working subsystem version. Note that a “mandatory rebase” becomes trivial (unnecessary) if the previous “recommended rebase” is done. On the other hand, the mandatory rebase marked “e” may imply code merge if the previous recommended rebase was not done.

101

Frequent System Build

The variant “Frequent Build” can be viewed as the well-known software development concept “Daily Build” applied to a large software system; perhaps not daily, but frequently (Figure 8.13). In contrast to core IDD and the subsystem variant, this variant may be an alternative only when considering large software systems.

With Frequent Build we remove the subsystem integration level and tests are focused directly on the system level. This also means that developers and teams don’t deliver subsystems, but components. The team concept in this variant is not clearly defined. Or, more precisely, we don’t prescribe how teams should be formed. Teams may be formed around groups of components or temporarily around features; these different types of teams coexist and a developer may be a member of several teams. Moreover, you can choose to have developers doing a system test or have a specialized team for it. In short, we don’t apply the second principle, “teams have an end-to-end responsibility”.

However, the first development principle is valid and development is managed as in core IDD. The development scope is divided into deltas and the integration plan shows when deltas are expected to be integrated and ready for testing.

13 27 332625242322Working System Version: ...

VerifiedSystem

Qualities

Time

....

1 week

System Test

12 ....11

Un-VerifiedCode

Automated System Regression Test

∆

Com

pone

nt T

eam

s

∆ ∆ ∆∆ ∆∆

Check in a fault correction or a contribution to the planned ∆Check in “no harm” code(preparing for a coming ∆)

Where&

How?

What&

Why?

When&

Who?

∆

∆∆

∆

∆

∆∆

∆∆∆

∆∆

∆

∆ Anatomy

R 4.0

R 5.0

Formal Verification

R 3.0

Formal Verification

R 4.0

∆∆ ∆∆

1. Work is divided into verifiable system changes

2. Teams have an end-to-end responsibility

3. Teams do verification before integration

4. Formal verification in parallel with development

✔

øø

✔

Figure 8.13: Frequent System Build

The WSV is a baseline created weekly in the one and only code branch. Every night a complete system build is done, based on the latest “checked in” component versions, and an automated system regression test is run. The quality and coverage of the regression test determines the quality level of

102

the WSV. In the best of worlds, the regression test will check that basic functions which worked in the latest released WSV are still working (for example, WSV 12 in Figure 8.13). So, when establishing a WSV baseline we know that basic functions still work. However, a check remains to see whether the newly integrated deltas work. This is done by a System Test in Figure 8.13. Hence, the system test is done after integration with WSV and, obviously, the third development principle isn’t applied. This also means that the quality stamp “working” is weaker than in the IDD variants described earlier.

As mentioned earlier, applying the third principle, “verification before integration”, implies branching and no development directly in the WSV-branch. The main advantages with this approach are:

1 It’s possible to always have full control of the WSV content and quality. 2 It’s possible to halt the realization of a delta without the cumbersome

work of removing things from the WSV. 3 Teams have a stable, high-quality test base (the latest WSV) and are not

forced to always use the latest “checked in” code for testing activities.

In which situations can we still be motivated to consider the Frequent Build variant? The short answer is: When merging code and models is considered to be a nightmare, and you have no idea how to avoid it. Having teams working on their own development branches requires a modular system architecture, clear interfaces, and components that implement well-defined parts of the services provided by the system. If, from a total system perspective, every verifiable change requires changes to a majority of the components, then developing many changes in parallel on different branches may not be the best approach. Instead, it might be better to strive for one single development branch and avoid the risk of spending most of the development time merging versions developed in parallel.

Single Track

The third and last variant is called “Single Track”. This variant is very similar to the previous Frequent Build, with the only difference being that not even the forth IDD principle is applied. And, when only using the first development principle, it is indeed a bit difficult to argue that Single Track is an IDD variant. The reason for bringing up Single Track is that it tackles one of the most urgent issues for providers of large, evolving, multi-customer systems, namely, cutting down the number of versions maintained. One system version means one and only one version of each component, and consequently, changes and corrections are done only once.

The idea behind Single Track is to have, from a system-provider perspective, one single version of the system at every moment in time. The only existing sequence of system versions – the one single track – must serve for new system releases, maintenance releases, and for development.

103

13 27 332625242322Working System Version: ...

VerifiedSystem

Qualities

Time

....

1 week

SystemTest

12 ....11

Un-VerifiedCode

Automated System Regression Test

∆

Com

pone

nt T

eam

s

FormalVerification

FormalVerification

SystemTest

∆ ∆ ∆∆ ∆∆

Check in a fault correction or a contribution to the planned ∆Check in “no harm” code(preparing for a coming ∆)

Where&

How?

What&

Why?

When&

Who?

∆

∆∆

∆

∆

∆∆

∆∆∆

∆∆

∆

∆ Anatomy

R 4.0

R 5.0

✔ ✔ ✔

1. Work is divided into verifiable system changes

2. Teams have an end-to-end responsibility

3. Teams do verification before integration

4. Formal verification in parallel with development

✔

øø

ø

R 4.0R 3.0

Figure 8.14: Single Track

In Figure 8.14 WSV 12 and 26 are released directly to customers. There is no verification track, and no maintenance tracks for corrections on released system versions. There is one and only one development track: The WSV-track. In contrast to core IDD, the quality of the WSV varies over time. All through Formal Verification development is halted and new WSVs are used to correct faults and improve quality (WSV 24, 25, and 26 in Figure 8.14).

Throughout the development phase, which also means the system testing, the latest WSV is the only existing design and test base. Therefore, we must allow developers to check in “not ready code” used to test and prepare for coming deltas. The key task for the automated regression test is to ensure that the “not ready code” doesn’t break the system, and that everything still works as expected. The amount of “no harm code” in the WSV will vary over time, but most likely there will always be some code that doesn’t contribute to the system’s working functions and qualities.

Whether a “single track strategy” is a success or not isn’t primarily about how well the development method is established; it is about the current business model and the relationship with customers. Here are some issues that need to be sorted out before trying to establish Single Track:

• Will customers accept that maintenance releases are replaced with ordinary scheduled releases?

• Will customers accept the risk of replacing a defective version with a corrected one when the new version also includes features they haven’t asked for? What about the existence of “no harm code”?

104

• How do we ensure that customers don’t use the new features they get for free when sending them corrections included in an ordinary release?

• For how long can we guarantee backwards compatibility? What about maintenance after that? Can we “force” customers to upgrade?

Let’s end this section by concluding that IDD and Single Track are two different solutions for two different types of waste. The IDD strategy is primarily an attempt to solve the Quality Problem: We find far too many costly faults and unwanted characteristics far too late. Whereas Single Track focuses on the Track Problem: We have far too many system and component versions that we develop and maintain in parallel. The choice of strategy depends on the problem you want to solve. Neither will solve both.

Summary and Discussion Agile methods emerged as a well-justified reaction to the heavyweight development ideals promoted by formal systems engineering and the waterfall approach. As often happens with such paradigm shifts, the pendulum may swing all the way to the other end of the spectrum. Agile methods are sometimes seen as the “silver bullet” that will solve software development issues once and for all. However, with the increasing scale of projects, concerns with “agile-only” methods begin to show up. IDD might be seen as yet another step in the evolution of methods, combining careful planning with agile development. In a sense, the IDD approach is an empirical, strong-voiced answer to the issue of whether plan-driven or agile methods should be used. The answer to which is – both. With the increasing scale of system development, an element of stability in agile methods is indispensible.

A critical element in the IDD strategy is the ∆-anatomy. The anatomy construct has remained in place at Ericsson in one form or another through all the years since it was first conceived almost two decades ago. The main reason for this is undoubtedly that it visualizes the most important factors when developing complex systems: how system capabilities or changes depend on each other.

Moreover, an anatomy is consciously kept as simple as possible in order that it can be easily understood by all stakeholders. The importance of shared or common understanding cannot be overestimated. If there is no common view of the development scope, the risk of failure is high.

Concluding the chapter, the main point about IDD can be expressed as follows. If there are many agile teams working at the same time, and all teams develop parts of the same system, then it is necessary to spend time on coordinating these teams. This effort primarily involves dividing the development scope into suitable system changes, and deciding their best order of integration. Having done that, it’s possible to have many teams working in parallel, letting them apply whatever agile practices they like, and still having them stepwise develop one and the same system. Therefore,

105

combining agile development practices with plan-driven methods is not only possible, it’s probably necessary in order to improve large scale development performance.

106

How Teams Become More Motivated and Effective When Working with Anatomies

Erik Schumann, Sellegi Technologies AB

The way teams work in software and systems development projects has changed drastically during the last ten years. What once was governed by waterfall-like approaches and rigid control was first changed with the advent of iterative and incremental development methods. Later, an even bigger change happened when agile, team-centric paradigms were introduced – XP (Wikipedia) and SCRUM (Wikipedia) to name two of the more prominent examples.

From a project management and risk management perspective, this change of paradigm is often seen as a mixed blessing. On one hand, project managers welcome the increased productivity and efficiency of the ‘new methods’, as they are advertised. On the other hand, the same project managers fear losing control and giving more responsibility and autonomy to the development teams. What I often saw in the discussion around process improvements, agile development, and likewise is the desire to get the benefits, but keep control. This, however, does not work. When you want to reap the benefits, you have to pay the price; but this price is less than most people expect. The fear of losing control, according to my own experience, is often tied to a lack of information about, and understanding of, the critical parts of the system. So, when you combine the introduction of team-centric methods with anatomies, you gain a tool that can be used as information channel and help you in the identification of critical parts and risks during development. If you use this method and receive continual feedback from the development teams to other teams and management, you take care of a lot of problems.

But why should you do that? What happens in the development teams, when you give them the authority to make their own decisions according to an agreed-on schedule? Why do the planning games and anatomy workshops often bristle with energy and creativity? Why do people working in autonomous development teams, in fact, work more effectively?

In this chapter, I will give a very brief introduction what happens within teams that work team-centric and where anatomies are used. To do that, I also have to describe some requirements and prerequisites which work, according to my experience. How should the work be set up and what kind

107

of authority is needed by these teams? And, of course, the main theme of this book: how do anatomies fit into this context?

Teams There are many definitions of the terms team or workgroup available, but to explain what is meant with teams in this text, I follow a definition based on (Alderfer, 1977) and (Hackman, 1987), and expressed in (Guzzo & Marcus, 1996):

A “work group” is made up of individuals who see themselves and who are seen by others as a social entity, who are interdependent because of the tasks they perform as members of a group, who are embedded in one or more larger social systems (e.g., community, organization) and who perform tasks that affect others (such as customers or coworkers).

This definition fits very well with an intuitive understanding of team and teamwork as it is applied in software development projects, both with traditional waterfall methods and within so-called agile development, as in Scrum (Wikipedia) or Extreme Programming (Wikipedia).

Prerequisites for Successful Team-Centric Development

With this definition of team in mind, what do I mean by team-centric development? Team-centric development, as I have experienced it, is a name for development forms where the teams act as autonomous agents that include all needed competencies and faculties to produce at regular intervals working and testable parts within the scope of a project.

So, the team is • Autonomous • Has a specified authority • Has a principal who ordered the work (customer, project manager,

product manager, …) • Has all the needed competencies to perform the assigned work • Has a time plan

I want to analyze this setup and the arguments behind it even more. The reason for this setup is the understanding that added value for the

developed product is produced purely by the development team. All other functions, such as project and product management, or verification, are support functions. These support functions must enable the development team to develop an efficient product effectively and with the desired quality to satisfy customer demands. In addition, the development team is the final authority and expert regarding its own situation, needs, and capabilities.

108

Therefore, the development team must have the mandate and competence to make design decisions and prioritizations on their own, based on the frame and scope of the agreement between the team and their principals, e.g., project and product management.

This understanding explains certain prerequisites for an ideal environment for the team. The team must

• Have the possibility of being efficient and effective o Right size for the job o Right competence for the job

• Have a clear understanding of the scope and the desired outcome • Have a defined outcome which will be executable and a result that will

be measurable • Have a clear understanding of the timeframe • Have a mandate to make decisions within the scope of the agreement • Have the possibility of rejecting proposals that are impossible to fulfill

within the boundaries of the agreement (too complex, too short time, etc.)

• Needs a very clear understanding of how its own work is impacted by and dependent on the work of other teams

• Needs a very clear understanding of how its own work impacts the work of other teams

• Have a possibility of effectively communicating with principals • Have a possibility of effectively communicating with peers (other

teams)

This description of team-centric development fits the needs of teams in SCRUM, XP, and some other processes very well.

In investigating this train of thought further, I assume that we have a project setup that fulfills these prerequisites. With that in mind, I was quite surprised when I learned that this reasoning has been studied and discussed since the 1970s under the name of agency theory (Eisenhardt, 1989).

Agency Theory

Agency theory stems from the analysis of risk-sharing within groups and has been analyzed and debated since the beginning of the 70s. Agency theory describes how work is performed and risks are shared when a principal delegates a body of work to an agent. Within agency theory this delegation is described using a contract as metaphor. According to Eisenhardt, agency theory includes a number of propositions where there is a strong relationship to team-centric development and the prerequisites stated above: • When the contract […] is outcome based, the agent is more likely to

behave in the interests of the principal. For teams this emphasizes the need for a well-described outcome of

109

the results the development team shall produce. The goal is to describe the outcome as well as possible and in a way that both development team and principal understand.

• When the principal has information to verify agent behavior, the agent is more likely to behave in the interests of the principal. This means that we have to have a good flow of information from the agent to the principal, where the team provides information about what it is doing and with which results. This information flow has to be understandable for the principal as well as generating value for the producing team, since we need to transmit information on progress, risk, and changes to the agreed-upon plans.

• Outcome uncertainty is […] negatively related to outcome-based contracts. In other words: it is important to minimize the risks of change for the contract between team and principal. Once the work has started, it should not be changed, and if there is still risk of change, this part of the work might need to be delayed.

• Task programmability is […] negatively related to outcome-based contracts. This says that the less repetitive and more creative or ingenious a task is, the better an outcome-based contract will fit the situation.

• Outcome measurability is […] positively related to outcome-based contracts. This emphasizes the need for defining the work for the teams in a measurable way. If you have a hard time measuring the results, an outcome-based contract is not well-suited. Therefore, it is necessary that the outcome from the work done by the teams is executable and that its quality is measurable.

So you can see that team-centric development is a way of working described in a number of development methods used by a number of companies and projects. It establishes a number of prerequisites for the definition and autonomy of the development team which makes it possible to describe and analyze the teams’ behavior and work with the help of agency theory. Agency theory also explains some of the positive effects experienced by most who have worked with teams in this way.

Increased Motivation within Autonomous Teams

Working with autonomous teams in a setup such as that described above is, in my experience, often fun. These teams often perform very well, carry heavy loads, work hard but have fun, and display other characteristics of highly motivated people. So, in this section I want to look very briefly into the connections between autonomous teams and motivation.

Motivation, as I use the term, can be summarized as a process which influences the direction, persistence, and vigor of goal-directed behavior (Passer & Smith, 2008). Even though there is no commonly-accepted

110

definition of motivation as such, motivation can be seen as a result of a number of factors that either draw us to or repulse us from a certain observable behavior (Arnold, Cooper, & Robertson, 2005). According to Arnold et al., we can observe three distinct key factors:

• People are usually motivated to do something. • Motivation is not the only important factor for effective behavior;

prerequisites, abilities, quality of equipment, and cooperation in a workgroup are other examples.

• Motivation is abstract and cannot be observed as such; only its effect is observable.

Based on this, let me discuss what seems to motivate teams and help them work efficiently and effectively; this is something which is related to the aspects of team-centric development mentioned above. For this I turn to a thorough meta-study of research of team-performance and effectiveness in organizations (Guzzo & Marcus, 1996) where the authors review and discuss a large number of studies in this area:

• There is broad evidence of the relationship between effectiveness and the amount of self-management in the team.

• Several studies show that a high level of familiarity within the team has a positive effect on that team’s effectiveness, even though it seems as if this familiarity can have a negative impact after about two to three years.

• Group potency, defined as the group’s collective belief that it can be effective, has a positive impact on group motivation and group performance.

• There seems to be no clear evidence of a direct relationship between group goals and performance. However, some studies show a positive impact of group goals on cooperation and communication within the group.

• Groups having a decision-support system and structure are more productive and satisfied with their work because of such things as increased participation, synergy, and enhanced structure.

• Self-managing groups can be expected to be more successful in turbulent environments.

• Several studies show that substantive participation has a significant, long-lasting, positive effect on productivity while others show that it almost never has a negative effect.

Another study that focused on the performance of knowledge workers in general came to similar conclusions when it came to a team’s degree of participation, autonomy, and control over its own environment and way of working (Davenport, Thomas, & Cantrell, 2002).

Taking into account these positive aspects of self-managed teams, and thinking about the prerequisites for autonomous teams from the previous sections, it seems logical that autonomous teams display a lot of the characteristics discussed by Guzzo & Marcus. The items listed above offer

111

at least a basis for understanding why the teams working in an autonomous way seem to have fun and show signs of being highly motivated.

Autonomous Teams, Agency Theory, and Anatomies In the previous section I have elaborated on which definitions of motivation, team, and autonomous teamwork I have experienced as working very well, leading to efficient work and high quality. Coincidently, in my work many of the teams I have seen showing highly-motivated behavior and producing efficient results had one thing in common: they were working with the help of anatomies.

How efficient development is achieved using anatomies is explained in other chapters of this book, and I will not go into an explanation of this topic. You will find very good descriptions and examples in those chapters. However, I will try to explain how an anatomy can both act as an enabler for autonomous teams according to agency theory and support a motivated-team environment.

Anatomies and Autonomous Teams

I want to lift up the importance of a clear agreement and understanding of the scope of work, effective communication, and dependencies among the work performed by different teams. All of these areas can be addressed with the help of anatomies, and then the anatomy becomes the central part of communication. It is a kind of contract between the development team, its principal, and the surrounding environment. If the anatomy is experienced as a part of contract between a principal and autonomous agents, then some interesting things happen within the team. I have seen this in a number of projects and heard similar stories from other people working with anatomies as well. The team takes on more responsibility and works very hard to fulfill the agreed-upon schedule, but only if it really is committed to this schedule. It is necessary that the team acknowledge and accept the schedule. Again, this requires the opportunity of rejecting a schedule that the team deems impossible to achieve.

Anatomies and Agency Theory

Eisenhardt (Eisenhardt, 1989) formulated a number of propositions to explain the behavior and effects of agents in this context. Let us see how they connect with the anatomy:

112

• Outcome-based contracts lead to behavior in the interests of the principal. The unique aspects of the anatomy in generating a common understanding comes into place and focuses the discussion and analysis.

• When the principal has information to verify agent behavior, the agent is more likely to behave in the interest of the principal. The system anatomy has a central role as an enabler in breaking down the development of the system into testable parts, while at the same time the program anatomy can transmit information on progress, risk, and changes to the agreed-upon plans.

• Outcome uncertainty is […] negatively related to outcome-based contracts. The anatomy helps as a tool in the identification of parts of the project that are stable and where development can start. In this way the anatomy helps minimize risks of change as well as making all participants aware of elements where this risk is greater.

• Outcome measurability is […] positively related to outcome-based contracts. It is absolutely necessary that the outcome from the work done by the teams is executable and the quality is measurable. Here the anatomy helps the teams in breaking down the work into testable, executable parts to ensure measurability.

You can see how the prerequisites for work in autonomous teams are tied to anatomies, and that anatomies can play a central role for communication and contract between agents and principals.

Conclusion/Discussion Autonomous teams show a high level of motivation and effectiveness. This can be explained, in part, with the help of agency theory. Both the definition of autonomous teams and agency theory have a lot of requirements for the team environment and its way of functioning. Most importantly

• The possibility of controlling its own work • Authority within the scope of the agreement (project) • Effective communication

o Within the team o Towards the principal (project manager, product manager) o Towards other teams

• Clear understanding of the scope of the work and of its dependencies and impact on others

Anatomies, on the other hand, act as an enabler in fulfilling some of the requirements for autonomous teams and agents. In this way, anatomies can have a central role for working autonomously in a turbulent environment.

113

References Alderfer, C. (1977). Group and intergroup relations. In J. Hackman and L.

Suttle, Improving the Quality of Work Life (pp. 227-96). Pallisades, CA: Goodyear.

Arnold, J., Cooper, C., & Robertson, I. (2005). Work Psychology - Understanding Human Behaviour in the Workplace (4 ed.). Prentice Hall.

Davenport, T. H., Thomas, R. J., & Cantrell, S. (Fall 2002). The Mysterious Art and Sience of Knowledge-Worker Performance. MIT Sloan Management Review, 23-30.

Eisenhardt, K. M. (1989). Agency Theory: An Assessment and Review. Academy of Management. The Academy of Management Review, 57-74.

Guzzo, R. A., & Marcus, D. W. (1996). Teams in Organizations: Recent Research on Performance and Effectiveness. Annual Review of Psychology, 47, 307-38.

Hackman, J. (1987). The design of workteams. In J. Lorsch (Ed.), Handbook of Organizational Behaviour (pp. 315-42). Englewood Cliffs, NJ: Prentice-Hall.

Passer, M., & Smith, R. (2008). Psychology: The Science of Mind and Behaviour (3 ed.). McGraw-Hill.

Wikipedia. (n.d.). Extreme Programming. Downloaded 2010-09-01 from Wikipedia: http://en.wikipedia.org/wiki/Extreme_Programming

Wikipedia. (n.d.). Scrum (development). Downloaded 2010-09-01 from Wikipedia: http://en.wikipedia.org/wiki/Scrum_(development)

114

A Short Executives Guide to Anatomy-Based Planning

Erik Lundh, Compelcon AB

What if there was a simple down-to-earth representation of a system that all interested parties can build together in days on a wall, learning of the true nature of the challenges ahead? Anatomy-based planning will help your development even with a single team, since it, when done properly, captures certain tacit knowledge that all other vendor/technology driven methods seems to miss... You might see more dramatic benefits compared to most other methods if you have multiple teams, locations, contributors.

he problem of scale: You might have a software development effort with multiple teams, possibly on several locations. Maybe one, several or all teams has been successful with now popular methods like agile planning and development, but you can’t realize their potential when scaling up to multi-team development of complex products or systems. Each team or location seems to work well but in isolation, like a stovepipe, proud of their own

accomplishments they want to take on their own projects and bring them to market on their own. But a single highly successful, maybe agile, team can’t accomplish nearly enough to satisfy your business needs, regardless of their talent. Your organization is large, maybe disperse and each group try to look good, alas on their own.

Your opportunity: What if you could bring all these teams together and make it feasible for each of them that they can build a much larger system together without stovepipe behavior, extensive rework, and very long costly runaway projects that trash requirements and never get really stable.

Anatomies - A proven solution: Companies that is well-known for their ability to develop large complex systems and products, like Ericsson and RUAG space, have been using anatomy-based planning to bring diverse parts of their development together. Anatomy-based planning gives these

T

115

companies a way of aligning their resources. The practice of anatomy-based planning inside Ericsson since 1990 predates the agile development movement. When the methods originator Jack Järkvik gave a keynote at the international agile conference in 2006, it was all news to the agile community at large.

What is this anatomy thing? It is a map, often shaped like a tree, which leads up to the top-level capabilities that your business (your market) needs delivered. The anatomy maps out all the capabilities that need to be there behind the scenes to reach the goal of the moneymaking capabilities that you, your business, your market, needs. By focusing on needed capabilities, the anatomy describes necessities that can later be realized as software, hardware or even services. Development plans are then based on the anatomy, often in the form of project plans, system architecture, business plans for new service offerings, etc.

The anatomy practice might seem obvious, but a surprisingly large part of all systems development, complex or not, both hardware and software, lack this basic understanding on this since most tools and visualizations have grown out of a particular technology or vendor offering.

An anatomy is not a plan, but a solid logical foundation for a plan. It is an intuitive representation often created on a whiteboard to describe the necessary entities that make up a system and how they relate. The anatomy should not be used as a plan in itself; it is a way of understanding the logical structure of necessities, with relationships, that make up a system. The anatomy is a hands-on compilation of what it takes to get a system to work. It is not the same as a technical architecture, but can be related.

The collaborative creation of an anatomy is often a cross disciplinary effort that may collect a surprising amount of collectively held tacit knowledge in a very short time. The people involved discover and learn from each other.

An anatomy usually has a first necessity like “The system should power on without crashing”. Might seem obvious to you or even a little daft, but a surprising number of large systems, planned and developed with traditional or agile methods, have problems with fundamental things like this at their first full integration attempt, which too often is discovered very late in the game.

116

Figure 10.1: The team is split in two to get different perspectives that are merged later by the whole team into a single anatomy.

One or more moneymaking features are leaves of the often treelike anatomy, where opportunities to parallelize development can be discovered, but also what needs to be done in sequence to avoid extensive rework. The alternative is to develop everything with overly general interfaces that usually means a vast expansion of the development effort, especially if you consider integration and verification. Cross-functional groups often find opportunities to re-arrange the anatomy and re-think the capability definitions to further decouple and parallelize the development effort.

When a group walks through the anatomy they created, they often discover missing relationships and necessities.

Among the current successful practitioners, the anatomy of a system often serve as the base for planning, architecture and project follow up. A capability can be even be a service offering.

An anatomy can be used to follow up on progress without getting tied down in details. Do the necessities show up according to their relations much like a growing plant without skip-overs and jumps? Then your large project is on the right track!

The anatomy could and should evolve with the collective’s continuous learning on how to grow the system. The anatomy methods originator likes to put short expiration dates on each revision, short dates like on a milk package.

A few notes: Today, interest in things like agile probably has its own momentum in your organization. One of the forms of anatomy planning that connects well with the agile enthusiasm that you might want to encourage is the one day anatomy workshop with no other tools than posit-it notes, whiteboards and markers. The participants represent each team, site or contributing party. They need to be knowledgeable and experienced.

117

Recommendation: Participate yourself in the first few of these workshops, marking its importance. Being present and visible might be the single most effective move you make, regardless of the method. And anatomy-based planning is an intuitive planning process that you can easily follow regardless of your background.

Check if your people are really creating anatomies or just swinging on another buzzword: Have them explain to you, in a walkthrough fashion, the relationships of the anatomy they have developed. An anatomy that can be clearly explained and related to a plan that makes sense, in the time you can afford to listen, is a good sign, especially if several people seem to fill in for each other to help explain and take turns without obvious rehearsal.

118

Anatomies in Requirements, Processes and Research1

Kristian Sandahl, Linköping University

Andreas Borg, Ericsson AB

Pär Carlshamre, Innovationsbron AB

The purpose of this chapter is to extend the use of system anatomies to other types of systems of importance in product development: requirements and processes. We will also attempt to foresee how anatomies might develop in future to facilitate understanding of both function and quality. The common denominator of our experience and research findings is the use of anatomies as a natural way of supporting human understanding by visualising dependencies, even when the input data of the anatoms and dependencies is preliminary and incomplete. We have, furthermore, found anatomies to be a useful tool for solving so-called wicked problems (Rittel & Webber, 1984). A wicked problem has no perfect solution, is based on incomplete information, and requires human expertise and trial-and-error to find an appropriate solution. The goal is not an optimal solution, but one that is good enough.

Requirements

Release Planning

At the most abstract level, release planning is about scheduling the fulfilment of requirements for specific releases of a certain product to maximize customer value while minimizing development resources. In this situation, many different circumstances have to be taken into account. For instance, a top priority requirement might need a lower prioritised requirement to be implemented first. The latter requirement might require a specialist programmer who is only available on specific dates. Dependencies between requirements increase the complexity of the

1 The authors wish to thank Mikael Patel at Ericsson AB for a long period of coopeation and engaging discussion.

119

planning problem. We have conducted several studies (Carlshamre et al. 2001; Carlshamre, 2002) in order to understand how to support release planning, taking these dependencies into account.

The first step in release planning is to make some kind of prioritization of requirements. In our case studies we let Requirements Managers select twenty of their top-ranked requirements from out of several hundred.

Secondly, we used a spread-sheet for the Requirements Managers to obtain the dependencies between requirements. Five types of dependencies were judged to be sufficient for our trial persons:

1 None 2 R1 AND R2 – R1 requires R2 to function; R2 requires R1 to function.

For instance, a device requires a driver to function, and a driver requires a device to function.

3 R1 REQUIRES R2 – R1 requires R2 to function; but not vice versa. For instance, sending an e-mail requires a network connection, but not vice versa.

4 R1 CVALUE R2 – R1 affects the value of R2 for a customer. The value can be positive or negative. For instance, a detailed on-line manual may increase the customer value of a product, but decrease the value of a printed manual.

5 R1 ICOST R2 – R1 affects the cost of implementing R2. The value can be positive or negative. For instance, a requirement “no response time shall be longer than one second”, will typically increase the cost of implementing many other requirements.

In addition to the values and relations, the Requirement Managers were also asked to rate how certain they were on a three-grade scale. Typically the collection of this data took about four hours for twenty requirements. This information was used to generate an anatomy with these top requirements as anatoms and their relations as dependencies, as shown in Figure 11.1.

120

Figure 11.1 Dependencies between requirements in an industrial case study. The colours of the arrows show positive (red) and negative (green) value impacts for ICOST and CVALUE.

The Requirements Managers now inspect the picture and use reordering and pen and paper to identify cohesive sets of requirements for the different releases to come. In successful planning the customers get some positive value in each release. It is of special importance to find the highly dependent requirements, such as requirement number 2 in Figure 1.1. It might become necessary to place requirement number 2 in a release where not all directly dependent requirements fit. In that case, the Requirements Manger has rather to minimize the loss instead of finding an optimal solution. Using the picture, the Requirements Manager can also easily identify singular requirements with no dependencies, such as requirement number 17. It is quite straight-forward to place these requirements in whatever release they fit.

The complete release planning also involves requirements of lower priority and resource planning; our method provides a valuable seed for the planning.

Our approach was evaluated by Requirements Managers of five different companies, all of whom corroborated our idea of supporting their manual planning work by visualizing dependencies (Carlshamre et al., 2001). We must remember that the Requirements Managers are experts at their tasks and appreciate our method as a way to organizing their own expertise to provide a sufficiently good solution to the release planning problem. It is not certain that a person with less experience will be able to accomplish the planning, given a picture of dependencies.

121

The alternative would have been to use a graph partition algorithm to generate an optimal solution, but this would have been a brittle technique requiring very exact data that would take far longer to obtain.

A prerequisite for this to work is that the requirements involved are well-formulated and understood.

11.1.2 Non-Functional Requirements

The anatomies described so far are functionally oriented. However, competition also requires attention to non-functional requirements. These requirements are roughly divided into quality requirements and design constraints. Non-functional requirements introduce two other kinds of dependencies among the capabilities of a product: first, there are dependencies between non-functional requirements and functional capabilities; and, second, there are often complicated dependencies among the non-functional requirements themselves. In this sub-section, we will focus on the latter dependencies and present the NFR Framework – the most cited approach for graphically depicting this as support for decision makers (Chung et. al. 1999).

The NFR Framework is a goal-oriented method that is based on the decomposition of the most general, but still the most important, non-functional requirements. In Figure 11.2 we illustrate the refinement and investigation of the dependency between security and capacity using so-called Softgoal Interdependency Graphs for an automated teller machine.

Fiugre 11.2 A sample Softgoal Interdependency Graph for an automated teller machine

122

The term “Softgoal” denotes a specific, non-functional goal and is used to point out that such a goal has no clear-cut criteria for determining whether it is satisfied or not. Chung and his co-workers coined the term “satisfice” to indicate that a goal is sufficiently satisfied.

In the Softgoal Interdependency Graph the decomposition goes all the way from the initial softgoals to design decisions and implementation suggestions. The latter are called “operationalizations” and are drawn with thicker lines in Figure 11.2. The overall Softgoals displayed in the Softgoal Interdependency Graph are capacity and security. The former is shown in detail in Figure 11.2 and has been decomposed into Softgoals “space” and “response time”. The “angle” notation indicates an AND dependency, which means that both Softgoals need to be satisficed to make the above Softgoal satisficed. Two operationalizations have been suggested in order to implement the response time Softgoal: using uncompressed format and use indexing. Both operationalizations contribute positively to the Softgoal, which is denoted with the “+” sign. However, using uncompressed format has a negative impact on the space Softgoal. Moreover, an operationalization from the security part of the Softgoal Interdependency Graph (which is not shown in Figure 11.2) contributes negatively to response time. These are shown with “-” signs on the arrows.

In the book by Chung et al. (1999), there is a plethora of specialized notation, but at this point we leave behind the anatomy idea that builds on fairly simple diagrams which enable a common understanding among stakeholders. We would rather call the full implementation of all notation a Goal-Oriented model, with an emphasis on refinement into detailed solutions that might be valuable later in the development phase. Playing the role of an anatomy, a Softgoal Interdependency Graph works in parallel with a system anatomy and is used to monitor the fulfilment of the Softgoals and the trade-offs that are necessary to make. There are many practical activities contributing to the realization of a Softgoal, making it necessary to have a trusted way of collecting and measuring data.

Users of methods and tools based on the NFR Framework appreciate the support for remembering relationships when making solutions, and that it is possible to build libraries of standard decompositions of common sub-goals (Andreopoulos, 2004). As is typical for wicked problems, the practical solution to the Softgoal fulfilment problem will depend on negotiations and human creativity; the graph offers support and a way to create common understanding.

11.2 Process Improvement The development process of a product is also a complicated system with several steps that can be seen as the capabilities of the process. Among the various challenges for a Process Engineer we specifically note: 1 Process steps can be described at various levels of abstraction. On the

lowest level, there are complex detailed flowcharts that are too specific

123

for general reasoning. On a higher level, it is possible to achieve a common, general understanding, but then we must be aware that we have neglected some possible dependencies, just as we did with the requirements in the first section of this chapter.

2 One of the cornerstones of software engineering is that process improvements are an important means of achieving quality goals. The wicked part of this problem is that changing a process means changing not only the order of the working steps, but an entire socio-technical system, with many success factors and barriers. Niazi et al. (2005) is one of many documented industrial case studies on this.

In 2006 we initiated an interview series among different practitioners from various business units at Ericsson concerning their successful practice in developing high capacity in telecommunication networks. The findings were interesting but proved to be hard to communicate until we realized the power of an anatomy, a concept that had been used earlier for process improvements at Ericsson. This section will guide the reader through our “journey” with partial successes with different notations on different levels of abstraction.

The results from the interviews were possible to condense into nineteen Capacity Sub-Processes that are critical for the successful improvement of capacity requirements, design, and validation. The Capacity Sub-Processes were organised in a CMM-like maturity model with three levels:

• Capacity Sub-Processes that were frequently deployed in almost all organisations visited.

• Capacity Sub-Processes that were only used in some organisations. • Capacity Sub-Processes that were not in everyday use, but were

suggested by experts. In our first attempt, we created a two-dimensional table divided into

major areas; within each area we listed the Capacity Sub-Processes in order of increasing advancement. This table was verified with some of the interviewees, but proved difficult to explain to other people unless it was accompanied by a full research paper (Borg et al., 2006).

To adapt the results for more practical and widespread use, the Capacity Sub-Processes were concretized and a plug-in in the Eclipse Process Framework was developed. The plug-in can be used to configure the OpenUP process with roles, activities, and artefacts that are needed in the development of high-capacity systems (Borg et al., 2007).

The plug-in served us well to check that we had a coherent picture of all concrete activities. In addition, we could deliver the plug-in together with other specialized tools for product development. However, the real-life fact is that it is too expensive to deploy an entire process in one step. Instead, you need specialized guidance of the ordering of improvements in the processes. This is where we, after having explored several other diagramming techniques (e.g., Sandahl et al., 2007), found the anatomy concept to be useful. Without a clear understanding of the meaning of the anatoms, the anatomy will not fulfil its goal as a solid support.

124

Inspired by earlier work on process anatomies we created the following picture of the Capacity Sub-Processes:

Figure 11.3 An anatomy of Capacity Engineering (ACE); the arrows can be read “contributes to”

The anatomy should be read bottom-up. An arrow in the figure generally means “contributes to”. The anatomy states that VER1 (“Capacity requirements defined, communicated, and understood”) naturally precedes capacity improvement. However, it could, of course, be the case that organizations practice other Capacity Sub-Processes even though VER1 is not fulfilled.

The anatomy shows the possible paths to achieving the more advanced Capacity Sub-Processes dealing with UML models annotated with quality requirements, and measurement-informed improvement of capacity. To aid the process engineer, it is useful to have a method for selecting the right improvement step to take next (Patel et al., 2007). The initial two steps of the method have been tried out in the case studies described in (Sandahl et al., 2007), whereas steps 3 and 4 are only initial suggestions that have not yet been evaluated. The proposed steps of ACE are: • Assess current existence/coverage of the Capacity Sub-Processes with

respect to process descriptions or actual development. So far, we have only made assessments based on process descriptions and a three-grade

125

scale, but assessments based on real practice and more fine-grained scales are, of course, also possible.

• Fill each box of the anatomy with a colour that represents the grade that the Capacity Sub-Process in scope has been assigned in the context. Figure 11.4 shows the assessments from one of the industrial case studies. Green represents grade 3 (Capacity Sub-Process fully covered), yellow represents grade 2 (Capacity Sub-Process partly covered), and red is used to visualize grade 1 (Capacity Sub-Process not covered).

• Areas of improvement can be identified from the anatomy by visual inspection. The borders between grades are of special interest and one such border, between grade 1 and grade 2, is represented by the dotted line in Figure 11.4. It shows that SPEC3, TUN3, TUN6, TUN2, VER4, and EST1 are primary candidates to address if the main target is raising the ability from grade 1 to grade 2.

• Construct improvement plan. It is often the case that not all improvement candidates can be addressed. We suggest that the anatomy can aid in prioritization and that Capacity Sub-Processes that are important for supporting other Capacity Sub-Processes and/or blocking the possibility of moving “higher” should be prioritized. In our example, this should result in EST1 and VER4 as top candidates for improvement, which we also believe is congruent with intuition when considering the shape of the dotted line. An option would be to also add TUN2 and SPEC3.

Fig 11.4 A colored process anatomy. Green areas are implemented fully, yellow partially, and red ones are not yet implemented. The dotted lines show the approximate borders between levels. The Figures 1, 2, and 3 represent the actual choices of our case study.

126

This method has been evaluated in five case studies, whereof three are from an industrial setting at Ericsson. To check the transferability of the results to outside of Ericsson, we conducted a focus group with four engineers from the defence and avionics company SAAB, all involved in the development of the combat aircraft Gripen. The results showed that the method in general, and the anatomy particular, are transferable to the context of avionics, both from a general perspective and from the specific perspective of the Gripen aircraft. However, we found that a clearer description of anatomy semantics will help practitioners to understand the anatomy concept and stay focused on capacity assessment and improvement. We also recieved suggestions on how a few Capacity Sub-Processes could be merged and split to improve the anatomy (Borg 2009).

11.3 The Future

11.3.1 Three-Dimensional Anatomies

We have seen the proficiency of anatomies in many practical and research situations, but what will the future hold? Of course we hope that this book will lead to a more widespread use of anatomies to increase predictability in system development projects. The art of creating useful anatomies will probably be improved as more experience is gained from more people discussing their experience in different fora. Here we will take a brief look at what you might do with an anatomy itself considered as a graph to be used in system development. The goal is to stimulate the reader’s thinking rather than to present full-fledged solutions.

The first idea to ponder is the use of three-dimensional anatomies. To introduce an analogy, consider the following two pictures of a glucose molecule:

127

Figure 11.5 (left) A two-dimensional structure diagram of a glucose molecule (source Wikimedia commons, user Rob Hooft)

Figure 11.6 (right) A drawing of a three-dimensional model of a glucose molecule (source Wikimedia commons, user Klaas1978)

The leftmost Figure 11.5 corresponds to our notion of an anatomy, and the rightmost to a three-diemenstional representation. The question is: What do we gain by moving into three dimensions? In this example, Figure 11.5 gives a clear idea of the individual atoms and how they are integrated; interfaces (bonds) between the atoms are also visible. In the rightmost Figure 11.6 we can represent more complex connections (for instance, the ring of carbon atoms), and we can use size and colour to represent different properties. In a system development situation this could denote estimated effort, or the physical location of the organisation developing a part of the system. This is possible because of the added degree of freedom for making a good layout of the dependencies. This approach might seem interesting, but it will come with the cost of the need for a tool when it is viewed. This makes it harder, but not impossible, to spread information via whiteboards and posters available in the offices of the developers. The reason that chemical engineers like the three-dimensional model is that their main interests are:

• The possibility of reactions with other molecules, something that is very much determined by the spatial location of different atoms. Developers of software-intensive systems are interested in the logics of the external interfaces of the system, but not from a spatial point of view; it is sufficient if they are visible, such as those shown in Figure 11.5.

• Chemical engineers are interested in determining the possibility of breaking a molecule into sub-structures, whereas system engineers are

128

more interested in bringing the capabilities together, once the anatoms are defined. An exception is the release planning problem described in 11.1.1, where substructures were sought.

We probably need more ubiquitous media before the three-dimensional anatomies become standard, but we can see the value of some projections for facilitating a focus on different factors while developing and integrating a system. In this chapter we are intrigued by the relationships between a functional capabilities anatomy and a non-functional one, such as the NFR Framework. Consider Figure 11.7 which illustrates the principles from these perspectives.

Fig 11.7 A projection of a Softgoal Interdependency Graph and a product anatomy

In Figure 11.7 we show a functional system anatomy (squared anatoms) and a Softgoal Interdependency Graph. It is not a full three-dimensional anatomy, but it uses the human ability to interpret three-dimensional structures from a two-dimensional drawing. The hypothesis is that only one

129

or two different pictures of this kind are necessary in order to intuitively comprehend the entire structure of the idea of maintaining both a system anatomy and a Softgoal Interdependency Graph, as put forward in Section 11.1.2.

In Figure 11.7 we have opened for highlighting the most important dependencies between the functional anatoms and the Softgoals. Developers can use this information for:

• Distributing Softgoals to anatoms to make sure that quality is also budgeted and tested.

• Making sure that if an anatom is removed, the Softgoal is not forgotten. This has happened in real life (Borg 2003).

• Showing where in the anatomy conflicting Softgoals can be reconciled.

• Showing “sweet spots” in the anatomy where only a single Softgoal is involved and the integration of anatoms is about assuring the right level of quality instead of making trade-offs.

Of course, there are quality attributes affecting almost all anatoms which make the graph blurry, but it can nonetheless be a good idea to point out where in the integration different qualities can be tested.

11.3.2 Weaving Information

Another future development is to keep the two-dimensional representation, but to use software tools to create a diagram revealing some more information. If we keep the example of dependencies between the functional and non-functional anatomies, we can, for instance, generate an anatomy that looks like the one in Figure 11.8.

130

Figure 11.8 An anatomy annotated with quality factors and strength. Most important conflicts are marked with red arrows indicating relative severity.

In Figure 11.8 we have annotated the anatoms with quality factors qn and the relative strength of the dependency between the quality factor and the anatom. Consider the anatom in the upper left corner. The quality factor is q5 and the number four indicates on a scale from one to five that there is a quite strong dependency. This means that in realizing that anatom we have to put a quite high emphasis on the design and testing of q5. Suppose that q2 and q5, representing, for instance, security and efficiency, are in conflict; we have then indicated the conflict and its strength among the most dependent anatoms with a red arrow. Some anatoms have two quality factors that are not in direct conflict, but need to be realized simultaneously. The only conflicts can be conflicts about development and testing resources.

This can conveniently project information into the anatomy in two-dimensional space, but in real life the relationships might become complicated and simplicity would be lost. In that case, we might consider another approach, one less exact, but perhaps sufficient for a human interpreter of the picture.

In Figure 11.9 we let the horizontal dimension denote three different areas by rearranging the layout horizontally:

• Conflict area, where we collect anatoms with conflicting quality factors.

• Sweet spot, where we do not have strong dependencies to quality factors, or when we only need to focus on a single quality factor.

131

• Multiple quality area, where we do not have to trade off conflicts, but still have the responsibility of fealing with several quality factors at the same time.

Figure 11.9 A rearrangement of the anatomy in Figure 11.0 where the horizontal position indicates whether the anatoms have a potential conflict among non-functional requirements.

We might also use colour coding to denote strength; in the figure we only distinguished between areas.

To make the figure even simpler, we can consider removing the annotation and also the marking of the different areas. Perhaps it is sufficient to realize that conflicts might appear more often to the left and multiple considerations to the right. The balance between exactness and simplicity is hard to determine without cognitive experiments, but practical experience from anatomies speaks for the advantages of simplicity.

Regardless of the correctness of these ideas for future development of anatomy tools, we are certain that there will be interesting developments in the use and representation of anatomies as the concept begins to spread outside its origins in software-intensive industry.

11.4 Concluding Remarks In this chapter we have exemplified a number of situations in system development: release planning, trade-off among conflicting non-functional requirements, and selection of areas for process improvements. All three

132

more or less conform to the properties of so-called wicked problems as defined by Rittel & Webber (1984):

• Wicked problems have no stopping rule. For instance, when is the process improved enough?

• Wicked problems have better or worse solutions, but no optimal ones. • Every wicked problem is essentially unique. For instance, in a process

improvement situation, the organisation, the motivation and education of the personnel and the maturity of the product vary. This means that the opportunities for the different improvement steps will also vary.

• There is no immediate test for the successful solutions of wicked problems. In all three examples it takes at least one iteration before we can see anything of the result. In fact, wicked problems by their nature require iterative methods.

• Wicked problems have no given alternative solutions. For instance, in a complicated web of different quality requirements, it is seldom as easy to lower the fulfilment of a single softgoal in order to raise the fulfilment of its conflicting softgoals.

There is no definitive formulation of a wicked problem. Defining the problem is the same as defining the solution. This is where the anatomy comes in: it provides a model of how the problem can be formulated and visualised. If the anatomy is fairly simple, but at the same time captures the most salient parts of the problem, the anatomy creates a common understanding of the problem among teams of creative and experienced people capable of working under time constraints with incomplete information. Under these circumstances, the “system of humans” can use an anatomy to find a path towards a solution, and also to monitor their progress towards a solution. The world just became a little bit less wicked.

References Andreopoulos, B. (2004). Achieving Software Quality Using the NFR

Framework: Maintainability and Performance. Proceedings of the 3rd International Conference on Computer Science, Software Engineering, Information Technology, e-Business, and Applications. Special Session on Object-oriented software engineering, Cairo, Egypt, December 27-29 2004.

Borg, A., Patel, M. & Sandahl, K. (2007). Integrating an Improvement Model of Handling Capacity Requirements with OpenUP/Basic Process. Proceedings of the International Working Conference on Requirements Engineering: Foundations for Software Quality (REFSQ’07). Trondheim, Norway, 11-12 June 2007, 341-54.

Borg, A. (2009). Processes and Models for Capacity Requirements in Telecommunication Systems. Linköping Studies in Science and Technology. (PhD thesis).

133

Borg, A., Yong, A., Carlshamre, P. & Sandahl, K. (2003). The Bad Conscience of Requirements Engineering: An Investigation in Real-World Treatment of Non-Functional Requirements. Proceedings of the Third Conference on Software Engineering Research and Practice in Sweden. Lund, Sweden, 23-24 October 2003, 1–8.

Borg, A., Patel, M. & Sandahl, K. (2006). Good Practice and Improvement Model of Handling Capacity Requirements of Large Telecommunication Systems. Proceedings of the 14th IEEE International Requirements Engineering Conference. Minneapolis/St. Paul, Minnesota, USA, 11-15 September 2006, 245-50.

Borg, A., Patel, M. & Sandahl, K. (2007). Integrating an Improvement Model of Handling Capacity Requirements with OpenUP/Basic Process. Proceedings of the International Working Conference on Requirements Engineering: Foundations for Software Quality (REFSQ’07). Trondheim, Norway, 11-12 June 2007, 341-54.

Carlshamre, P., Sandahl, K., Lindvall, M., Regnell, B. & Natt och Dag, J. (2001). An industrial survey of requirements interdependencies in software product release planning. Proceedings Fifth IEEE International Symposium on Requirements Engineering. Toronto, Ont., Canada, 27-31 August 2001, 84–91.

Carlshamre, P. (2002). Release Planning in Market-Driven Software Product Development: Provoking an Understanding. Requirements Engineering, 7(3), 139-151.

Chung, L., Nixon, B.A., Yu. E. & Mylopoulos, J. (1999). Non-Functional Requirements in Software Engineering. Springer.

Niazi, M., Wilson, D. & Zowghi, D. (2005). A maturity model for the implementation of software process improvement: an empirical study. Journal of Systems and Software, 7(2), 155-72.

Patel, M., Borg, A. & Sandahl, K. (2007). A Case Study in Assessing and Improving Capacity Using an Anatomy of Good Practice. Proceedings of The 6th Joint Meeting of the European Software Engineering Conference and the ACM SIGSOFT Symposium on the Foundations of Software Engineering. Dubrovnik, Croatia, 3-7 September 2007, 509-12.

Rittel, H. & Webber, M. (1984). Planning problems are wicked problems. In N. Cross (Ed.), Developments in Design Methodology (pp. 135-44). Wiley.

Sandahl, K., Patel, M. & Borg, A. (2007). A Method for Assessing and Improving Processes for Capacity in Telecommunication Systems. Proceedings of the Seventh Conference on Software Engineering Research and Practice in Sweden. Göteborg, Sweden, 24-25 October 2007.

134

Why is the System Anatomy Useful in System Development?

Lars Taxén, Linköping University

Joakim Lilliesköld, The Royal Institute of Technology

Images such as Gantt, WBS, PERT, and CPM have always played important roles in project management. In recent years, new types of images, such as the system anatomy, have emerged in complex development projects. The purpose of this chapter is to investigate why alternative images seem to be more useful than the traditional ones in turbulent and complex circumstances. In conclusion, we find that the alternative images are focused on integration activities and critical dependencies in the project. Typically, they emphasize common understanding and comprehensibility over formalism and rigor. In addition, these alternative images seem to be resonant with how our cognitive apparatus conceives coordination, thus making them more apt for managing complex development tasks.1

Introduction Projects are most often described in terms of plans, resources, tools, organizations, etc. In essence, project management (PM) is about enabling all these things to jointly contribute to the project objectives within given financial and time limits. Today, organizations are facing ever-increasing complexity and turbulence. One way to manage this situation is to use images for coordination and communication; images such as Gantt charts, PERT (Program Evaluation and Review Technique) / CPM (Critical Path Method) charts, WBS (Work Breakdown Structure). These “traditional” images were developed many years ago, and are still useful in many cases. However, it has been reported that they can become almost unmanageable in projects with many changes (Maylor, 2002; Milosevic, 2003).

1 This chapter is a revised version of the paper Taxén, L., & Lilliesköld, J. (2008). Images as action instruments in complex projects, International Journal of Project Management, 26(5), 527-36. Reprinted with permission from Elsevier.

135

The system anatomy and its related images are examples of alternative images that have been found useful in practice for managing complex system development tasks. The purpose of this chapter is to investigate which qualities these alternative images have, and why traditional images appear to be insufficient in complex circumstances. As a theoretical “screening grid” for the investigation, we will utilize a particular framework called the Activity Domain Theory (ADT). This theory emerged in the telecom practice at Ericsson, a world-wide supplier of telecommunication products, as a way to understand the coordination of extraordinary complex development projects (Taxén, 2009).

The chapter is outlined as follows. First, we briefly describe traditional and alternative images. Thereafter, we provide a short overview of the ADT, the “search light” by which we then investigate these images. In conclusion, we find that the alternative images are means for managing integration activities and critical dependencies in a project. Typically, they emphasize common understanding and comprehensibility over formalism and rigor. In addition, the alternative images seem to be resonant with how our cognitive apparatus conceives of acting in a coordinated way. For this reason, alternative images might be better suited to managing complex development tasks than traditional ones. We suggest that future research into the management of complex projects needs to take these findings into account.

Traditional Images The dominant methods and images (WBS, Gantt, PERT, and CPM) for planning a project were developed in the late 1950s. These images show graphically the sequence of, and the relationships among, the individual work tasks required for the completion of a project.

The Work Breakdown Structure

A WBS is often performed as the first step in the planning process. It is a deliverable, oriented grouping of project elements that organize and define the total scope of the project (work not included in the WBS is outside of the scope). By breaking the work down into smaller elements, it is believed that risks and uncertainties will be reduced, since each level provides a greater probability that every activity will be accounted for. In its graphic format, it is obvious why the WBS is often described as a project family tree, hierarchically displaying interim and end project deliverables (see Figure 12.1):

136

Make new RNC

Make preliminary market analysis

Make preliminary manufacturing

study

Develop preliminary

product design

Evaluate and select best

product design

Develop detailed manufacturing

plan

Create the advertisement

Write work descriptions for

the roles

Market

Plan a sales campaign

Design

Publish the ad in some technical

press

Chose candidates for

interviews

Production

Train the sales team on the new

product

Interview some of the candidates

Create a sales team

Interview 1 Evaluate result from interviewsInterview 2 Interview n

Send invitation for interview n

Prepare interview n

Perform interview n

Document interview n

Create feedback on interview n

Level 1 - Scope

Level 2 - Project

Level 3 - Task

Level 4 - Subtask

Level 5 - Work package

Level 6 – Level of effort

……. …….. ……... …….

Figure 12.1: A WBS diagram

Although a variety of WBS forms exist, the most common, according to Kerzner (2001), is a six-level indented structure. The top three levels are called the Managerial levels: 1) Total Program/Project, 2) Project/Subproject, and 3) Task. The three lower levels are referred to as Technical levels: 4) Subtask, 5) Work Package, and 6) Level of Effort. Project managers normally manage and provide status reports for the top three levels (ibid.).

Gantt

Even though this is the oldest formal scheduling tool, it is still widely used. The Gantt chart uses bars to represent activities or tasks (see Figure 12.2). It shows when the project and the activities start and end against a horizontal

137

timescale. The chart is a useful tool for planning and scheduling projects, as well as for monitoring the progress of a project.

ID TASK Start Endjul 2007

30 1 2 3 4 5 6 7 8 9 10 11 12 13

1 2007-07-022007-07-02Make preliminary market analysis

2 2007-07-062007-07-02Make preliminary manufacturing study

3 2007-07-092007-07-03Develop preliminary product design

4 2007-07-092007-07-09Evaluate and select best product design

5 2007-07-122007-07-10Develop detailed manufacturing plan

6 2007-07-132007-07-12ETC

Figure 12.2: A typical Gantt chart

Network Diagrams

A network diagram represents project activities as nodes or arrows, determining which of them are critical in their impact on project completion. CPM is one of the more common network diagram techniques for analyzing, planning, and scheduling projects. CPM is similar to another common network diagram technique called PERT (see the example in Figure 12.3). The difference is that activity duration estimation is deterministic in CPM, while PERT uses a weighted average to calculate the expected time of activity duration.

Figure 12.3: A PERT diagram

A driving force behind developing a network diagram is its usefulness in highlighting interdependencies among activities. Initially, this was also the major discrepancy between Gantt charts and network diagrams. This divergence has, however, disappeared over time, since Gantt charts have incorporated inter-activity dependencies. Just like the Gantt chart, all major

138

PM software tools provide CPM/PERT chart notations. And just as with Gantt, CPM/PERT charts exist in several versions, allowing for different modeling possibilities.

Except for the layout, the main difference between CPM and the Gantt chart is that CPM states time relatively. Moreover, tasks are equipped with information pertaining not only to duration, but also with early and late start and finish (relative) times. Furthermore, slack time, i.e., the time span of independency, is expressed for every task. Slack time, in turn, facilitates the identification of the project’s critical path.

Alternative Images The alternative images we are interested in here are the system anatomy, the organic integration plan, and the development plan. The “system anatomy” is the same as described in Chapter 2. The “organic integration plan” and the “development plan” represent images related to the system anatomy, the purposes of which are described in the following.

The first image (see Figure 12.4) is an example of a system anatomy. The purpose of the anatomy is to illustrate the common understanding among system experts about how the system works of in terms of capabilities and their dependencies (and independencies). Critical capabilities can be easily recognized, such as the encircled capability “Start-up” in Figure 12.4.

139

MIP Support for No Stop Copy (20)

IPNA Start (30, 33)

MIP I-test for IPNA (30, 33)

IPNA Load from AP (30, 33)

CP Reload from IPNA (30, 33)

MIP for Capacity (33)

OCS over IPNA (30, 33)

Communication buffer CPS-SW (20)

Start-Up, Single CP (33)

MAS (SW) Increase of MIP Program store (30, 33)

APS Support for Communication buffer (20, 30, 33)

MIP for SFC (33)

IPU HW for SFC (33)

IPNA Error handling (30, 33)

MAS Fault handling SFC (HW) (33)

MIP I-test for SFC (33)

MAS fault handling capacity (SW) (33)

Communication buffer (Restart) (30, 33)

CPT Initiate reload(30, 33)

Create Initial dump (33)

Initial load (33)

MIP I-test for Capacity (33)

IPU HW for Capacity (33)

MAS (SW) 100 Mbit Ethernet termination in 212 30

APG 40

No Stop Copy (20, 30)

FCSUC with new FURAX interface (20, 30, 33)

Parallel Start (33)

De-Compress dump in CP (20, 30, 33)

Compress dump in I/O (IO 20, 30, 40)

DSU HW (30, 33)

SYREI, Initiated reload (30, 33)

SFC SW (33)

LA for SFC (SW) (33)

SFC APS (33)

Serial RP bus at FC (20, 30, 33)

MAS CPT for capacity (33)

Increase number of blocks to 4K (SW) (30, 33)

MAS fault handling SFC (SW) (33)

MAS Fault handling capacity (HW) (33)

CPS Kernel (SW) (33)

Loading functions (SW) (33)

AXE Parameter CPS-SW (20, 30, 33)

Test/Measurement (SW) (33)

AXE Parameter APS (20, 30, 33)

Backup in 212 33

AXE Parameter DBS-SW (20, 30, 33)

RPG3

Projekt koord, typ STAMPRPS???

Compiler APS (20, 30, 33)

MAS (SW) Pre-loading of static data

Axfconv, edit EMRP loadfiles (20, 30, 33)

Anatomy of GAP11.0 forAPZ-P7 project, 990907, PA2Mikael Klasson

20=APZ 212 20 & APZ 212 2530=APZ 212 3033=APZ 212 33

Figure 12.4: The system anatomy of a processor

The second image, the organic integration plan, illustrates the grouping of capabilities into suitable integration and verification packages (see Figure 12.5). These packages correspond roughly to the work packages (Level 5 in Figure 12.1) in a traditional WBS. As can be seen, the anatomy is a prerequisite for doing the organic integration plan.

140

MIP Support for No Stop Copy (20)

IPNA Start (30, 33)

MIP I-test for IPNA (30, 33)

IPNA Load from AP (30, 33)

CP Reload from IPNA (30, 33)

MIP for Capacity (33)

OCS over IPNA (30, 33)

Communication buffer CPS-SW (20)

Start-Up, Single CP (33)

MAS (SW) Increase of MIP Program store (30, 33)

APS Support for Communication buffer (20, 30, 33)

MIP for SFC (33)

IPU HW for SFC (33)

IPNA Error handling (30, 33)

MAS Fault handling SFC (HW) (33)

MIP I-test for SFC (33)

MAS fault handling capacity (SW) (33)

Communication buffer (Restart) (30, 33)

CPT Initiate reload(30, 33)

Create Initial dump (33)

Initial load (33)

MIP I-test for Capacity (33)

IPU HW for Capacity (33)

MAS (SW) 100 Mbit Ethernet termination in 212 30

APG 40

No Stop Copy (20, 30)

FCSUC with new FURAX interface (20, 30, 33)

Parallel Start (33)

De-Compress dump in CP (20, 30, 33)

Compress dump in I/O (IO 20, 30, 40)

DSU HW (30, 33)

SYREI, Initiated reload (30, 33)

SFC SW (33)

LA for SFC (SW) (33)

SFC APS (33)

Serial RP bus at FC (20, 30, 33)

MAS CPT for capacity (33)

Increase number of blocks to 4K (SW) (30, 33)

MAS fault handling SFC (SW) (33)

MAS Fault handling capacity (HW)(33)

CPS Kernel (SW) (33)

Loading functions (SW) (33)

AXE Parameter CPS-SW (20, 30, 33)

Test/Measurement (SW) (33)

AXE Parameter APS (20, 30, 33)

Backup in 212 33

AXE Parameter DBS-SW (20, 30, 33)

RPG3

Projekt koord, typ STAMPRPS???

Compiler APS (20, 30, 33)

MAS (SW) Pre-loading of static data

Axfconv, edit EMRP loadfiles (20, 30, 33)

Organic Integration Planfor APZ-P7 project, 990907, PA2Mikael Klasson

20=APZ 212 20 & APZ 212 2530=APZ 212 3033=APZ 212 33

Figure 12.5: An organic integration plan for the development of a processor

When defining the organic integration plan, design and testing are parallelized as much as possible. The plan describes in what order work packages need to be completed to ensure smooth progress. The structure of the plan is determined by a number of circumstances such as the system architecture, available resources, customer feedback, complexity of functions, geographical proximity between resources, joint functions testing, and so on.

The system anatomy and the organic integration plan are the main images used to manage the project. Sometimes, however, a third type of image called the development plan has been used (see Figure 12.6). In this image, which resembles network diagrams such as PERT or CPM, the focus is on what is delivered when, and from whom. When the development plan is created, resources are assigned and dates for deliveries of the increments settled. For each work package, traditional time and resource plans are made as well. The development plan also clarifies the receiver of each internal delivery. Thus, it focuses on the dependencies between subprojects. In Figure 12.6, such a plan for the processor is shown. It can be seen that this plan is a ‘tilted’ variant of the organic integration plan, where the timing aspects are emphasized.

141

No Stop Copy(20, 30)

MAS (SW) 100 MbitEthernet termination in 212 30

CP Reload fromIPNA (30,33)

MIP I-test for IPNA (30,33)

IPN

IPN

CS-P7

IPN

IPNTerminatorHW

TerminatorHW

TerminatorSW

RPS

CS-P7

TerminatorHW

CS-P7

IPU HW forCapacity (33)

Create Initial dump(33)

MIP for Capacity(33)

TerminatorHW

DSU HW(30, 33)

De-Compressdump in CP (21)(30, 33)

TerminatorSW MAS (SW) Increase of MIP

Program store (30, 33)

TerminatorSW

CS-P7

Start-UpSingle CP (33)

TerminatorHW

TerminatorSW

TerminatorSW

IPN?

CPS Kernel (SW)(33)

CS-P7

CS-P7

CS-P7

APS

APS

CS-P7RPS

AXE ParameterCPS-SW (20, 30,33)

FCSUC with newFURAX interface(20, 30, 33)

MAS Faulthandlingcapacity(HW)(33)

TerminatorSW

Increase number of blocks to 4K (SW)(30, 33)

Communication buffer CPS-SW(20)

Parallel Start(33)

TerminatorHW

TerminatorHW

TerminatorSW

MIP I-test forSPC (33)

MIP for SFC(33)

MAS Faulthandling SFC(SW) (33)

SFC SW (33)

TerminatorSW

APS

CS-P7?

Time

Figure 12.6: A development plan for the processor project

The dependencies in the development plan between subprojects clearly show the impact of a delay in the project, since all the internal deliveries are in some way related to the delivery of the final system to the customer. Thus, the plan provides the project with early warnings of delays and gives the project manager ample time to take corrective actions. On the surface, the development plan appears to be similar to a CPM-diagram. However, the development plan and the CPM-diagram are derived in completely different ways.

The Activity Domain Theory – A Theoretical “Search Light” When trying to understand complex situations, there is a need for some kind of framework or perspective from which relevant things can be distinguished out of the myriad of details that otherwise stand out as an incomprehensible mess. Such “search lights” are called, by a more sophisticated name, “theories”. In this chapter, we will use a specific theory called the Activity Domain Theory (Taxén, 2009). The central concept in

142

this theory is the activity domain, which simply is a convenient name for capturing fundamental aspects of how humans coordinate their actions.

In order to illustrate the activity domain, we may use the mammoth hunt scenario in Figure 12.7:

Figure 12.7: Illustration of an activity domain (Bryant & Gay, 1883. Original wood engraving by E. Bayard).

When looking at this scene some things immediately come to mind. The mammoth is clearly the object in focus for actions. There are also several perceivable motives for the hunt, the primary one presumably being obtaining food. Related motives may be obtaining material for clothing, making arrowheads, and the like. Together, the object and the motive form a point of gravity around which everything else revolves: hunters, bows, arrows, actions, shouts, gestures, and so on. Moreover, it is obvious that the hunters have to act in a coordinated way; if every hunter attacked the mammoth one at a time, the result would be disastrous.

In order for hunters to coordinate their actions, certain capabilities are needed. To begin with, there must be a common understanding about the context around the mammoth. This context frames the relevance of individual actions. For example, it can be seen in the background of the illustration that some hunters, the beaters, have started a fire and are making noise to scare the quarry away. The mammoth escapes in a direction where other hunters wait to circumvent the quarry and kill it. However, it is only in the light of the activity domain as a whole that the beaters’ actions of scaring the quarry away make sense.

Second, a common sense of what things are relevant in the context must be developed. This enables the actors to orient themselves in the same way that a map does. For example, the river is probably relevant since it hinders

143

the mammoth from escaping in that direction. On the other hand, the fish in the river are certainly irrelevant in this activity domain (they are of course relevant in a fishing activity domain).

Third, when the hunt starts, individual actions must be carried out in a certain order that enables the actors to synchronize their actions. For example, the hunters must be in place before the beaters start making noise, the archers must shoot their arrows at a certain command, and so on.

Fourth, the archers cannot shoot their arrows in any manner they like. If they shoot in the wrong direction, other hunters may be hit rather than the mammoth. Gradually, after many successful and less successful mammoth hunts, a common understanding about how to achieve appropriate mammoth hunting will evolve. This provides a common understanding of the “taken for granted”: rules and norms indicating proper patterns of action that need not be questioned as long as they work.

Fifth, activity domains are not isolated. The brought-down quarry will be cut into pieces and prepared for eating. This is done in a cooking activity, which in turn has its own particular motivation (to still hunger) and object (which happens to be the same as that for the hunting activity: the mammoth). Other related activities might be manufacturing weapons and weapon parts from the bones and the tusks of the mammoth. So, when several activity domains interact, certain issues must be resolved in the transition between activities, such as how to share the quarry among hunters and cooks, or deciding how many ready-made arrowheads will be returned for a certain amount of food. Thus, there must be a common understanding about how to coordinate different activity domains.

These five aspects of coordinating actions are called activity modalities, and represent inherent predispositions for acting in the world. The term “activity modalities” is deliberately coined to connote with sensory modalities such as vision, hearing, touch, taste, smell, etc. Thus, the way we experience the world through our senses is transformed by our brains into an activity modality percept that enables acting as individuals and together with others (Taxén, n.d.).

In summary, the activity domain is characterized by the following aspects:

• The actions in the domain are motivated by some need, and directed towards an object.

• The object and motive impel the formation of a context in which actions make sense (contextualization).

• Actions require a spatial comprehension of the context (spatialization). • Actions are carried out in a certain order (temporalization) • Actions require rules, norms, etc. that express which actions are valid in

the domain (stabilization) • Specialization of actions according to different motives and objects

brings about a need to coordinate domains (transition)

An inherent part of an activity domain is that actions are always mediated by tools or means. The hunters make use of bows and arrows, the beaters

144

use some kind of tools to make a fire, the assault on the mammoth is most certainly coordinated by gestures and shouts, and so on. The individual actors must, of course, learn how to use such means, both tools and specific mammoth-hunting terms, in order to become resources in the mammoth hunting activity.

Discussion In this section we will use the theoretical “search lights” provided by the ADT to investigate the properties of traditional and alternative images. We begin with the traditional ones.

Traditional Images

The primary purpose of traditional images is to control planned actions and, in addition, to optimize time and effort. These images were not devised to support tasks such as creating a common understanding of the work, supporting the project’s alignment of itself with moving targets and emerging, fuzzy goals, and making decisions regarding changes. Such actions were to be done by one or a few key persons responsible for the work.

A first observation of traditional images is that none of them provide a clear and coherent view of the system to be developed. The focus is on activities. The system being developed is visible only indirectly as texts in the boxes, for example, “Develop manufacturing plan” and “Develop preliminary product design”. Nor are the dependencies between system elements shown. Such dependencies, which indeed constrain freedom in laying out the order of activities, must thus be kept implicit in the minds of the main actors. It’s like a mammoth hunting “project”, in which the hunters would see only vague fragments of the mammoth like the tail, the tusks, the trunk, and so on, without ever catching a view of the entire mammoth. In particular, vital dependencies might remain concealed in a project, something that quite naturally may have severe consequences.

Next, in both Gantt and network diagrams, there is a strong temporal emphasis, as is indicated by the horizontal time axis. Therefore, temporalization modality is dominant in these diagrams. Concerning WBS images, these appear to display several activity modalities in one image (see Figure 12.1). At the very top, the object of the activity is given: “Make new RNC”. At Level 2, the boxes seem to signify contexts of work division: “Market”, “Design”, and “Production”. These contexts can be seen as activity domains. However, there is no indication of how these domains depend on each other. At Levels 3 to 5 there are clear indications of a sequences of activities; that is, a temporal dimension.

Therefore, from an activity modality point of view, several modalities are, so to speak, compressed into the same two-dimensional WBS image. This

145

makes WBS images hard to apprehend for the human intellect. In more complex situations, this may severely aggravate the achievement of common understanding about a project.

The inclusion of activity dependencies in Gantt diagrams is one indication of increased attention of the importance of dependencies; this is still done, however, within only one modality: temporalization. In addition, several other drawbacks of traditional images have been reported. Network plans look convoluted and perplexing to first-time users. Even though they have a strong temporal character, most network diagrams do not have a time-scale, and appear timeless to the untrained eye.

With respect to changes, Gantt chart and network plans easily become too complex. In fact, it has been reported that updating and maintaining network plans and Gantt charts can be overwhelming for very dynamic projects (Kerzner, 2001; Maylor, 2002; Milosevic, 2003). If the diagrams become larger than one page, they are not useful for communication or discussions. The diagrams are good for static environments, but less useful during constantly-changing circumstances.

In summary, it seems that traditional images either show one modality at a time or squeeze several modalities into the same image, without indicating how these modalities are related to each other. This aggravates the task of forming a coherent perception that makes coordinated actions possible. If the modalities do indeed reflect inherent, cognitive predispositions for acting in the world, then traditional images are weak at mediating such actions.

Alternative Images

The most striking observation about alternative images is that they start from a comprehensible view of the work object in the shape of a system anatomy. Even if everybody does not agree on all the details, there is no doubt about what the target of a project looks like. In a metaphorical sense, the “prey has come out of the fog” so to speak.

Moreover, each image appears to be aligned with a dominant activity modality. The system anatomy has a spatial structure since only static dependencies between capabilities in the system are shown. The organic integration plan shows the dependencies among work packages / activity domains. Hence, in the organic integration plan the transition modality is in focus, visible where the domains interact (see Figure 12.8). This kind of information is absent in a WBS diagram.

146

Figure 12.8: Dependencies between activity domains

The development plan has an obvious temporal characteristic since there is a horizontal time axis in the image. Finally, the three images are related to each other through the anatomy. Thus, the dependencies between modalities are clearly seen.

Summary

In summary, we can state the following:

• The system anatomy provides a clear picture of the system to be developed, regardless of whether the capabilities are ultimately implemented in software, hardware, or any other way, for example, by human intervention. In contrast, in traditional images the system is visible only in a fragmented and diffused way.

• Traditional images are focused on optimization and control rather than action and coordination, while alternative images are focused on dependencies and integrations, emphasizing comprehensibility and informality over formality and rigor.

• Both the WBS and the organic integration plan use the “work package” as the unit for planning and monitoring projects. The purpose is to arrive at a reliable estimation of the work effort and to assign suitable units of work that may be distributed to project teams. However, the ways in which the work packages are derived are quite different. The organic integration plan is based on dependencies among capabilities in the system to be developed. This is lacking in the traditional WBS diagram.

147

• The alternative images each addresses / emphasizes a particular activity modality. Therefore, they must be seen as complementing each other; using just one of them would not make sense.

• A conspicuous difference between traditional and alternative images is that traditional images seem to “compress” different modalities into a single image. However, since these are shown in the same image, it can be expected that the “cognitive load” of making sense of these images increases with increasing complexity. The alternative images, on the other hand, appear to “decompress” the modalities in such a way that each image displays a dominant modality without losing interdependencies with other modalities. It is as if alternative images are more aligned with the modalities than are traditional ones. This would indicate that the alternative images are more resonant with our innate predispositions for acting in the world.

An extensive inventory of the PM literature by Pollack (2007) indicates that there is a shift in PM from a “hard” paradigm to a “soft” one. The hard paradigm denotes a focus on stability, predefined goals, control, reductionist techniques, and the project manager as the “expert”. Up to now this has been the paradigm prevalent in PM. However, more and more evidence is being gathered that points toward the conclusion that the hard paradigm cannot cope with turbulent environments, unstable conditions, moving targets, learning ‘on-the-spot’, and so on.

The alternative images resonate well with a “soft” paradigm. They are used as tools for anticipating possible actions and foreseeing the consequences of these actions. The system anatomy is, in fact, the central coordinating instrument in enormously complex projects. This action aspect of traditional images is much less evident.

An indication of how to approach a softer paradigm is given by the ability of the alternative images to cater to what might be called “federative control” or self-organizing teams, which allow the total project manager to coordinate only what is necessary. At Ericsson, where the anatomy concept has been used, it has been possible to move from a traditional PM approach to a more self-organized approach (Taxén, 2006). Therefore, alternative images may provide one set of instruments for advancing the shift from the hard paradigm to the soft one.

Conclusions We have investigated the striking observation that extremely complex projects are coordinated and monitored using, in principle, very simple images. In dynamic environments, there is a need to focus on common understanding and dependencies. Images are one way to achieve this. However, it appears that traditional images are not adequate for this purpose. The system anatomy and its related images, the organic integration plan and the development plan, are quite distinct from the traditional ones.

148

The main reason for their usability in complex situations appears to be that they are better aligned with our innate predispositions for coordinating actions.

References Bryant, W. C., & Gay, S. H. (1883). A Popular History of the United

States. Vol. I, New York: Charles Scribner’s Sons. Kerzner, H. (2001). Project Management: A Systems Approach to Planning,

Scheduling, and Controlling. 7th ed., New York: John Wiley & Sons. Maylor, H. (2002). Project Management. 3rd ed., London: Prentice Hall. Milosevic, D. (2003). Project Management ToolBox – Tools and

Techniques for the Practicing Project Manager. Hoboken, NJ: John Wiley and Sons.

Pollack, J. (2007). The Changing Paradigms of Project Management. International Journal of Project Management, 25, 266-74.

Taxén, L. (2006). An Integration Centric Approach for the Coordination of Distributed Software Development Projects. Information and Software Technology, 48(9), 767-80.

Taxén, L., & Lilliesköld, J. (2008). Images as Action Instruments in Complex Projects, International Journal of Project Management, 26(5), 527-36.

Taxén, L. (2009). Using Activity Domain Theory for Managing Complex Systems. Information Science Reference. Hershey, PA: Information Science Reference (IGI Global).

Taxén, L. (n.d.). Modeling the Intellect from a Coordination Perspective. In B. Igelnik (ed.), Computational Modeling and Simulation of Intellect: Current State and Future Perspectives. Hershey, PA: IGI Global.

149

Where do ideas come from?

Erik Lundh, Compelcon AB

Notes from conversations with Jack Järkvik

In the spring of 1990 Ericsson reviewed the ongoing GSM projects, the first to deliver GSM network equipment other than lab prototypes, to make sure they would deliver on time, which was July first 1991. It turned out that the base station project was in trouble. The review estimated that it would not be completed on time unless substantial changes were initiated. One of the actions was to invite Jack Järkvik, then an outside consultant, to help rescue the project. Jack was well

known by several Ericsson managers, having previously worked at Ericsson for more than twelve years.

Growing experience Jack grew up in Trollhättan, where his father worked at the development department of what now is known as Saab Automobile, the car maker with origins in Saab Group, the maker of fighter airplanes. Saabs car development department was a tight operation where all hands helped with testing and Jacks father usually came home with test cars that had parts under development, which malfunctioned accordingly. During work hours people had different tasks but outside work they were all doing testing by driving test cars to go shopping, traveling to their summer houses etc. They all experienced the results of development not by reading test reports but by daily driving.

It might very well be that Saab had lean product development practices before Toyota. Toyota started with what now is called lean production after World War II in the form of Toyota Production System, TPS. Saab had a similar approach in the way the design department was run since the start in 1947. The Saab design philosophy that was in many parts similar to Taichi

150

Ono’s (father of TPS). People involved in design always tried and tinkered with cars that embodied their new ideas. While Toyota implemented their philosophy in production, it took many years to spread that thinking to other Toyota functions, like design. While Saab was designing with a ‘Toyota mindset ‘, they had not been able to translate that into production practices. It is not until recent years that Saab has been able to implement a lean (Toyota-like) philosophy in production. Saab often developed new technologies ahead of the competition and showcased it in prototypes and custom-built rally cars, but other car makers too often were able to beat Saab in making mass-produced cars with the same new technologies.

Jacks father initially worked with design of manufacturing tools, later with engine testing. Even later he moved into quality supervision and project management. Jack remembers many years later, when Jack himself worked as a project manager, that his father reflected felt that he had not been that good at project management in general but he knew a lot about cars. Like most if not all design people at Saab, he lived and breathed cars, not methods. A new department manager was judged on whether he had the skills to perform well on the test track. Not a competition, just a sign of whether the new manager was really into cars that performed well under various conditions. A manager that just viewed cars as transportation containers on wheels had a hard time earning their respect.

Most of what we here consider being Saabs best development practices was not there by clever design. The Saab development department was very small compared with the car makers in Detroit, Germany and Japan. Even Volvo had a lot more people in development. The Saab people did not necessarily work cross-functionally with design and test because they knew better than the rest of the industry; they did it because they had to, because they were so few.

That the families had to endure long weekend trips with prototype cars that broke down more often than not, was deemed necessary to meet deadlines, not a futuristic precursor to the Japanese “genchi genbutsu” (“go and see”) made famous by Toyota. Constraints paired with vision and a real hope of accomplishment drives innovation and self-organization.

It took Jack some years to fully appreciate the value of being a youth listening in on the challenges not only in actual design of a technology crossover product such as a car, but also in designing generations of

151

products that appeal to end customers while driving a global business on multiple markets at an industrial scale.

These days Jack also observes that Saab was honing the skill of keeping things that worked and do stepwise refinements of the concept still releasing it as new car models. The first 20+ years, Saab created a series of models around the same base concept of the aerodynamic frameless self-supporting steel body that had the lowest drag in the car industry when it was first introduced in 1950. Note that the first prototype Saab car 92001 had been shown to the public already in 1947. Saab was pioneering platform thinking long before it was a buzzword in several industries. But it was not a “design for reuse” approach. It was a ‘best of breed/keep the good parts’ approach to design reuse. Things got standardized across several model generations by virtue, not by initial big upfront design. Saab thus avoided creating costly over-generalized ‘Swiss army knife’ components and concepts that was a risky investment, hard to fully verify. No designer at Saab was dedicated to developing platforms or components.

Jack reflects that he has yet to see any large company that is good at truly new products, or greenfield projects. Most large businesses fail utterly at totally new things, recover (or pick up someone else’s failure) and occasionally turn the failure into a success.

Jack studied mechanical engineering in Trollhättan, went on to study electrical engineering at Chalmers Institute of Technology as well as business administration at Gothenburg University 1970-1975. (Ten years later he got the opportunity to get an MSc in the Management of Technology at the Sloan School of Management, MIT).

After getting his MSc degree in 1975, Jack tried and failed at two different careers, before coming to Ericsson as a development engineer.

Jack was hired by Ericsson in 1979 as a software designer. He got to work with development of AXE Remote Subscriber Stage (RSS) a satellite system to the centralized AXE telephone exchange system.

He quickly became interested in how to set up and run the development projects, or what we usually call methods. However, instead of moving into working with methods full-time he was made responsible for running critical development projects. To be successful, he introduced several new approaches. One such approach was the ‘design/redesign’ approach instead of the common ‘design followed by testing’ approach. Jack's idea was that after design comes testing, where the difficult part is not running the test cases but correcting all the faults found correctly. The issue is that there are always requirement faults, system design faults, coding faults and test case faults. The different fault types have to be dealt with differently. Managing the correction of all the different faults was one of Jack's improvements.

152

An important experience In the later 1980s, Jack was a project manager for hire at a then large Swedish consultancy house. He was brought in by a Swedish defense contractor to help a series of naval combat control system projects that were in bad shape. In fact, some of the systems due to be installed on new corvette class flagships that were in production for several naval forces in Scandinavia, was unstable to the degree that they often crashed as soon as they were switched on. (Or when someone touched one of the trackballs, a pointing device much like a mouse used in many military systems.) The new billion SEK ships were utterly dependent on the rescue of the projects, being no more than floating displays of utter software failure without functioning combat control systems.

Jack's approach was the following: At the time, no ships would be used in war efforts. The development effort had to refocus to solidify the most basic capabilities of the system, rather than trying to juggle on a unicycle well before learning to walk. When Jack took part in system testing very often system start took a long time and often the system crashed as soon as the operator started interacting with the system. Based on the order in which weaknesses would appear, Jack introduced the Järkvik capability levels. Based on this scheme people started to focus more on making sure the system started properly every time and less on being able to shoot down many approaching aircraft at the same time.

The Järkvik capability levels were not the same as the anatomy but logically they had a lot in common with the anatomy. The anatomy described hierarchies of single or multiple dependent capabilities instead of just levels, and thus was a step-wise refinement of the Järkvik model of capability levels.

Jack came back to Ericson as a consultant and facilitated the creation of the very first anatomy at Ericsson, when certain critical GSM radio base station projects had been suffering for some time. The anatomy approach was born out of necessity, not by design, to fulfill Ericsson’s promises to their pioneering customers on the GSM technology. Enabling cross-functional teamwork was a nice benefit, but Ericsson needed a feasible plan not another method. The very first anatomy went through several iterations before it was good enough to base a plan on, with days in between for people to investigate and get back to the anatomy drawing board. It was not until later Jack and his people got enough experience with the dynamics to

153

be able to guide people to do an anatomy for a complex project (such as a mobile radio base station) in days and later in just a day.

Jack then came up with several other pieces that helped solve puzzling complex systems development: Like the organic integration plan based on the system anatomy that came as a natural next step.

154

Contributors

Christer Bengtsson, Director of Swedsoft – an industry initiative formed to strengthen Swedish competitiveness with regards to research and development of software intensive systems. Members include ABB, Ericsson, Saab Group and AB Volvo along with all the major Swedish universities and research institutes. Christer has over fifteen years of experience of sales, marketing and entrepreneurship mainly within the embedded software space and earned his master’s degree in electrical engineering from the Royal Institute of Technology, KTH. (homepage: www.swedsoft.se)

Andreas Borg combines experience from small-scale and large-scale systems development. He started his professional career as a programmer at Focal Point AB in 2000. His interest in requirements engineering and software quality led to PhD studies at Linköping University, where he defended his dissertation 2009. Andreas's work on non-functional requirements and process improvements involved the anatomy concept thanks to a fruitful collaboration with Ericsson AB, and he performed some of this work as a consultant in the company. Andreas currently work as a system engineer at Ericsson AB in Linköping.

Erik Blom, after graduating from Linköping University, worked for about ten years with system coordination and project management in large development projects. After that, the last ten years have been focused on methodology and quality management. Erik’s previous assignments include organizations of different sizes, such as Ericsson, Andrew and NasdaqOMX. He is currently employed by FindOut Technologies AB, a company specialized in helping development organizations improve, where he works as a consultant in the areas of product development methodology and quality management.

Pär Carlshamre started his career as one of the pioneers in software usability engineering in the early 1990's. He then worked with research, development and deployment of software development methodology at Ericsson Research for almost a decade. His research efforts spans from usability-oriented design to software product release planning. Pär holds a PhD in Requirements Management.

Helena Gällerdal Högfeldt has 10 years experience working in a large scale system development environment mainly at Ericsson. Helena started in the area of usability and introduced these ideas in the general process

155

framework for Ericsson. Helena continued in the process and methods area and supported different organizations within Ericsson in adapting their ways of working to be more efficient. In 2004 the interests in the anatomies started to grow within Ericsson. Helena belonged to a central R&D team supporting these ideas and worked to spread this practice globally at Ericsson. Today Helena work as a line manager in a design unit at Ericsson, driving ideas of working in efficient teams based upon agile practices.

Inga-Lill Holmqvist has more than 25 years experience in system development for large, integrated systems, mainly in the telecommunication and defense industry. Inga-Lill has been directly involved in development in different roles such as designer, tester and as system responsible. She has also been working in various leadership roles spanning phases from product management, project management to system verification. All the time Inga-Lill has been very interested in how to work efficiently. The last 11 years she has focused on helping different large-scale organizations with new ways of working to improve R&D Efficiency. In this work, the use of anatomies has been one method to help projects to manage dependencies and gradually integrate system capabilities in a structured way.

Erik Lundh has more than 25 years’ experience in software development. Erik has worked with mature innovation firms and start-ups, from small to large organizations such as Ericsson and ABB. Erik programmed industrial just-in-time (Lean) systems in the 1980’s, was a “process and management guy” in the 1990’s, and has spent the fun part of the 2000’s as an agile evangelist and coach. In 2006 Erik was invited to Ericsson’s first major agile transformation of 2300 R&D people at 10 sites in 5 countries. Agile techniques married well with large scale low-fi techniques like anatomy-based planning and flow-based development, turning the R&D unit into one of the best within Ericsson.

Jack Järkvik started 1975 in the telecom business by accepting an employment position at Ericsson. He has seventeen years of employment at Ericsson, and an additional eleven years working for Ericsson as an independent consultant. His educational background is mechanical and electrical engineering (Chalmers), economy (Gothenburg University) and Management of Technology (Sloan School of Management, MIT). He is well known for saving numerous development projects in Ericsson, giving him the informal title "project doctor". He created and introduced the concepts ANATOMY, ORGANIC INTEGRATION, LAGOMISING AND SYSTEMAKUT, now household concepts not only in Ericsson. Jack has contributed to some published documents in the area of project management, and is now active as an independent consultant.

Ulrik Pettersson has worked 20 years in the systems and software engineering business taking on various roles such as software developer, system designer and project manager. For ten years Ulrik worked at Ericsson with the forming and establishment of Ericsson’s system development strategies. Ulrik is now managing a unit at Saab Aeronautics

156

responsible for strategies, methods and tools used to develop safety-critical avionic systems.

Joakim Lilliesköld is assistant professor at the Royal Institute of Technology (KTH). During the last 12 years, he has studied complex system development projects in many different settings. His thesis, "Managing Complex Industrial Projects - A Comparison Between Holistic Models" was based on best practice models found in Swedish industry, of which the Anatomy concept was one approach. Joakim also has a strong interest in education, and has many years of experience teaching project management. He has authored and co-authoring several books. Today, he is the Director of Undergraduate Studies at the School of Electrical Engineering at the Royal Institute of Technology (KTH).

Joakim Pilborg has more than 15 years of experience from developing embedded systems for telecom, cars, trucks, space and defense. His career started within Ericsson in the beginning of the 90's where he worked with all parts of the development chain like systems engineering, software development, systems integration, systems verification and field support. The last 10 years Joakim has worked as a consultant primarily supporting line managers, project managers and key-persons within different companies when it comes to making improvement projects in the area of processes, methods and tools really work. Integration-driven development using anatomies is one of Joakim’s key competences and the last couple of years, Joakim has also been engaged in leading roles in several projects where model-based development has been introduced in large organizations both in the telecom industry and in the automotive industry. Since 1997, as a consultant, Joakim has supported more than 20 projects within Ericsson, Saab Ericsson Space and Ericsson Microwave Systems to introduce and start using anatomies and visual integration plans.

Kristian Sandahl is a true enthusiast in knowledge transfer between Industry and University. Since that start of his career in the early 80’ies he worked as researcher, teacher and consultant with knowledge-based systems. After his PhD in 1992 at Linköping University he has continuously moved the focus to methods of large-scale software engineering, with an emphasis on processes, software quality and requirements engineering. During the years 1995-2001 he worked for Ericsson research and was a part-time visiting professor at Linköping University. Since 2001 he is a full professor in Software Engineering at Linköping University and adjunct researcher at St Anna IT Research Institute. The leading star for Kristian Sandahl’s research has been on applications and empirical investigations and he has had a broad range of collaboration partners, especially in biomedical and telecommunication industry.

Erik Schumann is an experienced change manager and project management specialist. He has worked with software process improvements, operational efficiency, personal and organizational change in large, technology-oriented companies since more than 15 years. Erik has a

157

track record in introducing customer optimized modeling solutions and process improvements in international multisite projects. He has coached executive managers and key personnel, developed improvement strategies and led improvement programs on both small and large scales. He has worked with market leaders in the field of telecoms, automotive, road machinery and transportation. Since 2010 Erik is the managing director of Sellegi Technologies, a small and highly specialized company which provides modeling solutions for large scale system and project modeling.

Lars Taxén, associate professor, has more than 30 years of experience from the Ericsson telecom industry, where he has held several positions as line manager, project manager and technical expert related to processes and information systems. Between 1995 and 2003 he was responsible for implementing a PLM (Product Lifecycle Management) system supporting projects developing the 3rd generation of mobile systems. The experiences from this work lay the ground for his thesis in 2003, which concerns the coordination of large, globally distributed development projects with focus on the interplay between ‘soft’ issues like sense-making and IT-technology. Lars is the originator of the Activity Domain Theory, which is rooted both in the Ericsson practice and theoretical research. He has written a book, several book chapters, and published in various conference proceedings and journals. Now, Lars is active as a researcher and consultant (homepage: www.neana.se)

158

The situation is all too well-known: the number of spectacular development failures in, for example, large software projects remains at an alarmingly high level. In spite of frantic ongoing efforts to come up with new methods and tools to support such tasks, there seems to be no radical improvement in sight. While the complexity of systems increases at an ever-accelerating pace, our human, innate cognitive capabilities to manage such development tasks remain the same as in historical times.

This book takes an alternative approach to the development of complex systems. Technology, methods and tools are still important, but human-centric aspects like common understanding, coordination, visualization, and reduction of complexity, need to be brought to the forefront.

The core of the alternative approach is the system anatomy, a means that was invented in the early 1990s by Jack Järkvik when he was asked by Ericsson, a world-wide supplier of telecommunication products, to help with a challenging and important project that was in trouble. The system anatomy is a simple but powerful image showing the dependencies among capabilities in a system, from the most basic to “money-making” ones, thereby representing a novel way of describing and discussing what a system is. The system anatomy has since that time been used extensively at Ericsson for managing extremely complex system development tasks.

The book is a collection of chapters from authors who, in one way or another, have been working with the anatomy concept. The intended audience is both practitioners facing complex development tasks, and researchers who are interested in exploring new perspectives and theoretical frameworks for managing complexity in areas such as information system development, organizational sciences, project management, and more.

159