The Context of Software Development

For real estate, the motto is “Location, location, location.” For software process, it should be “context, context, context.” In my rant paper Voyage in the Agile Memeplex in ACM Queue, I stressed the absolute necessity to put our processes in context. But “what is this “context” you keep referring to, Philippe?”, many people asked, “what is this context made up from?”. It is very unfortunate that too many advocates of agile development practice are preaching good practices, but completely removed from the context in which they were proven to be successful. It turns some of their followers, several levels of transmission down to become just blind bigots, sometimes rabid bigots (again see my paper for this phenomenon and the down side of decontextualization).

I provided some elements of response in my XP 2008 Keynote speech in Limerick. The short answer is in figure 1.

fig.1-the 8 context attributes (project level)

There are 2 sets of factors that make up the context, which can be partitioned roughly in 2 sets: factors that apply at the level of whole organization/company, and factors that apply at the level of  the project. In small organizations, with few software development projects, this distinction does not apply, and all factors are on the same level.

The organization-level factors (environment conditions) do influence heavily the project-level factors, which in turn should drive the process and practices used.

fig.2-Drivers

Project-level context attributes (or context factors?)

1. Size

The overall size of the system under development is by far the greatest factor, as it will drive in turn the size of the team, the number of teams, the needs for communication and coordination between teams, the impact of changes, etc.

2. Stable architecture

Is there an implicit, obvious, de facto architecture already in place at the start of the project? Most projects are not novel enough to require a lot of architectural effort. They follow commonly accepted patterns in their respective domain. Many of the key architectural decisions are done in the first few days, by choice of middleware, operating system, languages, etc.

3. Business model

What is the money flow? Are you developing an internal system, a commercial product, a bespoke system on contract for a customer, a component of a large system involving many different parties?

4. Team distribution

Linked sometimes to the size of the project, how many teams are involved and are not collocated? This increases the need for more explicit communication and coordination of decisions, as well as more stable interfaces between teams, and between the software components that they are responsible for.

5. Rate of change

Though agile methods are “embracing changes”, not all domains and system experience a very rapid pace of change in their environment. How stable is your business environment and how much risks (and unknowns) are you facing?

6. Age of system

Are we looking at the evolution of a large legacy system, bringing in turn many hidden assumptions regarding the architecture, or the creation of a new system with fewer constraints?

7. Criticality

How many people die or are hurt if the system fail? Documentation needs increase dramatically to satisfy external agencies who will want to make sure the safety of the public is assured.

8. Governance

How are projects started, terminated? who decide what happens when things go wrong? How is success or failure defined?  Who manages the software project manager?

Organization-level factors (the environment of the projects)

There are other, higher level factors that apply usually across a whole organization. They have a less immediate impact on the selection of process and practices, but we have to be aware of them, as they do condition the first set of factors, project-level.

fig.3 - relationships between the 2 sets

1. Business domain

Web-based systems, aerospace embedded systems, small hand-held instrumentation?

2. Number of instances

Building one system, a dozen, or millions?

3. Maturity of organization

How long has that organization been developing software? How mature are the processes (and the people) relative to software development?

4. Level of innovation

How innovative is the organization? Creators or early adopters of new ideas and technologies? Or treading on very traditional grounds?

5. Culture

In which culture are the projects immersed, both national culture and corporate culture?  What are the systems of values, beliefs and behaviours that will impact, support or interplay with the software development practices?

Examples

If your business domain is “aerospace-onboard software”, this will pre-condition several project-context factors: criticality, size, business model,… This in turn will make some practices suitable or not, will influence amount and type of documentation, the “level of ceremony”.

As a simple example, here is a depiction of the agile sweet spot, the ideal agile project (where most of the agile practices will work out of the box. A web-based commerce site, for example, built on dot-net technology:

Fig. 4 - the context of the agile sweet spot

Discussion

Other people have tried to define the context of a software process, to define the main factors that affect the process they use/could use/would use.

• Boehm-Turner

In their book Balancing agility and discipline, B. Boehm and R. Turner have 5 factors to contrast software process/methods: Size, Criticality, Personnel (skill, know-how), Dynamism (rate of change) and Culture (of the team: thriving on chaos or on order).

• Cockburn & Crystal

In the Crystal family of processes, Alistair Cockburn defines different processes based on  Size, Criticality, and Skills. The first two are fully aligned with mine, but I find the ‘skills’ as it difficult to use in practice. It is not quite a linear scale. I have some of it under “Maturity”.

• S. Ambler, IBM, and Agile@scale

Closer to our views are that of Scott Ambler in Agility at Scale. See fig.5.

Fig.5- Ambler's scaling factors

We seems to cover mostly the main grounds, though with some small differences here and there, as shown in table 1. Ambler seems to focus on scaling agility to larger project, whereas I am mostly attempting to adjust to the contest, regardless of the size or ambition.

Table 1 – Comparing Agile@scale and Situated agility

end)