So you’re starting an Agile software project…

10 questions to ask before you get going to set you up for success

I’m always on the lookout for helpful tips and tricks that I can add to my project delivery toolbox. Enter the Inception Deck by Jonathan Rasmusson. It’s a simple yet powerful ten-question framework with two goals: alignment and expectation setting within the product team. These are often skimmed over at the start of Agile projects causing friction, misunderstandings and delays down the line.

Alignment is about making sure the product team and stakeholders are in agreement about why you’re here, what you’re going to build, and how you’re going to do it. Or to put it another way, making sure everyone is pulling in the same direction so that you can move at speed all the time.

Expectation setting is about communicating clearly with the product team and stakeholders what it’s going to take to make this product a success. Most projects are complex, with many moving parts and dependencies, so articulating the rules of engagement upfront saves countless headaches later on.

In this post, I’ll run you through Rasmusson’s tool and add some insights and comments based on my own experiences. Let’s jump straight in.

1 — Why are we here?

Asking why is a great place to start. It’s also the flashlight that helps you navigate the dark and winding road on the way to success. Often the how and the what will change (and it should!) to ensure you’re delivering the value of your why.

A project-wide shared understanding of the why will help the team

• make better, more informed decisions,
• do a better job of balancing the conflicting forces and trade-offs they face each day, and
• come up with better, more innovative solutions because they are empowered to think for themselves and focus on outcomes, not outputs.

And how do we get to the why?

We ask our customers. Rather than assume or guess, we ask them what they need. Walk a mile in their shoes, spend a day in their environment, talk to them. Ethnographic research is a great way to build empathy for and an understanding of the problems you’re solving.

We speak to each other. Document your commander’s intent: a concise expression, phrase or statement that summarises the goal or purpose of your project or mission. Often by simply talking about this with the rest of the product team, you quickly realise that everyone believes there’s a slightly different reason for why the work is being done.

2 — What’s my elevator pitch?

The process of creating an elevator pitch is useful in two important ways: it forces you to think about the value you create for your customer and why you’re better placed than your competitors to provide this value.

Sticking to the format below means you end up with a concise, clear statement you can keep in mind to ensure you stay focused on the customer needs as you’re building the product.

Template:

For [target customer]

who [statement of need or opportunity]

the [product name]

is a [product category]

that [key benefit, compelling reason to buy].

Unlike [primary competitive alternative]

our product [statement of primary differentiation].

3- What would the product box look like?

If you packaged up your product and stuck it onto a shelf next to other products, what would make your product stand out? Why would someone buy it?

Creating a product box for your product is a great way to get the whole team focussed on what’s compelling for your customer and the underlying benefits of using your product. It’s easy to get caught up in the excitement of creating and adding features to a product, but the real focus should always be on how you’re improving the lives of your customers.

4 — What’s on the NOT list?

When setting expectations about the scope of your project, saying what you’re not going to do can be just as important as saying what you are going to do.

All too often features and functionality that is not discussed end up on one person’s ‘assume this is included’ list and another’s ‘assume this is excluded list’.

A NOT list clearly states what is out of scope, sets expectations with the customer and ensures the team are focussing on essential stuff while ignoring everything else.

Split your list into three: in, out and unresolved. Your goal should be to move all unresolved scope items into either in or out of scope.

5 — Who are my neighbours?

Digital products are rarely built in isolation. It needs to be hosted somewhere (DevOps), there are security implications (InfoSec), it needs to be supported (help desk) and marketed to customers / the wider business once it is live (marketing). Plus a whole host of other things!

For products to be successful, you need to understand whom your project touches, what they need in order to help you, and what constraints they’re operating within. Meet your neighbours is a trust-building exercise, where you find out whom you need to interact with before your product can go live and start building those relationships.

As Rasmusson puts it: it’s courteous to say “hi” first instead of just running to your neighbours when your house is on fire.

6 — What does my solution look like?

Diagrams are great. Unlike verbal or written descriptions, there is little room for ambiguity or misinterpretations. They are a much more effective way of communicating the shape of something compared to describing it in words only.

Visualising the problem and solution is about mapping out how you see things coming together, adding some details around your technical approach and making sure the wider team is in agreement with the chosen approach.

Our brains are wired to process information visually so using diagrams to communicate information is useful in several ways, e.g.

• it conveys more information more directly (e.g. project boundaries, proposed technology, risks and unknowns)
• it breaks down any language barriers
• it’s much more flexible than written or verbal communication

7 — Ask what keeps us up at night?

Talk about challenges and risks that might affect the success of the project early on, decide what you can control and what you can’t, and make a plan for those you can control.

Remember: don’t sweat the things you can’t control and know that your plan for the ones you can control will probably change.

Talking about risks and concerns upfront and openly just feels good too.

8 — What size is this project?

The goal here is to give the project sponsor some idea of when they’re likely to get the solution, e.g. one, three or six months from the start date. Don’t forget to factor in things like testing, migrations, training, handover and anything else that needs to be done before the project can go live. Emphasise that this is a best-guess and not a firm commitment.

9 — What’s going to give?

Time, budget, quality, scope: the four project forces that all appear equally important, but, in reality, are often in conflict.

Project success sliders were first described in the book Radical Project Management by Rob Thomsett. Mike Cohen created this easy-to-use online version.

How does it work?

Most customers understand that during complex projects, things will change and you need a degree of flexibility to ensure the optimum project outcome. Project sliders help communicate where you can be flexible and where you can’t.

Just because something is ranked lower doesn’t mean it’s not essential, it simply means something else is more important. For example, a launch date may be more important than scope or quality may be more important than the budget.

10 — What is it going to take to make this a success?

The final question is about bringing it all together.

By this stage, you’ll have a pretty clear idea of what the team you need looks like to deliver the project. For example, you may need a product manager, developers, designers and testers. You can calculate a rough budget for your project by multiplying the weekly team cost by the number of weeks you’ve estimated the project will take to complete. Be clear — this is still a guess, but it’s an educated one based on the foundational work you’ve done so far. We use Velocitaire to estimate project duration — read all about it here.

The last thing to do is to make sure everyone is clear on who’s calling the shots. It doesn’t mean that all the different stakeholders don’t have a say; it simply means that there’s a single person that speaks with one voice for all the stakeholders. This ensures instructions to the delivery team is clear and allows everyone to stay focused on what’s important.

That’s it! You’ve painted a wonderfully detailed picture of what success looks like and what it will take to get there. The product team is aligned, expectations are set, and the runway is clear to proceed at speed.

What are some of the tools and tricks you use to deliver Agile projects successfully and have fun while doing so? And if you use the Inception Deck, let me know what you think!

Whether you’re new to Agile or a seasoned professional, I also recommend checking out The Agile Samurai by Jonathan Rasmusson if you’re not familiar with it. It’s packed with excellent practical tips and examples to help deliver even the toughest of Agile projects.

This article first appeared on the Pixie Labs blog. Check it out for more posts about digital products, tech and smarter ways of working. Thanks for reading!