The transformation of a Customer Contact Centre using Agile and Lean

How REA challenged Call Centre preconceptions

There is a lot of bad press about Customer Contact Centres; callers usually dislike having to deal with one, and people working in them are rarely proud or engaged with their jobs.

But is it possible to create a Contact Centre where callers are left happy and valued, and the people working within them feel empowered and enjoy going to work?

And is it possible to achieve all that while moving the key metrics that matter to the business?

Yes, yes and definitely Yes! But you will have to be bold. You’re going to have to try a few unorthodox moves when it comes to Call Centre Operations. Continue reading

To Kill a Mockingtest

Please don’t use mocks or stubs in tests.  While they are seemingly ubiquitous in enterprise development, they have serious drawbacks, and typically mask easily fixable deficiencies in the underlying code.

Even their most ardent defenders concede that mocks and stubs have flaws. These include:

Dependence on fragile implementation details

Mocks and stubs require intimate knowledge of how code interacts with other modules.  Even if the implementation is correctly refactored without altering public contracts, these tests will tend to break, and draw your attention away from more productive tasks.

Testing incidental properties with no bearing on correctness

What is the point of this code?  This is an essential question to ask, in order to understand it.  Tests have a story to tell here, and mocks invariably tell the wrong one.  Is the point of makeCoffee() that we made a coffee, or that we opened the fridge to get the milk?  When we payShopkeeper(), do we care that we completed a transaction, or that we rummaged though our wallet for change?  When mocking tests fail, the poor maintainer is left to reconstruct the real intent from a trail of indirect clues and anecdotes.

Web of lies

It is good practice to write data structures that are correct-by-construction; any constructor or sequence of method calls is guaranteed to leave the data in a meaningful state.  Stubs introduce test-only fictions that are stripped of any of the safety latches and guarantees that may have been built in; they introduce fresh sources of error that are not present in the codebase.  There is no value in detecting any failure that arises in such a way.

As time goes on, lies beget more lies.  It is not unusual for a stubbed input in one place to result in another here, and another there; the fiction leaks and spreads into some kind of evil facsimile of the original code, but with more bulk, complexity and defects.

Continue reading

The Hack Day story

Hack Day at REA is something that started very small in IT 4 years ago and has grown to become the showpiece of culture, collaboration and innovation for the whole company. It took us a while to get there but we’ve cracked the formula for awesome Hack Days and now have an ever growing roster of visitors coming to see how we do it. We put together a little video that showcases our Hack Day story. We hope you enjoy it and it sparks some ideas on how to do it in your own company. Share your own Hack Day story in the comments below!

Distributed Agile – Extreme Communication

In my first post on distributed agile I described how our teams are structured.  That’s a foundation piece, but a more interesting aspect of our distributed agile model is how we communicate.

Communication is at the heart of a healthy IT delivery team.  And at REA we believe in the value of face-to-face communication, so much so it’s enshrined in our operating principles.  But isn’t that the very thing that becomes difficult with distributed teams?

Well, If you’ve worked in traditional distributed teams you may have seen the signs of a break down in communication – long overnight emails, long lists of issues and actions, frustration, missed goals, misaligned expectations, poor quality, the occasional stilted video conference call for project updates or to fight fires, etc.

So at REA we practice extreme communication.  In this post I’ll describe some of our practices, but it’s important to understand that good communication is based on strong relationships and trust, and achieving that in a distributed team is difficult, I’ll describe how we do that in another post.

Continue reading

Feeling Validated – A different way to validate your input


The following post is a Scala example of validating input into your software.  We use Scala, but you can do this in many other languages like Ruby, JavaScript and even Java!  After trying a more traditional approach we then use a type called Validation to encode our business rules.  It’s a different way of thinking.  It uses the Scalaz library.

Continue reading

The abject failure of weak typing

More discussion on Hacker News, and the Clojure, Haskell, Rust and Programming subs on Reddit.

Over the last few years of maintaining code old and new at REA, it has become abundantly clear that the neglect and misuse of type-systems has had a sharply negative impact on our codebases. Here we address the concrete causes and consequences, and propose concrete and achievable solutions.

Types at REA

REA’s codebases vary between statically typed languages such as Java and Scala on one hand, and “dynamic” languages such as Ruby, Javascript, and Perl on the other. I’ll mostly leave the dynamic ones alone — while the same arguments obviously apply, they are what they are. However, if we are paying for the conceptual overhead of a static type system, we need to be sure we are using it effectively; otherwise we are simply writing the same old Ruby play-dough but with long build-times and cumbersome syntax. Used properly, the tradeoff of static types is overwhelmingly beneficial. Continue reading