“The best way to have a good idea is to have a lot of ideas.”

Linus Pauling

Overview

For a long time, addressing software needs has been the responsibility of IT departments, with ideas for new or improved applications typically ending up in a backlog of IT demand. Given the often-constrained capacity of the IT team, they must continually prioritize their efforts, which inevitably means some ideas get deprioritized and pushed to the bottom of the backlog.

We introduce an approach that eases the burden on the IT department by empowering the business to mature ideas and kick off the process of creating eventual solutions. Done correctly, this will eliminate effort and the often-lengthy time frames associated with pitching an underdeveloped idea to IT. In addition, it will have the added benefit of reducing the burden of up-front paperwork and evidence. Ordinarily, the IT team would want a level of detail for the solution that may yet to have been broadly considered or articulated. This slows down the process further, often resulting in scope creep and an underdeveloped solution being built. Given the inherent suitability of citizen development platforms for this purpose, Ideation 2.0 presents an approach that combines brainstorming and real-time developing, which enables organizations to drive significant value in condensed time frames.

Looked at another way, Ideation 2.0 is about avoiding the pitfall of taking a snapshot of an idea in its infancy and handing that over to the IT department to build. It is about recognizing that sustaining ideation during the build phase is something that should be encouraged. Citizen development can harness this approach to shape, and ultimately deliver, a better end product in less time.

Ideation 2.0 differs from standard ideation processes in two key ways:

•Ideation continues throughout the full process of designing and developing the app.

•It involves real-time design.

Ideation 2.0 in Practice

Guidelines for Ideation 2.0

•Ideation 2.0 is about speed, agility, and collaboration with minimal documentation. To borrow from the Agile Manifesto: “Working Software Over Comprehensive Documents.”

•Idea refinement happens concurrently with development of the solution, and not just at the beginning of a project.

•Ideation is a nonlinear process. Inspiration comes from a deep understanding of not only the problem, but also the wider environment, and should involve stakeholders from across the organization with different points of view and specialisms.

•Real-time development is at the heart of Ideation 2.0. The principle is to create mock-ups and working solutions in place of extensive documentation and design specifications, and do this very quickly.

•Ideation 2.0 works best with a minimum of two iterations of idea refinement and real-time build, done collaboratively.

•The Ideation 2.0 process is applicable and encouraged across the life cycle of the project, from the idea to project execution.

•Ideation 2.0 works well even when the solution has been published into the live environment. It is particularly well suited to facilitating focus group sessions with end users of the application.

•A citizen developer practitioner or someone who is competent in the chosen citizen development platform is required to lead the mock-up of the brainstorm in real time.

•Outputs of an Ideation 2.0 process are continually updated with each subsequent iteration.

Ideation 2.0 Outputs:

•Product vision board (Tool 1)—A simple, yet immensely powerful, tool that agile and, in particular, Scrum practitioners will be very familiar with. When well crafted, it is a clear and concise communication tool and acts as the team's North Star. It informs and influences everything from who is engaged and to what extent, how the application will fit in the wider landscape, what requirements are captured in the backlog, and what the build priorities are. It is intended to be high level and should give direction in an easily digestible manner.

-Vision: “What is the motivation for creating this application? What positive change will this bring about?” Completing the vision section can sometimes be the hardest part of the exercise. Some teams do this at the beginning, but it can also be a task well suited to wrap up the ideation process. The vision needs to be succinct and precise, but also not overly restrictive. It is key to note that the vision isn't really about the application, it's about what purpose the application will serve and the problem it will solve. One good example of a company's vision statement is from the Swedish furniture retailer, IKEA: “To create a better everyday life for the many people.”

-Target group: “Who are we building this for? Who are the users?” The target group section is our customer hypothesis and should be populated with those groups that will be served by the application. It is good practice to define narrow target groups and broaden them later if necessary. This will inform the user stories that will be created.

-Needs: “What problem will the application solve? What benefit will result from this application going live?” This is both the problem hypothesis and value proposition and should address why anyone would want to use the application.

-Product: “What are we planning on building? What does the application need to have and do?” In this part of the template, we should be aiming to describe the key defining features of the application that are crucial if it is to address the needs of users and be adopted. This informs the backlog that will be created.

-Business goals: “Is it worth investing in this application? How does this help us achieve our overall business goals? Will we be able to achieve these business goals by equipping our target audience with the application we are proposing to build?” This is the solution hypothesis and is about creating the case for investment. This will help guide prioritization of the backlog and will be invaluable for any external (to the core team) stakeholder communications.

•User stories (Tool 2)—This is another staple of agile project delivery that has its origins in Extreme Programming (XP). User stories are short and simple descriptions of ideas or desired features from a specific user perspective. These user stories should be continually reviewed and refined. Indeed, the level of detail contained in a user story evolves over time, either by decomposing them into smaller user stories, or by adding conditions and prerequisites as they become apparent.

•Backlog: As described by Scrum.org, this is an ordered list of everything that is known to be needed in the product. The product backlog can be represented in physical form using sticky notes, or electronically in a spreadsheet or one of the many purpose-built backlog tools that exist. Electronic boards are the better option for a team that has remote members. Physical boards offer the advantage of making the product backlog continuously visible and concrete during discussions around the product backlog. A fundamental aspect of the backlog is that it is ordered (and reordered) to represent the priority of the desired features.

•Application mock-up: Following an initial brainstorming session, the team can start to mock up their solution straight into the citizen development platform.

-There are a few ways that the team can elect to start the mock-up exercise, and it depends on which part of the solution is best defined at this early stage in the process.

>Start with the UI—Does the team already have a good sense of what the user experience and visual components are going to look like? If so, then designing the user interface is a great place to start.

>Start with the workflow—Perhaps the user groups are well understood and the relationships between them are already articulated sufficiently. In this case, start with constructing the underlying workflow.

-Whatever starting point is chosen, performing a collaborative mock-up of the application in the citizen development platform is an opportunity to rapidly prototype and test assumptions at project inception. How straightforward is this to build? Can we deliver on the needs of our target audience and build the features required? Can we do this without needing IT delivery support? Perhaps we need to focus our effort on a particular stakeholder group rather than try to cater to everyone? Maybe that feature isn't so important, or the value is marginal given the effort to build it.

-Many aspects of the proposed solution become apparent during the initial mock-up exercise, and even more so during subsequent iterations. This activity provides useful insights that can result in a refinement of the product vision board and reprioritization of the backlog and user stories.

Figure 5 is an example of a filled-in product vision board. Following Figure 5, we explain what each of the five sections of the template are and best practices on how to fill it in.

There are a variety of ideation techniques that could be used to help populate the outputs from Ideation 2.0. The following is a description of how one of these, the really round robin, can be applied.

A practical approach: Really round robin

The really round robin is an enhanced variation of the round robin brainstorming technique. It is a highly creative approach that focuses on building up ideas as they are handed over from one stakeholder to the next and then leveraging the citizen development platform to interactively and iteratively mock up the idea into a working solution.

Key characteristics of a really round robin:

•There are two fundamental outputs from a really round robin:

-The ideation board, which is used to facilitate the real-time mock-up; this is the basis for creating the product vision board, user stories, and backlog.

-The application mock-up, which is the foundation of a working prototype of the eventual application; the mock-up can be continually worked on and refined in subsequent really round robin iterations, or it can be handed over to the IT department, depending on the complexity of the idea and the ability of the citizen developer.

•The optimal team size is between four and eight, including individuals from the team or department where the idea was conceived with representation from individuals who bring in the perspective of the wider environment. Larger team sizes can be accommodated if individuals are allocated into subgroups to work together.

•At least one member needs to be a skilled citizen developer practitioner who can perform the real-time mock-up.

•A really round robin takes at least 1 hour per iteration, increasing in time, based on the number of team members.

•A really round robin is underpinned by the ideation board, which is populated in the brainstorming session, and updated and refined in the mock-up. The populated ideation board will help create a product vision board, user stories, and the backlog for the initiative.

•Easily visible space is required to collate all the inputs from the team members. We recommend sticking or drawing the template (see Tool 1) on a wall, whiteboard, or flipchart; however, there are numerous online equivalents that can work just as effectively for those in remote teams.

•Each team member is given the opportunity to present their ideas to the group without being influenced by other members.

•Silence from the group is vital when one member is speaking. They can talk uninterrupted for a brief time period that is agreed upon up front, e.g., 5 minutes.

•After having their views captured and being given a chance to speak, the team spends some time discussing the different perspectives and attempts to resolve them. When this cannot be achieved, the team assigns these to a subsequent really round robin iteration, involving stakeholders who are better placed to address some of the open items in the backlog.

Really round robin in practice

Here, we look at one approach to conducting a 2-hour really round robin iteration, with five participants on the team.

•Really round robin brainstorm (70 minutes): The exercise starts with collaborative brainstorming, facilitated by the idea originator and/or the citizen developer practitioner.

-The idea originator and the citizen developer agree up front regarding the questions or prompts they want to include in the template. (5 minutes)

-Participants are invited to capture their thoughts onto the ideation board (Tool 3) e.g., on color-coded sticky notes. (15 minutes)

-Each participant then has a preallocated slot (in our case, 5 minutes) to talk through their views without interruption. The rest of the team captures notes or questions during this time. (25 minutes)

-After each member has spoken, time is allocated for questions, clarifications, and discussions of divergent points of view. The facilitators capture additional items on sticky notes while the discussion ensues. (25 minutes)

•Mock-up (50 minutes): The citizen developer practitioner starts the mock-up based on the unanimously agreed statements. The citizen developer practitioner can seek clarifications from the other team members as the mock-up starts to take shape. The idea originator makes sure to capture items from the team in the backlog, and any considerations, design constraints, or points of contention in the ideation board as the mock-up progresses are guided by the practitioner as to what they can or cannot build in the session.

Output:

•An ideation board containing:

-Set of agreed statements that have informed the mock-up

-Backlog of agreed statements that need to be built into the app

-Points of contention that do not have agreement, allocated for review by different stakeholders or experts in a subsequent really round robin iteration

-Set of design queries or constraints that arose in the mock-up session and could not be resolved

Subsequent iterations of the really round robin will help to further refine the idea and build on the mock-up. The questions or prompts in the ideation board can be adjusted to encourage alternative or more focused thinking where more detail is sought.

It is important to remember that while really round robin is ideal for Ideation 2.0, it is a highly iterative and collaborative process that can continue to be applied throughout the design and build of the application. It is a means of pulling together a community of informed or impacted individuals, or those representing and holding important technical and domain experiences, who are able to influence and guide the continual evolution of the idea and the solution that is being built.

In traditional application development, such an approach would inherently be labeled as a source of scope creep. New requirements proposed while in the build phase have been the bane of many a project manager or software developer working under tight and inflexible time lines and budgets. However, it is by virtue of the flexibility and ease of use of modern citizen development platforms that many new features or “mid-flight pivots” are far less disruptive and easier to accommodate rapidly. Indeed, scope creep is something to be encouraged in this new way of working. It is a recognition of the fact that we will not get the design right, nor complete, at inception. As an application evolves, new ideas or feature requests are triggered that shouldn't have to be consigned to a future release if they are adding immediate value for users of the solution and can be relatively easily built by a savvy citizen developer practitioner.

Participants add their thoughts to sticky notes and adhere them in each box.

Hackathons and ideathons

Hackathons are events where people come together to collaboratively transform ideas into reality. Facebook's “like” button and chat features were famously divined through an internal company hackathon. The scale of a hackathon can vary in the number of participants (ranging from the tens to the several thousands) and events (usually lasts around a day or two, though some can extend over several days). A notable characteristic is the use of technology to cocreate solutions in a sustained, deeply intensive burst of concerted activity.

Similarly, an ideathon applies the same collaborative and cocreation approach. Where the goal of a hackathon is to create a tangible prototype or application, ideathon participants propose and refine ideas to solve existing challenges by applying design thinking methods and practices. Ideathons are typically shorter than hackathons and can last from a few hours to a day.

Both hackathons and ideathons are meant to be fun, engaging, and high-energy events, full of hype and excitement. As a community, participants should feel a shared sense of purpose. Individually, they should be comfortable and inspired to play their part in helping to achieve the outcomes of the event.

So, what does this all mean in terms of Ideation 2.0 and citizen development? For a start, introducing citizen development platforms in the mix allows us to make such events much more special, involving, and impactful. The simple and clean visual interfaces and intuitive methods of building are particularly well adapted to being cast on large screens for large teams or groups of audience members, while enabling individuals to easily follow actions performed by the citizen developer practitioner.

A hackathon is an alternative approach to the mock-up phase in the really round robin, albeit more intensive and grander in scale. Similarly, the ideathon is brainstorming at scale. This means that these events can be used individually or combined as a means to effectively achieve the goal of Ideation 2.0. Compared with a regular really round robin, there will be a broader and more diverse group of stakeholders contributing to the effort. The action-oriented spirit of the event will be beneficial in making big strides toward thinking about ideas and building the corresponding applications. Further refinement of the idea and application can then be managed through subsequent breakaway really round robins as required before publishing into the live environment.