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.
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.
Project-level context attributes (or context factors?)
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?
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.
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.
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?
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?
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:
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.
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.
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
|Team size||Size||Team size – new code size – funding size|
|Geo distribution||Team distribution||same|
|Compliance||Criticality||not quite the same|
|Organization and culture||Culture|
|Organization distribution||Business model||How does money flow in and out?|
|Application complexity||Stable architecture ?? Size?? Level of innovation?|
|Enterprise discipline||Maturity of the organization||Enterprise level, not project level?|
|Age of system||Issues different with heavy legacy|
|Rate of change||Not all systems have the same rate of external changes, and iterating and releasing furiously maybe counterproductive; this drives somehow the iteration rhythm|