STEP 4: marketable R&D projects
If you’ve reached this step in the #guide2innovate, it means that you’ve secured funding to start your R&D project, develop your product, start your business or you’re thinking ahead to when you’ll do so. Well done, because that’s when the fun really starts! But how should you go about implementing your project to ensure that it leads to results that meet the needs of the market? Here are three ways to go about it.
OPTION 1: Manage your project in an AGILE way
Regardless of whether you are working on an R&D project, developing a new product or starting your a new business, it is important to manage this process in an effective and efficient way to reach your goals and ensure that what you’re doing remains connected to those who you’re doing it for, whether that’s your lecturers or fellow researchers, a specific business owner or your future clients. Although there are many ways to manage a project, not all of them are geared towards delivering marketable results. That’s why the #guide2innovate suggests working with SCRUM, a framework that makes use of the principles of agile management.
What is AGILE management?
Agile project management focuses on producing smaller deliverables more frequently and efficiently, allowing you to introduce the solution of your project quicker than when using more traditional approaches. Agile management divides the project into smaller “bite size” pieces, promotes collaborative working with the “user” of the project, enables regular reflection, learning and adjustments (iteration) to ensure the satisfaction of the project user and integrates planning and execution, allowing teams to easily respond to changes.
To manage a project using agile, you should consider involving the ‘user’ throughout the whole process, plan for activity sprints of no more than 4-12 weeks, form a multi-disciplinary team who is 100% committed to working agile, ensure the team members are physically close (or can be connected virtually) and encourage regular and open communication among team members and the user.
The SCRUM FRAMEWORK
SCRUM is a practical (and very popular) application of agile management, providing a basic framework for teams to successfully manage complex projects. SCRUM was initially developed for the ICT sector but it has been adapted by all types of sectors and processes due to its adaptability. The SCRUM framework is deceptively simple and – like with chess – it takes a day to learn but a lifetime to master. Indeed, the more you use it, the better you’ll get at it. Learn more about the basics of SCRUM and how to set up a SCRUM project by reading the SCRUM guide or follow the steps described below!
How to start a SCRUM process
Step 1: Create a team
Most projects need a team to be implemented. If you’re using SCRUM to manage yours, the team that you pick is one of the most important success factors. To work effectively, everyone within the team should follow a common goal, play by the same norms and rules and show respect to each other. In new teams, it might take a while for everyone’s way of working to enter into sync, so count on it taking at least three sprints for the team to become mature enough to operate optimally. SCRUM teams are empowered and self-organised and they share accountability, which means that the team (and not a single member) is responsible for the timely delivery of the project results. While the size may vary, optimally a SCRUM team has between five and seven members with the complementary skills needed to complete the project.
Roles in a scrum team
Unlike a traditional project, there is no project manager in a SCRUM team. Shocking, right?! As mentioned above, the team as a whole is responsible for defining the project and its deliverable, as well as monitoring progress and quality. But it’s not total anarchy! While there are many roles that can be defined, two in particular are central to the proper functioning of the SCRUM framework:
The SCRUM master, who ensures that the scrum team adheres to the SCRUM theory, practices and rules. He/she is part of the team and acts as a “servant-leader” to the team and is fully dedicated to this task at the beginning, (thus not contributing to the sprint results). Over time, as the processes settle and the workload decreases, the SCRUM master can also actively contribute to the sprints.
The product owner – who combines the responsibilities of traditional product and project managers in a single role – represents the end customer (who will “use” the project results) and is responsible for maximising the value of the product and ensuring that the right work is done at the right time. The product owner works very closely with the team (and can also contribute to the workload) and is the only one allowed to change the set of priorities established by the team.
As you see, creating a team is an important step in your SCRUM journey, so make sure to dedicate sufficient time to getting the right people around you before moving forward!
Step 2: collect user stories
In order to plan the implementation of a project, the SCRUM framework typically works with user stories instead of specifications or objectives. User stories are short narratives where a specific subject (an actor) describes a specific wish or criteria for a product and they have the advantage of describing what someone wants without going into how this will be achieved.
User stories can be formulated in different ways, but a typical template would be: as a < actor > I want / wish < accomplishment >, For example, “as a business owner, I want my product to be cheap for consumers”, or “as a product owner, I want everything to be finished in time and on budget”. They can be as big (“I want our product to appeal to everyone in the world”) or small (“I want my lecturer to approve my budget”) as you can imagine and should be collected from as many different actors as possible, including all team members and any others who (might) have an interest in your product (think the business owner with whom you’re working, the lecturer who’ll evaluate your research project or potential new customers who you’ve identified for your new business).
We recommend collecting user stories using post-its or cards that you can hang on the wall so that you can put them all together and move them around when you’re organising your product backlog (which we’ll get into next).
Step 3: create a product backlog
This step simply involves organising all of the wishes and ambitions collected through the user stories according to their level of priority in the process. One way to do this is by creating an iceberg and organising user stories in three levels: the future, not yet scrum-able and scrum-able. While the future holds the wishes and ambitions that are currently too far away in the process to plan for, the “not yetscrum-able” section holds all of the elements that still need further thinking or time to work out and the “ready to scrum” section contains the elements that need to be addressed first and that should be included in the upcoming sprint.
During this step – which the whole team works on together – the product owner plays an important role in deciding which wishes and ambitions collected through user stories should be kept or discarded, whether there are elements missing from the whole picture and which elements to prioritise for the next step. Nevertheless, the whole team should critically discuss and agree on whether the product owner’s vision and expectations are realistic and achievable.
Step 4: Build a sprint backlog
Having identified the things that you should focus on first, it’s time to plan your first sprint! You can do this creating a sprint backlog, which is a list of tasks identified by the team to be completed during the SCRUM sprint. This normally means translating the user stories (wishes and ambitions) that you put at the top of the iceberg into a set of tasks, basically describing how you expect to achieve it. Four elements are very important in creating a sprint backlog:
Duration of a sprint: SCRUM works best in projects that run for 4-12 weeks (or longer projects that can be cut into chunks of 4-12 weeks) and a sprint should last about 1-2 weeks, so keep this in mind when making your sprint backlog by defining tasks that can be complete within the available time or dividing longer tasks into smaller steps.
The Definition of Done (DoD): This describes exactly what it means to have completed a task, which helps to create a common understanding of what a task exactly entails. For example, if the task is to “make invitation for event”, does this simply mean creating the text or also the graphic design? Should it also include a guest list? Having a DoD helps to clarify expectations and in planning implementation.
Time of completion: Next to the DoD, the team also needs to agree on how much time is needed for each task. One way to do this is by creating a standard measures (for example, XS for tasks up to 2 hours, S up to 1/2 day, M up to 1 day, L up to 3 day and XL up to 1 week). This helps to calculate the total amount of time to be spent during the sprint. Although this be difficult at the beginning, it becomes easier after one or two sprints.
Development team: Finally, a team is assigned to work and report on each task. If no one is made responsible for a task, no one will feel responsible for getting it done.
It might take a while, but properly planning a sprint is crucial for the whole framework to work, and over time you’ll see that the more often you plan sprints, the easier it gets and the more accurate your plans will be.
Step 5: Get sprintin’!
After all that planning, it’s now time to get sprinting! Sprints work best if the workload and progress are visible to the whole team, which is why teams usually work with a physical boards where all sprint tasks are posted and moved from “to do”, to “busy”, to “done”. At the end of the SCRUM, all tasks have ideally moved across the board and been completed. For a sprint to work, it is important to keep a continuous overview of the progress of all team members, flag and address any complications as soon as they appear and – most importantly – improve with every step. To enable continuous transparency and learning, teams are in constant contact, which happens in the following specific meetings:
Stand-ups: Short daily meetings during which the scrum master discusses the progress made the day before with the team members, as well as plans for the current say. These meetings should be short (normally about 15 minutes) and preferably be done standing up around the sprint backlog.
Sprint review meeting: This takes place at the end of the print to show the results of work to the product owner and anyone else who’s interested. This meeting is also used to measure the delivered results against the planned sprint goals.
Sprint retrospective meeting: During this meeting, the team looks back at the sprint and tries to identify ways to improve the process. To make it easier, the meeting can be organised around three questions: What should the team start doing? What should the team stop doing? What should the team continue doing? The meeting is facilitated by the SCRUM master and all learnings are taken on to the next sprint!
That’s it! Once you’ve finished the sprint, you start it all over again! Plan. Sprint. Review. Repeat!
OPTION 2: Prototyping
When you are undertaking your R&D project within a company, it means that you have the opportunity to test your solution in the ‘real world’. The benefit of testing in a company is that you can receive immediate feedback on your product or service innovation, and you can quickly learn the extent to which your solution responds to the problem of the user (the business owner in this context).
To test your assumptions about how your solution works in practice, you can develop a prototype, as a draft version of a product or service that allows you to explore your ideas. It enables you to show the intention behind a feature or the overall design concept to its users before investing a lot of time and money in development. In prototyping, you have a bias towards action and learn by doing.
Prototypes can take different forms, as long as they make your ideas more tangible. When you decide to prototype, it is important to reflect on how you can communicate your ideas in the cheapest and easiest way possible. Prototypes can be paper drawings or mock-ups, storyboards and short videos about the product or service. More advanced prototypes may already allow testing some of the functions of your solution (i.e. one element of the solution) and experience first hand (e.g. through role plays) what benefits the solution offers.
Prototyping makes it much cheaper to change a product or service early in the development process, while it allows you to gather feedback from the user(s) early on and more regularly, thus reducing waste.
If you want to develop a prototype to test your R&D solution, consider answering the following questions:
Which elements of the solution should and can I test (now)?
What is the easiest and cheapest way to test (which elements of) the solution?
What materials do I already have access to that I can use to build the prototype?
Steps to prototyping
Step 1: Just start building
Design thinking has a bias towards action: if you have any uncertainties about what you’re trying to achieve, your best bet is to simply make something. Creating a prototype will help you to think about your idea in a concrete manner, and potentially allow you to gain insights into ways in which you can improve your idea.
Step 2: Don’t spend too much time
Prototyping is all about speed: the longer you spend building your prototype, the more emotionally attached to your idea that you can get, thus hampering your ability to objectively judge its merits.
Step 3: Remember what you’re testing for
All prototypes should have a central testing issue. Don’t lose sight of this issue, but at the same time don’t get so bound to it that you lose sight of other valuable lessons.
Step 4: Build with the user in mind
Test the prototype against your expected user behaviours and needs, then learn from the gaps in expectations and realities, and improve your ideas.
OPTION 3: INCUBATION
If you believe that your R&D project has a viable business case, you can opt to explore whether you can approach it from a business start-up perspective. You’ve made a plan outlining your business case and why you believe that it works. However, starting a new business is a costly affair and is difficult to do on your own. This is why participating in an incubation program may be of interest for your R&D project.
In business incubation, you get the opportunity to test and develop your business in a supportive or ‘safe’ environment. Business incubation programs offer support to start-up companies through a range of business support resources and services, which can include physical space, capital, coaching, common facilities and services and networking connections, tailored specifically to the needs of early-stage companies. The services offered are often sponsored by private companies or municipal entities and public institutions.
To join a business incubator, you usually have to submit an application. The criteria for acceptance may vary from program to program. One important criterion is usually the feasibility of your business idea and the quality of your business plan. You may also have specific ‘learning’ questions in mind that require the support of specific experts.
If you consider incubation to develop your R&D project, it is important you first ask yourself:
What specific support do I require right now? (What needs immediate attention for you to prove the value of your project? What element of your projects requires most effort? Which questions can be answered the most easily?)
What can I do myself and where do I need help from others? There might be elements in your project that you can do without much support, whereas for other elements you need to get on-board additional expertise.
The answers to the questions above may help you in your search for an incubation program that fits with your current and most urgent needs. Don’t be seduced by the first incubation program that you come across. Make a shortlist of relevant programs, check them out, start a conversation and determine your best fit. Choose wisely! There is no point enrolling yourself in an incubation program that cannot offer you the support that you need!