(This blog has been written following a question raised on LinkedIn by Brian Wernham)
In July this year Brian Wernham posted the following question on LinkedIn:
In AgilePM/DSDM, the DSDM ‘Structured Timebox’, increasingly feels like an ‘exam only’ practice. True or false?
By ‘exam only’, Brian was asking if this style of timebox only related to theory and was of no use other than for passing an AgilePM/DSDM exam.
I have replied to the thread on LinkedIn with a short reply but I felt that the subject was worthy of a wider explanation and this blog relates to that…
So, what is the answer?
Brian this is an excellent question and there is a lot more to it than I think you might realise!
The shortest answer I can give you 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 and how the structured timebox came about.
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.
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). 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 ‘green screens’ to applications built with a GUI (Graphical User Interface). Also at this time, people were starting to use a timeboxed approach to this work. This meant working within fixed time intervals e.g. four weeks, and 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.
The thinking behind the structured timebox
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. Then do ‘the bulk of the work’ and create the new function or prototype (‘Refinement’). This would involve another major review point where everyone would look to see that the timebox objectives, and the plan, had resulted in the right thing being built. 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 iterations) of investigate/refine/consolidate.
Ten years later, things had moved on a lot with how IT solutions were delivered and 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 on in this article.
@David Tomlinson kindly gave me a name check there has being a lead author of DSDM and back in 2006 I suggested that the only way to save DSDM was to rewrite it. This idea was given board approval and over 15 months I led a 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 way DSDM had timeboxed and it went into the rewritten method without very much debate.
2007 and a new dawn for DSDM
However, after the method had been launched and some level of interest started to slowly come back to the 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 in any way attracted to it. I need to point out that a few were and some really loved it, and wouldn't dare do it the other way - but this was a very small minority.
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 absolutely 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 this was the only way to do a timebox properly and therefore the message it was sending to the Scrum community (in particular) was ‘you are not doing timeboxing correctly’.
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 and arduous 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’. I won't bore you with the very long and arduous journey that eventually resulted in the inclusion of a ‘free format’ timebox in and around 2011.
By this point there were so many people who saw it as a limitation and a theoretical dalliance. I think someone described it as ‘intellectual masturbation’ at the time.
So around 2011, a new style of timeboxing was therefore supported by the DSDM framework albeit somewhat begrudgingly. In one of the final edits to a new DSDM pocketbook the word ‘free format’ 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 used at the time was ‘if you're not doing IRC timeboxing you are not doing DSDM’!
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 would not be using the IRC format.
To return to your question Brian 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 and my advice to people going on the AgilePM course and organisations using DSDM/AgilePM is that you should look very closely at the IRC structured timebox because it contains a couple of very powerful options that people may wish to take advantage of, or not, as they see fit.
Specific review points within a timebox
The first concept, is the idea of having a very specific review point at some point in the timebox, perhaps quite early on, just to check that we have set off with this timebox in the right direction. Perhaps when cust involvement is low – so they know when they need to turn up? This does not need to be exactly at the end of the second day (if you are working in a ten-day timebox) and more importantly you don't need to just have one of them. 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, where a ‘heads-up’ would be seen as good idea to do in the timebox.
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.
A review point before the end
The next concept in IRC timeboxing that I feel is perhaps the most powerful, and 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!
I think IRC timeboxing as described in the handbook doesn't do DSDM and 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 a second 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 would 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 can now take place, and usually do, in a timebox. Therefore, a timebox is full of many short items, many fast-moving items and very importantly many dependencies and therefore you cannot bring everything together very 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 a 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 on to a page in a handbook things start to go in a different direction.
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.
However, let me be clear, if you're taking the exam just go to page 55 in the manual and do exactly what it says.
In summary, I'm not sure whether you prefer the one-word answer or the ‘War and Peace’ version but the sentiment of your question, in my opinion, is actually correct - it's just a little bit too theoretical and doesn't really stand up for 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 you were being somewhat ironic with your 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, is to engage brain and do it collaboratively.