The topic of hothousing has come up recently in several conversations with Agile colleagues. When it was first described to me as a two or three day intense working session that produces a work product or provides portfolio and architecture planning for organizations that use Agile, I also breathed deeply and reminded myself of Bikram's Hot Yoga that I've incorporated in my personal yoga practice. Until recently I never heard of "hothousing" as an agile term, but it seems to be making a debut.
The term originally came out of England at British Telcom as a way to plan out the backlog for a given product. The entire project team and several different disciplines come together with business partners to creatively solve problems and launch into a 90-day development cycle.
My own personal experiences reminded me of RiverCityGiveCamp, which is a charity event where IT folks come together and donate their time to local non-profit organizations over the course of a weekend. IT teams work in an agile format to quickly develop a small but valuable IT tool that is oriented to the needs of that non-profit organization.
Another example that is also aligned with the concept of hothousing is described in this article where Facebook employees, in the course of an all-nighter called a Hack-a-thon, develop new ideas and apps. Facebook applies this approach in several different ways in their business. Interesting to say the least, but Facebook is not risk-adverse in their methods, and they achieve some wild success. They allow themselves the room for failure and growth internally, and deploy publicly what is successful. This does demonstrate Facebook's ability to make this work in its own way.
The common thread between British Telcom, Hot Yoga, RiverCityGiveCamp and the Facebook example are all intense work sessions where a lot work is done (or calories burned) that yield some pretty awesome results. As my own reading of Agile and Scrum techniques continues, I've also been introduced to the Scaled Agile Framework. Otherwise known as SAFe, this method applies Agile techniques throughout an organization to plan out the portfolio and architecture to support the product owners who are leading programs and development teams.
So does running a hot-house sound enticing? The format is one where all necessary minds are pulled together in a 2-3 day work session. The goal for the session must be understood by all the participants. Is it to hold an intense application development session to crank out prototypes? Is it to plan out about 80% of the stories to fill a backlog for a product's next 90 to 360 days? Once the goal for the hothousing session is defined, the iterations within the 2-3 days are structured with a cadence so that the deliverable(s) are produced. It may be code, it may be stories that are pretty close to ‘ready-ready'. Some companies prefer large conference rooms with many information radiators to show what discussion is revealing about a product. A sample timeline for a given day in a hothouse session might be structured like this:
- Hour 1: Goal introduction, divide into teams and a conduct mini planning session.
- Hour 2&3: Work session, discussion, fun exercises to encourage brainstorming.
- Hour 4: Present the ideas or demo the code, come to a consensus about those results, and plan out the next three hours and team tasks.
- Hour 5&6: Work session, discussion, fun exercises to encourage brainstorming, but different from the morning.
- Hour 7: Present the ideas or demo the code, come to a consensus about those results.
As you can tell, two and three days of this can be very intense but deliver an overall plan to provide more definition around a product's vision, create several different prototypes, or come up with different possible product ideas and some vision around each one of those. Organizations can then decide to hand out this work and have it taken one step further by specific agile teams.
This is where hothousing makes the most sense with regards to how it was originally described to me. If a company applies SAFe, the Business and Architectural Epics would require the use of hothousing to pull the right people together to understand how these releases should be delivered. In these sessions, the stories that support the vision and align within the architecture are crafted for the product backlog. The intense work sessions can pull together subject matter experts, product owners, development teams, business and system architects, release management and other pertinent viewpoints that can help craft high level solution plans and visions, with an appropriate amount of detail which translate into what the product owners and scrum masters can deliver in a program using a scrum-of-scrums or within a single scrum team.
While the term has been out there for a while, I think the concept of how to apply this in an agile organization is one that is new and being explored in several different ways.