Do I Really Have to Stand? – An Agile Glossary

by Roisi Proven

As we work with larger and more complex companies, we become the people to introduce Agile ways of working into an organisation. However, when you’ve worked using Agile for a decade or more, as many of us have, you often assume some knowledge that people don’t have. With that in mind, we decided to put together a glossary of Agile terms, so you know why we randomly ask you to stand up every day at the same time!

Agile – let’s start with an “easy” one. What is this Agile thing? It’s described as “a set of principles, not a process”. Below you can see a classy business image with this set of principles but really, the clue is in the name. If you want your organisation to be Agile you mean just that, a business that is malleable and responsive to change. Don’t let someone come in and hit you with a process stick in the name of agile.


Backlog – This is what we’ll help you to build at the start of the project. Simply put, it is a list of things you want, prioritised from most to least important. Decide something is more important? Move it to the top! Realise that support for cat gifs is not as crucial as you once thought? Move it down, or drop it off the list altogether. As a team, we will work through a backlog from top to bottom, until we get to the end.

Card – a “card” is a unit of work. Each thing you want to be done goes on a card, and each card goes into the backlog. So when you move a card up or down the backlog, you are telling the team how important that piece of work is to you

Continuous Delivery – This is the process of taking the fear out of putting new work live. Rather than having “big bang” releases that are built up over the course of weeks or months, we aim to release new work as soon as it’s ready, often several times a day.

Demo – Where we show off the progress we’ve made. This can as often as the client requires, but is mostly commonly done weekly. This is crucial to keep the stakeholders up to date with progress and allows them to make changes to the backlog in response to the latest work.

Kanban – literally the Japanese word for “visual signal” or “card”. Kanban is a framework originally developed for use in the Toyota factory, and our preferred way of working. It revolves around the flow of work through a system, rather than trying to predict each piece of work along with a traditional Gantt-style plan.

Kanban board – a physical representation of the work you are currently doing, usually stuck on a wall in the office. This is designed to be an at-a-glance view of what each team member is doing at any given moment, and is also where the morning status meeting (a stand-up) is held.

Little’s Law – Maths! Little’s Law is the maths behind Kanban, and the formula we use when showing overall progress and forecasting timelines for the future. Little’s Law uses a combination of Throughput (the number of work items completed in a pre-defined period), Lead Time (the average time it takes to complete a work item) and Work In Progress (the average number of work items in progress at any one time).

Product Owner – This one definitely needs more than a short entry. The role of Product Owner is one of the roles most likely to be misinterpreted within an agile team, and it is far more complex than it is given credit for, which is why a team also finds itself with a part-time Product Owner when full-time attention is needed.  For more on this, I suggest checking out Toqir’s blog on good Product Ownership

Retrospective – The best teams learn from their mistakes, so it’s important to have time to call mistakes out, and discuss how you can improve as a result. This is where we use retrospectives (often shortened to just “retro”), where the whole team gets together (usually once a month,but can be at any time) and discusses where things have worked, and where they haven’t.

Scrum – Another framework for running a project, and the one that people will probably most readily recognise when talking about Agile. This method revolves around story points and “sprint” cycles of around two weeks. However, at Red Badger we definitely prefer to use Kanban.

Standup – A morning status meeting. Called “standup” because the aim is to literally stand in a circle around the project Kanban board. Each team member reports what they did the previous day, what they are planning to do today, and whether they have anything blocking them from completing a task. It is ideally timeboxed to 15 minutes or less to avoid unneeded disruption

User Story – Each card should represent a piece of value for the end user. If it doesn’t then it shouldn’t exist. The way that we validate this is by using User Stories. This is a description on each card that follows an easy to remember format. A user story should look like this:

As a someone
I want something
So that something happens for the user

So, going back to the aforementioned cat gif example, the user story would be:

As a user
I want to see cat gifs
So that I feel happier whilst looking at the website

If you cannot figure out a user story for a card, then you should be questioning the value of that piece of work.


This list is by no means exhaustive, and at least some of it could be seen as subjective. However, it should fill some gaps in knowledge for people who are entirely new to agile.


Getting user feedback into the backlog

by Sasha Ward

As UX designers we are always aiming to balance the needs of the user with the requirements of the business and with what’s technologically feasible.



A key element of this is understanding and addressing the user needs, which can be done by talking to them, testing prototypes with them and giving them the opportunity to give feedback.

Within large product teams, the likelihood is that there will be an abundance of feedback collected from a range of sources, which is great as feedback from our users is essential to creating products people want and can use. But what do we do when this feedback is scattered across a team of 40 or 100 people in multiple teams? How do we get the generic feedback that isn’t directly related to a current piece of work, back into the backlog?

In this post, I will run over the types of feedback that you can get from users and give you a framework that can help you turn this data into small pieces of work.

What types of feedback are there?

Firstly, I just want to clarify what we mean by feedback and how we categorise it. When I talk about feedback I am referring to any kind of response that happens as a direct result of a user using a product.

We can separate the feedback we get from our users into two categories, qualitative and quantitative feedback/data.

Qualitative data – Insights in the form of opinions, feelings and behaviours (e.g. “I didn’t expect that to happen when I clicked there, I feel slightly disorientated”). Usually gathered through observational research methods that require some form of direct communication with a user and used to help to define a problem or to explore an idea/concept. These kinds of insights are generally harder to get hold of as it requires more effort to gather. However, there are a number of ways to find these insights whilst still keeping your process lean, here are some examples:

  • Cafe/Guerrilla testing
  • Feedback forms
  • Social media channels (twitter, Facebook)
  • Reviews (trip advisor, app store)

Quantitative data – Insights that can be depicted by numbers (e.g. 80% of users bounced on the signup page). These sorts of insights are gathered through measurement methods including surveys and analytics tools. We often use quantitative research methods as a way of quantifying a problem, in order to validate its severity/prevalence. (1)

So…how do we turn all this data into something that we can actually work on?

1.Firstly, gather all your data in one place

Round up all the data that you have, this includes data from analytics tools and comments from user testing. All the most recent feedback that you have. (Grab some post-its too).

Ensure the data is summarised in a bite-size format with one insight per post-it, focussing purely on observations with no solutions at this stage. This is important as the purpose of this exercise is to translate random pieces of data into actionable pieces of work, therefore it’s essential that the data you have is in a short, simple language that you can communicate easily to the rest of your team. Find a large wall that you can use to pin up your data and then gather your team.

2. Secondly, identify themes

What you’ve got so far is a big pool of data, and in order to have something actionable and the end of this session what you need is some way of filtering down this data.

A great way to do this is by affinity mapping (sorting into groups) this data/feedback. As a group, sort the data into similar categories and name each category once all the data has been categorised.

3. Thirdly, write user stories/actions

Once you’ve got your main themes, you can then begin to write actions based one each of the themes. The most likely output from this would be user stories but it most certainly isn’t limited to this. It is likely that the data you have gathered might provoke more questions that require some form of validation, therefore a user story that is purely focussed on exploring or experimenting might be another great outcome from this exercise.


Here’s an example of a space we helped create, where we gathered insights, identified themes and created actionable user stories.

4. Last but not least, prioritise within the backlog

With the Product Owner or whoever organises each team’s backlog, go through the user stories that you have created and prioritise these alongside the other work that is the backlog. There are a couple of ways you can do this:

The MoSCoW (Must, Should, Could, Would) method whereby you gather the user stories that you have created and vote on which category each story falls into. Differentiating between each category is vitally important, I find using these definitions a great starting point:

Must – are features that must be included before the product can be launched.

Should – are features that are not critical to launch, but are considered to be important and of a high value to the user.

Could – are features that are nice to have and could potentially be included without incurring too much effort or cost. These will be the first features to be removed from scope if the project’s timescales are later at risk.

Would –   are features that have been requested but are explicitly excluded from scope for the planned duration, and may be included in a future phase of development.  (2)

5. Alternatively, you can use the prioritisation matrix mentioned in Jeff Gothelf’s Lean UX.

Our goal is to have a prioritised list of things to work on. This matrix helps us create that list, based on how risky a piece of work is. If a piece of work is not well understood and is high risk/expensive we want to find out earlier rather than later how it will affect us, therefore any user stories that are sorted into the top right (hatched area) should be worked on first. (3)

This way of gathering data, sorting, defining and prioritising is just one method that we have experimented with, but we’d love to hear from you if you’ve had any experiences both good and bad about how you’ve gone about getting user feedback back into the backlog.


1. http://www.surveygizmo.com/survey-blog/quantitative-qualitative-research/

2. http://www.allaboutagile.com/prioritization-using-moscow/

3. Lean UX – Jeff Gothelf


Red Badger’s UX team is growing- check out our current vacancies here.


What’s coming up next?

by Marcel Cutts


The Badgers love their technology, both new and old – but what’s coming up next?

Recently, we spent a fantastic day discussing developer and testing topics ranging from new languages to new ways of working. This culminated in a bustling open spaces session to find out what the Badger collective thinks about our current, and future technological ecosystem.

The session began with every Badger being armed with trusty post-its and pens. Everyone then placed languages, frameworks and methodologies into categories of stop using, keep using and start using. If you agreed with something already in a particular category, you could add a dash of support by placing a mark on that post-it.

So what do the Badgers think lies on the horizon? What gained the most support? What was the most controversial? Have a peek below!



CSS has been around for close to twenty years at this point, and many Badgers felt it had some fundamental flaws. Unpredictable side effects, subtly different rendering between browsers, inconsistent rules and its cascading nature make CSS difficult to combine with the a component based approach to creating web applications. These problems are explained fantastically in this talk by Pete Hunt.

While many agreed these are issues, the solution was less clear. Discipline approaches like BEM exist to minimise some of these pains, CSS Modules have proven popular, but maybe something more exotic like the recently released Styled Components or defining our styles in JS is the future?

Styling is definitely a hot topic in the community and we’re keen to experiment, so watch this space!

Node 🍃

Node was an interesting subject, appearing quite popular in both the stop using and keep using categories.

Red Badger has delivered quite a number of successful projects on the back of Node, but some thought that we had perhaps grown overly-reliant on it. The general conclusion from our discussion was that it’s a great tool for some problems, but not all, and it should retain a place in our toolbox. In future projects, perhaps we could explore other back-end technologies like Elixir for our upcoming projects.

Cucumber 🍆 and other automated UI testing tools

Automation testing forms the top of Mike Cohn’s oft-quoted testing pyramid, representing the smallest size and costing the most to both create and run.

Red Badger has a number of generously sizeable web projects where automation testing has been pushed to its limits – in speed, in maintainability and in value provided. Some Badgers felt that many automated testing tools provide little value, or can even be damaging. Automation testing processes can begin to add to the lifetime of pull requests, and unreliable or unwieldy integration tests inject uncertainty into the readiness of the product.

UI testing is a difficult problem, especially at scale, and no framework seems to be perfect for us at the moment. Perhaps snapshot testing through tools like Jest allow some of the automation testing to be filtered down to a middle layer, letting the automation tests remain lighter.

We’re thinking deeply on this one, lets see what we come up with!

AWS ☁️ + Serverless ⚡️

We’ve become big fans of AWS and look to continue using it and its products. Some Badger projects have a huge need to scale and AWS, combined with tools like Terraform, have served us well in decreasing our need to engage in traditional ‘DevOps’ activities.

Recently, we’ve been enamoured with a new offering called Serverless. Serverless leverages AWS’ Lambda and other services to provide infinitely scalable, immediately provisionable environments. This allows us to focus almost entirely on the meaty application parts of development, having abstracted away so much of our platform concerns.

We have high hopes for this technology in the future, and have already launched projects utilising it successfully. If you want to know a bit more about our attitudes to infrastructure problems, check out this smashing blog post by our CIO and half-pint scorner, Stuart Harris.

Java ☕️

Some Badgers have recently burrowed their paws deep into Java systems, which brings back memories for many! Java and its frameworks, especially for legacy systems, has both advantages and flaws that have been explored often.

Given the general internal trend towards functional programming, many were keen to perhaps try Clojure or Scala to allow firms to keep their JVM infrastructure while gaining the benefits of these whiz-bang languages.

Flow 🌊

Flow is an optional typing library released by Facebook that allows you to gain the benefits of static types in the normally dynamic language wonderland of javascript. These types can be defined by hand, and through Flow’s impressive type inference system.

So, what does that give you? Safety from all kinds of null errors, and through fantastic tooling such as Nuclide, great hints on possible pitfalls in your code and groovy developer experience niceties like on-the-fly parameter documentation.

While this can increase confidence and predictability of your code, some Badgers felt this removes from the dynamic core of javascript, while others mentioned that the current tooling caused them aggravating issues.

This technology was quite contentious amongst the Badger gathering, but the optional and incremental aspect of Flow means that for teams where it’s providing value, it can be used without treading on other people’s toes.

Keep an eye out on Flow, and maybe we’ll all be in agreement when the syntax settles and the tools mature, or perhaps we’ll have moved on to something completely different!

GraphQL ፨ and Apollo 🌝

Generally, we’ve had great experiences with GraphQL. REST has carried us a long way, but anyone who has looked after a large API will know the cracks that begin to form. How do you approach API versioning? If you need just one more piece of data on a page, do you add another endpoint resulting in another call, or do you start to make a small amount of very fat endpoints? If you have fat endpoints, will it be terrible when you need to call two of them just for a small amount of data from each while discarding the rest?

GraphQL soothes many of these long-known problems, allowing you to declare exactly what data you require to a single endpoint, and allow the backend to resolve these needs.

Although we haven’t had the opportunity to use it at scale yet, many Badgers are scurrying in excitement about Apollo, an incrementally-adoptable data stack leveraging GraphQL that manages the flow of data between clients and backends. It seems like a well designed system that works fantastically with some of our favourite front-end core technologies like React and Redux.

Elixir 🍾

Elixir! A very exciting backend language that many Badgers are keen to embrace. It provides the tools to implement scalable, fault tolerant concurrent backend systems by utilising the power of the BEAM VM and the lessons of Erlang.

In addition to intrinsic language virtues, it provides a fantastic developer experience and a menagerie of tools. For example, Elixir can run code examples in your method documentation to ensure everything’s up to scratch! How cool is that‽

We’re all itching to put Elixir into production. If you’re around in London on the 21st of October, why not come to our Elixir Build Day, led by our chief Elixir artisan and propaganda minister, Louis Pilfold?

Elm 🌳

We were fortunate enough to be visited by Elm creator Evan Czaplicki a few months back, showing off his powerful, functional front-end language. Evan demonstrated how to write fantastically concise, run time safe, deterministic and confident front-end interfaces and the Badger huddle has kept close watch since.

Elm is an absolute joy to use, with the strong type system allowing it to have features such as exceptionally insightful compilation error message, should you ever lose your way.

Over the last year Elm has only been gathering steam, gaining features, and growing a vibrant and brilliantly helpful community. We’re definitely keen to use it in the future.

So what are the big themes here? Red Badger believes in Strong Opinions, Weakly Held, but for now the Badger Future looks a lot more Functional and Immutable than it did before!

Do you agree? What excites you? Let us know in the comments.


Learning to program with the world’s best hypnotists.   

by Toby Merlet


Everybody was very focused during this 2 day seminar.  Veerryy Fooccussedd…   And I’m sorry to disappoint, but they were not teaching us to program JavaScript, Closure or Elixir! This was about a different sort of programming altogether.


Hypnosis pendulum


Most of you will have heard of Paul McKenna.   A household name in the UK, he started out as a stage hypnotist getting audience members to dance around like chickens.  But he soon realised he could make more money help people change their lives for the better.  You can hardly walk into a branch of Waterstones without  being assaulted by his myriad of books and audio recordings.  Apparently he can  “Make you sleep”, “Make you rich”, “Make you thin” but also “Make you smarter” and “Play great golf”.

All for a mere 12 pounds each.  Bargain.

His change from entertainer to self-help guru was facilitated by a man called Richard Bandler, the co-creator of a discipline called NLP (Neuro Linguistic Programming) and a hypnotist himself.  What is NLP?

“(n) a model of interpersonal communication chiefly concerned with the relationship between successful patterns of behavior and the subjective experiences (esp. patterns of thought) underlying them; a system of alternative therapy based on this which seeks to educate people in self-awareness and effective communication, and to change their patterns of mental and emotional behavior.”




The seminar I attended was called “Get the life you want“,  hosted by both Paul McKenna and Richard Bandler.  I was interested in attending to learn more about NLP, and hopefully feel more confident.

And yes, we did get hypnotised.

If you’ve never been hypnotised then it might sound a bit scary.  Mainly because stage hypnotists have given it a bad name.  But the induced trance feels more like a state of increased focus.  The best way I can describe it is when you read a book  and the world around you disappears because you’re so engrossed in what you’re reading.  Coders might call it “being in the zone”.  Anyway, I first learned techniques of self-hypnosis from Dr. Val Walters, who was at the time Professor of Hypnosis at University College London, so it wasn’t unfamiliar to me.

40 years ago, if you wanted to get rid of a phobia, it required 6 months of desensitising therapy, and even then, the results were uncertain.  McKenna claims that ‘if it takes you more than 60 minutes for 99% of patients’, you’re doing it wrong.

Traditional forms of therapy look into the past to try and find the root of your psychosis.  Because, apparently, having that knowledge will fix the problem.  Bandler on the other hand, told us with a degree of playfulness that “People start telling me how fucked up they are, but frankly, I don’t give a shit”.  Charming.  But he wasn’t being mean, he just believes that it isn’t very helpful knowing about the past, and cares more about how you think rather than why.  What is it you see in your mind’s eye when you remember a disturbing thought?  What goes through your head when you’re beating yourself up?  How does it make you feel physically?  With this knowledge he can, with the help of hypnosis, do something about it.


Hand with eye


He was a charismatic fellow.  His stories were entertaining and while he was talking to us he was apparently using his NLP techniques to connect with our subconscious and feed us positive subliminal messages.  I felt very focused listening to him, but I’m still to be convinced by NLP; that may be because I wasn’t sure what to look for. I knew when he was using hypnosis, but NLP was not apparent to me.

On the other hand, I was sold on the hypnosis aspect of the seminar.  We learned practical techniques to help control that little voice we all have in our heads.  The one that tells you you’re not good enough, that you can’t do something, or that you want to eat the rest of that giant cake all by yourself.   You know who you are.

When I left the seminar, I was a bit disappointed.  I was tired and didn’t feel much different to when I first walked in the room 2 days earlier.  But a week on, I can honestly say that I feel like a much happier more content human being.

That’s a big claim! So let me clarify. I’m sleeping better, I worry less, I’m able to concentrate better and feel more productive.  I’ve even written my first blog.   Training Budget well spent?

“If you like the idea of an annual training budget, trips to conferences like this and a big focus on learning, Red Badger could be the place for you. Check out of current vacancies here.”


Practical vs Theoretical Agile Coaching

by Roisi Proven

The other day, the following tweet was shared by a friend of mine:

agile coaching

It put into words something that I’ve been struggling with for a while. As a Project Manager, I am always focused on the practical elements of the work I am doing. However, because Red Badger is a full-service agency, I also act as something more approaching an Agile coach. I help our clients work better within their organisation, so that they can subsequently achieve more with us.

As a result, I have attended coaching courses, and events attended more by Agile coaches than by people on the project side. After these events, even if I’ve learned something, I often end up feeling slightly unsettled and off-kilter. The theories and ideas that people were communicating were sound, but I was itching to know how they had been applied in a practical context, and that information never seemed to come.

Theory is just a beginning

Our priority at Red Badger is to make projects work as best they can so we can deliver a successful outcome. The theory is constantly evolving, and whilst knowing all the theory is sound, it is simply a jumping off point. For example, you can’t pass your driving test by only reading a book, but it’s an important part of the process.

When we engage with a client, delivery is everything. When we go in, we feel that the best way to introduce Agile into an organisation is to actually practice it. We take a full, cross-functional team, deliver a project quickly and to a high level of quality, and in the process show the true benefits of introducing Agile into an organisation (or, honestly, whatever method of delivery will work best for them). It’s very much a case of do as I do, not as I say.

The bigger the corporation, the more vital it is to show rather than tell. We have worked with several companies that have been going through “agile transformation” for months, or sometimes even years. They’ve read the books, they’ve had the lectures, but in the day to day they’re stuck with the old ways. It is natural to be risk averse when you’re responsible for £millions, so making a change that is so fundamental is almost impossible to achieve. There’s also a worry that if a way of working changes, jobs are at risk. When all you’re hearing is the theory, it can be difficult to see how you might fit into the new normal at your organisation. That’s where people like us come in.

Delivery is irrelevant?

This idea of learning by doing may seem like a no brainer, but I have heard some coaches state that delivery is irrelevant; that the theory of the process is all that needs to be discussed, and that it will answer all your questions. Just like in science, you don’t need to see something happen to know that it works (the sun controls the tides, right?).

When we go into a client, we do start as theorists. We poke and prod what they have, and put in an Agile framework that feels best for the situation. However, it isn’t until we start delivering that we discover what truly works for that specific client. A way of working that seemed like the gold standard on paper turns into a nightmare when used. So we use our failures productively and take small, incremental steps away from the theory until we have something that works for the situation and the client. This is the way that I’ve seen an “agile transformation” really start to succeed.

So for me, delivery is everything. Putting into practice the things I learn during lectures, learning from my mistakes and the outcomes is going to make me a better project manager. Theory can only get you so far.

Not All Agile Coaches

I may sound like I’m tarring all ‘Agile Coaches’ with the same brush. So I’d be remiss if I didn’t mention the fact that I’ve met some truly great coaches. Mike Cohn, for instance, provided the best Scrum training course I’ve ever attended. And of course there’s our very own Toqir Khalid, who’s come into project manage several very complex projects for Red Badger and managed to herd the largest of cats.

However, the things that these guys have in common, along with the other coaches worth their salt, is that every theory they taught was backed up with practical examples. The thing that made Cohn’s training so engaging was that every time someone asked a question, he offered a real-life situation for context.

The best Agile coaches have been there, done it. They already had failures that you haven’t encountered yet, and have found ways to improve. Those are the people who I want to learn from. The ones that are happy to fail, and eager to share the resolutions with others.

So, if you’re an Agile coach, be mindful that not all projects can be perfect, and that ‘failing fast’ should be encouraged. The best coaches I’ve come across understand this, and help educate us all in how to apply the theory to achieve success. So if you find yourself becoming a pure theorist, and hitting people with a word-constructed process stick, I’d strongly consider spending some time back on the ground. You might be pleasantly surprised to see what we’re managing to deliver, even if we’re not perfect.


React London Meetup September 2016

by Seb Flippence

Free beer and pizza, developers, and maybe React talks? You’ve come to the right place!

This month’s React London Meetup was held at Skillsmatter, CodeNode, which a great place for like minded developers to socialise, share their ideas and see the latest trends in the React community.

So without further ado, on to the talks!

Keith Woods – Building Maintainable Single Page Applications With React

Keith Woods

Keith Woods works for Adaptive, who are real-time application and infrastructure specialists.

His talk was around patterns that they’ve used to manage complicated state. He also demoed a simple Scrum Task Board using esp-js-react with epics, stories, and tasks.

They’ve used their framework esp-js at Adaptive to avoid creating fat controllers, views and models. esp-js revolves around a model-first development process, which can be used to deterministically update their models.

A React view can be used with the ESP event router, this acts as broker between the model and the view, so anything that wants to publish events can stream updates to the view. This means that the latest version of the model is dispatched to the view or observers in real time. It’s similar to unidirectional data flow that exists in React Flux architectures.

For their team, it also simplifies their codebase by providing these events where certain computations should happen such as working out sums and when/if components should update.

Events can be serialised into an event queue and replayed through the ESP event router to help manage state.

His talk also covered mutable (changing states) and immutable (non changing state). To change an object’s properties in an immutable event-based system, you first have to create a new object and assign it the previous object properties and any new properties you want to set.

Using immutable state makes it easier to track if a component should update, because you can check to see if an object instance is equal to another object instance. Whereas in an OO/mutable model you have to keep track of property value updates to make sure that it’s okay to set your React components shouldComponentUpdate flag.

ESP events can be wired up using the ES7 decorator syntax, which then observe events as they happen. These can be created in a granular fashion and then built up to handle complicated state changes.

There were examples of how you can use esp-js’s built-in React components such as <RouterProvider /> and <SmartComponent /> to configure your application, which creates the router and pass down the props the relevant components/subscribers. ESP also provides an @esp.viewBinding decorator to automatically resolve view bindings for models.

His team have built a real-time FX Reactive Trader Cloud app written in esp-js which is bundled as a client application using openfin and Electron. Traders can use it to buy and sell different currencies and get notifications on prices and transactions. It’s push-based and can be left open all week and will automatically update the app’s base code and prices:


The backend is event-based and works using linked microservices in the cloud.

Graham Mendick – The Navigation router

A photo of Graham Mendick presenting

The Navigation router is a new data-first URL router for React. In his presentation, Graham explained what’s wrong with the existing React Router:

“React Router was initially inspired by Ember’s fantastic router. Many thanks to the Ember team.”

He went on to question their reasoning, that if: “React is nothing like Ember, why have they used used this statement?” and that it’s only “fantastic for Ember and not for React”. When parameters change in the Ember’s router it’s passed down into the view, but it doesn’t replace the view.

React router “Displays a view”, “Changes a view”, and “Changes the data”, but there’s nothing new here that you can’t already do in React itself.

Graham’s Navigation router is the opposite and provides new functionality which React and React Router do not provide.

A new StateNavigator can be created and this holds URL parameters that can be used to map/route to a certain state. So when the URL changes it checks to see if the key state.${your-react-render-method}.navigated exists as a function and will then call it. This gives you control on how the route is rendered.

When building hyperlinks the URL is never hard coded, instead a <NavigationLink /> component is imported and given the stateKey you want to navigate to and navigationData that you want to provide to the route.

Default values can be used for your state properties, so that you don’t have to provide it in the URL or <NavigationLink />. State is maintained across the application so you won’t lose user input when navigating.

URLs are automatically generated for states, but can be configured into prettier URLs being any subpath the user requires. So that query strings can be route/subpath parameters.

Alexey Golev – Pros and Cons of Static Typing

A photo of Alexey Golev presenting

Alexey argued “Should we use typed language within a dynamic untyped language like JavaScript and do we actually need types?”

As a developer using JavaScript there are a number of typing stages we go through:

Stage 1 – Denial

Types don’t exist in JavaScript, or do they? Under the hood, variables are casted into types and providing types upfront can help us find problems before we even run our code because if we provide an incorrect type our IDEs and compilers will complain.

In JavaScript we can use TDD to assert if variables are a certain type (e.g. assert.isFunction(myVar);), but this seems like a lot of extra work. So we should either use a typed language upfront or use type hinting.

“A type system is a tractable syntactic method for proving the absence of certain program behaviors by classifying phrases according to the kinds of values they compute.”

–Benjamin C. Pierce, Types and Programming Languages

Stage 2 – Anger


– ██████████, Good Programmer

People may disagree about using types in their programming language of choice, saying that it’s too verbose and less flexible and maybe that’s why they are using that language in the first place.

Stage 3 – Bargaining

Using an additional framework or runtime checks can provide some safety nets around typing issues such as:

In React we tend to use PropTypes to define the type contracts between our components.

Stage 4 – Depression

The depression stems from fatigue and “What am I going to use?”:

There’s also the problem of how long the framework will be around and if it will just disappear.

Looking into how many stars and forks a project has on GitHub can help you decide which one you should use. There are a lot of JavaScript based type system out there, so choosing the right one can be tricky. Looking to some of the larger companies to see who’s using what, can also be an influencing reason.

Alexey did also suggest not to use the any type as it’s pointless!

Stage 5 – Acceptance

“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.”

– Martin Fowler

Using a statically typed system that outputs JavaScript has a lot of advantages and can help you write better error free code.

Are we what you’re looking for?* Red Badger is hiring! For details on our tech stack, positions and clients take a look at our Join Us page.

* And vice versa


React London Meetup August 2016

by Matt Phillips

Great beer, pizza and speakers can only mean one thing, another React London Meetup! This month we had three awesome speakers and the sweltering hot weather that can only be “enjoyed” once or twice a year in London.


Redux Middleware

Jonny Reeves – Improbable

First up we had the fantastically fast and clear talk by Jonny giving a great introduction into Redux, Redux Middleware, and how to implement your own tested Middleware.


Jonny gave an excellently executed demo of a counter app with a twist – an extra requirement that if a user selects add five times the app will have a side effect.

The Counter App was composed of:

  • View – a React Component that has two buttons, add and subtract, that when clicked dispatch an action to a reducer
  • Redux root store – the app’s root atom state management. When actions are dispatched they are consumed by the related reducer which updates state, triggering a re-render of the view
  • Redux Middleware – sits between the view layer and the reducers and intercepts actions before they hit the store. Once they’ve done their bit, they then pass the action object onto the next Middleware, and once all the middlewares have been consulted in order, the store reducers are reached. Redux Middleware are a fantastic choice for encapsulating side effects.

Jonny concluded this demo with examples of how to test your middleware using Mocha, Chai and SinonJS and how to design your middleware to be composable by injecting callbacks into the middleware allowing you to test your side-effect using spys.

You can check out Jonny’s slides here.

Re-writing a frontend with re-usable React Components via an API

Chris McKenzie – Notonthehighstreet

Next up we had the very interesting talk by Chris on the troubles of incrementally migrating an existing system to React and how NOTHS achieved this through Toga – a CaaS (Components as a Service) system developed by Chris himself.


Chris began by describing the age old problem of being tied into a specific language and outdated tech (sorry jQuery!), and the struggles of code becoming stale and brittle due to changing architectures and opinions over time.

So what did they want to achieve at NOTHS?

  • Develop faster for the business
  • Make changes easier
  • Share code
  • More out of their tests (no longer is testing an afterthought)
  • Serving the browser efficiently

This led to Toga which serves universal components which are pre-rendered on the server and initialised on the client so that they can be instantly used with any web-app.

So how does it work? Toga runs as a service supplying your custom component library on request. These components should be considered as Top Level components which contain all of the business logic needed. When making a request for a component props can be supplied as a url query. Toga will return the component as pre-rendered HTML. It also returns the associated JS, CSS and Vendor bundles to the page containing only the required assets – serving the browser efficiently.

Toga has allowed NOTHS to deliver code with the most value to the business during this migration phase, providing quick feedback cycles and sharable code.

Cycle.js: a reactive framework

Luca Mezzalira – Massive Interactive

Finally we had Luca give us a persuasive introduction into an alternative architecture of Model-View-Intent with Reactive Programming concepts in Cycle.js, with his eye-catching and informative slides.


Luca began with an introduction into Reactive Programming versus Imperative Programming. He then gave us an explanation of the core tenants that make up Cycle.js:

  • Pure functions – a function that given the same input will always return the same output and not cause any side-effects
  • Drivers – functions that listen to sink streams (their input), perform imperative side effects and may return source streams (their output)
  • Components – reusable piece of the UI, except in Cycle.js they have a special property, any Cycle.js app can be reused as a component in a larger Cycle.js app.
  • Streams – Observables are lazy event streams which can emit zero or more events, and may or may not finish

Luca finished with a demo of a TFL live feed and an overview of the Model-View-Intent architecture that is implemented in Cycle.js. By using Observables to communicate, each layer is decoupled as it does not directly know where to send each event, rather the event is detected by being observed. This decoupling and the fact that Observables are just pure functions is very powerful when testing.

  • Model – this is where the state is stored
  • View – receives data from the model observable and prepares the Virtual DOM
  • Intent – interaction from the user that prepares the data for the Model
  • Renderer – the Virtual DOM is injected and rendered.

Thanks to Jonny, Chris and Luca for their great talks, Facebook for hosting and everyone that joined us! Did you know we’ve moved the home of the React London Meetup? Check it out! Be sure to keep an eye out for next month’s tickets as they are likely to sell out quickly.


Branding a castle for a weekend

by Sam Griffiths

This year for Red Badger’s sixth birthday we stayed at Schloss Beesenstedt, a castle 45 minutes from Leipzig in Germany.
We had our Company Day, setting the direction of travel for the next 12 months – and then we had a party. It was a magical and stunning setting. It was amazing!


Amy, Becca, Val and Saadia all did a huge amount of work to make this happen, including a site visit earlier in the year. As part of that they were able to give the design team a great brief on the feel they wanted to capture in the graphics for the event – and naturally enough this sprang from the very individual, esoteric, dramatic and gothic nature of the castle (Schloss).

We hit upon the phrase “gothic decadence” to sum up the feel we were aiming for. We then hunted for ways in which we could express that, looking in bookstores, online, finding samples, testing colours…

We started using a heavy blackletter font called Fette Gotisch – it’s pretty hard to read – and as such would be impossible to use on almost any other job! But functionality was taking a back seat to decadence!

We knew that our palette had to be dark and rich. And that’s something we wanted to run through our imagery too. The question was, what were we going to use…? We were pretty sure we wanted flowers… rich, decadent and fleeting *swoon*. In the end Froso dug out a book she’d picked up from the Riks Museum in Amsterdam – it featured an amazing still life of a vase of flowers with insects crawling over them and a snail in the corner. It was rich and beautiful, but also dark and a bit dangerous.

Then we really lucked out and found this. The Riks Museum have digitised a huge part of their collection and made it freely available. It’s a fantastic resource. And it meant we suddenly had access to a wealth of appropriate high-res imagery. We now had a palette of rich, gothic decadence to use across all the materials required.

As part of putting the materials together we realised that they should not appear to come from Red Badger but from the Hotel itself, helping to create a make believe world around the hotel for this one weekend. The booklet we created for all the guests has an introduction written by Armin, the lovely/crazy guy who owns the Schloss. And the logo on the back page is framed by the line “Prepared for [Red Badger] Leipzig 2016”.

In the end the Schloss itself was so atmospheric itself that our materials didn’t have to do a great deal more – just help amplify what was already there. This was heightened by flowers Amy sourced, that fitted the theme perfectly, and the Badgers themselves, especially during the gothic masked ball. Here are a few pics….







A blog article by Sam Griffiths, Froso Ellina and Nathalie Goepel


Emotions and sales are ruling your life!

by Nathalie Goepel


120 international speakers, 3000 participants and more than 900 companies – that’s the Fifteen Seconds Festival. For two days, the city of Graz in Austria was celebrating the digital thought leaders of tomorrow. All this with a special dedication to the topic of innovation.

I attended both days (16 and 17 June) to find out about current trends in marketing, sales and advertising. What are the hot topics right now? What do people in small and big business talk about?

Technology has already taken over our private and work lives. Everything is controlled, everything has an algorithm, but what is happening to the human being?

The overall theme of the talks was that it’s time to take back control and be user-centred again. Using emotions can help businesses to stand out and be successful again.

Here’s an overview of my personal highlights:

Nobody cares what you say.

Oracle’s Vice President Matthew Banks excited the audience from the beginning with his provocative and outgoing talk.


It’s quite simple: no one remembers what you say, no one is interested in what you say because no one remembers anything at all!
All that matters is how you make people feel. Think about it for a second, talking to your friends, do you actually know what they said? Well, maybe you’ll remember a few words but that’s about it. In the end we remember the emotion behind how they said things, how it made us feel and how it changed our relationship. In the end it’s all about feelings. As a human being nothing controls us more than emotions and relationships.

And this is what really matters for organisations too. If you want to stand out as a company today you need to invest in journey mapping. Invest in your user. It’s critical to learn the emotions of the modern buyer and what triggers their decisions.

It is important to understand your customer and to reconsider the customer relationship. Opinions and prejudices about products and brands control a customer’s behaviour. Therefore it’s necessary to apply a positive change to detach them from those opinions and tensions by involving the customer with the following process:

  • Create Initial Map
  • Evaluate
  • Explore
  • Brainstorm and create a new customer experience.

This is a brilliant and simple technique for focusing on the inside in. It’s a quick way to bring to life what matters the most to the customers, when and where to deliver a special experience and how to tell the right story.

Where is the romance? Rules for creating romantic emotions in business

In contrast to the provocative Matthew Banks, Tim Leberecht – the bestselling author and founder of Leberecht & Partners – was all about romance.


We live in an disenchanted era of big data and quantification in all areas of life. We live in a world of algorithms. More than ever we are in deep need to rediscover romance, beauty and serendipity in business. It’s time for a new romantic era. Let’s fall back in love with our work and our life by designing products and experiences with an emotional and purpose-driven benefit.

But how do you become a business romantic? There are three rules of enchantment to follow:

Find the big in the small:
Algorithms are not everything, people strive to break out of the norm. The small and unexpected moments in life are what make the difference, not the big gestures.

Keep the mystique:
Secrecy and mystery make experiences meaningful again. Romantic is what is mysterious and does not last. It’s about the special moments. For example, take the experience company Secret Cinema, the movie itself almost doesn’t matter, it’s the unforeseeable details of the experience that catches attention and excitement. It’s all about making the familiar strange again!

Suffer (a little):
Real passion can only be developed with a bit of suffering. Business romantics require customers and colleagues to make a bit of effort themselves. Ikea has perfected the art of frustration, it’s an exercise and sacrifice to buy and build the furniture. Customers have to experience frustration, they have to want your product desperately, it’s like a love relationship aiming for the product. Like a real romance!

You are in sales. Get over it!


The next talk sales pitch was by Steli Efti the founder and CEO of Close.io. As one of the biggest sales people in the world he knows that sales has a bad reputation. And yes, the truth is no one wants to be in sales. No one ever said “When I grow up I want to be a salesperson”.

Well, the fact is if you are a human being, you’re always selling. Everything you do in your daily routine, in your career and your private life is selling whether it is in order to get a better job or selling yourself to the opposite sex. You’re always selling!
You can’t just change the world by only proposing ideas but you can change the world by convincing other people to take action. Sales means nothing else than being result-driven in your communications. The only questions are: What am I selling today? & how can I become better at it? You need to educate and sell them on the idea about why this makes everyone’s career and life better. You can’t just tell people “Sales is important.” You need to educate people. You need to pitch it to people again and again. Highlight the behaviour you want other people to replicate.

Start selling! Just do it and truly care about it! Sell yourself, a belief, a thought; just make sure you have convinced yourself first.

A happy team is a productive team

In the end it’s all about happiness. Isn’t it? Nico Rose, Senior HR Director at Bertelsmann and responsible for thousands of people definitely believes in it.
Culture is the secret to every company’s success. At Red Badger we strongly agree with this. Positive psychology can contribute a lot to make companies more valuable in terms of productivity, success and profitability.


To treat your staff well first means you have to invest a lot. Investing in time, facilities and staff. However in the long term a happy workplace equals more cash.

So what’s the point of spreading positive emotions such as satisfaction, excitement, or happiness?You want to know why? Well, there’re a lot of reasons.

  • Happy employees are less often sick. Why? Because positive emotions act like a protective element for the psychological immune system.
  • A happy staff also stays longer in your company. This saves you time from teaching new starters the ropes and you’ll need less personnel marketing as happy people also use word to mouth more actively.
  • Happy employees trust you more easily and are more likely to help other team members.

You see it’s very simple. If we are anxious or stressed, we withdraw. Positive emotions, however let us grow and are infectious. They help us expand our thinking and acting and drive a sustainable learning experience. They are the breeding ground for creativity and they drive us to think outside the box.

Developing aspects such as creativity, commitment, joy and self-fulfillment can increase the company’s value. Creating a workplace where your staff can flourish has a huge impact on people’s psychology and in the end their working attitude. Working for a company like Red Badger shows me and my teammates everyday how much of a difference it can make. I feel good coming to the Badger office every day. Why? Because it’s a relaxed environment where I feel comfortable chatting to my colleagues about life and work. This is why we’re more creative and productive at the end of the day; happy people are more productive, motivated and creative. Sometimes it’s just that simple!



I learned a lot during those two days and created a simple conclusion for myself. I will use the gained insights to make sure I focus on the users and create special and emotional experiences for them.

So I came to two key messages:

Learning 1:
Get outside your comfort zone. You don’t have to like it. Just get over yourself. See it as a valuable opportunity to train yourself.

Learning 2: It doesn’t matter what you say or do but what feelings you are evoking in people. Only those feelings will be remembered.


Emotions are replacing machines and technology. We need to focus on the human beings and their experiences to stand out of the crowd and be successful.
Be provocative, different and surprise with the unexpected and you will win people’s hearts. Fifteen seconds took this to its heart and created a magical festival. They connected the right people at the right place and time in a relaxed and intimate atmosphere. A place created like an inspiring playground to unleash and motivate networking filled with inspiration, all kinds of activities and not to forget amazing drinks and food. Simply an unforgettable emotional event..


Photo credit: Fifteen Seconds


WE HIRED A GERMAN CASTLE! ( AKA the best summer party ever)

by Amy Crimmens

Last month all the Badgers plus a whole heap of our friends and partners headed off to Leipzig to spend the weekend IN A CASTLE.

Red Badger is quite well known for throwing pretty fantastic parties (last year we took everyone to a private island) but I think last weekend was our best yet. We have resorted to writing a collaborative blog as after looking through the fantastic photos we have realised many of us have a missing hour here and there; so here are some of our favourite bits….

London > Leipzig, Joe Dollar-Smirnov

It was that time of year. The Badgers were ready. The annual summer party was upon us and in preparation we had packed our bags, booked our tickets and made arrangements to convene in one of the various trains heading to Standsted airport on that Thursday afternoon.

Badgers, distributed around Central London put down their tools, let down their hair and embarked on a journey to the mystical place that had been slowly revealed from a series of teasers earlier in the year.

The holiday had started.

Champagne toasts on the train, cheering and laughing and last minute panics, checking to see if everything was packed.

By the time we got to the airport the Badgers were united with their beloved plus ones for double the fun. Meeting and greeting new faces and old. Distributed teams, across bars in departures. Long queues. Very long queues. Then the next long queue to check in to our flight.

Looking up and down the line every other person was a Badger. The plane took off, more drink, some sleep then land.

A slightly lethargic but excited group gathered in arrivals led our fabulous crowd control expert. One by one she called off the names from her list. Organisation like this does not come easy. Herding cats.

“Half of you in that coach, half of you in that coach”

And off we went.

1 hour later the hi-tech luxury coaches pulled up to a mysterious location in a quiet village.

150 tired but excited, ready to go again, yet some hungover people all disembarked. It was 11pm at night.

BOOOOOM and a fireball of red hot flames shoots into the sky. Some duck and cover, some cheer. Everyone is amazed. Again, BOOOOOOOOM. Another fireball. A dragon is spitting excited fireballs into the air and then above the din the sound of the founding Badgers and the rest of the welcome party can be heard shouting, laughing and enticing these coach loads into the Castle.

This is where the real fun begins.

The Gothic Masked Ball, Valentina Soricaro

Finally the long awaited evening comes….I had been preparing my outfit for months and I was so curious to see how everyone else looked like. And I was not disappointed!



Despite being the only known “goth” in the company, everybody had made a massive effort and when I walked  down the castle stairs to meet at the Champagne Reception accompanied by a String Quartett, my eyes were overwhelmed with lots of black, darkness, mystery, fascinating masks and beautiful smart dresses.

group blog

The evening continued  with a great dinner and when we entered  the hall, everything was  decorated in the classiest way and there were beautiful flowers and candles all around, thanks to the work of our 3 amazing colleagues Amy, Saadia and Becca. I am sure I wasn’t the only one feeling like I got the time machine back to the 12th century.  The food was fantastic and we soon were drowning in rivers of delicious wine from the castle vineyards. After the dinner the merry Badgers met on the dancefloor to set free their inner ballerinas at the rythm of Trikosaki music (a band hired just for the occasion) and not long after down in the basement for some Techno courtesy of our founder Cain and other amazing Djs!


Remembering it now, I get a weird feeling of nostalgia and euphoria at the same time. Being in that decadent beautiful place, all dressed up, all having fun, all sharing our life outside of work, all being happy,  truly made it a special and unforgettable evening (despite some blurs given by the wine…). Most of the Badgers made it through the end of the night and I retired in my room at the early hours of the morning, with smudged make up and the happiest smile on my face!

The day After…., Harri Adams

I would love to tell you about our visit to the vineyard on Saturday, but sadly I was still dancing with a bottle of prosecco clutched in my hand when many badgers were getting up for breakfast. Safe to say, when I eventually went to bed, I was out for a good few hours. When I eventually emerged (around 5pm) I was feeling fresh and ready to do it all again!

By this point, there were some interesting tan lines (award for best suntan undoubtedly goes to Jon Yardley’s sock-marked ankles), some jolly wine faces, and all sorts of stories about the weird things that had be found in the castle the night before. Sombreros, bottom halves of mannequins, giant bathtubs, creepy portraits, strange metal sculptures, furry-walled rooms… And that’s just for starters.

We sat by the pool in the evening sunshine, drinking more prosecco and smothering each other in glitter, growing more ravenous by the second. As soon as the BBQ was ready, we scampered up to the ballroom and enjoyed a feast of german sausages, burgers, halloumi and a variety of salads, all washed down with many more alcoholic beverages. I’m sure you’re starting to see a pattern here…

IMG_2354 (1)

An hour or so later, and we heard there was a surprise waiting for us all by the pool. Electric with excitement, we gathered outside, just as the first of the fireworks lit up the night sky. What a spectacle! A truly special and memorable moment for us all – sparklers in hand, or in Federico’s case, a flare in hand.


Afterwards, feeling on a high, we all headed back to explore more of the castle. I found myself an hour or so later in the Liebe room, a room with fur walls hung with many naked pictures. I chose not to think too carefully about what those walls had seen. Towards the end of the night, about 20 of us ended up sat around the huge dining table chatting and listening to music. The venue couldn’t have been better suited to us and it was fantastic to share this experience with so many like-minded, fun people – it’s sometimes easy to forget they’re our colleagues.

Huge hats off to Saadia, Amy, Val, Becca & Nathalie for all their hard work – without which either the party would never have happened, or we’d all still be there.

The Castle, Becca Evans

I think it is fair to say the castle itself was EPIC. I remember when we first went over in June to do a recce – there had been a rave for about 300 people the weekend before, the place was a tip, people were literally still crawling out of it – but even in its state of complete chaos we were still blown away.

It took 3 hours for Armin to give the complete tour of it (albeit we were stopping every 20 minutes to refill our wine glasses) and at the end of it all i thought was the Badger’s are going to bloody LOVE this!

As soon as everyone arrived on the Thursday evening (much to Dave’s dismay…) they spread like wildfire – for such a huge place we really managed to make our mark. From the main dining room, to the balcony, to the weird Liebe room (I still haven’t worked out what that room is actually used for although i think i have a good idea…) there were Badger’s everywhere – it was the perfect setting.


I think the best thing about the castle was how versatile it was. On the evening of the Masquerade Ball everything was done to perfection – the chandelier staircase leading down to the champagne reception looked like it was built for royalty and the main dining hall that we ate in was equally as grand…. Fast forward 6 hours and you would find half the badgers had made their way down to the underground caves where the after party had begun. Things were a lot less fancy down there – it was dark and there was a smell that I would like to forget – but no one seemed bothered – they just wanted to carry on the party..

It really did cater for everything we wanted  – An evening to begin with decorum and to end in debauchery…


I think the main reason for the weekend being such a success was because of Armin (the owner of the castle). For those of you that met him, you will agree he is a unique character – his answer to pretty much anything to both men and women is “just take your clothes off”. Throughout our trip he was on hand to make sure everything was going to plan and that we had everything we needed, e.g. 20 extra bottles of Cava at 9am by the pool – it was there without fail.


(Armin with his brilliant yellow trousers)

The castle really was a magical place but it was the people that made it special. Now that we have been back a couple of weeks and just about recovered – who is ready for round two? I am.

Back to me again ( Amy)…

It may sound like it was one big party, and it was, but we also spent a day thinking about what we want to achieve over the next 12 months and came up with some great ideas. Spending time away together is also a great opportunity to build memories as a team and remind ourselves what fantastic people we work with. I think we’ll be talking about this trip for a long time to come!

There are heaps more great photos from our trip here. If you’d like to join our brilliant team check out or vacancies here and get in touch!