Planning a ‘firebreak’ – beta website development

We are starting our first ‘firebreak’ – a short break in a development cycle to rejuvenate and reset the team. Because this process is new to us, we thought we would share the thinking behind it. 

To develop our new website, we have been using the iterative development approach known as Agile. This means you build software in small, incremental stages, called sprints, working to achieve a series of goals that can be released as features or fixes periodically. In contrast to other approaches, Agile encourages the development and release of individual functions as opposed to a whole, finished product. This is what has enabled us to release our website in its “beta” stage. 

Each Agile development is unique, and we have chosen to work in three-week sprints. During this time our development and technical teams deliver features, bug fixes and infrastructure changes. 

This is a very intensive way of working and the team can quickly burn out if the cycle is not broken. We looked to the Government Digital Service, Google and other tech organisations to see if they had any solutions, and they did – a ‘firebreak’. 

A firebreak is, as the GOV.UK team describes it, a time to “investigate new ideas”, allowing developers to “scratch their own itches”. We decided that a two-week firebreak once a quarter would help to maintain development pace and morale. The break would help the development and technical teams to reflect and recharge by working on their own ideas for the Scouts. We could also use this time to reflect on our work, meeting with key stakeholders to look at the year ahead and plan for the next quarter. 

We also decided, to ensure we were maximising value from the ‘break’, that we would set some rules. 

How it works 

Just as in a normal sprint, the team comes together to discuss issues. In this case, they also discuss ideas they have had, to see whether it ‘has legs’. As individuals, or in small groups, team members then pitch their idea, explaining what it is and why they feel it’s important. 

To ensure pitches are relevant to the development of our website, they have to fulfil these criteria: 

  • the idea must be related to the overall direction we are moving in; 
  • the work must be completed within the firebreak and take no longer. 

The team then votes on ideas they want to work on and those they feel will positively impact the Scouts. From this, our firebreak work is decided. Development work then begins and is presented at the end of the two-week period. 

We can’t wait to share the outcomes of our first firebreak with you.

Prototyping: what it is and why it’s useful

We mentioned in our end of year roundup that we were developing a prototype of our new programme planning tool for section leaders.

We’ve been testing this with a Community of Interest group and, during those tests, explained the purpose of a prototype within the wider context of the tool’s development.

Prototyping is a crucial part of the design of any modern tool, so we thought we would go into more detail about why.

 

What is a prototype?

A digital prototype usually takes the form of wireframes. Wireframes are simplified designs which help to keep a viewer’s focus on the substance of the product rather than the designer’s visual choices, like which font they used.

Images like this are intended to demonstrate the functionality of a tool. Copy may not be finalised and images may be lacking but the viewer is aware of the purpose of the page.

Where a wireframe becomes a prototype is when a tool links these images together. There are various online services that provide this functionality, such as Marvel, InVision and Axure. We’re using the latter to prototype our digital programme planning tool. Linking wireframes together allows a static page to emulate a functional tool.

 

What is a prototype for?

A prototype is intended to help viewers test what we have designed without distraction. The aim is to see if the user can fulfil their goals on their own. It isn’t the time to critique colours or image choice, hence the rectangular box with an ‘x’ in the middle which acts as a placeholder for an image.

This helps to evaluate ideas and, through testing, to learn what we didn’t know. That lesson could be how people react to the placement of a button, or what users are expecting from your tool. A prototype will help you develop and test the function, as opposed to the visual form.

Because a prototype is not the finished product, it can prove integral to ensuring development is on the right track, before going too far in the wrong direction. Being careful to avoid bias, user engagement through prototyping can help to keep the development of your tool focused on creating a positive user experience.

What next?

Once you have a prototype you and your testers are happy with, you can start to create the visual design, or the form, of your tool.

Creating a digital tool like this means constantly balancing form and function. It is incredibly easy to do one or the other – the hard work is striking the right balance.

To learn more about our digital programme planning tool, or to become part of our digital Community of Interest group to assist with future testing, please get in touch.