Do you use a digital agency, it might be time to re-think your options?

Coming from a background in digital agencies I’ve often asked why a client wanted to hire an agency. However clients rarely understand why they need to hire an agency and in a lot of cases it’s not actually what they need at all, well not a traditional agency relationship anyway.

Traditional agencies work on the basis of project work. They are hired to do a project for the client (build a new website, re-design an existing website to make it better etc). There are only two reasons a client hires an agency in this context.

  1. They have the skills but not the time/resource to do the work themselves
  2. They lack the skills to do the work themselves

These two reasons, when coupled with project thinking (thinking where you give a brief, the work is done and then handed over to the customer at the end) lead most companies to look at an agency model to get the work done. You agree a fee with the agency, they do the work and the risk is all theirs. Sounds lovely in theory, but unfortunately the business of the web doesn’t fit neatly into the project model. It’s a good model for when you’re building a house or something tangible but falls apart with software.

The reason it falls apart is that a website or piece of software is not a finite project. There is no end state, just a constant state of improvement and development. You launch your site and customers want new features, or the market changes. You then need to go back and make changes to the “finished project”.

So now you have a choice, if you haven’t planned for this already, you either go back to the agency and do another project to add improvements or you do the improvements yourself (depends if your underlying reason was 1 or 2 above). So really you didn’t solve your underlying problem, lack of skills or resource, you just delayed when it became an issue. Add to this that the pace of change is getting quicker in the marketplace and you can see that old project based thinking is not the solution.

So what are the options you do have?

  1. If you have a lack of skills then get those skills on board.
  2. If you have a lack of resource then get those resources on board.
  3. Use a digital agency that thinks beyond projects.

Option 1 and 2 are really the only viable and sensible solution if your digital product is at the heart of your business. In fact think about the message you send out to your existing team(s) if you get in a digital agency. You could be sending out a message that you don’t want to invest in their skills and would rather pay someone else than help them get better.

Option 3 means looking more closely at your agency of choice and understanding that you will need to be with them for the long haul. This means thinking beyond projects. You’ll need an agency that values transparency with you and wants to work collaboratively with you and your team. The agency will need to gel with your organisation seamlessly and become like another ready built department. The agency will need to be brave enough to share knowledge and skills with your teams and sometimes work co-located with your company. You’ll need to look at a billing model that is collaborative and cost effective over time.

Does that sound like your existing agency or any agency you’ve worked with before? Chances are it doesn’t and that’s because most agencies are stuck in old ways of project centric thinking because clients expect/demand it. However it is incumbent on both the agency and the customer to reject this old mode of thinking to ensure that agencies and the solutions they provide are fit for the future.

Traditional vs collaborative agency model
Traditional vs collaborative agency model


Avoiding monsters by opening the box of requirements

How many times have you had a requirement from a client and implemented it diligently, only to find it’s not actually what they wanted at all?

Perhaps the conversation went something like this:

Client: It’s an emergency I need to add images to the “about us” page.

You: Sure no problem I just need to enable that in the CMS. It’ll take 2mins.

Some time later

Client: (Irate) It’s not working! I add images and they all appear in the wrong places.

You: Hmm, ok I think I can see what’s happening. Let me add some extra styles which should clean that up for you.

A little bit later still

Client: (really irate now) You’ve made it worse I tried to add a table to make it look ok but now the whole page is wrong.

You: Ahhh, I see what you’re trying to do – add a list of staff with a biography. I think we’ll need to build you a tool to add members of staff to that page.

Client: (Exasperated) Well of course! That’s what I asked for!

Now in this scenario, it’s easy to blame the client and say they didn’t know what they wanted or how to communicate effectively. But, to be frank, this is plainly wrong. The issue here is not bothering to open the box of requirement, then being bitten by the contents once you did.

Every requirement, no matter how small, is really a box. It can contain absolutely anything and it’s beholden on us to work with the client to open the box, look inside and make sure it contains what the label says. To do this we ask questions about what the requirement is trying to achieve and what value will be provided by the requirement.

Here’s a diagram showing a journey through the unboxing of a requirement in order to build a shared understanding.

A journey to shared understanding with the client

This diagram shows that although we start with an expressed requirement, the requirement we have in our mind and the one held in the client’s mind may be different. Therefore until we share our understanding with the client and they share their understanding with us we cannot arrive at the actual solution. As the actual solution will always remain unknowable until we have uncovered our and the client’s pre-conceptions of the requirement/solution. In short unboxing the requirement!

Often we forget to unbox a requirement when we are trying to be nice, when the client is putting us under pressure or when a requirement comes late in the project. However these are the times we need to be most careful to actually check what’s in the box before ploughing ahead.

Formal documentation is also the enemy of unboxing a requirement, as the written word acts as a box in itself. A written requirement is often written when we have only had the requirement expressed (top left of the diagram above). We are then more likely to trust the written word and therefore fail to gain a deeper understanding of the requirement – missing the fact that although the requirement is written it has not yet gone through the unboxing process.

It is this journey to a shared understanding that helps us ensure that what we build is truly valuable and that we are protected from the nasties lurking in the bottom of the box, ready to bite us when we’re least expecting.

The value of values

I read with interest Alexander Kjerulf’s blog post on 10 things companies should stop doing now. Obviously any article in a top 10 format is going to talk in very general terms but I was surprised to see number four on the list… Corporate values.

I think that rather than simply casting aside values there is a greater need to define what we mean by values and where they fit into an organisation. To simply stop considering them is very much in danger of throwing the baby out with the bathwater.

Values do not exist in isolation. This is where I think Alexander’s problem is with values;  corporates coming up with vague nebulous values and simply imposing them on the company. Or values are simply stored on a piece of paper gathering dust, rather than acting as a unifying set of goals and principles.

Values exist in an onion shape, in that there are multiple layers of values. Corporate values are just one of these layers.

At their most basic, values can be thought of as existing at these three levels:

  • Personal
  • Team
  • Organisation

Dr Steve Peters in his book The Chimp Paradox talks about the stone of life, where we store our personal values. Organisational values are critical to the Toyota way (lean) as mentioned in the book This is Lean by Niklas Modig. Team values are important in Agile and there are well defined techniques for helping teams develop shared values (see Coaching Agile Teams by Lyssa Adkins).

These three value layers feed into each other. If we have team or organisational values which conflict with our personal values then we will likely experience cognitive dissonance, causing us stress.

This means that in most instances values at the team and organisational level should be negotiated and agreed. Only our personal values are non-negotiable. Although like anything our personal values can change with experience.

Values are living and breathing entities, like plants they need light and water to grow. We need to ensure that when the seeds of values are sown they take root and we attend to them regularly.  Also that unrealistic or unhelpful values are pruned back as we, our team or organisation grows.

Values far from being a static burden are a living embodiment of who we are and what we believe and as such they are at the heart of any organisation. Use dusty old values as a catalyst for change and don’t simply toss them away without at least first trying to fix them.

Persistence hunting and the art of agile

Thousands of years ago on the grassy plains of Africa before the bow and arrow, early hominids used to literally run their prey to death. Their prey was fast and cunning. But crucially it could only run short distances and if the hominids persisted they could eventually catch their prey by wearing it down.

When we are managing projects we need to take a similar approach. If we plan the hunt in great detail the prey will slip away almost immediately, easily able to sprint off whilst we remain static trying to second guess what will happen.

However if we get started quickly and persist, allow ourselves to focus on the objective of running the prey down, change direction as we need to, not panic if the prey gets ahead of us (as long as we can still see it). Then in time the project will slowly tire and we will get close enough to finish it. This model reflects how projects will start off volatile (full of energy and change) but as we progress and deliver, slowly become more manageable.

It is part of our evolutionary history and makeup to think like this. It seems absurd that we find this an alien way of thinking and must invent process to try to engage in a hunt. Instead all we need is to lean back on what made us successful in evolutionary terms.Then we will find that we have all the mental tools needed to work in this way.

Tools such as working as a team in relentless pursuit of our prey. Not knowing how long a hunt will last but remaining clearly focused on the objective. Changing and adapting to the conditions as we find them. Communicating across the team to effectively bring our collective resources to bear on the object of the hunt. Also and most importantly progressing at a sustainable pace, as that is the very nature of persistence hunting.

There can even be roles for specialists on the hunting team. Trackers who are adept in reading the prey’s mood and whims so we always stay with them. Sprinters who quickly catch up with the prey and fall back at other times. The management and leadership of the team is rotated and seamlessly switches from person to person as the hunt progresses.

So get Palaeolithic on your next project and remember that through agile techniques we are simply attempting to reconnect with our innate ability to work in this way.

More about persistence hunting:

Are you doing or being Agile?

It’s amazing how many times I’ve seen companies saying they are doing Agile, when in fact what they have is a ritualised version of Scrum without the good bits.

The very term “doing” Agile should always ring alarm bells. You can’t do Agile at all. By adopting this mind-set you invariably fixate on the tools and rituals of (usually) Scrum, without ever-moving to the understanding stage.

In fact I’d say that it doesn’t really matter what framework you tell yourself you are adopting the main part of becoming more Agile is a shift of mindset. This shift of mindset can be hard to achieve, in fact you could say being Agile is like being happy.

It’s something we all want but often don’t know how to go about. This again is often because we focus on the method or the tool of being happy. If I lose a few ponds I will be happy. If I could just run a marathon I’d be happy. Again this is focusing on the mechanism not on the mindset.

This is why I am beginning to see all sorts of ranty blog posts about how Agile sucks and it isn’t all it’s sold to be. This is normally because what people have experienced is what I call mechanised Agile. A process imposed from on high to a problem that is cultural.

So take time to think about your current Agile practice, are you being or doing? If you are simply doing then take a moment to reflect on one thing you could change that would help you or your team be Agile.

Perhaps you could start with the standup and do away with the interminable three questions ritual which often becomes an anti-pattern. Or perhaps just introduce the elephant in the room; that rather than being Agile you are merely doing.

When did you last help your boss?

Put your hand up if you have ever moaned about your boss (ok, don’t actually put your hand up the boss might be watching). I suspect it made you feel better but didn’t solve the problem.

Next time instead of venting to someone else, try and recognise the human in the bosses suit. They have needs, desires, fears and insecurities like the rest of us. Perhaps try and see things from their point of view.

Why not even try and help them? Try and work with them to help them understand what you need from them and what they need from you.

Obviously there are some alpha wolf types who can’t be helped but often your boss is just someone trying to get their work done the same as you.

We all have values and needs and we need to recognise this  in everyone that we work with. But someone has to make the first move. Will it be you who starts making the work environment a better place or are you waiting for someone to do it for you?

Become the beachcomber

I was walking along the seashore in Norfolk recently, watching a group of people trudging up the beach picking up the valuable pieces of driftwood and objects that had been washed up during the night. They were busy in their work and were extremely discerning. Rejecting out of hand clumps of greasy seaweed but carefully inspecting anything that looked interesting. But even then only a very few items would actually make it into the string bags hooked to their belts.

Since then I have resolved to become the beachcomber, picking up the items of value washed up by the tides of agile methodologies. Waiting for the tide of popularity to recede a little before inspecting what it has left behind in the way of useful detritus.

It is easy to be beguiled into thinking that the latest agile tide will be the last, but it won’t be long before that tide recedes and another follows. By keeping to the tide line, we can observe the cycles of popularity and pick only that which is of value. Leaving the rank piles of seaweed to slowly rot away.



Bored at work? Build a robot

Often at work there are repetitive tasks that need to be completed and if we’re not careful it’s easy to get stuck in the following thought pattern; “I hate this task, I have to keep doing this boring action every time. My job is boring.”

But this type of thinking is disempowering. We need to shift our thinking to how we can remove this repetitive task.

Do not engage with the internal voice that is complaining but to listen to the complaint and do something about it.

Wouldn’t it be more interesting to build a robot instead?