Build it in a Week

Posted on by

I ran a massed prototyping exercise with my current team. The whole team: development, user experience and design, testing, product management, business analysis, programme/project management and the programme director. It was a concerted effort to get a solution covering everything. The idea was to build wide not deep. The requirements for the end to end workflow was a generic operating model we’d developed previously. Microsoft Sharepoint was the underlying platform so this exercise concentrated on “out-of-the-box” solutions based on Sharepoint.

Expected Benefits

I allocated a week for this so the cost was quite high. On the other hand I expected considerable benefits. I expected “Build it in a Week” to enable us to:

  • understand the requirements more
  • validate the generic operating model
  • validate the emerging information architecture
  • identify technical challenges and identify if “tricky” things were in fact simple
  • demo an end to end solution (even if clunky and with caveats)
  • understand Sharepoint 2010 more, specifically understand what “out-of-the-box” means in 2010
  • identify what we can’t do “out-of-the-box” right now
  • understand each other more

As programme manager I thought it worth the cost.

Daily Heart Beat

During the week I ran daily sprints, i.e. an entire sprint within a day. This was quite intensive but paid dividends. The daily heart beat was:

  • Start of day: Sprint Planning. Product Owner(s) outlined aspirations for the day. Team agreed a reasonable chunk to tackle that day. Team self organised to deliver.
  • Mid day: Daily Scrum / Stand up. Brief chance to coordinate, clarify, address impediments, drop features, change tack, etc.
  • End of day: Sprint Review. Show n tell. Start forming backlog for the next day.

    • At the start of the week we agreed a few rules of engagement:

  • Wide rather than deep. This is the one from which all other self imposed rules flowed.
  • Quick is good. So clunky is also good, if it is quick. That means Quick and Dirty is good.
  • Slow is bad. If anybody got stuck on something then they/we had to decide, quickly, whether to change tack, mock up a non-functional version, or just park it. Both product management and development had to be involved in that decision.
  • Feedback is good. Product managers gave feedback to the configurators during the day and didn’t wait for the show n tell. To facilitate this configurators tried to put together a non-functional screen first.
  • Don’t refactor. We noted problems with underlying architecture and code but didn’t fix them. Fixing could come later.
  • Use the parking lot. The parking lot was a flip chart on the wall. We “parked” anything that was slow or irrelevant, i.e. wrote it on a post-it note and stuck the note the the parking lot.
  • Test in place. We didn’t want to spend time releasing code to multiple environments so configuration, development, data entry, and testing all happened in the same place.

The quick and dirty nature of the activity meant we had to accept throwing away the result. Unusually for this type of exercise we did throw it away. Or more accurately we archived it to a server where we could demo it but we didn’t use the code base going forward.

Roles

We didn’t get too hung up on who did what. The team self organised each morning to make things happen quickly. Even the Programme Director built some functionality during the week. Having said that the roles were roughly:

  • Configurator (if such a word exists). These did the build stuff. We picked “configurator” to emphasise the “out-of-the-box” nature of the exercise, i.e. configure rather than develop. Admittedly some of the developers did real coding during the week but this was minimal. This group included developers and anybody else with a technical inclination e.g. product managers and the technical project manager.
  • Product manager. Worked with the configurators to define what is needed, comment on work in progress, feed into backlog for the next day. They were also responsible for putting in plausible data. Generally we paired product managers with specific configurators for the work to be done during the day.
  • User Experience Design. Ensured have wireframes before sprint starts, work with product guys and configurators on wireframes, explain wireframes, check that output matches wireframes, do stuff on styling
  • Tester. Test output of previous day, take a view on how testing should work going forward.
  • Scrum Master. Facilitate the process, remove impediments.

Was it worth it?

Was it worth it? Absolutely. We achieved all our objectives. Our understanding of the technology (Sharepoint 2010) was increased. The requirements were clarified. We found our generic operating model was largely correct however some gaps were surfaced. Ditto for the information architecture. In a couple of areas we managed, with little effort, to build some functionality that we had anticipated would be difficult and time consuming. We had came out of the week with a much more robust list of functionality to build and associated technical challenges. The experience was also a brilliant team building activity; we achieved a lot and it was fun.