Living prototypes

Recently on a project we had the pleasure to work with a colleague of mine Alex McNeil, in what I thought was a very interesting and successful way of developing UX friendly designs.

The story starts off with a familiar tale, we had just been given a set of designs from an external design agency, which according to the client developers had a history of excruciatingly painful changes. Even more so, was that the so-called "web" designs, were semantically incorrect, ie having a radio buttons for optional choice fields, or standard editable text fields for static read only data.

The marketing department loved this design agency and would fall into the habit of requesting 1001 changes, which would ultimately blend changes in behaviour as well as aesthetics. The poor developers would only find this out through constant revision after revision of print outs of the designs, just to notice that "that check box is now a radio button, because the field is no-longer optional". You get the picture...

So how did we turn this around?

1. Taking control of the designs - almost day zero of the project we took ownership of the designs and proclaimed that all changes must now go through our designer Alex, the BA and developers. Changes were still welcomed, but now we could control their arrival.
2. A Living Prototype - this idea was born from chance more than anything during the project inception after estimates were presented to the client. In short, our estimates were far too long, in fact they needed it done "next week", an impossibility! The client would not move on this date, and when asked why the date could not be moved it was due to a national sales conference. They needed something to demo. Ahah! What we needed was a living breathing working prototype (more than a wireframe), that looked and behaved like the real thing but could be done in a week, whilst the real application proceeded along it's merry way.

So how did this work technically?

Although we were using Asp.Net MVC and string template, this same technique can apply to any templating engine that allows you to partition and include sub-templates within other templates.

We first created a "Demo" controller, from which Alex could begin working from and creating static html templates, styling and any "fake" javascript functionality. The master page and sub templates which were to be shared later on, were placed in relevant view folders matching the expected future controllers.

/static/js/demo.js

/static/css/real-style.css

/controllers/DemoController.cs

/views/Shared/master.st

/views/Demo/index.st (drives out sub-templates, master.st and real-style.css)
/views/Demo/page2.st
/views/Demo/page3.st

/views/Real/indexSectionA.st

/views/Real/indexSectionB.st

/views/Real/page2SectionA.st

/views/Real/page2SectionB.st

/views/Real/page3SectionA.st

As stories were picked up and played and "Real" controllers introduced, the new pages could pick up the shared sub-templates (with styling) and inherit all of Alex's goodness. More and more of the sub-templates were included as more and more functionality delivered.

/static/js/demo.js

/static/css/real-style.css

/controllers/DemoController.cs

/controllers/RealController.cs

/views/Shared/master.st

/views/Demo/index.st

/views/Demo/page2.st

/views/Demo/page3.st

/views/Real/real-index.st (uses sub-templates, real.js, real-style.css)

/views/Real/indexSectionA.st

/views/Real/indexSectionB.st

/views/Real/real-page2.st

/views/Real/page2SectionA.st

/views/Real/page2SectionB.st

/views/Real/page2SectionB.st

As complexity grew in the "real" controllers and changes in the type of data sent to the sub-templates, the demo controller was brought up to standard so that it could send equivalent data into the view.

The greatest benefit of this living prototype method is that, because the app could be demonstrated working much sooner, it enabled many iterations of feedback before the actual stories had even been played. This lead to far fewer changes in behaviour at implementation time. Given the chance this is a technique I would definitely use again in the future.

Ménage à trois in kinky teams

My fellow Thoughtworker Greg recently posted about our revolutionary experiences and experiments with team formation and delivery at our current client.

I wanted to expand a little more on a subtle and incredibly important point that has lead to the success we have been having. Our wall, as described by Greg, has only a single central delivery column "in progress". It is what happens here that makes our new team formation a kinky success.

Traditionally in perhaps an XP style team, you would have dev pairs assigned to a story, which is then handed off to a QA, who writes defects against the story, which the dev pair fix, and is retested and so on. We decided this doesn't work... well at least for very long anyway!! Before long (usually towards the end of a release) cards and defects get piled up into one big traffic accident of a story wall. Any "Individuals and Interactions" goes out the window, whilst we cling to the ceremony of raising defects, reading defects, closing defects, explaining defects, re-opening defects, explain what those changes to the acceptance criteria were you missed whilst at lunch. What is all this craziness? It shouldn't be this hard? Delivering software, should be sexy!

Sexy?

In our new team, we have Threesomes, some times several at once, and I'm not sure what that is even called (never was that adventurous)? No longer are there dev pairs, now there are only delivery threesomes, two developers and a QA. This is the subtle and overlooked part. It is only as this combined unit that a story is delivered.. together as one intertwined collaborative ball of sexiness.

So what are the logistics of this? Surely people will be sitting idle?

Firstly there is the story huddle, which I won't go into great detail as this deserves its own blog post. The acceptance criteria are read together as one team, we get the breaking news on the story and a shared idea of what will be done and expected.

Next the dev pair formulate a plan on how they will deliver the story to the QA. This is a valuable pairing technique, known as micro-tasking and usually involves a bunch of stickies. The stickies break the story up into more vertically sliced, micro end-to-end business functionality (not technical functionality), which can be individually showcased.

The dev pair continually share, showcase and communicate with the QA, who continually explores and probes the virgin behaviour that is just delivered. This continues until the the development work is complete.

Now the crux. If development has finished and QA has not, then the dev pair then submit to the QA, who instructs them at their will to do all that they desire and more. When and only when the QA's appetite is fully satisfied and final climatic showcase has ensued, can the dev pair return to the awaiting pile of stories.

Although, our new threesomes are not faithful within their new found relationships. If when a story is finally complete, there are no more stories to pick up, then attention is shift to new meat in the BA. The developers or QA, remove their current hats and get stuck in with the juicy task of analysis. (There's probably a metaphor in there somewhere, but I won't go there.)

Finally, if we find our dev pair has finished entirely too prematurely, and there is nothing more that can be done with our QA. Then we still do not pick up new stories, but go off to satisfy ourselves, with trusty old tech-debt cards.

Has this Ménage à Trois been successful?

As Greg pointed out, we have only yet raised one solitary defect since October. This was caught and fixed within the Sprint the story was played.