Posts Tagged ‘management’


Characteristic of a Good Product Owner

by Toqir Khalid

Typically on most Agile projects, the success (or failure) of a project can heavily depend on how good (or bad) the product owner is and how committed they are. Good Agile teams that consistently deliver the right thing at the right time, and with quality in mind, will always have a product owner that is focused on the overall bigger picture and able to articulate this into the smaller pieces that are needed to deliver their vision/goal – i.e. the individual user stories.

Anyone can take on the role of the product owner, but to be a great one is hard! Let’s take a look at some characteristics that great product owner’s have:

Relating the vision/goal to backlog items

A lot of product owners are good at making the business case for a project to go ahead, but very quickly end up with a backlog that is disjointed and seems disconnected from the original vision/goal that they started with. After a couple of sprints, it’s likely that most of the team (perhaps they too) have forgotten what the original goal was and why they’re doing the project. The phrase ‘can’t see the forest for the trees’ comes to mind.

A great product owner will

  • ensure the business case is encompassed into a short vision statement,
  • makes this visible to everybody.
  • But more importantly, can always refer back to this when explaining every user story on the backlog.

One of the best ways to convey your vision/goal is with an elevator pitch. The product owner should

  • come up with their elevator pitch,
  • make it clearly visible to the team,
  • and constantly refer back to this to explain why the team is working on the prioritised backlog and the individual user stories.

Write User Stories with the team and allow them to contribute to the business value, i.e. the ‘So that…’

Often product backlogs are created by the product owner in silo and given to development teams. A lot of the time, the user stories are a set of task lists (or wish lists) the product owner wants the team to do. It can be difficult for the team to understand why they’re doing what they’re doing, especially if the vision hasn’t been stated.

A great product owner will

  • work with the team to come up with a product backlog that is
    • relevant,
    • links back to the vision,
    • but also includes the business value (i.e. the so that …).

This means the team fully understands the reasons and value of each user story and how it is intrinsically linked back to the vision.

The product owner must ensure that each user story has

  • a clear ‘why’ for each user story which explains the value/goal for the user
  • what the user is trying to accomplish rather than the feature in the system.

A great product owner will try to work with the team to solve the problem/issue for the user. This is likely to allow the team to solve the problem in a way any individual wouldn’t have thought of doing.

Respond to changing circumstances

For the duration of a project, business goals, technology changes, new regulations, or a competitor’s latest release will likely mean that the business/project priorities need to be changed in order to adapt. Often product owners and senior management will try to stick to the original goal in the hope that they will be seen as correct. Often that is not the case, and the project ends up delivering something that is out of date before it’s even launched.

Product owners should

  • always be able to adapt to changing circumstances
  • and modify the current product backlog so that it’s inline with what’s current now.

The modern world moves at a rapid pace, and great product owners are able to ride the wave and change the product backlog accordingly without having to throw away lots of work.

In order to do this, the product owner and the team should only be looking a couple of sprints ahead. The top of the product backlog should contain user stories that are small enough and have the necessary details that the team feels comfortable with. It’s very hard to see past a couple of weeks, as things are likely to change, so why plan to detail product backlog items that are planned for several months into the future. Simply add Epics/Themes to the backlog which can be elaborated upon when the time is right

Backlog priority

Say No without being a jerk

Senior stakeholders trust product owners to make the right decisions for the product that is being built. Therefore, a product owner must be conscious of what they say yes or no to. Great product owners will say no to many requests without being a jerk. The following are some examples a product owner could use:

  • ‘Thats a good idea, but we’d need to pull something out from the current backlog to accommodate this. What would you suggest?’
  • ‘Can you help me understand why this is important for you. Maybe there’s another way to solve your problem and we might have something similar already on the backlog’
  • ‘Maybe we could include that as part of this story, which is similar?’
  • ‘I”m not sure that aligns with the current vision for the product/project’
  • ‘No, because [reason why you’re not putting the item onto the product backlog]’

It’s very hard to say no to requests, but if it doesn’t align with the vision for the product, the product owner should be saying no, but providing the reasons for it in a friendly, and courteous manner.

Size matters! Small is good (for user stories)

A product owner must be able to

  • take the high-level vision and start to deliver value early on
  • in collaboration with the team, turn the vision into a prioritised list of user stories that are small enough to deliver value to the users immediately.

Having user stories that are large, vague, and take a long time to deliver are of no value to anybody.

Splitting out user stories into small manageable chunks of work also allows you to prioritise and focus on the high-value items that should be worked on first.

Becoming good at breaking down user stories into smaller chunks has the following benefits

  • Helps prioritise the high and low-value user stories, allowing the team to always work on delivering high-value user stories, and not waste time on low-value items
  • Focuses the team on building what’s right for the product and the overarching vision
  • Reduces risk by allowing you to concentrate on completing the hard to do things first. Generally, items that are of high value tend to be hard to do. By focusing on this first, you reduce risk on the project
  • Early feedback – by completing small chunks of work, users will be able to feedback to the team and allow them to adapt and change the backlog accordingly

Available, Engaged & Committed

In an ideal world, the product owner should be available to the team at all times. However, most product owners will have other work to do too, so it may not be possible to be 100% available. They should try to spend as much time as possible with the team, preferably face to face, to work in a collaborative manner. If they aren’t available to respond to questions, or participate in team discussions, it’s likely that the project will struggle, due to the lack of leadership. If they aren’t available to provide feedback and sign off for completed user stories, the team is likely to lose momentum on the project. If they can’t be made available for considerable amounts of time to support the team, consideration should be given to a proxy product owner who has the authority to make decisions.

The product owner should also be actively engaged and committed to the project’s success. The more time they spend with the team and is working with them in a collaborative manner, the better the chances of success on the project. An engaged product owner is a natural leader, as they find themselves leading a team through their decisions and makes it apparent to the team that they are committed to the final product. Great product owners build up a very good rapport with the team, and builds relationships with them to allow the team to focus on delivering the right things at the right time.

Great product owners are able to inspire and motivate teams just by being available to the team and working side by side with them to keep the project aligned to the original vision/goal. One of the best things they can do is to sit with the team as much as possible, so that they are available to the team and allow relationships within the team to be built.

Empathy and humility

Product owners have been given permission by senior management to make the necessary decisions to build the right product. With this comes the product power to lead teams and drive their vision forward. Great product owners lead through empathy and humility, working side by side with the team to make the correct decisions. They show their empathy and humility through their past success, continually making the right decisions, and correcting poor decisions to lead the team forward.

Be Prepared

As any good boy scout will tell you, you should always be prepared. It comes as no surprise that great project owners are always prepared. They alway come prepared to the ceremonial agile meetings, they are prepared and ready to make the necessary decisions.

A team will have greater confidence in their product owner, if they’re prepared for everything. If a product owner isn’t prepared, it will quickly become apparent, and the teams trust will be lost very quickly. It’s essential (and important) that the product owner is always prepared to lead the team, turns up to meetings with the right material, and takes pride in their work.

In God we Trust

No, I’m not trying to convert anybody to become religious, or even pledge their allegiance to the USA (‘In God we trust’ appears on a $20 bill). What is fascinating about religious people is their trust in their faith and trust in God (or gods for that matter). Some may even say it’s blind trust.

So what has trust got to do with being a good product owner? Well, quite a lot actually. Having a product owner that trusts the team to make the right decisions, and vice versa having a team that trusts them is great for team harmony and more importantly being productive. Having a product owner that trusts the team means they can convey their vision, and know that the team will do their best to achieve that goal. From the team’s perspective, having trust in the product owner means they’re doing the right thing and taking the necessary actions to deliver their vision for the product.

Having a team and a product owner that trust each other doesn’t’ just happen overnight. As the saying goes, trust has to be earned. Good product owners will establish a culture of openness and honesty within the team and encourage everybody to always be open and honest with each other, knowing that decisions and actions are being made for the betterment of the vision everybody is working hard to achieve. Trust also leads to respect. Having both trust and respect within the team and with the product owner helps immensely to deliver the right thing, at the right time, and with quality in mind.   



Staying Lean in Complex Organisations

by Joe Dollar-Smirnov

There’s been loads of writing about how operating models vary from business to business. Since Agile was a thing (from 2001) it has grown to become a buzzword that many organisations see as a silver bullet. This is not a new phenomenon. We often see the existence of companies who are using some methods that have a foot in the Agile camp but in fact find that things are still not working at organisational level.


Let’s be clear, ‘Agile’ started as a philosophy to deliver software projects, not a way to run a business.


In large organisations

If an Agile way of working is efficient then why do organisations so often fail (slowly) to get something out in front of customers in a timely fashion? Or why do you end up with disparate teams pulling in different directions? Multi-million pound transformation projects see huge amounts of money being lost on talented teams that are discombobulated despite being empowered to do the right thing.


In ergonomics and human factors engineering, we study the relationship between work and the worker. Whilst this may not sound very friendly, ergonomics is in fact concerned with the wellbeing of the people doing the work. Happy healthy workers mean a happy healthy organisation. This can include everything from the desk and computer, to the chair, the work type itself right the way through to the larger social and psychosocial aspects such as the culture, leadership and operating model (approach to structure, planning and process).


It may be no surprise that being such a wide area of study that Ergonomics is also concerned with how structure can impact error rates in organisations and how organisational structure can respond and deal with such errors. There is a wealth of stuff out there on human error and resilience engineering which talks about how to create cultures that reduce impact of error but right now I am focussing on organisational structure and the requirements for the successful and error free running of a business.


Whilst the tech industry does not generally operate in life and death situations (unless you have a really angry boss) there is much we can learn from looking at complex organisations in which organisational structure impacts on the success or failure of the business.


Nuclear Power Plant

3 mile island and Chernobyl are among the most studied examples of organisational failure in history. The events that led to the tragedies are varied and unfolded despite numerous training exercises to test multiple points of failure, in the end each of the accidents generated such unpredictable knock on effects when the operators made mistakes that nothing could be done to prevent the tragedies. There was not enough slack, and due to the unpredictable nature the complex systems at work nothing could have been done to predict or address every contingency. (Wickens). The system was both tightly coupled and complex, not too dissimilar in terms of the factors governing the organisational interaction in large businesses seeking Agile transformation.



We know how teams using a ‘just in time’ approach for delivering technical solutions can work very well. The most well known just in time method is Kanban and we use it in all our projects. Our teams are self managing and empowered to make decisions about the direction of the project based various factors, user goals, business goals, feedback from testing etc…


A just in time approach is by definition a tightly coupled system. Academic thinking around tightly coupled systems says that these systems are most prone to failure ‘because organisational requirements for their control are conflicting’ (Wickens) We can see this in businesses where a product owner is at the mercy of multiple stakeholders and project sponsors who disagree on the direction of a product or, the presence of complex subsystems (or ‘fiefdoms’) all vying for control. Where you have a complex organisation a flexible and decentralised management structure makes sense because the people at the top will never be able to make a good decision due to the complete lack of visibility.


The teams are trusted to make the right decisions at the right times.


But when the ‘system’ is exposed to something out of the norm, when something goes wrong the tightly coupled nature of the teams means there is little room for recovery due to the fact that all resources are accounted for. In our industry this does not result in life threatening situations and is fairly simple to remedy. We simply start again. Change is welcomed in Agile, but unnecessary change due to complex messages coming from an organisation has ramifications on cost.


The result is waste and wasted effort, as we know, is the antithesis of Lean.


It is essential that organisations balance giving teams autonomy with the centralisation of control. In the effort to have a flat structure, with self managing teams we must not lose sight of the end goal and give someone the autonomy to own it.



How to keep an office tidy: guidance from an Office Manager

by Valentina Soricaro

We are one: a strong company identity


Red Badger has one of the  strongest company identities  I have ever encountered in my working life.  We feel strong for the company, we like being part of it and the idea behind it; we are indeed always trying for new and funny ways to enhance this even more.

We just love being Badgers (follow us on Twitter  and you will understand what we mean when we talk about #badgerlife).


Ladies Badger monthly dinner #badgerlife

Ladies Badger monthly dinner #badgerlife




I think this is an important factor for a successful working business.

When the  employees feel like  part of the company, they act like they are part of its vital inner core, what can go wrong then? They will work their best magic, because they strongly want the company to succeed, as they will succeed too.


Good staff management skills are key to obtain a solid company identity. When your staff is treated well, it  will reward you (on this note you can read the blog written by Cain, one of our founders on why they have decided to take us on a island for Red Badger’s 5th birthday).


The office is our everyday  home


So the point here is: the Badger identity, the strong feeling we have for this company and for each other has to be applied to our office almost like a transitive property.

We love being Badgers, we work in our Badger office everyday, this has to mean we love our Badger office.

People need to be inner part of the office and need to start seeing it as their second home (after all we spend here the longest part of our days). We  need to almost feel like we  are part of the office, (but unlike furniture we are the vital part of it).


Creativity for the bathroom toiletries

Creativity for the bathroom toiletries



Our vintage stationary apothecary, newcomer in the office

Our vintage stationary apothecary, newcomer in the office



Not to mention the office reflects and  gives the first impression of what the core of the company really is. Clients understand very well when people are happy. Happy people work better; this means more profit for the company and in simple words more money. And a tidy office space where everything is accesible and in its right place helps make happier people.


So it’s all a circle really.


The secret is to make people understand that to care about the office means caring about the identity they choose to take, when working for a specific company

To treat the space almost like a living and breathing thing, living and breathing together with them.

Me and some other Badgers with our new awesome vintage fridge

Me and some other Badgers with our new awesome vintage fridge




The term “Agency” is overused

by Cain Ullah

What is an Agency?

-noun, plural a.gen.cies – an organization, company, or bureau that provides some service for another.

 “Agency”, is a pretty broad term. If I say I own an “agency”, in the literal sense, I could be in recruitment, window cleaning a taxi driver or a million other occupations. Red Badger are in digital. We build enterprise scale web applications for the likes of Tesco, Sky, Lloyds and Fortnum & Mason. In my industry, most would classify Red Badger as an “agency”. We are a member company of the Society of Digital Agencies (SoDA) after all. But “agency” in my mind is an outdated term and is used to describe too many things.

When most of my peers, colleagues or competitors are talking about “agency”, we are specifically talking about professional services companies that are in marketing/advertising and/or the digital space. Have a look at this list of companies in the Econsultancy Top 100 Digital Agencies (Formerly NMA Top 100) to get an idea of what the industry would define an “agency” these days. There are a number of categories in this list, Full Service/Marketing, Design & Build, Technology, Creative and Media. The categorisation of companies in this list seem dubious at best and service offerings of many of them are very different, despite being placed in the same categorisation. The lines between marketing, advertising, brand, web, agency, consultancy, software house and product startup seem to have become far too blurred, all of which have been thrown into the “agency” bucket.



The term “agency” for me has it’s origins in marketing/advertising like AKQA of old, but as we have moved into the digital age, companies like AKQA have had to adapt their service offerings, adding in a strong technical capability to their armoury. AKQA were once an advertising “agency”; they now call themselves an “ideas and innovation company”. AKQA still have an “agency” arm to them as they still do a lot of brand / campaign work associated to a typical advertising “agency”. Digital or not, a campaign is not built to last. However, they now also do full service delivery of longer lasting strategic applications that have a long lasting effect on their clients’ business operations; look at I would argue that this type of work is not that of an “agency”.

With the transition of some traditional marketing/advertising agencies to digital agency, technical companies such as Red Badger have been thrown into the “agency” bucket.

This has been something Red Badger has struggled with. We don’t see ourselves as an “agency”. As I said previously, for us, the term “agency” has its origins in the marketing space, with work largely focussed on campaigns or brand, be it digital or not. We also don’t see ourselves as “consultancy” because the connotations of that are associated to big cumbersome Tier 1 Management Consultancies such as Accenture and McKinsey.

What’s the alternative?

Red Badger deliver enterprise scale web applications for large corporations. They are highly complex, technically advanced solutions that can take upwards of 12 months to build. However, we also take User Centred Design as seriously as we do the Tech. Everything we build is user driven, beautifully designed and simple to use and we have an expert team of creatives to ensure this is the case. Finally, we wrap both the tech and creative teams into incredibly efficient Lean processes, running multi-disciplined, cross-functional teams, shipping into live multiple times a day. This is not the work of “Agency”.  So for now, as a slogan to describe Red Badger, we have settled on “Experience Led Software Development Studio”.

Why does it even matter?

The overuse of the term ”Agency” can cause issues. With the ambiguity of what a modern “agency” is, comes hand-in-hand confusion of what different “agencies” do. For big corporations, the sourcing strategy for a supplier has become equally confusing because they don’t know what they are buying.

When does an “agency” become a consultancy? Or are they the same thing? How do you differentiate from a digital advertising “agency” and a software house that builds digital products? I’ll leave you to ponder on that yourselves.

Some examples of companies that might be in the “Agency” bucket but have started to move away from describing themselves as such include some of the following:

  • Red Badger – “Experience Led Software Development Studio”

  • AKQA – “Ideas and Innovation Company”

  • UsTwo – “Global digital product studio”

  • Adaptive Lab – “We’re a digital innovation company”

Companies are starting to cotton on to the fact that the term “Agency” is confusing and those that provide full service application development are starting to distance themselves from the term and the brand/marketing/advertising stigma attached to it. Surprisingly, companies such as SapientNitro and LBI still describe themselves as an “agency”.

So the question I suppose, is do you class your company as an “agency” or is it altogether something else? I think it might be time for a new term that is not “Agency” or “Consultancy” that is more interesting than “Company”. Suggestions on a stamped addressed envelope to Red Badger please!!


Don’t go chasing waterfalls

by Phil Brooks



I used to really like being a Project Manager, I mean really like it. The order, the structure, the process. I would talk to people about ‘how things got done in an organised manner’ until their eyes glazed over. You see, I cut my project management teeth with local and central government. Yes! I was an advocate / practitioner of Prince 2 and the waterfall methodology. Now don’t get me wrong, I am not saying its not the right approach. Its just not the right approach for me. I thought it was, but then something happened. 

I discovered/was introduced to a new way and soon realised that the light at the end of the tunnel was not the headlight of a fast approaching,  document heavy, process driven train. There was an alternative. So I mothballed the gant charts and Microsoft Project, archived the 30 page requirements and specification docs and confined the ‘sign off by committee’  trackers to the basement. I packed my things in a hanky on a stick and went on my merry way. 

My leap into the Scrum unknown opened my eyes to a more flexible way of working, but with some limitations. Oh Yes, you still have to do certain manifesto ceremonies. Sprint planning, estimating (be-it story pointing or time-boxing) end of sprint retrospectives, end of sprint demos and daily scrums. All of which are valuable in their own right, but a little overkill, don’t you think? 

That aside, I still really really liked being a Project Manager. It opened up my creative side, it was not all about spreadsheets, and trackers, highlight reports and phone book sized documents. It was writing and drawing on walls, post it notes and sharpies, collaboration and teamwork, trusting and enabling. I noticed the teams were more open and honest. They worked together to find solutions and listened to their peers. My role changed from telling to coaching, from reporting to showing and from excessive planning, to agreed prioritisation. I was in my element and really really enjoyed my job. 

Then I joined Red-Badger Consulting and pretty much everything turned on its head. Firstly I was introduced to Kanban (similar to Scrum, but without doing the sprints). Secondly, there is no right or wrong way and nothing is set in stone. Thirdly, and probably more importantly, I was/am given thinking time, a luxury that us Project Mangers seldom get. I had to un-learn what I had learnt and un-think what I had previously thunk! 

I had never used Kanban before, and to be honest was a little worried that I had no experience with this particular methodology. But I needn’t have concerned myself. At Red Badger Consulting we are encouraged to think differently, encouraged to do what we think is right, encouraged to continuously improve and generally encouraged.

Kanban is our preferred approach, however, how we tweak and change it is totally the team’s shout. Oh yes, its a team thing, a collaboration not a dictatorship, at times even the COO hasn’t got all the answers! (although he mostly does, ask his opinion or advice and he will give it, it’s your call if you use it)

Here at the badger sett we use a mix of Kanban, common sense and flexibility to enable us to meet client’s expectations and deliver in a sensible way. Each team is empowered to make relevant changes to their processes, which makes such obvious, but often overlooked, sense, as each client is different and has specific drivers and goals. 


In my team we have made some radical changes, not to be non conformist, just simply because its what works better for us. Flexible, agile, collaborative and forward thinking:

We don’t do estimating – we see no value of finger in the air guesstimates – we do the work and collect the metrics. Real data on real events giving real lead times. 

We use littles law – what we have to do + what we are already doing / what we ship in a given timeframe (daily in our case) We ask the team to put a date on the card when it leaves the todo column and a date when it is shipped. IN and OUT. This gives us our estimated lead time and highlights tickets that have been in play for excessive amounts of time. We use this data to learn and understand what happened and how to avoid it happening or to ensure it continues happening. We also track blockers and impediments, as this has an impact on our lead times

Now, before you ask, yes I do have a spreadsheet, its a huge one too. (I am, after all a Project Manager) but I don’t bore the team with it. I take out what is useful for them, like average WIPhow long it should take to do the todo and overall metrics for the entire backlog and the occasional cumulative flowI capture data daily, how many tickets are in each line.  Todo, W.I.P, Shipped. Now I have estimate lead times, useful for when you want to advise your clients on how long something might take and why,

No more finger in the air guesstimating. Remember, real data, from real events, giving real lead times. 


We don’t do retrospectives at a set time or set day – we do retrospective when it makes sense to – we did do retro every Tuesday at 16:30, but when that reminder popped up on the screens, it was met with an audible groan from the team. So we ditched it. Now we collect thoughts and topics, when we have three or more, we do retro. The team control the topics, unless there is a crisis, then we focus on that and do a retro around that specific item. We also do it quick sharp and to the point, nobody has a chance to get bored and switch off. But in all honesty, we talk to each other constantly, so we tweak little and often.  

We don’t do massive planning sessions – we plan retrospectively. When we have enough todo, we focus on that. When the todo starts emptying out, we plan the next things that will be pulled from the backlog. We focus on the job in hand, we don’t waste time planning for something that might not make the cut.

We have continuous, one piece flow. – the team focuses on the the board from todo, discovery, UXD, dev, test and shipped. Nothing goes backwards, we have exit criteria for each swim-line. If a bug is found, the ticket stays where it is and a fix is worked on. Continuous flow,  everything moves from left to right, nothing jumps back and nothing falls off the board. Once a ticket passes todo, it is tracked to the end,  every time.  

We include Bugs and Issues in the flow – it’s still work, right? still needs to get done, so why separate it out, why not prioritise it along with the other things to do. Site goes bang, we all jump on it, slight irritating non customer facing issue we could live with, we prioritise it and get on with other things. (unless the client or the team think it should be sorted as soon as) But it’s all work, some is big, some small, but work nonetheless. 

We include UX and Design in the flow – again, work is work right? we are all the same team, right? why segment it?  well we don’t. If it has UX or design elements they get done in the flow and we measure the throughput along with everything else. 

We pair program – the designers work closely with the developers to do the designs within the app, saving time, effort and iterations. The developers pair with developers, they share knowledge and skills. They collaborate and review, the produce quality assured code with little to no technical debt

We collaborate, communicate, celebrate and encourage, through all stages of the process. 

I am fortunate to be involved in some of the most innovative, creative, technical, ground breaking and award winning projects with Red Badger. I love using Kanban. I love being able to work with a team of awesome individuals from different specialist areas. I love the ‘lets try it and see’ approach. I love the challenge and the change. 

Since Joining Red Badger,  I really really love being a Project Manager. which proves that working for the right company and the right group of people can have a profound impact on how you feel about your job.

Thanks for reading to the end, I take my hat off to you. If you want to see how we do it here, come and have a chat. We love a cuppa and a biscuit. 

visit us at


Phil Brooks 



JLT World Risk Review – Rapid Innovation

by Cain Ullah

Afghanistan Country Dashboard

We have recently delivered a project for Jardine Lloyd Thompson (JLT) to re-design and build their World Risk Review website. We’re currently in the final hardening sprint, doing some bug fixing and UAT. We’ll be able to talk more about the benefits in a case study, once the site has been live for a while and we can look at the analytics. In the mean-time I want to discuss some of the great bits of innovation (both tech and process) we have produced in delivering this project, which was just 8 weeks in total with only 6 weeks of development. 

What is World Risk Review?

World Risk Review is a country risk ratings modelling tool that JLT founded in 2006, providing corporations, banks and other organisations involved with international trade and investments with an assessment of short to medium term country risk. This allows users to build well informed strategies to manage political, security and economic risks. 

JLT is the only Insurance Broker to have invested in this capability in-house so they required a really modern website that would allow users of World Risk Review to have an intuitive and highly informative experience when consuming JLT’s expert advice.

What did we do?

World Risk Review is made up of three key areas – peril ratings data for each country, key insights (articles, insights, reports and blogs) and news. Red Badger’s role was to make these three areas easily accessible, engaging and informative. With more and more devices being used in the financial services sector, it would also need to work on tablet and mobile. So as well as being visually rich, the site would also need to be lightweight with regard to page size so that it remains speedy on mobile devices.


We designed the site using a visually rich set of dashboards to allow users to consume the data in a really intuitive way, compare different types of data and perform country comparisons. This is underpinned with easy navigation throughout the site via the dashboards and a flexible and fast search function.

How did we do it?

The site is effectively made up of two applications. The main website and a custom built admin console which consists of an analytics section as well as a custom built content management system (CMS) that provides the ability to do inline editing of content, preview of changes and deployment straight into the live environment.

I am not a techie, so I’ll ask the developers of the site to produce some more technical blogs with more detail (They promise me these are to follow!). However, below is a brief outline of how we delivered the project.

The tech

For the visual dashboards we used D3.js. D3.js is a JavaScript library designed to bring data to life using HTML, SVG and CSS. It is based on web standards. It is efficient, flexible, lightweight (which means it is fast) and the animations and interactions look and feel beautiful. The front-end is then underpinned by a Node.js server application stack (Any JavaScript run outside of the browser is run on Node.js including the admin console, APIs and Livescript – see below) and a powerful search function built using Elasticsearch. We have built an incredibly fast search based on tags, allowing flexible filtering of data with some advanced features such as “did you mean” suggestions.

My co-founder Stuart is a huge fan of Component (read his blog) so the website is built using components in almost every way you could use them, from just packaging bits of JavaScript, through custom UI elements (such as the autocomplete tag field which we vastly improved – public repo can be found here. We also improved the datepicker component – public repo here) to whole pages being rendered by a hierarchy of components. All client side JavaScript we use in the website is packaged as components, including the visualisation code. The benefit of building a site in this way, is that it is ruthlessly efficient and every bit of code that is contained in the application has a use. You build lots of little tiny modules that are great at doing one thing and then you hook them all together.

We also switched from CoffeeScript to Livescript to compile our JavaScript by writing in a functional way. The developers on the project find it really nice to use. It has tons of little tools for the typical boring tasks you do all the time and also has a lot of functional programming features, including the amazing prelude-ls, which make it ideal for data processing, such as the static site generator (see below). 

Last year we re-built as a static site. We loved the results so decided to follow a similar technical architecture for World Risk Review. The static site generation architecture deploys the site at the time that content is updated so that when users access the site, they are accessing a very simple static page rather than requesting content from a database for each action. The result is a website that is more secure and can serve pages much faster than traditional Content Management Systems (such as Drupal). The site is deployed to an Amazon S3 bucket and distributed via Cloudfront to 51 edge locations around the globe. Originally we were using Docpad as our static site generator (as we had for but we found it started to really slow us down so we built our own static site generator which brought down the time it takes to generate the HTML from the source markdown documents and Jade layouts from about 90 to about 6 seconds . This allowed us to work much faster and also enabled us to build a CMS where you could preview your changes almost in real-time. Having tested the application around the globe, it is incredibly fast wherever you are, with as little as 10 milliseconds and no more than 300 milliseconds to the first byte.

We have also set-up continuous delivery using Travis CI and Ansible. This is incredibly important for how we develop software but it also underpins how we have architected the CMS. Using continuous delivery allowed us to commit changes into a staging environment many times a day and made them available to test immediately. In the production environment, once the project is live, the content editor will be able to deploy their changes in the CMS straight into the live environment. The custom CMS is built on Git. An administrator can view the site as if they are a user, but can edit any element on the page, save it and then review comprehensive line-by-line changes to each document (or add new documents such as news items). Once they are happy with the changes, a publish button will commit to Git and will deploy into live. It allows multiple users to edit the site at the same time without stepping on each other’s toes and merges their changes in a smart way, so content management is not a race of who saves first anymore. In order to build in-line editing we were looking at a number of options such as CreateJS. However, we again decided to build our own editing tool using Javascript components for YAML and Front-matter.

The final piece of the puzzle and by no means the least important, was to build in analytics. Using the power of Elasticsearch, we built a tag based analytics tool that allows JLT to monitor user behaviour on the site. They can add custom tags to each user (such as “watch list”), filter, sort and search. This gives JLT a quantitative view of customers behaviour to allow them to adapt their future strategy around what their customers want.

The process

Given that we had only 8 weeks to deliver the project of which 6 weeks were for development, we decided to use Kanban as the methodology of choice, reducing as much friction in process as possible and allowing the developers to do exactly that – develop. The backlog was tightly managed by Sinem (the project manager) and the product owner from JLT who was deployed full-time to sit with us in our office every day. I cannot stress how important it was having the product owner integrated into the team full-time. We managed user stories on a Kanban Board and although physical boards are great, the developers managed all tasks in Github. This reduced duplication of effort, increasing productivity. Stand-ups each morning were held around the Kanban board, talking about what we had been doing at story level and we were focussed on getting stories through to delivery as soon as possible so used WIP limits to streamline the process.

To ensure quality control, we used Github flow to manage the process of building new features, ensuring that no piece of code is deployed without first going through code review by a 2nd pair of eyes. There are some simple rules to Github Flow: 1) Anything in the master branch is deployable. 2) To create something new, you create a new branch off of master. 3) You continue to commit to that branch locally until your feature is complete. 4) When you think your feature is complete, you raise a pull request. 5) Another developer then reviews your code and upon sign-off it can be merged to master. 6) Continuous Deployment then deploys your changes immediately.

When delivering a project at this speed, it is paramount that your features are tested properly. To do this, we integrate a tester into the team and get them to test as soon as a feature is deployed. In the past we have used separate tools such as Youtrack as our bug management system. However, in this project, we switched to Github issues. Having one central place for the developers to see all features and bugs together in Github has most certainly helped productivity of the team.


In just 6 weeks of development we achieved an incredible amount. We had an integrated team of Project Management, UX, Design, Dev and Test, all dependent on constant communication to get the job done. We built an exceptionally well designed, useable site on a really innovative tech stack. The use of Kanban, Github Flow and Github Issues proved to be an incredibly productive way to deliver the project. It was a very intense environment of rapid delivery but was lots of fun too. JLT were a great client not just in allowing us to be innovative with our tech and process, but also in the efforts they put in to make this collaborative. We couldn’t have delivered so quickly without their constant involvement.

As always, there is room for improvement in our process and the tech team are looking forward to new technology emerging such as those contained in the Web Components spec. Our project retrospective has highlighted some areas for improvement and we will continue to iterate our process, always pushing to try and provide our clients with better value. We have loads of great ideas about how the World Risk Review site can be improved in future phases but after 8 weeks, it is currently in a great place to deliver a far improved experience for both JLT’s customers and their admin staff.



A history of Lean in 10 books

by David Wynne


The term “lean” is thrown around a lot in the software world these days. It’s the new agile. In reality, most people don’t really understand what is meant by lean, or at least what was meant by the those who pioneered the movement.

It’s easy to hear “lean” and think “less”, presuming that we should stop doing stuff that we don’t like, or that seems hard or old fashioned and get more cool stuff done and do it quicker.

In reality Lean is a much more nuanced philosophy/methodology that requires a number of supporting philosophies in place to ensure success. At it’s core is the focus on adding value and the removal of wasteful activities, but over a long term curve and doing it consistently and predictably. That’s actually pretty hard. In fact, it’s pretty easy to get it wrong, especially if you don’t really understand what “right” looks, or feels, like.

There aren’t really a set of rules you follow to guarantee a success. More a set of principles that you need to understand, contemplating how you might apply them to your organisation, slowly and with a keen iterative eye.

The lean movement dovetails with the concept the learning organisation and continual improvement, or Kaizen. It is only with the ability to understand one’s current condition, comes the ability to improve it.

Here are 10 books from the Red Badger Library that chart the lean movement from it’s very beginning, to analytical studies on it’s success, to guides on how to implement Lean within your organisation.

1. Self-Help, by Samuel Smiles

Sakichi Toyoda (1867 – 1930), founder of Toyota, was significantly influenced by this book, first published in England in 1859. It preaches the virtues of industry, thrift, and self-improvement, illustrated with stories of great inventors like James Watt, who helped develop the steam engine.

2. Today and Tomorrow, by Henry Ford

“I, for one, am in awe of Ford’s greatness” said Taiichi Ohno (1912 – 1990), who is considered to be the father of the Toyota Production System. When tasked to “catch up with Ford’s productivity”, Ohno studied Ford’s 1926 book on his revolutionary approach to manufacturing. Ford’s moving assembly line was one of the best examples of continuous flow at that time.

3. The Machine That Changed the World, by James P. Womack, Daniel T. Jones & Daniel Roos

This book – a five year, $5m study by MIT – was the first real study of Toyota outside of Japan and helped popularised the term “lean production”.

4. Lean Thinking: Banish Waste and Create Wealth in Your Corporation, by James P. Womack & Daniel T. Jones

A follow-up to The Machine That Changed the World, the same authors discuss lean in the wider context, calling for a focus on those activities that create value for the customer and the systematic eradication of everything else.

5. The Toyota Way: 14 Management Principles from the World’s Greatest Manufacturer, by Jeffrey Liker

When people talk about Kanban and Lean they often refer to Toyota, but how many of really know how deep that link is? This book is the result of a 20 year study of Toyota and their unrelenting drive for continual improvement and removal of waste.

6. The Toyota Way Fieldbook: A Practical Guide for Implementing Toyota’s 4Ps, by Jeffrey Liker & David Meier

A companion, hands-on, book to The Toyota Way.

7. Gemba Kaizen: A Commonsense, Low-Cost Approach to Management, by Masaaki Imai

Masaaki helped popularizing the Kaizen concept in the West, with this being his second book on the subject. Gemba refers to the place where value is created, in other words the shop floor. This book fits right in next to Edward Deming and Crosby books on process and quality.

8. The Goal: A Process of Ongoing Improvement, by Eliyahu M. Goldratt & Jeff Cox

Dr. Eliyahu M. Goldratt introduces the Theory of Constraints. The Goal was a bible for Jeff Wilke and the team that fixed Amazon’s fulfillment network.

9. The Fifth Discipline: The art and practice of the learning organization, by Peter Senge

Named one of the seminal management books of the last 75 years by Harvard Business Review. Peter Senge, a senior lecturer at MIT, draws the blueprint for a learning organisation.

10. The Lean Startup: How Constant Innovation Creates Radically Successful Businesses, by Eric Ries

And you thought Lean was the latest thing! Eric Ries applies Lean to the startup.



Sprint efficiently with GitHub

by Jon Sharratt

As with everything we do here at Red Badger we try and iterate and improve each of our disciplines during an application’s or project’s life cycle. One of the items that we have been exploring is the use of GitHub and what it can bring to the table in regards to agile. Not only this, a view that in today’s world being able to iterate faster and being able to react to feedback from customers and building features as productively as possible whilst maintaining quality is key.  

There is a fantastic presentation from Zach Holman from GitHub who explains how they use GitHub to build GitHub ( It really opens the eyes to the fact that simple tools with no more and no less = happier developers and more effective development.

So with this mantra we decided to switch to try out and only use GitHub tooling for user stories, issues and managing the sprints. During the process of writing this blog post GitHub have announced the way that in which the team works aptly named GitFlow allows everyone to follow the process via the GitHub website.  

Having tried out this process the team and I agree that it is a satisfying and effective way of working especially when applied to agile methodologies.


It is important to note that we follow a branching model of the ever popular If you haven’t read this article and are working with git as version control I would highly recommend giving it a read.

Within your development team at the start of the project just getting your team together and making sure the team understands this before work begins it will 100% give you a smoother application development cycle. To make this process even easier there are git extensions to help you out at

Next we need to explain and break down the components in relation to GitHub tools and how we use them to relate to agile terms:


Within GitHub we would create milestones that represent the sprints and the current sprint we were working through.

User Stories

Within GitHub we would then create a branch that relates to each user story. For example a story/statistics branch for a user story related to statistics development within the application.

Reviews / Collaboration

At Red Badger we also strive to bounce off each other for ideas and improvement on code we produce. For that very reason once a user story is ready for the team to review and collaborate we submit a pull request to the develop branch. Once everyone is happy it is merged and the pull request is closed.

One area which was not explored which in a future project I think would also be great is to use the ability for designers to contribute to an empty pull request (which you can’t do in GitHub as it stands). This way developers can create user stories (pull requests) and collaborate all in one place (it is worth noting emails are supported within GitHub discussions, keeping designers in familiar territory when collaborating around a user story).


Bugs are always going to happen so we used the standard issue features within GitHub provides us with the most effective way of keeping a developer’s workflow focussed on the sprint whilst also allowing bugs to be assigned accordingly.  We gave access to our project manager who can also assign them to a realistic milestone for them to be resolved.

You really don’t need over engineered complicated bug tracking software.  GitHub have the right ethos in my view when it comes to the effective yet simple features they deliver to manage issues / bugs.

The upshot of using these tools in this manner on the project allows us to manage releases effectively within the team with every little disruption. Especially having this layer on top of your standard build tools such as Travis CI  that gives you instant feedback and continuous delivery directly integrated with GitHub.

The only one downside that isn’t cracked is that that traditional burn down charts for project managers are not integrated within the whole process. If we can solve the backlog planning and estimation with integration to GitHub we are on to the perfect solution for a self managed team without duplicated laborious project management “chores” each day.

It is all about keeping developers in the zone, doing what we love to do best.


The influence of Systems Thinking on Agile practices

by Arnaud Lamotte

If one should do a word cloud out of the Agile literature one word that would be big and bold is ‘pragmatic’. It is the essence of Agility, which is a response to prescriptive methodologies elaborated far from the reality of the field. However pragmatism, extracting intelligent practices from experience, has a limit: these practices are contextual. For this reason some Agile practitioners and thought leaders would like to see one or more theories underlying Agile practices. Not that there is a need to justify Agile, countless success stories are sufficient, but because with theories comes understanding and the ability to apply them differently in different environments. 

Two related bodies of knowledge, System thinking and Complexity sciences are the main candidates for providing theories behind the success of Agility. In this blog I will give an overview of Systems thinking as taught by Russel Ackoff, A.K.A. the Dean of Systems Thinking, and its applications at the level of organisations. There are other schools of Systems Thinking but I have chosen to present the work of Russel Ackoff because firstly he was the first to apply Systems Thinking to Management,  and secondly the more recent schools of Systems Thinking tend to have a ‘new age’ aspect certainly very valuable at the individual level but not necessarily relevant when it comes to Management.


Since Descartes the most common approach to understand systems is to break them down in smaller parts easier to apprehend. This is the analytic approach. While this approach has proven itself valuable, it has an inherent limitation: it ignores the properties of the whole that the parts do not have. It is also argued that the analytic approach produces knowledge (how?) not understanding (why?). Systems thinking is the opposite but nonetheless complementary approach, a holistic approach. A system is a view of the world, composed of at least two interacting parts, which has properties the parts do not have. Different classifications of systems exist, Russell Ackoff proposes the following one based on choice:

  • if parts and system as a whole do not display choices it is a mechanical system, an example is a car.
  • If some parts do display choices but not the whole then it is an ecological system, an example is Nature.

  • If parts do not display choices while the whole does, it is an animate (relating to animal life) system, an example is Humans. These systems are also often called organic systems but it is a slight misuse of the word as plants are organisms that do not display choice.

  • if both parts and the whole do display choices it is a social system, an example is an organisation.

For long organisations have been studied and run like mechanical systems (taylorism) for profit generation and then like organic systems aiming for growth, profit becoming a mean. This model still prevails. In both cases parts or subsystems are mechanical, they do not display choice. This is not deliberate but a consequence of the analytic mindset and its underlying assumption that parts of a whole are independent. It is not even a bad idea, humanism put aside, in an environment where members of an organisation are expendable and where there are more opportunities for growth and profit than the organisation can handle.

However it is not the environment of organisations nowadays, these models are obsolete and system thinkers see this mismatch between model and reality has the source of many organisation’s issues. Typically mechanical parts perfectly fit together. Just like Sales and IT ? Not really.

Indeed when both the parts of a system and the system itself can display choices, the complexity of the system raises drastically. This is when systems thinking really comes into play. If analytic thinking is the reason for many system failures, then analytic thinking should not be used to address these failures. As Einstein stated: “We can’t solve problems by using the same kind of thinking we used when we created them.” The answer is systems thinking, which is a synthetic rather than analytic process and explained as follow by Russel Ackoff:

“1) Identify the whole of which the system to be explained is a part 

2) Explain the behavior or properties of the containing system 

3) Dis-aggregate the containing system so as to identify the role or function within it of the system to be explained.”

Stage 3 implies the study of the interactions of the system under study with the other sub-systems. This is a key concept of systems thinking. The interactions between the parts of a system matter much more than the individual action of its parts because its emergent properties derive from these interactions. Emergent properties are properties of the system but not of its parts. For instance, consciousness is an emergent property of the brain but a neuron on its own is not conscious. In other words, a system is not the sum of its parts but the product of their interactions. Systems thinkers do not solve problems with solutions likely to create other problems but dissolve problems by redesigning interactions and systems. “Design is to systems thinking what Research is to analytic thinking” says Russel Ackoff.

Based on this approach, Russel Ackoff developed a new kind of planning called Interactive planning, which is  based on the idea that the future of organisations depends as much on the actions of organisations in their environment than on the effects of environment upon organisations. Interactive planning has two phases: idealization and realization. Idealization consists of identifying two elements, the ‘mess’ and an ‘idealized design’. Systems need to adapt to their environment to survive, therefore systems contain the seed of their own destruction. Should they freeze in a changing environment, they would die. Formulating the “mess” is about finding this seed. This seed is likely to be not only one problem but a set of problems. Problems rarely appear in isolation. Once the mess is formulated, systems thinkers know what not to do, what they want to avoid. However, effective management is directed at what one wants, not avoiding what one does not want, thus the need for an “idealized design”. It consists of imagining that the systems you want to improve has been destroyed and that you can redesign it with only three constraints:

1) it has to be technologically feasible,

2) operationally viable,

3) able to continuously learn and adapt.

The realization phase is about filling the gap, getting closer and closer to the idealized design. Interactive planning is continuous and iterative. Working backward from where you want to be to where you are, reduces the number of variables to be considered, it is the the best way to ‘beat the system’. (e.g. if Wimbledon starts with 65 players, how many games will be played?…think about it…If you took the problem from the front you are still searching, if you took the problem backward:1 winner, thus 64 losers, thus 64 games).

To endeavor that kind of transformation in organisations requires a new kind of leaders. Leaders aware that organisations are social systems. Leaders who take into consideration not only the objectives of their organisation but also those of its employees and environment. Leaders who are creative because structural issues are not dissolved with a quick fix. Leaders who have sufficient courage and influence to redesign organisations. Leaders who manage the interactions between subordinate teams or employees and not their actions. Leaders who encourage and facilitate an increase in competences at the level of both employees and organisation in a win-win situation.


This is obviously not a demonstration that Systems thinking underlies all Agile practices. Nonetheless we can recognize in Systems thinking many Agile key concepts such as iteration, continuous planning, importance of people, non-controlling leader and importance of interactions, to name a few. Hence, it is not pushing inductive reasoning too far to assume that what Russel Ackoff showed at the level of an organisation is also true at the level of a team. Also I am not sure if approaching problems backward is directly related to systems thinking although encouraged by Russel Ackoff but it seems somehow related to TDD

Now if you wish to appreciate the power of theories and see systems thinking applied to other fields than management, for instance the work of Marvin Minsky on cognition is fascinating.



Automating your Infrastructure with Vagrant & Chef – From Development to the Cloud

by Joe Stanton

Crafting the perfect development environment is difficult. Reproducing this environment for every member of your team, across development machines, running on different platforms and filled up with dependencies from previous projects is even harder. When you add staging and production environments into the mix, the level of subtle inconsistency is normally quite high, even if you’re being careful.

Divergence in configuration is subtle, yet evil, and will breed bugs which slow down your development process, and reduce the confidence you can have in the finished product.

Enter Vagrant, a lightweight command-line wrapper around VirtualBox which can spin up the perfect isolated development/test environment for your projects in a single command. This environment is always consistent, can be destroyed and rebuilt at any time, and used by any member of your team, on any of the major platforms.


Thanks to our adoption of Vagrant, picking up any existing project at Red Badger is as simple as a ‘git clone’ and a ‘vagrant up’. Deployment of the same project is equally simple, executing an ./ec2-package bash script and copying the deployment package to a cloud instance of our choosing.The small initial investment of time at the start of each project is repaid over and over during the course of development.

The Vagrantfile

The key to Vagrant is the Vagrantfile, this is a Ruby file which sits in your project root and allows you to specify your perfect environment declaratively.

Example Setup:

  • A web server running Nginx on port 80 which reverse proxies requests to Node.js, on port 3000
  • A database server which runs MongoDB and Redis

Each ‘config.vm.define’ block specifies a virtual machine, with an arbitrary name, based on an Ubuntu Precise 64 box we downloaded automatically from This base box contains the VirtualBox Additions so we don’t have to do this ourselves.

Each ‘add_recipe’ declaration is referring to a Chef recipe, explained in the next section.

Chef Cookbooks

Chef is the embodiment of a principle known as ‘Infrastructure as Code’, it is a configuration management tool which can be used to script your specific infrastructure requirements flexibly and maintainably. It again uses a Ruby based DSL to specify these requirements (notice a trend here?).

Chef itself comes in two forms: Chef Solo, and Chef Server. I will only discuss Chef Solo in this post, but Chef Server is definitely worth a look if you have more complex requirements (we typically don’t).

The core principle of Chef is the cookbook; a cookbook specifies the configuration of a piece of software – How to obtain the latest version of it, how to configure it, and how to start it up. Cookbooks can be broken down into recipes, where software has distinct setup paths. Eg. a MySQL master vs a slave.

Chef recipes are easy to understand and generally platform independent and maintainable, but can be time consuming to write. Luckily you can build upon the hard work already done by the Opscode community and download pre-written cookbooks for popular open source packages, and modify these to suit your own needs.

Vagrant + Chef Integration

Vagrant provides the ideal testbed for Chef cookbooks. Vagrant VM’s are lightweight and can be destroyed and recreated at any time. We often destroy and recreate VM’s iteratively until they are absolutely perfect. At this point, the rest of the team can get on board or we can use these scripts to provision instances in Amazon’s EC2, for example.

In our Vagrantfile we have specified chef_solo as the provisioning tool. By default, chef_solo cookbooks are stored in the /cookbooks directory relative to the Vagrantfile.

In our cookbooks directory we have the following cookbooks:


Most of these cookbooks were downloaded from Opscode and tweaked to our individual requirements. After a few iterations of ‘vagrant up’ and ‘vagrant destroy’, we have a configuration we are satisfied with. We can now gain shell access to our brand new VM with the command ‘vagrant ssh’. Execution of the code is all performed inside this SSH session throughout the course of development.

From Chef to EC2 and beyond

One major benefit of Infrastructure as Code is the ability to transition your infrastructure to the cloud rapidly and consistently. We do this at the beginning of most projects to set up a staging environment, and nearer the end of the project for when it’s ready to go live.

We use a very simple technique to provision servers on EC2. It works because we don’t typically have very large deployments involving a large number of instances. For these more complex situations, I would recommend the use of Chef server.

We simply added a ‘package_for_ec2’ method to our Vagrantfile to export our cookbooks and run_list as JSON (remember it’s just Ruby!).

We call ‘package_for_ec2’ from every instance declaration, this will produce a .json file for each instance. We SCP this file along with the cookbooks and an install shell script up to /tmp on a new EC2 server, and then execute the command:

Our ec2-provision shell script looks like this:

When this finishes executing, we have an EC2 instance with an identical configuration to our local setup. Easy.


Within the last few days, Vagrant 1.1 has been announced which packages a built in AWS provisioning plugin. I’m sure we will switch to this form of EC2 provisioning when Vagrant 1.1 is released as it looks fantastic. See the screencast here:

Also related, Amazon have just announced AWS OpsWorks, which brings official support for provisioning EC2 instances with Chef cookbooks, this is a sign that Chef is starting to gain real traction amongst the DevOps community.