How reducing your batch size is proven to radically reduce your costs

Do you work in an organisation struggling to do more with less? We come across many projects where organisations have tossed in additional resources to meet a looming deadline, pinching pennies from elsewhere and creating stress for all, without solving the underlying problem of how to deliver faster, cheaper and better.

If you want to deliver faster, cheaper and better, you need to reduce your batch size.

Working with small batch sizes (a batch is a unit of work that passes from one stage to the next stage in a process) has tremendous impact. It improves flow and lets us deliver quickly and reach project completion earlier.

In software development terms, a traditional process means a team will define all of the project’s requirements first, complete all of the design next and then finish all of the coding before testing.

In contrast, working in small batch sizes means completing, for example, 10% of the design, the development and the testing before moving on to the next 10% of the product’s features.

Why is batch size important?

There are very good reasons why batch size is important.

First up, when we work with small batch sizes, each batch makes it through the full lifecycle quicker than a larger batch does. We get better at doing things we do very often, so when we reduce batch size, we make each step in the process significantly more efficient.

Smaller batch sizes also mean you’ll deliver faster and reach project completion earlier. Since work on a feature isn’t complete until it is successfully running in production and generating feedback from customers, large batch sizes delay that essential feedback.

Batch size can be one of the most difficult things to optimise but it is economically crucial. Numerous studies have proven that larger batch sizes lead to longer cycle and delivery times – and a longer wait to find out if you’ve delivered value to your customer.

batch size

Faster, cheaper, better

There’s a bunch of beneficial outcomes that come from working with much smaller batch sizes than traditional processes recommend.

Some of these benefits are:

  • faster feedback – the sooner you pass on your work, the sooner you’ll know if there’s an error
  • better feedback – you’ll know earlier on if you’re building the right product, because you’ll get it in front of your customer sooner
  • greater visibility – bottlenecks and inefficiencies are clearly seen
  • improved quality – and when quality goes up, efficiency increases and team morale goes up too
  • less risk of delays and cost overruns – the larger the batch, the more likely you’ve made a mistake in estimating or in doing the work, and the likelihood and impact of these mistakes increases as batch size grows
  • reduced complexity – you’ll reduce the amount of complexity that has to be dealt with at any one time by the team
  • improved decision making – it’s easier to make business and technical decisions and recover from mistakes.

All this makes for better economics. Donald G. Reinertsen’s diagram uses testing as an example, and shows the direct links between a smaller batch size (which results in smaller changes, fewer open bugs and faster cycle times) and improved economics.


Smaller batches = greater output

We’ve even got mathematical proof that you should reduce your batch size!

First published in 1954 and proven in 1961, Little’s Law has been used across many industries. At its heart, it deals with queuing systems, which is what coding-oriented projects also have to deal with. Little’s Law means that if you reduce your cycle time by the power of 10, you increase your capacity/production by a power of 10.

Tips for reducing your batch size

What is an ideal batch size, and how do I reduce my current batch size?

Reinsertsen recommends reducing your batch size by 50%. You can’t do much damage in this range, and the damage is reversible. Observe the effects, keep reducing, and stop reducing when total cost stops improving

Batch sizing is very much a horses for courses endeavour. Some large projects might favour a 30 day sprint, but for most of the projects we’re involved in, we’ve found the sweet spot is two weeks.

If you’re using Agile, you should be working with small batches already. (If you’re trying to implement Agile but using the same batch size as a traditional project – that is, 100% – Agile will not work!) However, it’s important to remember these guidelines when you’re setting up your next project:

  • reduce the timeframe for delivering results
  • don’t define all your requirements and success criteria in one go
  • prioritise your product’s features and begin with the smallest amount of work that will still deliver value to your customer
  • test and release as soon as that work is complete – adopt continuous integration and ensure deployment and testing efforts are ongoing during your project.

The last word goes to Reinertsen and his video: The practical science of batch size. It has all you need to know about batch size – how it works, why it works and what to do next.

3 top tips to set up your project for success

Over the last 10 years, I’ve seen the differences between projects that start from a good place and those that don’t. After analysing the patterns, I’ve distilled it down to three critical things that will reduce your risk and give your project the best chance of success.

1. Partner with your developer

There is a traditional mindset that creates a supplier and vendor relationship which feels a bit ‘us versus them’. Your project will only thrive on a WE relationship. At Boost, we prefer to partner with clients on a project from the get-go, forming a strong, collaborative team that works together towards the same goal throughout the duration of the project.

2. Start at the beginning

Having found your partner, you need to go on the whole journey with them and not just dip in and out.

We often get clients coming to us after they’ve made strategic decisions and already have a project fully mapped out, which doesn’t necessarily set it up for success. We aren’t just about the delivery of a project; we specialise in helping clients to learn about what the customer really needs, validate ideas early, and develop and refine the right product that will lift your digital relationships to another level. We get great results that look very different than if we’d just built something directly from a requirements document.

3. Build what your customer values

Project inception is an exciting time when there are seemingly limitless possibilities. It is also a daunting time for the same reasons. You need to listen to your customer and build something that will deliver the outcomes they want.

How do you get that focus? We have been running workshops with clients for years to achieve just that. We use processes and tools that will make sure you build the right product – and nothing more. You won’t spend money on unnecessary software that has been developed because we made too many incorrect assumptions. They say that 80% of users only use 20% of features, so we start by identifying – and more importantly, delivering – that first 20%.

Check out our free workshops on setting up and running great projects!

Te Papa changes tack to deliver their flagship website

Adrian Kingston final

We’re always keen to help our partners deliver better results, and we were delighted to be invited to run a workshop on Agile at the National Digital Forum – a conference on all things digital in the culture and heritage sector.

We’ve worked with a bunch of great organisations and folks in this sector, including Adrian Kingston from Te Papa. Catching up at the conference, we took the opportunity to get Adrian’s reflections on web development processes and shepherding organisational change.

A national museum, a national treasure, a complex online beast

Te Papa, as befits a cultural treasure and collection, doesn’t take changing its website lightly. As both the first impression of Te Papa for many visitors and a gateway to a vast storehouse of knowledge, the website has a lot to deliver.

The national museum has backed Agile to deliver their new website by February 2016. One of the core members of the team tasked to work on the project is Adrian Kingston.

Fourteen years at Te Papa and part of the Collections Information team, Adrian brought Agile to its business practices since returning from a nearly year-long secondment to the DigitalNZ project.

Transparency delivers better results

Te Papa’s decision to use Agile to develop its new website was both a trust and transparency thing, Adrian says. Senior management had seen Agile working successfully in small pockets across the organisation and were now willing to give a bigger project the chance to run with it.

“There’s a lot of goodwill and trust from others,” he says. “There’s genuine interest from people about whether Agile’s the right way to do it.”

He’s noticed increased transparency with Agile.“It’s a very open decision-making process. We’re participating in a fast, collaborative, user-focused development process; we’re doing things impartially and sharing that knowledge.”

Organisational change in increments

Adrian has been at the coalface of bringing the new website to life. It is a complex beast, broken into three components to allow multiple vendors to help deliver the whole project.

Te Papa would probably be the first to admit they weren’t an Agile organisation. Te Papa’s own project team and planning fully run in Agile, alongside a more traditional waterfall governance team – which “again has been a learning thing,” Adrian says.

Part of the new transparency has included an internal blog. The blog has not only demonstrated trust in the project team but served as a way to promote Agile processes to the organisation, as well as the project itself.

An adaptive process that focuses on the customer

“Agile has been useful in the way we’ve been prioritising requirements and adopting a user focus,” he says.

“Instead of being entirely business focused and all about Te Papa itself, we’ve reminded ourselves we aren’t our audience. So we’ve done a lot of user testing, having worked with about 900 users to get the experience and tone right. One of the advantages is that because it is online we get engaged feedback, and we can make informed decisions and adjust things quickly to make sure we’re delivering value to our customers.”

“That’s compared with spending nine months building it and then seeing how it all hangs together at the end.”

Find out more

“Because it is so visible, the project has attracted a lot of interest from other parts of the organisation. People have been watching our stand ups, looking at the whiteboards, asking us how to do Agile.”

Adrian’s been recommending that people pop along to Boost’s free Introduction to Agile workshop to “see what they think.”

“Agile also shows in small ways as a part of daily workflow,” he says. “If people ask, I’ll send them a Kanban Board by pointing them to a link and getting them to print it. There’s a few around the organisation now.”

CSS Calc: Creating fluid layouts with more precision

Recently I have been using the “calc()” css property to add more precision to the fluid layouts I’m working on.

If I wanted a combination of fixed & flexible width columns incorporated into my designs, I can simply use “calc()”. In the past, creating this layout was highly difficult, but this has been made easy with “calc()”.


First, You set up the width of the fixed column, then you make the width of the fluid object 100%, then you subtract the styles that make up the total width of the fixed width object.

.fixedWidthElement {
  width: 200px;
  margin-right: 2em;
  float: left;

.fluidWidthElement {
  width: calc(100% - 200px - 2em);
  float: right;

View the working example here

The “calc()” css property has a great range of support across all browsers, as you can view here.

To make sure you have all browsers supported, you can install Modernizr, which detects HTML5 and CSS3 features in the user’s browser. You will want to manually add the “css-calc” detection, which is under the “Non-core detects” drop down. Click here for a link to the custom build of Modernizr.

Fallback for browsers with no support

.fluidWidthElement {
  width: 80%;
  float: right;
.csscalc .fluidWidthElement {
  width: calc(100% - 200px - 2em);

Building for mobile first

What is a mobile first approach?

Instead of creating a website for the desktop first, then scaling it down for mobile devices, we should embrace the constraints of mobile first and enhance the desktop design in a later stage. This allows us to address common issues with legacy browsers and help remove bloated CSS code.

Mobile First - Desktop Last

How does organizing Mobile First CSS benefit legacy browsers?

During my R&D ( Research & Development ) on a Friday afternoon, I started experimenting with organising my CSS in a Mobile First approach, which consists of writing the mobile base styles first, then implementing the Media Queries to change the layout based on the screen size for larger devices.

  • The Base CSS will target: Mobile ( + Legacy browsers )
  • The Media Query CSS will target: Tablet, Laptop, Desktop ( Supported by modern browsers )

Note: CSS ( Cascading Style Sheets ) are read by the browser from top-to-bottom, if the browser doesn’t support the code ( eg. Media Queries ), it will ignore those styles.

By creating our Mobile First CSS, we have created a layout that will work well on legacy ( older ) browsers, without having to bloat the stylesheet with additional CSS to fix specific browser layout issues. These browsers, such as ie6-ie8 don’t support media queries, so they will be served with a minimal, but usable layout based on the mobile view.

The following diagrams and CSS code snippets show how to setup the Mobile First CSS approach.

Base CSS – Fluid Layout

Our Base CSS ( Fluid Layout )

/* ===============================
Base CSS
=============================== */
.exampleClass { width: 100%; }

Note: The class / property above is an example and won’t create the illustrated layout.

Media Query CSS – Responsive Layout

Our Media Query CSS ( Responsive Layout )

/* ===============================
Media Queries
=============================== */
@media only screen and (min-width: 500px) {
.exampleClass { width: 50%; }
@media only screen and (min-width: 850px) {
.exampleClass { width: 540px; }
@media only screen and (min-width: 1500px) {
.exampleClass { width: 75%; }

Note: The class / property above is an example and won’t create the illustrated layout.

The key difference here is the use of min-width rather than max-width. The best way to understand this is by getting stuck into the code! So get started.


Ringing out the red – making the most of the Boost blog

Having a blog is a very effective way to get exposure and build your brand.

Your blog gives you a chance to share your work in a more in-depth and meaningful way. You can share your process, your knowledge and constantly communicate and grow with your community.

If you’re going to have a meaningful presence it should not only contain great content, it should also look great.

About 2 months ago our MD, Nathan came to me and said the current blog design needed to be less red. I sat at my desk and looked at it for a good while. A simple cosmetic change wasn’t going to be enough to mend this broken heart. I decided what the heck, I’m going to completely redesign the Boost Blog.

The old tomato once known as the Boost blog

The old tomato once known as the Boost blog

Any spare time my developer colleague Sam and I had was spent working on the new blog design with a focus on:

  • Readability
  • Responsive design
  • Highlighting Boost’s biggest asset (our team)

To make our blog a more readable experience I threw away the alarming amount of red and instead used color to draw your eye, highlight and show relation between the elements. I focused on subtlety and slight tonal differences (your eyes can relax now) to create a design that is much more calming and approachable.

Our blog is now fully responsive to work on any browser width, with a focus for mobile, tablet, desktop and also those with an abnormally large bowser window.

A blog post in mobile view

A blog post in mobile view

We also wanted to highlight the hardworking and passionate Boost team by giving each blog author a profile image and small work bio ( these will drop down when you click on their beautiful mug’s) to make the blog just a little more personable.

I am really happy with the new blog! I believe we’ve created something pretty… well, pretty.

We hope you enjoy the new blog and we’d love to hear your feedback on it via the comments! : )

What does Lego and building high quality software have in common?

All the way from Poland and after a stint with NZ Customs, the Lego blocks we ordered a while ago are finally in our hands and we’re very excited.


For those of you who have already been on the Intro to Embracing Best Practice workshop that we run, you’ll recall that we mentioned several times that some key concepts around building high quality software could be demonstrated very easily and in a very tangible way, if only we had some Lego. Who’d have thought building high quality software and building Lego would have shared so many similarities? :)

Well now the Lego is here and we’re ready to get down to some “serious play”. During our next Intro to embracing best practice workshop we’ll facilitate a hands on demonstration of the Agile concepts of Test Driven Development (TDD), Refactoring and Continuous Integration (CI). Our aim will be to facilitate your understanding of why these concepts are so important to building high quality software whilst enabling you to continue to be leaner and faster. Best of all, you’ll be building Lego, not writing software.

The next Intro to Embracing Best Practice workshop will run on February 14th 2014, you can book your place here.

However, if you can’t wait that long, or you’ve already been to the workshop, why not get in contact with us and we’ll run a special session for you. Email us at [email protected] or give us a call on 04 939 0062.

The new Boost website is live

You may have noticed a bit of extra colour has crept in to the Boost website recently. After just over a year of refining our content and finding out exactly what people wanted from our site, the time has come to apply the design.

It’s always difficult for a company that designs websites to create their own, but in the end the Boost site came together surprisingly easily.

These are the steps we undertook when designing the site:

  • Created a simple, modular site
  • Iterated the user interaction design
  • Created moodboards
  • Designed the website directly in the browser
  • User tested the site’s interactions

As you may be aware we were approaching the new site build in the same way we like to approach all our design work, in an Agile way. We start by making a very basic, modular site. We don’t do any design up front and focus on getting all the content and functionality we want in place, along with the user experience (UX) and site structure.


The designers are heavily involved in this process, and by the time it comes to actually creating a look and feel for the site they are already fully immersed in the project and can make much more informed decisions.

We began the design process by creating a moodboard. Our two designers collaborated to gather elements so we could decide on a direction that we wanted to take. These elements included examples of typography, colours available to us from the Boost palette and a range of icons the designers liked.


The team have been very excited to further progress the site so that we now have a design that represents Boost. Michael Trilford (who has been a designer at Boost for 7 years) said “I have been waiting 6 years to redesign the Boost website, finally the time has come to go live, Bliss!”.

The enthusiasm they had for the project was obvious, they pair designed the site directly in the browser. The introduction of web fonts and icon fonts allowed them to skip the extensive Photoshop aspect of building a website. Jesse, the developer on the project, collaborated with the design team daily to ensure that their ideas became something that could work, and work across platforms.


By doing it this way, they could then be confident that every pixel was aligned correctly on the baseline grid, which in turn created a great vertical rhythm and mathematical harmony.

We also sent out an IntuitionHQ test to check that the navigation was making sense to people. We followed up our online testing by doing some in-person testing so we could observe how participants were interacting with the website and where they were having difficulties. We are compiling the results of these tests which will inform future enhancements.

Speaking of which, we plan to keep evolving the site over time. So leave a comment if you have any feedback as it is very valuable to us and will be taken on board when we are planning future sprints.

The Boost website evolution

It has been a while since we last posted an update on the progress of the Boost website. There have been many additions since then, and there are a few radical changes just around the corner, so it feels like a good time to talk about where we’re at now.

We’ll be talking about the following features today:

  • Boost blog enhancements
  • Landing pages for mobile and app development
  • Adding Rally as a partner
  • Including Boost Jelly on the homepage
  • Content restructure
  • Adding an about us page
  • Our internal Scrum

Boost blog enhancements

The sidebar on the blog was getting a little unwieldy, so we decided we needed to tidy it up. Gone were the months listed out in the archive, in came the years, with a post count beside each one. This gave us a lot more space where we could then list out the categories, again with post counts beside them.

These changes may seem minor, but have made it a lot easier to navigate through our previous posts.

Landing pages for mobile and app development

We wanted to advertise some of our services, and chose to do so on Google and Linkedin. These ads were specifically about Agile Coaching and Mobile App Development, so we felt the need to have landing pages that dealt only with those services.

Unbounce gave us the opportunity to get these landing pages up quickly once they were designed, and allowed us to track conversions with ease.

Once a user lands on one of these pages, they need to enter their details to download the case studies we had put together, making these very meaningful leads from our perspective.


Adding Rally as a partner

Boost has partnered with Rally, who offer Cloud-based solutions for managing the Agile development lifecycle, and we find their principles closely align with our own. You can now see their logo and a little bit of information about them in our sidebar.

We now use the  Rally software to manage most of our Agile projects, and the features it provides make it suitable for small projects all the way up to Enterprise level projects.


Boost Jelly

We love having people from a variety of interesting industries come in each Friday and use our workspace (and our Wi-Fi and coffee machine). It’s always fascinating to have someone completely unrelated to Boost set up and work amongst us for a day. We noticed that no one had arrived for a few Fridays in a row, and realised that we needed to add Jelly back to our homepage so people were aware that it was still an open invitation. We hope to see some of you here soon.


Content restructure

As Boost has evolved our focus has shifted from pure website development to web and mobile application development. We cut back on the homepage content and rewrote what remained to reflect this change.

We removed all of our Agile Coaching content, as that now has a home at, and gave more prominence to Boost Agile in the sidebar so that visitors can still find it. All our workshops and courses are now listed under the Boost Agile umbrella.

About us page

We finally have an about us page. With all of our homepage content devoted to our services and our work, we needed to  find a place where we could give a little bit more background about ourselves and provide a more extensive list of the clients we have worked with.


Our internal Scrum

We like to practice what we preach, so all of our internal projects are run using Scrum, and the Boost website is no exception. We try to keep the team who work on the website as stable as we can, and they are now a close-knit and truly self-managing group.


Our retrospectives have consistently brought up interesting ways to improve a variety of aspects of the project, and the enthusiasm and openness of the team have kept the momentum going.

We are happy with the website in terms of content, and the next stage will be unveiled very soon. We are pretty excited about the work coming out of the current sprint and keen to let everyone else see it too.

5 steps to better value for money in web application development

No one wants to be the next Novopay! How do you ensure good value for money in web application development? It’s a question we are often asked and doesn’t have a straightforward answer. In this post we will look at some of the techniques we use to deliver better value for money on our projects.

Customer and team collaborate at every stage

To ensure that the vision held by the customer is shared, the customer and team must collaborate effectively and efficiently. Using good facilitation tools and techniques, and agile ways of working, the customer’s vision is clearly shared by the team and enables them to make sound decisions at every stop of the way.

Get fast feedback from the market

Key to getting good value for money is getting feedback from your market early and often. Working to get the application to market as early as possible reduces risk by ensuring the feedback loop from clients is as short as possible and by reducing investment before feedback. Integrating customer feedback into your development process will ensure that the features being developed are of value to your customers.

Build quality in to reduce the cost of change

Following technical best practices such as BDD & TDD is an excellent way to ensure quality is at the forefront in development. Technical best practices reduce the number and severity of defects in the work which frees valuable resource for creating features. The cost of finding and correcting defects grows quickly, so early discovery and re-mediation is key.

Prioritise the highest value features first

By focusing on producing the highest value features first you will ensure that the product is viable at the earliest possible stage. This ensures that the return on investment is as high as possible.

Inspect and adapt your product, processes and tools

It is absolutely essential to continually and rigorously inspect both the software being created and the way the team is working to create the software. We use agile processes to ensure that the team and client work together to improve on a continuous basis. The result is a high-performing team that is continuously improving, adapting to change and providing more and more value.

All of these ideas are supported by Agile and Lean and we are in a great position today where we are able to stand on the shoulders of giants who’ve discovered pragmatic solutions to the problems of software development.

We would love to hear your your point of view, what has worked for you in the past?