Home Blog Agile Starting app development efficiently - how to do it?

Starting app development efficiently - how to do it?

Whether your new digital product is part of a complete digital transformation of your business or just you dipping a toe in the app or digital platform waters, here at Boldare, we know agile is the way to go. It allows you to be both bold and cautious – brave enough to aim high but careful enough to minimize the risk of doing so. Agile frameworks like scrum are tailor-made for digital product development and beneficial for both business stakeholders and end users of the application. But while agile might be the professionals’ choice, that still leaves the question of how exactly to begin your agile project so as to give yourself (and your product) the best chance of success. Read on to learn more!

Starting app development efficiently - how to do it?

Table of contents

Beginnings are important.

Ask any storyteller.

And if you want the story of your digital product to end well, the best way is to begin well. At the beginning of any agile project, you need to get the right people working in the right direction (not to mention the same direction!) and on the right problem. What you’re aiming to do is align everyone behind a deep understanding of the issues, problems, and likely solutions. How to do that?

Boldare co-CEO Piotr Majchrzak has the answer:

“We start with a meeting. A very long meeting.”

We call that meeting a Product Discovery Workshop.

You might be also interested in the article:

Product discovery workshops - practical insights on how we do it

Product discovery workshops - practical insights on how we do it

It might seem more obvious to start with reading through the client’s desired product specifications. But that’s getting ahead of ourselves and there are risks to using documentation to find out about the product; not least of which is that assumptions might be made (about users’ needs, about the product’s purpose, etc.)

Much better to start with as blank a slate as possible, get all the right people (and knowledge) in the room and work out the picture together. Especially when we’re working with a client with little or no experience of scrum or agile product development, in general.The benefits of product discovery

Before we get into the ‘what’ let’s agree on the ‘why’. There’s one key benefit to beginning with a product discovery workshop: shared clarity.

With the right focus, after a couple of days of exploring everything about the product to be built, both our development team, the scrum master and the client’s product owner have a common understanding of what we will be building, how we will go about building it, who we’re building it for, and why.

This shared clarity means that the whole team and all of the major stakeholders are viewing the project in the same way. This means project decisions are relatively easy to make because the priority goals and features have been agreed in advance. Likewise, if any of the key influencing factors change (market, users, client’s business needs) and a pivot is necessary, that same clarity and priorities usually mean identifying the project’s new direction is relatively easy.

Furthermore, teamwork is enhanced as not only is everyone on the team involved, but also the necessary protocols (e.g. for communication within the project) are agreed, effectively laying out a route map to the project’s core goals.

A product discovery workshop is a time- and resource-efficient way of focusing the team, building trust, and motivating key players.

You might be also interested in the article:

Product Vision Workshops – seeing clearly from the beginning

Product Vision Workshops – seeing clearly from the beginning

Product discovery meeting goal #1: Meet the team

It might seem the most obvious (and easy) outcome but the value of getting everyone who’ll be working on the project (in whatever capacity) together cannot be underestimated. Diverse teams bring a variety of experience, knowledge and perspective to bear on the project, resulting in a better quality product. One purpose of the product discovery workshop is to align and focus that diversity on a single problem: the development of the product.

Who should be there?

From the client’s side, at a minimum the product owner. The product owner is the representative of the client’s business and strategic needs, and can provide insight into the ‘why’ of the product and what user problems the product is intended to solve.

Also attending is the development team itself, including not only the experts who will be doing the coding, but also UX and, product designers, quality assurance specialists (QA), and business analysts (BA), depending on the complexity and requirements of the project. Also present is a scrum master. The scrum master is not intended to be a project manager. Rather the role is one of facilitator, keeping the team (and project) within the scrum framework; i.e. he or she is focused on the process, allowing the rest of the team to dedicate their efforts to more creative work.

You might be also interested in the article:

6 benefits from having a QA/BA in your development team

6 benefits from having a QA/BA in your development team

Often, when the product development is being carried out by an outsourced team, the product discovery workshop is the first (and perhaps even only) time everyone involved in the project is together – it is the golden opportunity to ensure the project is heading in a productive direction from day one.

Product discovery meeting goal #2: Discover the product

Now we’re getting to the heart of the matter – or at least, the activity that the workshop is named after: finding out all about the future product for development. To do this, at Boldare we recommend a few key tools:

Product canvas – A product canvas is a simple template that ensures we address the key questions in relation to the product, gathering all the necessary information for an agile user-centered product solution: the product’s goal or reason for being (i.e. what problem does it solve?), the business benefits, metrics to help measure success, details of target user groups and the benefits the product offers them, and the product’s non-technical context (including UX, user journeys and visual design), all wrapped up in actionable goals. As a tool, the product canvas works perfectly with scrum and the lean startup approach that we combine in our projects at Boldare.

Product backlog – Once you know what you’re building and why, you need to agree what to do and in what order. This is the product backlog, effectively a to-do list of all the work and tasks necessary to build the product. Each individual sprint during the project is focused on selected items from the product backlog. Naturally, the product backlog is under regular review throughout the project. It usually covers the next three sprints, with additional tasks (and sprints) being added as they are identified. Part of managing the product backlog is agreeing the ‘definition of done’ for each task.

User story mapping – To ensure user focus during product development, we use user story mapping to delve deep into specific user needs. A user story is a brief description of a product feature from the perspective of the user, incorporating three key elements: the feature, the type of user that needs or wants it, and the motivation for that need or want (i.e. the benefit to the user). By mapping the various stories we create a detailed picture of the product’s intended use. User story mapping keeps users front and center in the product development process.

You might be also interested in the article:

Budgeting in agile software development - how it’s done?

Budgeting in agile software development - how it’s done?

Product discovery meeting goal #3: Plan a release

Now you know each other, and the product, the third step in product discovery is to agree the scope, deployment and timeframe for the first product release – probably a minimum viable product that will be used to gather user feedback for further development.

This discussion also includes agreeing the development process – effectively a set of project protocols, including how long a sprint will take (usually two weeks), what tools will be used, how team members will communicate, and also risk management for the project.

Product discovery meeting goal #4: Plan a sprint

The final major task of the product discovery workshop is to plan the first sprint, ensuring that the project gets off to a flying start. This begins with deciding which items and actions from the product backlog will be tackled in the first sprint. The results of the planning process should be threefold:

  • The agreed list of backlog items to be the focus of the sprint.
  • The ‘definition of done’ for each item.
  • An overall sprint goal (this ties the sprint activities together; it’s effectively a ‘definition of done’ for the whole sprint).

For more detail and depth on sprint planning, check out our Guide to Efficient Sprint Planning.

Once all four of these goals have been achieved, the preparation is done.

And, more importantly, it’s signed up to by all involved – the development team and the project’s key stakeholders. Now you can get on with the project, start the first sprint, and begin the practical product development secure in the knowledge that you’ve done all you can to ensure you’re on the right track to success.

Yes, you may have to pivot later but if you’ve done the right preparation, any future pivots will be due to unforeseen circumstances and not a lack of planning.

You might be also interested in the article:

Build better digital products with user story mapping

Build better digital products with user story mapping

A final thought: Do you meet remotely or face to face?

In the past, we would gather everyone together in the same room for a product discovery workshop. But in 2020 (and beyond), this shouldn’t be an automatic choice. In fact, many people may prefer to be part of an online event, given the pandemic crisis.

You might be also interested in the article:

How is it like inside Boldare on remote?

How is it like inside Boldare on remote?

The good news is that like any other meeting, it’s possible to run an online version of a workshop with multiple-participant video-conferencing software (like Zoom or Google Meet). Undeniably, the first time you run an online product discovery meeting, with everyone scattered, collaborating on these critical project questions will be more difficult. Communication may not flow quite so smoothly. The facilitator will have to be especially observant. Everybody may need a little extra patience.

The value of the product discovery workshop as a start to your digital product development project means that whether it’s face to face or online, you really shouldn’t start development without one.

So long as it achieves the following:

  1. A clear vision and goals for the project
  2. A structure for communication and decision-making within the project team.
  3. Agreed project roles and responsibilities.
  4. A detailed route map for moving forward.

Currently we are conducting those workshops online. We established some good practices that allow us to keep both sides engaged and fresh during those intensive hours. The secret ingredients are good tools (we usually use Miro and Mural but also user story mapping, and product canvas/vision techniques), two facilitators and … regular breaks!

You might be also interested in the article:

Event storming or product vision? Discover workshops that will help to build your next app

Event storming or product vision? Discover workshops that will help to build your next app

Start well, design well

Endings depend on beginnings.

And if you want your project to result in a high quality digital product, developed with your specific user groups in mind, proper preparation is key.

The core of a good beginning is the product discovery workshop; an event that brings everyone together (physically or virtually) and allows them to explore in detail the task ahead of them using tools such as the product canvas and user story mapping. The outcome is a detailed plan for the project, including everything you need to get started on that initial sprint and deliver a first product increment.