9 Agile steps that injected magic into our project.

Hi, my name is Simon and I am a Project Manager at Trade Me. Sandy kindly asked me to contribute to her blog, and I consider it a great honour. Below is my story about how we embraced Agile to inject magic into our project.

As a Project Manager I am keenly aware that most projects fail and that’s a good thing. However the part that I really want to nail is the project inception as this will majorly reduce the risk of your project failing and in some cases stop us from starting the project altogether.

The project inception is all about two things:

1. Making sure as an Agile Squad that we are all on the same page before the project has even started.


2. Making sure we ask all the tough questions up front.

The project inception draws out all the juice to fully fulfill those needs.

At Trade Me we used a combination of Sandy’s Mamoli’s wisdom and the approach outlined by Jonathan Rasmusson in his book, ‘The Agile Samurai".

The inception covered these key areas which we call our inception deck.

• Commander’s Intent.


• Elevator Pitch.


• Product Box.


• Pre Mortem.


• What’s going to give?


• Definition of Done.


• In and out of Scope.


• Measure up first release.


• Meet your neighbours.

I am going to explain what the purpose of each of the inception deck sections are, how we tackled them and the challenges we faced.

1.0 The Commander’s Intent

The Commander’s Intent is like our mission statement. It is essentially owned by the Product Owner, but we as a Squad collaborated to devise it. It is a one sentence statement that governs every decision we will do throughout the project. It is what we turn to at the eleventh hour, when we need something shipped and are debating over a feature that should or shouldn’t go to production.

Did you notice the anomaly there? I said, ‘we are debating over a feature’. Usually the Product Owner decides what he/she wants. And whilst the Product Owner is still in command of his product backlog items, especially when it comes to prioritising and grooming the product backlog, the Commander’s Intent encourages us to think collectively as a team and make decisions as a team. We ask ourselves, does that meet the Commander’s Intent? If yes, in scope. If not, out of scope. - which will be discussed later.

When devising the Commander’s Intent we each got into pairs and came up with our ideas. We then matched that with what the Product Owner had pre-conceived, aligned our thoughts with his and word-smithed and debated until we were all happy.

(Fig 1.0 - Our Commander's Intent on the beam)

2.0 Elevator Pitch

The Elevator Pitch is a two sentence statement that gets us all on the same page about what we are doing, who for and why.

One key purpose of the Elevator Pitch, is that it really challenges us to assess whether we should be doing the project in the first place. Many projects get scrapped after a whole heap of money and time has been spent and this potentially prevents us from going down that path. The key element to the Elevator Pitch is the ‘Unlike…our product…’ (see at the bottom of this section).

We found this last element particularly challenging. It can sometimes take a couple of hours for a team to come up with an Elevator Pitch and the last element is the stumbling block that most teams encounter. If you cannot prove what differentiates you from your competition then you seriously have to question why you would bother with the project. Gladly we were able to find a key point of differentiation.

We did the exercise by breaking into pairs again, and then come up with one phrase for each part of the Elevator Pitch with stickies. Then as a team we dot voted on those stickies. The voting was happily, unanimous.

Here is the template for the Elevator Pitch. I actually printed this out with an example, and gave it to each person in the team, to help steer them on the right path when writing up their ideas.

• For [target customer]—Explains who the project is for or who would benefit from its usage.

• who [statement of need or opportunity]—Expands on the problem or need the customer has to solve.

• the [product name]—Gives life to our project by giving it a name. Names are important because they communicate intent.

• is a [product category]—Explains what this service or product actually is or does.

• that [key benefit, compelling reason to buy]—Explains why our customer would want to buy this product in the first place.

• Unlike [primary competitive alternative]—Covers why we wouldn’t already use what’s out there.

• our product [statement of primary differentiation] —Differentiate and explains how our service is different or better than the com- peting alternatives. This is the big one. It is where we are really justifying the expenditure of money on our project.

3.0 The Product Box

If we could buy our software off the supermarket shelf, what would the product look like? Would we buy it?

That is essentially the point behind the product box. It’s about converting what we think could be product features into benefits. We don’t know what those features are yet, but it allows us to visualise at a very high-level what the product could be, and what is so compelling about it. It helps sets our goals and again teases out some tough questions; Why would that be a benefit? Why would our customer consider that a benefit?

The Product Box contains 3 elements, the Product Name, the Slogan and 3 benefits.

The product name, we derived instantly from our Elevator Pitch. We then tried to come up with 3 benefits. For this we paired off and came up with as many stickies as possible and clustered them into groups. Each pair added them to the whiteboard and as a team we clustered them into 3 benefits. The challenge was whittling down the amount of words for each benefit to make succinct and make sense. The slogan was the last part, and a heap of fun as well as a great team builder. It doesn’t have to be a Nike world beater, but it was fun to come up with a catchy slogan that combined marketing cheese and panache.

As you can see, ours is not flashy. It's not meant to be. It's about the copy and the intent.

4.0 The Pre-Mortem

The pre-mortem is like a post-mortem but before we have started the project. Post-mortem’s are all well and good, but I’ve found when documenting all our learnings, they are often filed tidily away and left to rot.

The key trigger for pre-mortems is to ask ourselves the question, ‘What keeps us up at night?’

The point of this is to get utter transparency upfront - the things that hurt us, the things that terrify us, the things that we simply don’t want to happen. We want these out in the open, and then we want to find out ways to make sure those things never happen.

In order to do this exercise, you need to imagine that it happened, you have to think in the future.

Firstly we individually came up with things and events that went wrong – time-boxed 10 mins. Then we silently clustered the stickies with a time-box of 5 mins. Silent clustering worked really well because it removed debate, and improved our collective focus. We then labelled the clusters and finally for each label we came up with things to do about them – ground rules, working agreements, etc.

This final bit took the best part of 3 hours. It seemed like a long time, but highly worth it! For me the pre-mortem was the most fruitful part of the entire inception process.

You can find a description for how to run a premortem in this blog post.

5.0 What’s going to give?

When faced with too much to do and not enough time, is it better to…

… cut scope?

... add more people to the project?

... push out the release date?

... sacrifice quality?

If you found yourself thinking, ‘it depends,” then that’s fine because there are no absolute right or wrong answers. They are intended to show you that there are forces at work on your project and striking the right balance between them takes work.

The levers that we therefore look at are Budget, Time, Quality and Scope. They are levers relative to each other.

What we decided upon was the following:

• Time was fixed.


• Scope could be altered if need be.


• Budget was flexible. If we needed extra resource we could get it.


• Quality (external quality) was the main point of debate. Some argued that it should be fixed and non-negotiable, but the product owner was adamant that in order to get to market he was willing to sacrifice a bit of quality. However note that it was more fixed that scope and budget, so it would be the last lever to pull if absolutely required.

6.0 The Definition of Done (DoD)

Initially this wasn’t going to be part of our inception, but as we did the pre-mortem it was clear that we had to establish this early.

We took as a given that our user stories would be tested and whilst we wanted to deploy at the end of each sprint, we realised there would be occasions that this simply could not happen.

We also bullet pointed our DoD instead of coming up with a sentence. Here is what it is for us.

• No known bugs.


• Relevant documentation written.


• Acceptance criteria fulfilled.


• Design review if needed.

7.0 In and out of scope and Release planning

The key part to this, is working out what exactly is out of scope. What are we not going to do?

How many times have you done a project where the stakeholder has asked, ‘can we do this?’, or, ‘why aren’t we doing this?’ and then you have to come with some detailed explanation or try and prove that it was previously discussed. To mitigate this, it is great to detail what we are not doing with the product owner, to avoid any awkward questions later on.

And then of course there is working out what is in scope which gets us thinking about the nitty gritty and preparing us for release planning.

What was really interesting about this session was that the product owner had pre-conceived a wish-list before we had started the inception. It became quickly apparent that some of the items on his wish-list did not meet the commander’s intent. This sparked off a group discussion and individual sticky notes about elements that we thought should be in scope.

These were then prioritised and a lot was culled into the not list.

From the priority list, we worked out which items should go where, and these formed our releases – of which there were 3 obvious ones and a 4^th which consisted of nice–to-haves that most probably would be broken down into further releases.

8.0 Meet the neighbours

The final part of the inception was working out our neighbours – people in the business who would most likely have a vested interest in our project.

Again, with projects I’ve done, I cannot think of an occasion when the team hasn’t been inundated with people from all over the company asking questions at the last minute. Even with regular demo’s there are often things that haven’t been thought of.

So to stop people panicking, we wanted to establish our neighbours which consists of one representative from each area of the business.

These reps included someone from advertising, commercial, customer services, analytics, finance, platform, legal, marketing, content, trust and safety, comms, and our API providing partner.

These people will be privy to our product backlog and will be included regularly with updates. It will be their job to communicate back to their departments and flag anything back to us – via the Product Owner.

9.0 Demoing the Inception

We did 2 demo’s of our inception to the wider company. The first demo was all the cool concept stuff up until and including the pre-mortem. The 2^nd demo talked about our release planning and a whole bunch of things we did after our inception which we called our discovery week. I will post another blog on that next time. But basically it includes things like experience mapping, personas, tech break outs and collaborative design workshops.

The demo’s were favourably met, and the company very much appreciated our transparency.