Help centre

← Go back

How do we develop new features?

Introduction

The process described here is the process we use for managing work specific to individual clients (implemented by our Projects team). The process for products work is slightly different.

The general objectives of the process are as follows:

• Agility: to provide us the ability to respond to change, by delivering change incrementally and at low risk
• Visibility: to enable us to let our clients know at all times the status of all work relevant to them
• Control: to give our clients an effective means by which to prioritise the work relevant to them

The Workflow

BeBanjo follows a Kanban workflow for software development, by adhering to these 3 principles:

1. Visualising the workflow
2. Limiting work in progress
3. Measuring and managing cycle time

We are going to focus on the first two steps in this document.

There are several stages to our process, and each piece of work follows all stages, visualised from left to right on a Kanban board:

Ideas

• Your Technical Account Manager (TAM) uses Trello to track the ideas and requests.
• The TAMs meet regularly to review all our clients’ plans and timelines, to ensure we’re proactively getting issues into Next.

Analysis and design

• Your TAM will work closely with you in order to completely understand your needs and any problems you’re trying to solve.
• A Technical Lead (TL) will work with the TAM to identify different solutions, evaluate their trade-offs and propose the best ones to you; the TL will also provide a t-shirt size estimate (XS, S or M) for the work.
• When a solution is agreed upon between you, a TL and your TAM, then one or more GitHub issues will be created.

Issues describe the solution in detail and without ambiguity. They implement the smallest amount of functionality that can be released independently of any other issue to provide actual value to you.

• A TL reviews the GitHub issue to ensure the requirement and solution is clearly stated and that everything (where possible) a developer needs is contained in the issue.
• If the t-shirt size estimate is large, then the TL will work with your TAM to either reduce the scope of the changes or split the issue into smaller pieces to reduce it to medium (or smaller).
  • The reason for this is that it’s agile good practice, designed to keep risk low, to monitor progress accurately and to avoid conflicts between changes made in parallel in different parts of the application.
  • A solution can be divided into several small issues, provided they are not interdependent and provide value by themselves.
  • Smaller issues often allow users to begin testing a subset of the solution sooner.
• Once the TL is satisfied with the issue they move to the Next stage, meaning it’s ready for development.

Next (ready for development)

• Issues at the Next stage can be considered as your backlog.
• Your TAM will work with you to prioritise items in your backlog, agree funding, etc.
• The TAMs meet each Tuesday to agree which issues from all of Next will be moved to To-Do.

To-Do

• A number of issues are moved to To-Do each week, based on the capacity and velocity of the Projects team at the time.
• The TAMs try to ensure that everything in To-Do has an equal priority.

Development

• When a developer is available they’ll pick an issue from To-Do to work on.
• They’ll work on it in their local development environment.
• When the developer is satisfied that the issue is ready for Acceptance they’ll push it through our automated testing system and then deploy the changes to the staging environment.
• The issue is then moved to the Acceptance stage where it undergoes functional testing and a code review by another developer.

What does available mean?

• The key to managing the amount of work-in-progress is for a developer to always work from right-to-left in our process.
• This means that before picking a new issue, from To-Do, a developer will always check the Release stage first to see whether there’s anything they can release to the preproduction and production environments.
• They’ll then check the Acceptance stage to see whether there’s anything they can functionally test and code review; a developer never performs acceptance for their own work.
• Only then will the developer pick something from To-Do.

Acceptance (system test)

• After releasing the issue to the staging environment the next available developer will pick the issue (subject to the right-to-left rule) and perform a code review and functional testing; it’s possible for small changes to made at this point or for the issue to be moved back to the Development stage if a bigger problem is found.
• Whilst you can test the issue at this point, you do so at your own risk.
• When the issue passes its acceptance it is moved to the UAT stage.

User acceptance test (optional)

• Your TAM will assign themselves to the issue in the UAT stage and work with you to fully test the changes.
• If problems are found they’ll be reviewed with either the developer or a TL and the issue may be moved back to the Development stage.
• If you confirm that the issue has been implemented correctly and has passed your testing it will be moved to the Release stage by your TAM.

Release

• The next available developer will pick the issue (subject to the right-to-left rule) and deploy the changes to the preproduction and production environments.
• The developer then moves the issue to Done. Your TAM will notify you that the change has been released.

Done

• Every Tuesday the work completed during the previous 7 days is reviewed by the TAMs, and the issues are closed.

Specific Trello boards are used to manage all stages of the process with our clients:

The client Trello boards are set up to mirror these stages to provide maximum visibility of our process to our clients. It allows you to:

• see the status of all your development at a glance,
• move the cards that represent the development issues into your preferred priority order, and
• see what actions (e.g. perform UAT) are on you.

And we use GitHub to manage our internal workflow:

Our process ensures quality and agility; using techniques of Kanban, Test-Driven development, Continuous Integration and Continuous Delivery, BeBanjo delivers high-quality software in a reliable and predictable fashion. Making frequent and small incremental updates allows us to respond rapidly to client requirements.

On average, one new version of the software is released to production every 3 business hours!