One of the key themes at many organisations on their agile journey is how to start a project. One of the questions I often hear is how much information is enough to get started? What is required is a flexible method of defining enough information to start your project journey and at times redefine what is required.
I came across a technique in the interestingly titled The Agile Samurai by Jonathan Rasmussen (a man who takes his craft very seriously). The Inception Deck is a toolbox of exercises, designed to tease out information of the project stakeholders and the development team. I’ve used these in a multitude of different ways, the whole deck to kick off a project in its entirety and selected exercises to tease out information for individuals features. This has proved extremely affective for the latter, where consensus regarding individual features/epics has been harder to build.
So, my first experience was using it for a high level project kick off. I wanted to achieve a real sense of team buy in, as the organisation I was in really struggled to engage the development team with the business. The main reason I was drawn to the Inception Deck was that the exercises are relatively light at heart, or at least my approach to them was. Project kick off can be a painfully serious time and I wanted to get off to a bright and breezy start.
So I gathered the major stakeholders (Business, Sponsor, Product Owner, Project Management, Architecture, Development Team (in no particular order)) into a room and embarked on the Deck. Its probably worth noting here that I had set expectations before hand, including the content and the duration. It is a forgotten art to pay people the courtesy of letting them know what to expect from an agile ‘ceremony’, it is often assumed that people know why they have been asked into a room.
As we moved through the Deck, the Elevator Pitch stands out as an area which triggered a great deal of conversation. This really helped to expose the commercial reality of the project we were about to embark upon. As a Consultant I am painfully aware of the commercial realities of major projects but often a development team is shielded from that. I think it is important that a team has enough context to know what is at stake, but not so much that they are paralysed with worry for the duration of the project.
Post the execution of the Deck I asked for feedback from those present. The main feedback from the development team was the level of engagement with the sponsors and main stakeholders was unique for the projects they have worked on. In addition we had generated a baseline plan for the project, including a sketch of the solution, plus every stakeholder had a basic level of common knowledge.
Juxtaposed with the high level application of the Deck was applying it to individual features. My main purpose was to ‘unblock’ thinking regarding a particular feature. The team in question had knowledge and ideas for the feature in question but struggled to express them in a real and meaningful way. As the ScrumMaster I felt that the information was bubbling below the surface but needed teasing out.
Armed with my previous high level usage experience I used a cut down version of the Deck and added a few brainstorming exercises interspersed within, to try and make ideas flow a little better. I tried to focus on the ‘Why’ for the team as I often find the ‘How’ and ‘What’ comes a little easier for a development focussed team. To be honest, as is my retro style, I allowed the discussion to flow, as I was keen to be unrestrictive on the conversation, while still sticking loosely to the agenda. I find that to be a key facilitation challenge, to allow conversation to flow without going too far off topic. Often answers are found at the loose ends of those conversations.
To be honest, I dropped certain bits of the Deck based on the flow of conversation, and drilled into areas which seemed to pique the interest of the team. Again the Elevator Pitch really shone through, which I think asks questions which everyone assumes we know the answers to, but maybe aren’t quite so straight forward. While exploring a feature I would timebox to about an hour, as you need to keep the time spent (after all its lots of expensive people in a room) in proportion with the value of the feature itself.
In summary, the things I really love about it:
- You can spend as much or as little time as you like exploring with it. So many sessions to tease out information progress for far too long, far outweighing the benefit, consider what you are trying to acheive, who needs to be there and for how long.
- It is a toolkit. As part of your larger toolkit. Your toolkit cannot be large enough. The more tools you have, the more flexible and effective you are.
- It really talks about the big stuff. Releases, budgets, architecture. Its a fantastic lead in for teams who have traditionally not been involved in such decisions, as is the case for most teams in organisations who are in agile transformation.
- Its basically a self documenting baseline plan. Bonus. Documenting while doing it.
A few things that I would like to improve on:
- Teams can get a little self conscious with exercises such as the Product Box. Speak to your audience before, see how open they are.
- Can be a lead in to a solution too early. If you want to leave your options a little more open then perhaps omit these sections until a later date.
- I believe the way of working a team commits to is more important than the actual subject matter that they are working on. The Deck is more project focussed than team focussed.
And finally, it is only a tool, it needs good, honest clear and open communication. If employed effectively and the honesty is present, it can form a great start to your Sprint Zero, and as a solid foundation into the project beyond.