Structured timeboxes in AgilePM

Introduction

In 2017, on a post on LinkedIn Brian Wernham posted the following question following a conversation he had with some colleagues.

“In AgilePM/DSDM, the DSDM ‘Structured Timebox’, increasingly feels like an ‘exam only’ practice. True or false?”

By ‘exam only’, the question was asking if this style of timebox only related to theory. It had no use other than for passing an AgilePM exam!

I wrote a short reply to the thread on LinkedIn but I felt that the subject was worthy of a wider explanation and this article relates to that.

So, what is the answer?

Well, Brian has posted an excellent question and there is a lot more to it than I think he might realise!

The shortest answer I can give in one word is …”almost”.

There is a longer answer, so that you can fully understand the relevance of the structured timebox, but this involves going into a little bit of the history of the DSDM framework and how the structured timebox came about.

Rationale of the structured timebox

Investigation

The layout of the DSDM structured timebox was, one could say, very appropriate and useful for this kind of work. Put another way, the idea was to do ‘a little bit of initial work’ (‘Investigation’) to check that everything seems to be going in the right direction.

Refinement

Then, do ‘the bulk of the work’ and create the new function or prototype (‘Refinement’). This would involve another major review (or control) point where everyone would look to see that the timebox objectives, and the plan, had resulted in the right thing being built.

Consolidation

Finally, a short burst at the end to tidy up loose ends and make some final adjustments before closing the timebox by producing a finished deliverable (Consolidation).

When the very early versions of the DSDM framework were created, this style of timeboxing was seen as best practice. The structured timebox was also known as the ‘IRC timebox’ to reflect the three cycles (or ‘steps’ or ‘iterations’) of investigation/refinement/consolidation.

History of structured timeboxes

The DSDM method was created collaboratively in the mid-90s and the environment in which it was created then – is very different to the world we live in today.

1990’s – Rapid Application Development (RAD)

Back in the late 90s, IT projects were struggling with waterfall-like approaches and many people and organisations started to move to more pragmatic approaches. One such approach was RAD (Rapid Application Development/Design).

Iterative prototyping

Amongst other things, RAD would use ‘iterative prototyping’ to try and drive out a solution in a much quicker and more accurate way. The context here often involved moving from ‘green screen’ applications to applications built with a GUI (Graphical User Interface).

At the same time, people were starting to use an agile timebox approach in their work. This meant working within a cycle of fixed time intervals e.g. four weeks, These timeboxes would often start from a blank canvas and end up with something that was at least demonstrable, or at best something, that could be used in a live environment.

These agile timeboxes were the ancestors of today’s Scrum sprints.

2000’s – Agile Manifesto

Ten years later, things had moved on a lot with how IT solutions were delivered. In 2001 the Agile Manifesto was created and one of the signatories was Arie van Bennekum who was representing the DSDM Consortium.

Unfortunately, by 2006 due to a few ‘bad calls’ by the DSDM Consortium, the DSDM framework was on the verge of extinction. Public training in the DSDM method had all but stopped, whereas the Scrum framework was beginning to get a tremendous amount of traction. The relevance of the success of Scrum is quite significant later in this article.

DSDM Atern

In 2006, I became Technical Director for DSDM and at the time I suggested that the only way to save the DSDM framework, was to rewrite it, and bring it up to date. This idea was given board approval and over 15 months I led a very large team that created an up-to-date version of DSDM called ‘ DSDM Atern‘.

One of the points of the rewrite was to address the point that the world of IT, and most importantly non-IT, had moved on considerably since 1995.

I do remember at the time not even giving structured (or IRC) timeboxing a second thought. This had always been the (only) way DSDM had timeboxed and it went into the rewritten method without very much debate.

2007 – DSDM

After DSDM Atern had been launched and interest started to come back to DSDM, I noticed that this form of timeboxing was not really what people in the real world were doing. I had several customers who I was helping with DSDM transformations and not many were doing ‘IRC timeboxing’ or were in any way attracted to it. Please note, a few customers were, and some really loved it, and wouldn’t dare do it the other way – but this was a very small minority.

2010

By 2009/2010 I had by now passed on the baton shaping the DSDM method from a technical viewpoint, but I was still part of the team trying to evolve it.

It was at this point I realised that not only was IRC timeboxing, as described in the manual, a bit theoretical and hardly anybody was using that form of timeboxing – but something far more problematic was happening and that was the message it was giving to the wider agile community.

The message in effect was saying that this was the only way to run a timebox and therefore the message it was sending to the Scrum community (in particular) was ‘you are not doing timeboxing correctly’.

Scrum success

This was obviously a farcical position because thousands of people around the world were having a great time with Scrum and doing very nicely with the ‘sprint style’ of timeboxing.

I then started quite a long campaign to try and get IRC timeboxing removed or at least adjusted. The adjustment at the very least would mean that the Scrum community were not portrayed as ‘timebox sinners’.

Free-format timebox

I won’t bore you with the very long and arduous journey that ensued, but eventually it resulted in the inclusion of a ‘free format’ timebox being included in the method around 2011.

By this point there were so many people who saw IRC timeboxing as a limitation and a theoretical dalliance. I think someone described it as ‘intellectual masturbation’ at the time.

2011 – new timeboxing style

So, around 2011, a new style of timeboxing was supported by the DSDM framework albeit somewhat begrudgingly.

In one of the final edits to a new DSDM pocketbook the phrase ‘free format timebox’ was introduced although it was originally labelled ‘unstructured’. Again, somewhat emotively, sending a coded signal to the Scrum community that they weren’t doing timeboxing in the best way possible. An expression and a mindset at that time was, ‘if you’re not doing IRC timeboxing – you are not doing DSDM’!

Successful timeboxing

The issue here being that many people were doing DSDM quite successfully and using different ways and styles of timebox (e.g. many were using Kanban). So, still to this day, we have the legacy of IRC timeboxing being presented first in the chapter on how to timebox and the ‘free-format’ timebox being described second. The reality is that 99% of people using DSDM are not using the IRC format.

Timeboxing advice

To return to Brian’s post and my answer of ‘almost’. There is a lot more to this situation than meets the eye because the thinking behind IRC timeboxing has many advantages.

My advice to people attending an AgilePM course (and to organisations using DSDM/AgilePM) is that you should look very closely at the IRC structured timebox because it contains a couple of very powerful concepts that people may wish to take advantage of (or not, as you see fit).

1. Review (control) points within a timebox

The first concept is the idea of having very specific reviews at pre-determined times within the timebox. Perhaps the first review point is quite early on, just to check that we have set off with this timebox in the right direction.

However, unlike the IRC timebox (as described in the handbook), this may involve more than just understanding the details of the requirements and some deliverables may have already been produced by now.

This can be useful when customer involvement is low – so that they know when they need to turn up. The first review point does not need to be exactly at the end of the second day (if you are working in a ten-day timebox).

More importantly you don’t need to just have two review points. So, the idea of everyone coming together (for example) in a room and checking things out with a mini- set piece event, a mini demo if you like, does have some merit.

Having said this if there is a lot of transparency in the team and visibility, maybe this will serve no purpose and add no extra value – so, as I say, it may be useful, I am certainly not saying that you must use it.

2. A review point before the end

The next concept in IRC timeboxing is one that I feel is perhaps the most powerful. Perhaps everyone should at least take a look at is the idea of having very significant review point towards the end of sprint/timebox but not at the very end.

This concept means that we have at least got some time to correct and adjust before we do the final demo and close the timebox down. Just a quick point here in IT terms, I do not mean a ‘code freeze’.

Brian, you are pretty experienced in agile and I am pretty confident that you have seen a few Friday afternoons when things are all pulled together only to find one or two ‘aha’ moments. The thinking behind the review point at the end of refinement is that, if you have an ‘aha’ moment on a Wednesday afternoon – you might just be able to do something about it before the big demo on Friday afternoon!

These two concepts (scheduled review points and a tidy-up cycle) can be quite useful. However, I think IRC timeboxing as described in the handbook doesn’t do DSDM any favours here.

My biggest single issue with it, is that it just looks too prescriptive. Although the method is underpinned with ‘pragmatism and common sense’ it’s very difficult to read this guidance in any other way than you have two review points, one is towards the front of the timebox and the other is towards the back.

If you felt very strongly that an extra review point in the middle would add a lot of value then my advice is ‘go ahead and do it’ – however in ‘AgilePM exam mode’ you will be marked down for this kind of thinking.

The irony is that it has a lot of merit

As I say, the irony is that there is a lot of sound thinking behind IRC timeboxing, it is just how the information is laid out – it can then become counter-productive. I’m quite happy to agree that it could have been best practice in the late 90s, but it just isn’t today.

One of the key reasons for this is that many things usually take place simultaneously in a timebox. Therefore, a timebox is full of many short items, many fast-moving items and very importantly many dependencies. Therefore, you cannot usually bring everything together easily at the ‘end of day two’.

The slightly sad thing about this is that in 2010/2011 we did have the opportunity to give guidance that was flexible as opposed to guidance that appears prescriptive.

Describing the benefits of significant review points and the idea of an ending with a consolidation cycle would have equipped agile organisations, teams and managers with the tools and the thinking to make an informed judgement. However, once you start getting numbers and diagrams on to a page in a handbook, things can start to go in a different direction and often do.

My advice on how to use IRC timeboxing

So, my advice for any organisation or individual using the DSDM framework is to look very closely at IRC timeboxing and try and pull out those two concepts and see if they can add value to the way you’re working with your timeboxes and sprints. If not, don’t bother!

But just to be clear, if you’re taking an AgilePM exam, just go to page 55 in the manual and do exactly what it says.

Summary

Thanks for getting this far in the article!

As someone reading this, I’m not sure whether you prefer the one-word answer or the ‘War and Peace’ version. But the sentiment of the question in Brian’s post, is in my opinion, actually correct. As described in the handbook it is just a little bit too theoretical and doesn’t really stand up to most ‘real-world’ situations.

Just bear in mind there are there are still places where the prescriptive IRC timebox can be very beneficial. Although I think Brian was being somewhat ironic with a dressmaking comment (in the original LinkedIn post) I feel – making a wedding dress over two weeks in this style could be the best way to do it (as I say could be).

Finally, just remember the single most important thing to do when timeboxing, irrespective of what your preferred method: use common sense and do it collaboratively.