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

At the start of this month we shipped a major version of the Singularity Process Platform.  The focus of 4.0  has been on support for Software as a Service,  Agile Business Rules,  and eDRMS integration (SharePoint and HP TRIM).   It’s a busy, exciting and tense time for a Product Manager coming up to a major release.  The key responsibility of the job is, after all, to ensure that the company delivers the best possible product at the time, given all the constraints.  Singularity is the first company I’ve worked for which has fully embraced agile development as the approach when working with customers and for delivering product releases.  I’ve plenty of experience in the past with companies who used iterative approaches, time-boxes, MoSCoW and the like, but it was new and invigorating to go the whole hog (or should that be pig? – agile in-joke, sorry).  It works too; not flawless -  my mantra is that “you’re always doing it wrong” so the improvement process never ends, but once product management and development ironed out the wrinkles in the mechanisms for managing the user stories and iteration planning, it flowed very smoothly.   And we’re now on a quarterly release train – and I’ve always liked release trains because of the way they turn the painful and endless “date versus scope” argument into a much simpler “which train will this feature leave on” discussion.

So did Product Management get it right?  Early days, but the SaaS content of the release has been quickly picked up on by the analysts and we’ve had enquiries from several existing and new customers, so it would seem that our belief that SaaS was maturing rapidly, and the economic advantages of a rental model, was well founded.  As we anticipated the interest is primarily from companies who wish to build out their own SaaS offerings and appreciate that a SaaS enabled and scalable workflow engine is a key enabler.

The SharePoint and HP TRIM integration is also arousing interest.   Microsoft are hugely committed to the success of SharePoint and it’s rapidly becoming the centre of the universe for many businesses. We’re using SharePoint internally as the core of our requirements management and iteration planning process (along with SPP of course) and it just works really well. It’s a great product for collaboration and content management, and the OOTB fit with our Case Management capabilities is a powerful story.

I’ll be talking some more about SharePoint Case Manager (as I would like to call it) in future blogs.

Did we get anything wrong?  Well hard to say; I’m personally very pleased with our new business rules and business parameters support, I think the current economic turmoil has underlined how essential it is to be agile, and using rules and parameters to separate policy and external determinants from the business processes gives you that in spades, but the response from customers has been more “that’s nice” rather than “wow”.  Maybe it’s a grower.

On the other hand, some smaller features which we hadn’t really played up very much, excited  customers more than anticipated. For example the integration with the Outlook Task list -  allowing users to view, take and complete activities from within Outlook, resonated very well.

So at this point, while I give the developers 10 out of 10 for the development, I’ll give Product Management 8 or 9 out of 10 for reading the market right.

Back to my user stories now, not long until 4.1.

It must take a long time to make a Universe. To paraphrase Douglas Adams, you might think it takes a long time to powerwash the front drive, but that’s just *peanuts* to making a Universe. Douglas managed it with his Hitchhiker Universe, and its now difficult to imagine there was a time when we did not know that Vogon poetry was among the worst in the Universe, that the way to travel vast interstellar distances is by using an infinite improbability drive, and that the answer to the untimate question of life, the universe and everything is 42.

Read the rest of this entry »

The words agile and agility crop-up more and more frequently in the business and technology press. Agile delivery techniques combined with BPM enable you to obtain working solutions faster, and these solutions are more closely aligned with business priorities. Through an iterative approach you get value delivered early and often. Singularity is a big believer in the power of combining agile techniques with the disciplines and technology of BPM. We’ve developed a specific methodology, called ASAP, that combines the best elements of agile techniques along with some BPM-specific elements, and to this we’ve added competitive ‘hot housing’ to drive out new and innovative approaches to business problems. At the recent Gartner BPM summit in London we gave a presentation on agility and BPM, in which we provided an introduction to the ‘Agile’ movement and its relevance to Business Process Management – to learn more, please click here.

Read the rest of this entry »

European financial markets seem to be getting flattened, in more ways than one. For a long time most people thought the whole world was flat. Then 2,500 years ago Pythagoras proved that the world is spherical. Rediscovering flatness of a kind, 44 years ago Marshall McLuhan introduced the term “global village”, recognising that technology was unlocking the doors between people and nations. More recently, Thomas Friedman declared 4 years ago that “The World is Flat” in his best-selling book of that name, quoting one of the drivers and benefactors of this new “flat” earth, Infosys CEO Nandan Nilekani.

Read the rest of this entry »

Today’s organisations compete through more efficient and better executed business processes. Business Process Management (BPM) is an approach and technology for implementing well-defined, well executed processes.

Michael White provides his top tips on how to successfully introduce BPM to your organisation.

1. Pick a project that will make a difference.

For your first BPM project, select a highly visible business process where improvements will yield real organisational benefits. The process you choose should be in a key operating area that is important to the organisation, so it can act as an example and inspiration for subsequent projects. Clearly define what the expected benefits of improving the process will be, such as cost efficiency, customer service, or faster responsiveness. Quantify these benefits you require in terms of money, time, people or other specific measures.

2. Obtain Senior Management Buy-in.

You want high-level sponsorship of the project at the outset to ensure you get the resources you need, to gain buy-in from staff and to overcome resistance to change. Your executive sponsor should have the authority and respect required to keep up project momentum. He or she should also be prepared to remain in a hands-on role throughout the first delivery – just showing up at project kick-off won’t be sufficient.

Read the rest of this entry »