The Better Method
Intro
The Better Method grew out of a desire to improve the working life of our team members. Focusing on setting them up for success, by having attainable goals, with the right motivation, and a good working atmosphere.
This was, and continues to be, an iterative process. We try new things, see how it goes, and adjust. Therefore the Better Method, and in turn the Better Goals App will continue to evolve as we learn and improve. This is an account of where we are right now, which has enabled us to have a lot of success in building products and reaching the goals we set out to achieve.
Goals
The Better Method starts with Goals. Setting the right goals isn’t easy and is often overlooked. To have success you need to take the care to properly consider what you are doing and why you are doing it. Having an understanding of the motivation behind what you are doing throughout the whole team gives the flexibility for the team to make sensible trade offs during the process.
To give an example, Lets say you have a goal to run a marathon. There could be many reasons why you want to do that.
To get fit.
To raise money for charity.
To prove the guy in the pub, who said you couldn’t, wrong.
What the better method would ask you is to consider what each of these mean.
If getting fit is the point then the time frame is completely flexible. Whether you run your first marathon in 6 weeks or 6 years is irrelevant if you are training consistently and fulfilling the purpose of your goal.
If raising money is the point then you probably have a specific Marathon you are getting sponsorship for so need to focus training towards that date. You also need to prioritise the logistics of organising that sponsorship, The person running to get fit might also want to get some sponsorship for a charity but it is less of a priority so if they don’t have time they can to organise it then they can more readily drop it.
If proving the local loud mouth wrong is your motivation, you will likely lose the will to keep up training long before you are ready to lace up your shoes to go 26 miles. So it probably isn’t the right goal to aim for.
Tracks
The concept of tracks is to have parallel streams of activities that contribute towards reaching the same ultimate goal. Keeping with the Marathon example, we could split the goal into two tracks.
Training - Getting physical ready to run.
Admin - Registering for the race, finding sponsors, arranging travel to and from the race.
Both tracks need to happen in order to achieve the goal, but they can run essentially independently of each other for the most part.
Milestones
Two important and deliberate omissions from Better are estimates and fixed cadences.
We believe that guessing how much time or work it will take to do something is unhelpful.
We believe that cramming whatever task fit into an arbitrary timeframe leads to bad decisions
The Better way is to set milestones. These are concrete events that are scheduled within tracks along the way to your goal. This gives you the ability to check you are on track with your plans but with the flexibility to chose sensible time periods.
In the Marathon example you might have milestones in the Training Track to run a 5k in 2 weeks, a 10 k a month later, and a half marathon 10 weeks after that. By having concrete events you can make adjustments to the details while still staying on track to reach the milestone. Maybe you plan to do strength training twice a week between the 5k and 10k, but you realise you are getting too tired, or losing the fun of training so you adjust to instead rest a bit more, or do a yoga class. You are not doing what you initially planned but if you can still run the 10k on the date you put then you are on track.
If, on the other hand, as the 10k race day approaches you realise you aren’t quite ready then that alerts you to the fact you need to make an adjustment. That could mean stretching the milestones out a bit and targeting a later date for your ultimate goal, or it could mean upping your training regime to get back on track. It might mean changing perspective to consider that you can walk some of the way and still make it across the line.
With Better you have the chance to react before it is too late.
Product Development
So far this guide has used running a marathon as an example, mainly because it is easy to conceptualise. But the methodology is really optimised for product development since that is the environment in which it was developed. Now we will explore more of the development specific concepts and processes, starting with Breadboarding.
Breadboarding
In electronics, breadboards are used to prototype circuits and this concept transfers quite well to user flows. This way of working is shared by other methodologies too.
When designing a product it is easy to dive straight into what it looks like, or what technology and tools to use. Then you end up designing yourself into a less than optimal solution. With breadboarding we define the flow of a product feature but leaving all the implementation details like the appearance or technologies to be decided at the implementation stage.
Here is simple example breadboard looking at the feature of managing skills. The boxes are user interaction interfaces, and the pills within are components that either show data to the user or allow user input. The arrows represent user actions with a component resulting in moving to a different interface.
Interface for company skills management with 4 components. Skills in company component.
Merge skills component.
Editing skills component with action pointing to edit skill interface.
Skill groups component with action pointing to Skill group Management.
Interface for skill groups management with 3 components.
Skill group component.
Edit groups component.
New Group component.
Edit skill interface with 2 components.
Change name component.
Edit groups skill belongs to component.
This is a very simplified example but demonstrate the fundamentals of the approach, in theory each interface could be anything, an app, a webpage, an email, a phone call. All that matters at the breadboarding stage is what information exists in an interface and how a user can travel from one interface to another around the product.
By building these breadboards we can rapidly iterate upon the UX flow of a product to figure out where the kinks are. We generally do this in real time with everyone involved in the feature. So we will have a call with product managers, developers, designers all together to draft and redraft the breadboards. Then once we are content the feature can move into implementation.
Implementation
At this point we have a clear high level understanding of how a functionality will work, what comes next is building it into the code base. The Better Method does not prescribe every detail of this process as teams and individuals will have their own preferences. However there are some aspects applicable to all teams, product features are normally grouped into milestones with multiple features being built and deployed in order to achieve the milestone. In some case an entire milestone could be a single feature as well. Either way, during implementation, we expect the work to be broken down into tasks that an individual (or pair in the case of pair programming) will work on.
Our own preference for how to go about implementation is to have designers and developers work together to iterate on the code. So taking the Skill Management Feature from the breadboarding section as an example. We would have tasks for each interface, the designer, frontend developer, and backend developer would then all work on each task together focussing on unblocking each other.
So the backend developer would discuss with the frontend developer what the API contracts could be to quickly figure out what is feasible and sensible, they then might build a stub to return mock data so the frontend.
The front end developer and UI developer would start throwing out ideas for how the screens could look and start implementing the code for that UI. Continuing the conversation as the implementation progresses to tweak details as they build.
Once everything is wired up all three would check the functionality and see if anything is missing or had been overlooked, and might also give a quick demo to someone else in the team. If it is deemed ready then the task can be marked as complete and the next task picked up.
This highly collaborative way of working is something that we feel provides the best development experience and the best results, but it isn’t for everyone which is why there is some flexibility in the methodology here. If teams want to follow the more conventional designer builds a high fidelity mockup, backend developer builds and documents an API, front end gets both documents to then build the UI on top, then they can define the tasks within a milestone that way too.
Delivery
A crucial aspect of the Better Method is what it means to deliver a feature, this is something which cannot be compromised on. To deliver a feature, and therefore to achieve the milestone it belongs, the code has to be deployed in release to a production environment. This means that testing and documentation has to be done as well. In order for this to happen the team needs to acknowledge up from that this needs to be factored in. If part way through a milestone we realise that we will won’t be able to get all the coding done until the last minute then that means we are behind. Our options are then in most cases pretty straightforward, miss the milestone, triggering the whole goal to be reassessed or make tradeoffs in the scope of the milestone features such that we can get something of value tested, documented, and deployed.
Of these two options the latter is almost always preferable. In order for this option to be viable we need to ensure that from the beginning of the milestone the essential aspects are built first, so that when things come down to the wire we have room to drop things from the scope.
This ability to make tradeoffs is perhaps the single most important factor in allowing teams to succeed using the Better Method, and it stems from setting up the goals thoughtfully, ensuring that everyone understands the motivation behind what you are doing.
Summary
The Better Method really comes down to setting the right goals, and pursuing them in a focussed way.
The Better App is designed to facilitate the Better Method in an intuitive way giving your teams the best chance of success. Click below for a 1 month free trial and get started with Better.