I’m no gardener.  I have trouble remembering to water my houseplants, never mind making informed choices about pest control, soil pH or hydroponics.  My level of expertise is slightly above ‘the green part sticks up, the white part goes in the ground, and if it turns brown, pour water on it’ (this could explain my usual less than stellar results).  But what I do understand is that plants can take heat and light and a bucket of dirt, and in a short amount of time, transform it all into something beautiful; and there’s something a little bit magical and miraculous about that. 

Humankind (being the inveterate tinkerers that we are) has then taken that natural process, and has worked out that if you stick it all under glass in a ‘hothouse’, you’re trapping that solar energy in with the plants where it bounces around the room a bit and transforms into heat, which gives you better results faster.  This deeply scientific description gives some clue as to why the agile community has borrowed the term ‘hothousing’ to describe the sort of competitive workshopping approach that’s making headlines at the minute. 

So what is a hothouse?

If you think of a standard requirements workshop as gardening unaided, the Singularity hothouse version adds three things to intensify this environment to give the group the right atmosphere in which to synthesise innovation, and to accomplish this over an extremely short three day timescale: 

• light (iterative realignment of requirements to the overall strategic vision of the project and the organisation)
• fertiliser (additional skillsets and information not usually brought into the workshop environment)
• heat (two teams of stakeholders  to provide some good old-fashioned competition)

Light

Traditionally, requirements capture starts in a workshop that might involve one or two analysts sitting down with a subset of business users to elicit everything the users can think of during that session. This activity is then repeated across functional areas and product stakeholders, and while there are a lot of techniques that can be used to good effect to coax requirements from end users, the activity is still up front, with the usual goal being to produce a lengthy, comprehensive technical document that will be frozen for change control purposes before anybody writes any code.

Even in the agile world, where requirements are identified using use cases or, even better, business-friendly user stories, requirements workshops produce a product backlog that often isn’t reviewed by the project’s sponsor in any great detail (the attitude is usually, ‘if the users are happy, then I’m happy’).  This can, however, lead to a backlog which is:

• misaligned to other organisational objectives
• delivering value, but in the wrong areas
• missing opportunities to deliver (or prove delivery of) some of the specific benefits promised in the project’s original Business Case

Singularity’s hothouses, on the other hand, aim to get business-friendly requirements in front of the project sponsor and product owner at the end of each d  d ay.  The sponsor and product owner become the hothouse judges, and evaluate each team’s daily presentation.  These detail:

• the problems that the organisation faces
• the benefits to be achieved by solving these issues
• a set of proposed requirements that will deliver a meaningful solution
• high-level evaluation of the cost and time required to deliver the key requirements, and
• prototypes and scenarios to provide visualisation of how the solution could achieve a positive change

This iterative evaluation allows the judges to steer teams toward proposals that complement ongoing organisational strategy, while also allowing the teams to excite the judges with a compelling vision of the future.  In addition, the presentations become key project collateral which can be replayed to wider audiences, to accelerate the process of achieving buy-in across the various user groups.

Fertiliser

Agile requirements workshops are usually run by analysts for end users, and often don’t incorporate development team members to any degree.  Cost is usually prohibitive in the run-up to construction, as developers and testers don’t come cheap, and once an initial backlog is in place, the development team is usually too busy building and testing valuable software to spare the time to sit in on sessions that can easily run to weeks.

Agile theory has documented at length how combining business users, developers and testers in a single co-located team offers communication shortcuts, while also providing cross-fertilisation of ideas and delivery options.  Hothousing therefore aims to include both developers and testers in any team alongside the critical business interests. 

This can happen because a Singularity hothouse requires only three days from development staff.  The inclusion of technical staff in each team provides the business with a whole new perspective to draw from, which they otherwise might not have access to until later in the agile development cycle.  Developers provide advice on feasibility, reuse and technical risk, and testers help business users to define the acceptable limits of each requirement, and to articulate these in easily testable ways.  In return, developers and testers gain invaluable tacit knowledge, which helps to achieve a deeper understanding of the challenges faced by the business.

Achieving the right mix of people and perspectives in the highly productive environment of the hothouse allows the product backlog to approach construction-readiness after only three days.  The goal is generally to leave the hothouse with only a few days tidy-up and estimate verification required before being able to take the backlog into the first sprint planning meeting.

Heat

It’s hard to imagine any standard requirements workshop, whether agile are not, being allocated enough budget to run parallel streams of analysis over the same exact functional space.  It might be possible for a day or two, but never over the long term.

A Singularity hothouse, being a high profile activity for any organisation, and run over such a short, intensive time period, accepts this cost in exchange for the added benefit of using competition to fuel productivity, and to allow exploration of different facets of the problem area by different groups.  Rather than having one workgroup, a hothouse comprises two teams, equally balanced on grounds of skillset, background and personality types.

This is what really pushes the group achievement into the stratosphere.  However hard a person works, there’s something about human nature that pushes even harder when there’s a high profile backdrop and someone else to beat.  Skeptical about that?  It’s no coincidence that dozens of world records are broken at every Olympic Games, or that Usain Bolt has set his most recent sprint record at the World Championships, rather than in a practice run.

Competition generates the ‘heat’ required to move the team more quickly into a performing state, and then challenges them to experiment with more radical ideas in order to differentiate their vision.  These ideas might be too quickly discarded in a standard requirements workshop as too ‘out there’, too scary, too much.  The advantage in an iterative, judged approach is that there is nothing to lose by proposing radical new ideas during the first two days of the hothouse: judges will steer teams away from genuinely extremist ideas, while encouraging exploration of the sort of innovative thinking and creative problem-solving that can generate unexpected benefits.

If you feel that a Singularity Hothouse might be right for your organisation, please don’t hesitate to contact marketing@singularity.co.uk.

Author: Marion Mcdowell, Singularity