Skip to main content

The prickly parts of project inception in an agile world....

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.

Links

http://agilewarrior.wordpress.com/2010/11/06/the-agile-inception-deck/

Comments

  1. Yeah its a good article. According to you what we project managers do is communicating. And a lot of this communication is done during project meetings. It can sometimes feel like you are running from one meeting to another and that your time is often wasted. Meetings don’t start on time, the issues aren’t dealt with, there is no agenda, there is no focus, nobody assigns any follow ups or tasks and of course then they also don’t end on time. An efficient project manager is required for the good management of a project. I think a project manager should PMP certified. Looking forwards to apply what I learned in PMP classes in my company.

    ReplyDelete
  2. Nice blog! you make nice content in here.i wonder how often you post. im writing from persia and i am thinking of becoming a blogger soon. its nice to come across various blogs like this. ;)

    ReplyDelete

Post a Comment

Popular posts from this blog

Testers Guide to Myths of Unit Testing

One area that testers might be able to enhance their contributions to software development teams is how we perceive and contribute to unit testing. I believe testers busting their own illusions about this aspect of building something good would bring us much closer to developers, and help us realise what other layers of testing can cover most effectively.

Also, I want to do a talk about it, so I figured I would test the premise, see if potential audiences were into it. I put this on Twitter:
Working on a talk about what testers might believe about unit #testing & how we interact with developers creating unit tests. Any challenges/additions for my list below? #development#agilepic.twitter.com/4oT5HE4qs3 — Ash Winter (@northern_tester) December 19, 201730 replies with ideas tends to indicate that people might be into it. 
The ListI thought, as my final blog of 2017, I would provide a super useful list of the myths and legends we as testers might believe about unit testing:
That developer…

Why do Testers become Scrum Masters?

It was late and I was stuck on a train, so I pondered on the question of why do testers often (in my experience) become Scrum Masters. Its a very dear question to me, as its been a big part of my career journey In fact, I've been there and back again. Tester to supposed-to-be-testing-but-being-a-Scrum-Master to Scrum Master, back to Tester and very happy thank you.

I encapsulated my reasoning in the following:
Long train delay, decided to think about a thing. :) Why do testers (in my world anyway) often become Scrum Masters? #testing#agile#scrumpic.twitter.com/FGGXFiBGz1 — Ash Winter (@northern_tester) February 13, 2018The tweet got a lot of traction, and generated a couple of interesting threads which made me think.
Great list. Personally I think that as a scrum master I can add even more towards the goal of quality. — Christian Kram (@chr_kram) February 13, 2018 Perhaps part of the reason for the transition is a growing appreciation of where quality has its roots? If testing i…

Wheel of Testing Part 3 - Applications

I've only had to quit two jobs to finally find the time to finish this blog series. Winning at life. If you need reminders (like I did) check out Part 1 and Part 2 before reading on...

After the first two blogs regarding the Wheel of Testing, I was delighted to receive a few requests for the wheel itself, which got me thinking about applications of it, beyond what its original intent was, which I've explored in detail in part 1 of this series of intermittent blogs. Most models need a little air time to show their value, in software development we crank out models all the time, but I'm not sure how many get used. I am inspired by models such as the "Heuristic Test Strategy Model" by James Marcus Bach, as I have used it and seen the benefits it has brought for my clients, particularly the ability to ask questions. So, I wanted to create a model which has a number of use cases, both real and imagined:

Helping to unlocking a career in testing which may be stuck

It is no…