So let’s start with a bit of an introduction.
After 10 years of learning about software delivery and actually delivering IT products, I’ve confirmed for myself that I really like to create things. Whether it’s a quirky side project or a core system for a large organization, creating applications always triggers a combination of analysis, creativity and a lot of learning. However, it’s not just the creation I have enjoyed. The process that guides the creation and sharing thoughts about different approaches within that process started to interest me along the way. Designing and delivering apps at both medium-sized organizations and varying departments of large enterprises (ERM, NCOI, NS, Philips, Rabobank, Vodafone) in different countries gave some interesting insights into when things work, and when they don’t.
It’s time to write down some of the things I have observed and more importantly, some perspectives that those observations gave me. Many times, I’ve come home from a day of work with an urge to share the day’s lessons. A particular approach led to a successful outcome that I had not seen before or, on the other side of the spectrum, not thinking about proper next steps hampered progress. Some questions that I have asked myself and got asked by others include.
With this blog series, I aim to go beyond the methods that are described abundantly. Design sprints, lean startups and agile sprints, they offer organisations great ideas but are not always as straight-forward as the articles and books that describe them make them out to be. I’ll dive into applying these methods and into the why behind them. The stories will probably be most insightful for readers with basic knowledge of concepts like agile and design thinking, but might provide enough background for people new to the field. My experience is based on reading and creating software for companies that are not in software development themselves; it might or might not be different from experiences at the big tech companies.
In the end, I hope to get to the principles that help you and me deliver great applications. Great applications that aren’t built just for the sake of having an application, but that are the best way to fulfil a need or opportunity.
So what are we waiting for, let’s get started!
It’s the first step in Google Venture’s design sprint and the start of applying Lean Startup, setting a goal. The idea of ‘starting with the end in mind’ makes sense, it’s the number one step that prevents you from solving the wrong problem. While it’s easy to come up with some goal and most organizations have thought about it, it’s worth diving a bit deeper into its nuances. The goal is one of the most crucial elements in creating the right solution and — less obvious — bringing important stakeholders together.
As the book Sprint explains, a design sprint starts with the definition of a one-sentence goal. This sentence should be specific enough to provide guidance, but generic enough to find out the actual reason why you’re here. It thus lies somewhere between ‘we need to make more money’ and ‘we need three screens with tables’. When asking an organization for the goal of an app development project, the answer is usually too specific instead of too generic. Finding the background of this specific goal is related to the Five whys technique in which people are encouraged to dig a bit deeper to find the actual cause of a problem.
Applying the why-technique (let’s forget the number of whys) is very relevant when building software, since the initially defined goal is more often than not ‘to have an app that can do this and that’. This starting point can be iterated upon in two parts:
Let’s go through this with an example: “We need a mobile app that brings the organization’s news to its employees”. Getting rid of its first part is quite easy and turns it into “We need to bring the organization’s news to its employees”. Notice how we ignored the part that defined the ‘mobile’ need. The context and modality of what you will create are assumptions that should not be addressed in the goal, but later.
Onto the second bit. Asking why you need to bring the organization’s news to the employees is the start of improvement. It might seem like an open door and it might raise some eyebrows, but there’s usually nuance to be found. A first answer could be that the employees need to be informed, which should both lead to a second why and challenging this assumption. The challenge is needed because an organizational news app is usually not only to inform employees. Often, it’s also to engage people and to create a bit of a community feeling. Getting more clearance on the why will lead to a better idea for the what. Informing employees could be done by pushing some C-level defined messages or giving people the ability to find what they consider interesting. Asking why employees need to be informed can give this insight. Do they need to perform their tasks in a more compliant way, does the leadership team want to flatten the organization?
You get the idea. An example of a resulting sentence that you might be happy with after some iteration is “We need our employees to work more efficiently by knowing what’s happening in the rest of the organization”. Be aware that it’s not the task of a workshop facilitator to define the goal. Rather than giving your own opinion, asking the right questions and repeating the participants’ input will help people to formulate the correct sentence.
The goal should not only give guidance to the direction of the rest of the project, but also build the common ground of your audience and give them a feeling of ownership. In my opinion, this is the real value of pushing for one specific sentence; a discussion about one word can show a different perspective on the project goals from different stakeholders.
The one-sentence approach is not the only and not always the best approach. In a workshop with low attendance or only one person with a vision for the project, the bringing-together-effect is minimal. In these cases, one of the following focuses could be more important:
This hopefully gives some extra ideas and insights for defining the goal of your application development project. In short:
Business Technology Consultant