Different kinds of organisation build software differently. Why might that be? Maybe it’s true that for some organisations Prince2 or PMBOK, or Scrum are absolutely the right choices. Maybe for a certain organisation .net is the way to go or Java, or Ruby on Rails. Perhaps your organisation captures requirements in natural language, or with use cases, or in user stories and that works fine for you. Probably every organisation in the world uses software, but for some software is the centre of their universe and for others it is a support function.
A company like Microsoft is likely to have a very different way of building software from a government department, or from a 3rd party supplier of software who wins their business in open competition. One way of describing organisations based on how they use software is presented below:
- Sealed Packaged solutions e.g. Microsoft, Apple
Build software products and sell them. - Unsealed Package solutions e.g. Siebel, SAP
Build software products, sell them and configure them - Managed services e.g. PatientKeeper,
Build a single software service and sell access to the service. - Information provider: e.g. Reuters, The Guardian, Google
Build and platform that gives access to valuable information. - Professional services, (incl. Government, Manufacturer/Supplier): e.g. Aviva, Barclays, Lloyds of London
Provide banking, insurance, order processing, manufacturing support, government services etc. and use IT to support the business. - 3rd party supplier: e.g. mPhasis, Tata, Logica
Build software and services on behalf of other professional services or information providers.
How core software is to what the organisation does is going to affect the way an organisation configures itself with respect to software engineering.
The ‘Universals’
If you want to build software, what are the kinds of things you need to worry about? Have you got all the bases covered? That’s the question the group ‘Software Engineering Methods and Theory’ (SEMAT) have been asking themselves. SEMAT aim to come up with a design for a meta-method-kernel. This is perhaps not a fundamental theory of software engineering [1], it is however a useful thing to have [2] because everybody building software should have thought about the tasks they are going to be faced with and can at least make a rational decision on what practices they should adopt. The decision they make will be affected by the type of organisation they are and the centrality of software to their core mission.
SEMAT haven’t finished their work yet, (and perhaps they never will!) but we don’t have to wait to propose one view of what that kernel of software concerns might look like.
Figure 1: A version of the Universal kernel of software engineering concerns
The kernel in figure 1 is a collection of placeholders and it is up to the organisation to put some practices into the holes. It can be argued that there will always be something in the holes, even if the something is actually an ad hoc practice. Having watched Jeff Sutherland talk about the work at Google to build Adwords, one is left with the impression that Scrum pretty much does it all [3].
Figure 2: a populated kernel as Jeff Sutherland might have visualised it working on Adwords.
That could be absolutely fine for Google, because they are pretty good at building software and they have access to their product owners on a daily basis. The culture of Google is to have few managers and it is led by engineers. Not all companies are like Google though and therefore there is no need to copy them, because the way they do things may just not be right for the way you do things.
Consider a different kind of organisation, such as an insurance company. This company spends a lot of money on I.T., they used to do it in-house and now they’ve outsourced it to Eastern Europe. They have a Programme Management Office (PMO), they have people who want to manage risk, and are interested in ‘quality’. It’s not my job as a person interested in methodologies to tell them they should change before I can help them build better software. I can work with them to demonstrate that maybe there is a better way and if that is successful they can choose to change themselves.
In the meantime it’s perfectly possible for them to take advantage of the kernel of concerns and define a set of good practices that work for them to improve their software delivery.
Figure 3: a populated version of the universals kernel that would be appropriate for an organisation where software was not its primary product.
In Figure 3, our imaginary insurance company has chosen a set of practices that suits it, its culture and the degree to which software is integral to its business. One of the benefits of this way of visualising a software engineering practice is that it makes it easier to ‘hot swap’ one practice out for another without disturbing the others. This is the familiar concept of ‘encapsulation’.
My particular areas of interest in this topic include:
- Opportunity: Demand management, Ideas management, and Benefits Analysis
- Requirements: Agile Requirements Practice
- Way of working: Unified Process lifecycle
- Governance: PrinceLite www.princelite.co.uk
References:
[1] ‘Why We Need a Theory for Software Engineering’, Dr Dobbs, Jabobson I, Spence I, [2009] http://www.drdobbs.com/architecture-and-design/220300840;jsessionid=RZLXNZ2D4154PQE1GHOSKHWATMY32JVN
[2] ‘A Detailed Critique of the SEMAT Initiative’, Cockburn, http://alistair.cockburn.us/A+Detailed+Critique+of+the+SEMAT+Initiative [2009]
[3] Scrum Tuning: Lessons learned from Scrum implementation, Jeff Sutherland, [2006] http://www.youtube.com/watch?v=9y10Jvruc_Q