Tag: scrum

The Complex, the Complicated and what it means for NASA

When people say ‘Simplifying Complexity’ I hear ‘I don’t know what these words mean’. This isn’t entirely fair, as we shall see, but it gives you an idea of my preconceptions before attending a training session of that title.

The facilitator started off by inviting each member of the group to talk about the influence of complexity in their professional lives. As we went around the room it became clear that for most of the group complexity was a synonym for hard or complicated. Many would agree, including the Oxford English dictionary. However, here was a group dominated by senior members of a very large IT professional services company. These are people for whom complexity science is highly relevant to their professional lives and people for whom there ought to be value in defining Complexity with a big C and in particular differentiating the Complex from the Complicated.

Cynefin

The Cynefin Framework characterises systems (and problem spaces) into five classes – Simple, Complicated, Complex, Chaotic and Disordered. Once the class of a system is identified the framework provides guidance on how to work most effectively with the system. On a personal level I find it very useful in explaining to me not only why an incremental and iterative approach generally works well in software development, it also suggests to me under what circumstances such as approach does not hold. You won’t see NASA using Scrum for instance, more on that later.

Cynefin can be expressed visually like so:-

 

cynefin_as_of_1st_june_2014-1

Credit Wikipedia

The key distinction I see is that of Complex and the Complicated.

  • Complicated

An example of a complicated task is building a submarine. It’s definitely not trivial, but if the tasks are broken down sufficiently the problem is tractable and predictable – essentially it becomes a series of Simple tasks. By contrast a Complex task retains its complexity even after being broken down.

  • Complex

An example of a Complex task could be to ask a room of people to arrange themselves such that the closest person to them is exactly half the distance from them as that of the 2nd closest. It would be extremely difficult for an individual to orchestrate this task, instead each individual actor must make a small change, observe the consequence and then make a further change based on the feedback.

What does this mean for Software?

Taking a manufacturing production line as an example, once it reaches steady state the system can be described as Complicated and is predictable. This is important because for many years Software Development looked to the world of manufacturing for guidance. In doing so, implicitly defining software development as a Complicated task. The thinking being that with sufficient up front analysis the problem could be solved without a line of code being being written. It is for this reason that the Waterfall model rose to such prominence and was so readily adopted.

More recently manufacturing has been shown to be an inadequate metaphor and that in fact software development is more akin to product design, thereby  inhabiting the Complex quadrant. This means that the correct approach, according to Cynefin, is to probe, sense and respond. In effect the iterative and incremental approach practiced by those inspired by Agile and Lean thinking.

So what does this mean for NASA?

If what I say is correct, what does this mean for NASA? After all they have some of the smartest brains on the planet available to think about this sort of thing and yet their processes appear to assume a Complicated rather than a Complex environment.

NASA is an extreme organisation and it is only natural that what works for them will deviate from the common case. Despite the challenging nature of their work I would argue that their domain is Complicated rather than Complex.

Complex systems are characterised by there being many unknowns and an inability to determine the nature of those unknowns at the beginning of the process. In NASA’s case they are genuinely in a position where, for software at least, the problem space is well defined.

For instance, the software runs upon hardware based on Intel’s 386 architecture, hardly cutting edge, but whose behaviour (warts and all) is well understood and has not changed in years. This means that the inputs to the system are well understood and the behaviour deterministic. NASA has managed to turn what would ordinarily be a Complex system (that of software development) into a Complicated system and in doing so their software teams work to vanishingly small defect rates, albeit at enormous cost and at the expense of delivery time. I found this article to be a fascinating insight into their working practices.

In conclusion, Complexity science provides a means to characterise systems, the Cynefin framework provides definitions to differentiate the Complex from the Complicated. Software development is almost always Complex though it was originally assumed to be Complicated. This is why agile and lean approaches have been shown to much more effective than traditional methods that assume a Complicated system such as Waterfall.

In Defence of ‘Scrum but…’

Scrum, as a framework, is practiced in many different organisations and can be considered a mainstream approach to software development. To me agile is way of scaling common sense and while I no longer practice Scrum I consider it an excellent implementation and would happily return to it if my circumstances were better suited to time boxing. However as with all great ideas that are adopted widely, there are many instances where people are simply doing it wrong.

Warren Buffett has a neat way of describing this:

First come the innovators, who see opportunities that others don’t. Then come the imitators, who copy what the innovators have done. And then come the idiots, whose avarice undoes the very innovations they are trying to use to get rich.

In the case of software it’s reasonable to replace the goal of getting rich with that of successfully delivering software that is valued by the customer.

As such there are a wealth of posts discouraging the adaption and variation of Scrum, in fact the notion of Scrumbut is so well understood it even has a definition.

scrumbut [skruhmbut] noun.
1. A person engaged in only partially Agile project management or development methodologies
2. One who engages in either semi-agile or quasi-waterfall development methodologies.
3. One who adopts only SOME tenents of the SCRUM methodology.
4. In general, one who uses the word “but” when answering the question “Do you do SCRUM?”

Project management will necessarily vary from company to company. As such the ubiquity of a term like Scrum has less value within a specific company, since the shared understanding of the company’s approach ought to be evident to all. When I talk to people outside of my company it’s useful to reference commonly understood terms as a starting point. For time boxed approaches Scrum is an obvious point of reference, but the specific system that I wish to describe is highly likely to deviate from Scrum in some way and I do not necessarily see this as a bad thing.

The challenge of software development is to produce something that someone will find valuable. There are plenty of different ways to achieve this and all are highly dependent on the context of the project. Generally an iterative and incremental approach that bakes quality in from the start is preferable and a number of ready made implementations exist such as Scrum, Kanban or Evo. In some cases it may be appropriate to lift something like Scrum wholesale, but in many other cases, there are legitimate reasons for adapting the process. For example a team might be writing an implementation of a system where the behaviour is well understood. In fact in order for the system to be compliant and therefore usable it must adhere to a large pre-written spec provided by an external party. Clearly this is at odds with Scrum but there is no need for the team to drop time boxing or stand ups as a result.

So adapting a process is not in itself something to be frowned upon. Clearly bad project management is bad, and if the manager blames their own failings on their inability to implement a methodology then larger problems exist. The key point is that good managers should not worry that they are running Scrumbut, or indeed if they are ‘doing it right’ as the only metric for correctness is that the team maximises the value they create.

The Switch to Kanban

Recently my team have been trialling the use of a Kanban board to manage our work flow and in doing so have dropped time boxing. So the far the switch has been very positive, while it may not be an appropriate transisition for all teams I thought that it might be useful to share our experiences.

In brief, Kanban is an agile development methodology that does not prescribe time boxing (i.e. fortnightly iterations), rather it focusses on limiting work in progress. For each stage of a story’s life span e.g. ‘in progress’ or  ‘ready to deploy’ the team has a maximum amount of work that can exist. As stories are completed the team pull new stories from the project backlog. For more information I would recommend Henrik Knibergs excellent comparison of Scrum and Kanban

Why Kanban?

We originally adopted time boxing about 6 months ago, the key benefits we were looking for included:-

  • A sense of rhythm and points to reflect on our working practices.
  • Better visibility over tasks that were dragging on.
  • A highly visible feedback loop to help improve our estimations.

For the most part the adoption of time boxing was very successful, we’ve certainly improved our abilities to estimate, and generally we have better visibility over our performance. The thing that didn’t work so well was working to the self imposed iteration deadline since it often felt false and sometimes was counter productive.

Any team working to an iteration will occasionally finish early or fail to complete all tasks, it’s not ideal but manageable so long as the team continually refines it’s working practices to minimise occurrences. In my team’s specific case this is especially hard since so much of our work is dependent on our interactions and integrations with companies much larger than ourselves. Experience tells us that it is practically impossible to predict the time spent on an integration and even harder to guess at what point the time will be spent. As a result, despite working in a predictable manner on the majority of our iteration goals it was common that we would under or over shoot.

This is hardly the end of the world though it started to chip away at the sanctity of the iteration and continually raised questions of why the system was pushing us in ways that felt wrong to us i.e. if we finish early then we can take another story from the back log so long as it fits into the time remaining, however ideally, for a given project, we’d want to the story with the greatest risk attached which may or may not fit in the time allotted. It felt that time boxing was nudging us away from this idea.

Furthermore, my company is such that our developers typically have a very good level of product domain knowledge, as such the need for a formal Scrum style Project Owner is reduced. This means that while we would demo our work to interested parties on completion of features, come the end of an iteration it was rare to demo our progress.

It was clear that while providing some benefits we were fighting against time boxing and we needed to find an approach that better described our work flow. What we were aiming for was not so much to complete a set of tasks in a pre-allotted time period, more that we should be able to regularly produce deployable features in a predictable manner. By limiting the work in progress rather than limiting the work per time Kanban presented a viable alternative we felt better reflected how we actually work, while preserving the discipline necessary to deliver working software multiple times a week.

Initial findings

Since mid iteration our practices were already similar to that of Kanban we found that migration to the system caused very little disruption and we did not notice a productivity hit while we got used to the new system.

The migration has brought about subtle but positive changes to how we work, largely due to the fact that by explicitly limiting the amount of current work it forces conversations to be had where we are close to violating the limits.

In addition to making it easier for us to refine our process, the main benefits so far include:-

  • Greater flexibility in our work flow, we can respond in days rather than the three weeks a two week iteration promises. This is key, as delivering supplier driven changes quickly provides significant competitive advantage.
  • On a related note, we no longer feel that we are fighting our process. It is no longer the case that we regularly take a course of action that violates our process (albeit for perfectly sensible reasons).
  • The board provides a highly visible place to display tasks, communicate priorities and highlight bottle necks. These benefits are not Kanban specific however Kanban’s greater emphasis on use of the board (through tracking work in progress limits) means that any benefits are magnified.
  • It saves us an iteration meeting – the role of the meeting is covered in stand ups or in project specific design meetings.
  • Our stand ups have become much more focussed, this is partly because we do them in front of the board. Again this is not Kanban specific but in Kanban running them anywhere else makes no sense at all. Id’ say that we’ve halved the length of time we devote to stands ups, where further discussion is necessary it is taken outside of the stand up.
  • Our retrospectives are no longer coupled to the period of our iteration, currently we still run retrospectives fortnightly, though since our stand ups are now more effective for day to day tweaks we may extend this period.

In terms of cons, thus far we do not feel that we have lost anything by adopting Kanban, the only potential problem that we have encountered is that greater discipline is required in ensuring that all tasks are completed in a timely manner.

The future

So far we are very happy with Kanban and will continue to use it.

In order to measure performance over time Kanban teams track two metrics.

  • Throughput
  • Lead time – the time it takes for a feature to be delivered after the team has committed to its delivery.

At present we do not have enough data for meaningful results but long term we will maintain something much like this as suggested here.

Further reading

In addition to Scrum vs Kanban comparison referenced above you may find the following useful.

Finally not everyone is as sold as I am on Kanban for some anti Kanban debate see:-

I found the comments that follow the posts to be of particular interest.