How to start an agile product delivery

When they told the whole story of how they got off track, it seemed totally avoidable. If anything, it was simply down to a lack of preparation. They were so keen to get going they simply assembled a team and started. Realistically, this was more down to maximising billable hours than a keen desire to consistently deliver quality product and this pressure to get started with immediate effect led them astray. We’ve seen it so many times in so many places.

It then occurred to me that many of the good folk I meet day to day as an agile coach are great at keeping a product delivery or project going, but pretty inexperienced at starting one up. If anyone is interested, our Effective Product Owner workshop is great for product owners, scrum masters and teams to get together and get a product started.

Getting started on your agile delivery shouldn’t take long – rarely longer than a week in my experience. It is more than just diving in, though. Taking the time to prepare now will save you time, effort and aggravation later on many times over.

What I have assembled below isn’t a definitive list, but it’s a rough mental checklist that I go through when kicking an engagement off. You don’t need to do everything on it either – part of the skill of getting started is know which tools to use and when. What’s for sure is that if you don’t do any of it, the problems you get will be annoying, expensive and will have been totally avoidable.

Finally, I intentionally make no meaningful reference to delivery frameworks such as Scrum or Kanban here. The points can be applied to almost any type of delivery framework.

Stage one – before you start

Someone somewhere has had an idea. They want to bring it to life and they have chosen you to help them do it. That’s great, but you need to get set up for success and that comes from getting some clarity before you move forwards.

The work done at this stage is so valuable, because it is easy to do and can have a huge impact on avoiding problems later. The exercisees are pretty cheap as well. The cost of one person asking some questions is much cheaper than having a whole product development team sweating away building the wrong thing – however well they build it.

The intent behind these initial points is simply understanding the reality you are dealing with – the lay of the land. It’s the best time to push for information, challenge the concept and strive for alignment – especially as time should be on your side at this stage. A short delay here for a few people saves no end of time, credibility and even long-term relationships later on.

Approach this stage with humility and directness and you will build solid relationships that stand the stresses of delivery.

Ask why should we bother doing this at all?	People often forget that testing begins at the start – and this is the first test to run. If no-one knows what this thing is and who wants it, then perhaps you should can it before you ever start it. Why build something no-one wants?
Describe the idea or need	Sounds silly, huh? …but if you can’t describe the problem you are trying to solve in simple terms, then it’s probably not well thought through.
Value driven proposal	A proposal needs to drive some kind of value or benefit. It’s good to question this at every stage, but especially before you start. If this is a bad idea to start with, speak up now. Don’t move on before you understand its intent and can describe what value is.
Outcomes, not outputs.	The proposal needs to focus on clear business outcomes. Being driven by outcomes not outputs is a key differentiator of contemporary techniques like agile. The reason an outcome is important is that it won’t dictate how you meet it, only that it needs to be met. Targets drive behaviours and requirements can go stale before they are delivered.
Commercials	Regardless of whether you are an agency delivering to a client or a manager guiding a team, commercials matter. Have the conversation about them now. Don’t start something that you may not be able to finish. If it feels like a stretch, it probably is.
Operating model	An operating model joins the dots between people, process and tools. Quite often it is visualised showing how information flows between all the nodes of communication. Agree up front how common situations will be dealt with, such as changing forecast delivery dates, requests for additional scope and changing requirements.
Agree Key dates	Are there any key dates that you need to be aware of? Christmas, transmission deadline, legislative cut-off? Some dates just can’t slip – best find that out now.
Understand what was sold	If you’re a consultancy delivering to a client, getting your sales team who won the deal involved at this stage is vital. It’s just part of the handover and you need to know what promises have been made that you need to deliver on. Don’t assume what got sold is technically feasible or even actually possible…
Assemble the team	The next stage is all about aligning what it is that you want, so now is the time to start considering the team you must assemble to deliver the work. Product, BA, engineers, architects, UXD, compliance…
Approach	Have you considered the delivery approach? Scrum, Kanban, XP? Explore the options now. Remember, there are lots of different approaches and they all have their strengths and weaknesses.
Handover	How will this idea get handed over to delivery? Do you need a mobilisation checklist
Collaboration	How will you collaborate when you are in build? Who will talk to who, when and how? What will you do when things go wrong – which they will at times. Remember, the problem you see coming is the problem you avoid – get this sorted now.

Stage two: Getting aligned – syncing up with the customer

By now you should be confident that you have clarity to move forwards and invest your time in figuring out what the problem is that you have to solve. This means breaking down the idea and the business outcomes above in to more tangible assets.

This is really creative, putting the end users at the centre and trying to view the problem from as many different perspectives as possible. A small yet diverse team will help you achieve this, as will the tools and techniques suggested below.

This isn’t an exclusive list and you certainly don’t need to do everything on it, but they are all quick, easy tools to help bottom out what it is you’ve taken on. All of these should be short interactive and illuminating exercises.

Map the reality	A mind or process map of what happens now. Use it to help create a base line of today’s current reality. This is about aligning different perspectives as much as anything.
Product vision	A short encapsulation of what problems you are trying to solve and for who.
Business & customer outcomes	I try to have about three outcomes for the business and three for the end customers. An outcome can be as simple as “reduce abandoned baskets”, for example.
KPIs	Key Performance INDICATORS. They are not targets. They are a benchmark linked to the outcomes that shows whether you are addressing them or not – so you can make an informed decision about what to do about it.
Pragmatic personas	Not a marketing persona, but a great tool from Jeff Patton that helps us understand how a customer might use a product and what might make it a success for them or not. [https://www.stickyminds.com/article/how-pragmatic-personas-help-you-understand-your-end-user]
Business model canvas	A tool that helps visualise key propositions and customer relationships. You can download one from the Strategyser website.
Value proposition canvas	A similar visual tool to the above that helps analyse the intersect where your product will meet the customer. It’s worth looking at as it’s often the weakest point in the business / customer handshake. Again, you can download one from the Strategyser website.
Identifying constraints	There are real constraints, such as legal and compliance and perceived, such as “we have always done it this way” and “I know best”. You need to know which is which.
Uncertainties	Remember, you need to know what you don’t know. And that takes some research. You need mechanism for resolving uncertainty so that you can start as quickly as possible with minimal risk.
Pre-mortem / risk storming	A classic tool. It’s 1 year after starting and the initiative failed. What happened and why? Imagine this scenario and capture the things that went wrong and now try to stop them from happening.
Roles and responsibilities	Work out who does what and why. Good teams work together to meet a common goal, not against each other.
Stakeholder maps	Stakeholders come in three main flavours: Promoters: They sponsor an idea, need or feature. Preventers: They stop you from making mistakes (like compliance, or legal). Interferers: They add no value but like having their say, like a seagull that flies in, craps over everything and leaves. Politely, but firmly, root these people out. They’re not bad people and they might be useful in the future. They’re just not adding value right now. Don’t go burning your bridges!
Customer validation	However you do it: Focus groups, A/B testing, surveys – get your ideas validated. You don’t know best. Your customers do.

Stage three: Product and Engineering working together

By this stage you should have the necessary material to be able to describe the problem you are trying to solve in detail. So, it’s time to map it out and start to bring it all to life.

This is about team bonding, challenging and being creative. Working to look at how engineering can create the what you have defined.

This is an exciting stage where the backlog is built by a forming team, together. It should be collaborative – but not necessarily about simply seeking agreement. Many of the best products I’ve delivered have been created by teams that are happy to disagree with one another, always seeking to find a better way and question assumptions.

Design sprint	Go from concept to reality in 5 days! Not for every product idea all the time, but if you can get the buy in it accelerates idea selection effectively and collaboratively.
Impact mapping	A mind-mapping technique that facilitates conversations between product and engineering ensuring that features can be traced back to the project goal via product users.
Story mapping	A workshop activity that allows people to gather round a set of high-level outcomes or functional areas, and map out the specific requirements that will be needed for the next release. Great for creating a new product backlog from scratch in an hour or two.
Minimum viable product	The embarrassingly simple first release of product that you can use to inform decision making.
Release planning	Subsequent iterations of the product made visible to everyone.
Cost of delay	A technique to help assess the half-life of an idea. You don’t want your project to deliver Christmas trees to deliver in January…
Process mapping	Thinking about how ideas get from product to engineering and then out to live. The basis of a Kanban board. These techniques help product and engineering work together effectively.
Initial product backlog	A list of problems you need to solve, requirements or actions – often written as user stories.
Example mapping	A method to driving conversations to clarify and confirm acceptance criteria. Matt Wynne over at cucumber has the definitive blog post on this.
Estimation	Estimating a product backlog item drives further discussion about what the problem is that you are trying to solve. The numbers that come from it are a bi-product that can be used for forecasting delivery.

Stage 4: Setting the team up for success

By now we should have all the information we need to get building. That doesn’t mean the engineering team is ready to go though.

Building teams is essential. They are often the highest cost of an agile product delivery too. Making a small investment at the start here outweighs the cost of a dysfunctional team in the future.

Here’s some ideas upon which to peruse:

Validate the mechanism	Are you going to use Scrum? Kanban? There’re loads of frameworks. What’s the right approach?
Team charter	A short exercise in which the team will agree the values they share and how they will work.
Definition of ready	What does a work item need to look like before the team agrees to work on it.
Testing methods	How will we know we are building the right thing right? Behaviour-driven development is a great tool here and the basis of test automation.
Training	Does the team need to develop skills before it starts? A common understanding of the intent behind agile tools, perhaps?
Expectation management	Does the team know how to set and manage expectations?
Governance	How will the team report, to whom and when?
Stakeholder management	Does the team know who the stakeholders are, how to manage them or who will do that on their behalf?
Pipeline to live / release	Devops. How will it work?

Stage 5: Getting started

Now we have to think about how the team will continue to run smoothly.

Don’t give up now! There are still things here that can make or break you.

In the same way that great sports people have coaches to help them reflect and improve, so do great teams.

This is about consciously building a culture. Don’t hope that you just get a team with a good culture, be smart about it and make it happen.

Coaching	Good teams seek help. Impartial facilitation and injection of ideas is extremely beneficial.
Backlog refinement	Little and often works well, and there are a lot of choices for how and when it should be done. One tip is to experiment and use retrospectives to evolve your approach: dropping the boring stuff while adding more detail to things that got missed.
Stopping	Knowing when and how to say no. Far too many features get built because no one challenges their value.
Reflection	Effective retrospectives. Continuous improvement. There is always a better way to work and you need to seek it out.
Team bonding	Good teams play together too. Even just getting out of the office together helps. Why not do your retrospectives off-site?
Psychological safety	Seeing every problem as an opportunity to learn. Good teams are made of people who won’t be ashamed of errors, but see them as a way to improve instead, with the whole team having an attitude of support and encouragement.

Stage 6: Doing it all again

Whelp, you did it!

The inspect and adapt nature of agile is based on the belief there is always a better way.

Whether your team disbands or stays together to take on a new challenge, get feedback about the whole life-cycle you have been through.

It’s also always prudent to do exit interviews when team members move on and, of course, keep the feedback from your customers at the centre.

What would you like to see added to the suggestions above? Please leave comments below.