A Place in London

It’s been a while coming and we are finally here, we’re properly in London, in Kings Cross to be exact. 344 Grays Inn Road to be exacter. Our very own capital oasis of calm productivity.

Until now, away from our Bristol office, we’ve been working on site in our London clients’ offices, taking up their space and drinking their tea. We still do that when necessary of course but now we also have our very own development, training and work area. And our own tea.

It’s a place that’s no more that 30 minutes from our Sitecore clients including ASOS, The Conservative Party and WaterAid.
A place place people want to go to work and maintain and improve our Sitecore productivity.
A place we can call Work. In London.


PS We’ve just hired yet another London Developer so that’s seven of us here permanently. Bristol, we’re catching you up 😉 We’re looking for more Developers (ideally with Sitecore experience). If you want to work with us and our clients, and you’re not a recruitment agency, please give me a call on 020 3428 6841.

Racing the Sun

Charity fundraisers and events are an excellent way to get colleagues working together and gelling as a team, and after the success of last year’s 40 mile ‘Plod’ across the Cotswolds, this year myself and seven other  f̶o̶o̶l̶i̶s̶h̶ brave volunteers took on the Race the Sun Brecon Beacons challenge, a bizarre triathlon-like event comprised of 47 miles of cycling, an 8 mile hike to the summit of Pen y Fan, and a canoe around the Pontsticill reservoir. The cause was a good one – Action Medical Research, a charity funding research into rare and lethal diseases affecting infants.  The fundraising had been tricky – we’d organized a few events here and there – and each managed to contribute a good amount under our own steam. Operating as two teams of four, we’d all done our bit to gather contributions where we could, knowing that it wouldn’t be over until the last team member had crossed the line, we’d each put effort into training in our own way too. Still, as we left work on Friday 27th June and headed for Brecon I think many of us were wondering if we’d perhaps underestimated the challenge ahead.

Continue reading

How Not To Demo

Recently, I was asked to demo a system that we are building for a client to some stakeholders from across the business. The demo would be delivered by me remotely, although the stakeholders would all be in the same room.

Simples. I’ve been managing the project ever since development had started (actually earlier than this, as I was involved in the ‘scoping’ phase as well), so I knew the system inside out and back to front.

I also deliver demos to the key stakeholders on a weekly basis, so I had no qualms on delivering a demo to a slightly wider audience.

‘Yep, no problem” I responded, “Just tell me when and I’ll set it up.”

And that was that. I put it to the back of my mind.

A couple of days later, it was time for the demo. I dialled in and introduced myself to the room at large. I then asked the facilitator at the client site to open up a browser and go to a particular URL, which would then display my screen to the room (I was using an online screen sharing program, and they were having this projected onto a screen in the room).

After the facilitator confirmed that everyone was there and they were ready, I began. I started by showing some of the latest features my team had been developing and explaining how they worked.

I talked.

And talked.

At one point, I had to talk to cover up the fact that I was waiting for an email to be sent to me via the system.

At other times, I was talking simply because I couldn’t hear anything happening at the other end of the line.

I was flying through the demo and after about 15 minutes, I realised that I had gone through parts of the system that I had expected to take twice as long to present. Was I going to fast? I posed the question to the audience.

“A little” the reply came back from someone in the room, “This is the first time I’ve seen the system so I’m struggling to keep up”.

It was as though someone had poured cold water down my back. What?! I thought the participants all knew about the system? Why didn’t they tell me that I was demoing to people who had never seen it before?

Hang on, did I ask?

I tried to keep calm. I backtracked, and went over some of the previous functions in a little more detail. I explained some of the background to the decisions we had made and what we were trying to achieve.

The demo came to an end. Silence.

“Well, that’s the end of the demo” I pronounced, “Does anyone have any questions, or are you all fast asleep?”

That at least got a couple of laughs, and negated my fear that everyone had left the room in boredom.

The facilitator then spoke up;

“Thanks Chris, that was great. I’ll handle any questions as we’ve got some other stuff we need to discuss here anyway, so thanks for the demo.”

“Oh, no problem” I responded, “thanks for your time”. I hung up.

It then struck me. I had absolutely no idea of what those ‘participants’ thought of the demo. I use the term loosely as they hardly participated at all, it was just me talking for most of it.

All sorts of thoughts were running through my head, how could I have not checked who I was presenting to before-hand? Did they follow anything I said at all, or did it go straight over their heads? I had made all sorts of assumptions going into the demo, and I was coming to the realisation that at least some of those assumptions were wrong. I had dropped the ball in spectacular fashion.

“What I need”, I thought to myself, “Is some feedback on how that went”. I couldn’t speak to the participants face to face, this wasn’t possible due to the distances involved. Phone calls to everyone that was in the demo wouldn’t be terribly efficient. Perhaps some sort of survey would get me the answers I need?

So that’s what I did. I used an on-line tool (Survey Monkey, which proved to be quick and simple to use), to create a basic survey . I sent off the link to those persons who were in the demo. Within a couple of hours I had a number of responses and plenty of data to start to analyse.

It wasn’t as bad as I thought.

As it turns out, only one person hadn’t seen the system before and they appreciated the fact that I went back to explain some of the features in more detail.

Another participant explained how the order in which I presented the functionality confused them, something that could easily have been solved by showing another part of the site first.

The other participants all thought the demo was well delivered and the pace of it was fine. The biggest issue appeared to be the projector used in their meeting room, which was a little blurry, plus the glare from the sun coming through on of their windows.

All in all, it could have been much worse. But I learnt a number of things from this little escapade;

  • In future, I need to check the equipment that’s going to be used as well as have a practice run through, this will ensure that things run smoothly on the day
  • Always find out who I’m demoing to. What is their knowledge of the system like?
  • Try to get my audience engaged. If I want feedback at the end of the demo, then I need to keep the attention of the participants.
  • I’m going to try and get feedback from as many demos as possible in future. This is invaluable in improving my deliver mechanisms for future demos.

If you ever find yourself having to deliver a demo. Don’t make the same mistakes I did. Why not read my handy guide for avoiding the major pitfalls.

How Effective Are Your Demos?

For those who have read my recent experience with undertaking a demo, you’ll know that sometimes you feel like they could’ve gone better. This is my simple yet effective guide that may help you avoid some of the usual pitfalls;

Feedback is important. Especially so when it comes to software development. How does the new functionality meet the expectations of the stakeholders? Does it ‘feel’ right? Does it positively impact on the customer experience? We need to know the answers to these questions to determine the value of any newly developed function.

There are many ways to gather feedback, but chief amongst our arsenal is the ‘demo’. A simple yet effective tool when done right, you get a bunch of stakeholders together (either on site or remotely), and present the new functionality to them. They can then freely discuss what you have shown them, allowing you to gather their thoughts and feelings on whether any further changes are required.

Demos can be extremely powerful, they allow us as the facilitators to guide the stakeholder’s thoughts onto particular areas of a system or site, to consider certain scenarios or UI enhancements. But, do we use them effectively?

We’ve all attended poor demos in the past. You can picture it; the stuffy room, filled with people from all areas of the business, some of whom have only passing knowledge of the subject matter. The monotone voice, droning on. The demo bounces around, showing different pages and functions so quickly that you have no idea what is going on. Or perhaps the facilitator is focusing on something that you know in detail already, and you’re being taught how to suck eggs. You lose interest, allowing your mind to wander. Your eyes glaze over…

A boring presentation

Sounds awful doesn’t it? It’s a waste of your time, the facilitator’s time and the business ultimately sees no value.

Now consider this, how many demos have you given that play out as described above? You sure? How do you know?

If you want to be sure, then follow this guide for delivering great demos and getting that all important, quality feedback;

Step One – Know who you’re delivering to

Who is coming to the demo? What is their background? Do they understand the system in-depth, or have they hardly seen the system before?

The content of your demo needs to take into account the knowledge held by the audience. There is no point going into technical detail for an audience that has never seen the product before, Similarly, don’t waste time demoing basic functions to people who know the product inside out. It’s not always possible, but try to keep the audience limited to those with a similar level of knowledge. You can then tailor the content to fit. These leads us on to point two.

Step Two – Limit the audience

When inviting you audience, consider what you are trying to achieve. Do you really need to invite someone from marketing to a demo of backend systems? Does QA need to be involved in a demo focused on user experience? Try to keep the audience limited to those who will have something to offer in terms of feedback, those whose opinions matter. Don’t invite loads of people; the more people there are, the less likely it is that your audience will feel confident to ask questions or provide opinions.

Step Three – Keep to a predetermined scope

It’s obvious really, but know what you want to demo and what you want to get out of it from the stakeholders. Don’t let your audience get side-lined onto a completely unrelated conversation. If needs be, you can always arrange for a separate meeting or demo to discuss any unrelated issues. Keep your audience focused on the task at hand.

Step Four – Have a run through before-hand

Again, a simple yet effective step. Practice what you intend to demo. If possible, use the same equipment and/or software that you intend to use on the day. Deliver the demo to a colleague; can they understand the information? Was your delivery clear and concise, or were you mumbling? Preparation is key.

If you are doing the demo on site, make sure the room you are delivering in is big enough, has the right number of chairs and has the equipment you need. There is nothing worse than wasting the first ten minutes of a meeting trying to get the projector working.

Make sure you consider different delivery mechanisms. Does it have to be done using a PowerPoint presentation or could you use something more creative or unusual? If it helps engage your audience, then give it a go!

Get creative with your demo deliveries!

Step Five – Gather feedback on the demo

Probably the step that most often gets overlooked. Just because you delivered the demo successfully and got some feedback, it doesn’t mean that it couldn’t have gone better. Try to get some feedback on the demo itself. You can do this in any number of ways, from chats around the coffee machine to asking the audience at the end of the demo. Personally, I have used online questionnaires to great success (Survey Monkey is a free, simple, yet effective tool). Keep in mind that some people don’t feel confident enough to make their opinions known in front of others (particularly if there are loud, brash or opinionated members in the audience), so sometimes you will get honest feedback only by approaching these people on their own or allowing them to answer anonymously.

All of these steps are simple enough, but they will help achieve that ultimate goal of getting useful, valuable feedback.


Going backwards is sometimes the only way to go forwards

I was recently drafted in as Project Manager on a redesign project for one of our clients. The project had been underway for several weeks, the team were all very busy, the ‘work in progress’ boards showed that lots was being worked on but the ‘accepted’ and ‘live’ parts of the board were worryingly empty. There was a project plan but it was clear the team weren’t delivering against it.

I observed what was happening in the team over the course of the next week or so whilst trying to get my head round the requirements. The team were doing daily stand-ups reporting in on what they were working on, everyone seemed to be working on unconnected component level user stories.

The team were complaining about the designs, they were inconsistent, kept changing, looked OK for print but wouldn’t work for the web, didn’t work if the content (which was content managed) got longer etc. etc. etc.

Many stories had been started but couldn’t be finished because they were blocked for one reason or another. If the team got blocked, they just started something else.

The team were demoralised, they weren’t getting any sense of progress, couldn’t see the big picture and nobody was doing anything about their frustrations.

One day I asked a question about how we were going to put the redesigned site live. The customer was going to need to do some content population in the live CMS so we would need to let them do that without the risk of the new pages going live before the client was ready. Some of the content on the existing site was going to be re-used but would need to be available in the new designs. Stakeholders would want to be able to see and approve the new site before it went live but this categorically couldn’t be on a URL that just anyone could access – even within the organisation concerned access to the new site would need to be restricted.

When I asked the question everyone in the room looked blank, the team hadn’t thought about this, nobody had asked the question before and there were no ideas.

So we stopped. Mad as it sounds, on a project which was running behind time, running over budget and with nothing actually delivered we decided to stop work. Anything we did was pointless, we weren’t getting anything accepted or live and we had no plan for getting things live.

We don’t like to deliver bad news, but if we have bad news we don’t try and hide it and we deliver it early. We called the customer, we told them we had a problem, we said we were behind plan and that we were going to stop and re-think the approach. Understandably they were concerned, they were adamant that the dates we had given them weren’t moveable, they said they didn’t want to have another call like that again and that they wanted us to update them when we had a new plan.

The senior developer and I then got together and talked about the problem. We took a fresh look at what we needed to deliver and simply printed out in colour all the pages we needed to build. Whilst our backlog of component level stories looked scarily unachievable, the number of pages we needed to build looked far less daunting.

We had a team of 3 developers on the project. All we needed to do was a page a day between the three developers and we’d still have 2 weeks before the go live date for amends, launch plan and as contingency. Was a page a day feasible or should we ask each developer to produce one page each every 3 days? We talked about the strengths of the team – one of the team was a whizz at HTML/CSS, another had a lot of Sitecore backend experience, another was a good all-rounder.

The Senior Developer bought the other developers into the room and put the ‘page a day’ challenge to them. They agreed they’d all prefer to work together, doing the things they were each best at and they were happy to commit to doing a page a day with a ‘we don’t go home unless we’ve met our goal’ attitude. They were fired up, they had something tangible to aim for, it would be really easy for them to know if they’d achieved what they wanted to.

My job as the Project Manager having got that commitment from the team was to make their jobs as easy as possible – clearing the path ahead of them.

I talked to the client about the inconsistencies in the designs and we consolidated a number of the components which were similar thereby reducing the work that was needed (and producing a better user experience). I asked the designer for an updated style guide confirming which fonts, colours, buttons should be used where and when.  We agreed the style guide was the definitive version of what we should follow even if the Photoshop files we had didn’t.  Before we started work on any page I suggested that we’d do a final sanity check that we were working to a confirmed/signed off design to minimise changes later.

We agreed that any ‘changes’ after delivery would be added to a backlog which we wouldn’t look at until after all the main work was done. We’d then prioritise the changes and decide which were ‘must have’ for launch and get as far down them as we could. If there were more ‘must have’ changes than there was time available the client accepted the fact the date would need to slip but that the slippage would be down to the organisational wants/needs and not our inability to deliver what we’d committed to.

We told the client that we wouldn’t start any story that we weren’t confident we could finish and get approval on. We set the client expectations about the time/effort this would require on their part and got their commitment to make the relevant people available on the right days to sign off the work.

We agreed that getting a page ‘done’ for the customer to sign off was getting it all the way through to a live environment and onto a URL to which we could restrict access. This required a change to the architectural approach and we had to spend several days unpicking and re-doing some work we’d already done. But it was absolutely necessary.

Our new plan and approach massively de-risked the launch of the new site. Code was going to be deployed up to live every day. Those that had access would be able to see the site coming together on the live servers, they could update content on the old site and see it in the new designs, they could add new content. In short on go live day, all we needed to do was a configuration change to point the site URL at the new site we’d created – no downtime for the end users or for the content editors.

With renewed vigour the team jumped on the new plan. We stuck those printed out designs on the wall in ‘to do’, ‘doing’ ‘done’ columns and every day those designs would move across the columns and we’d see the progress. The increased production with the team working together rather than independently was amazing to see. If one person finished their piece of the jigsaw early they’d help someone else out. Every day they were doing a new page, some days they did 1.5 or 2 pages.

Daily stand-ups became unnecessary, the team were working so closely together with the same daily goal that they were communicating non-stop all day across the desks. I didn’t need to ask whether they were on track or how they were doing – I could see and hear it.  The client didn’t need updated project plans or status reports – the teams progress was visible every day by the release of something new.

The team delivered the site on time and under budget. The client was able to use the spare budget to include some changes and new features they wanted. The launch day was as smooth a transition as anticipated, literally a push button exercise to switch the new site over. The client was over the moon. The team were buzzing and had a real sense of ownership and pride in the end result.

It was a real team effort and a project I thoroughly enjoyed working on (even at the most stressful times) with a great team of committed professionals (you know who you are).

Here’s what we/I learnt:
• Spend enough time planning up front – don’t be tempted to dive straight in to the work
• Don’t assume every project or piece of work is the same and that processes which have worked before will work again – look at each challenge with a fresh pair of eyes
• The power of a team is far greater than the sum of the individuals – play to your strengths
• Think about getting things live early and how you’ll launch – de-risk big bang launches
• Don’t start what you can’t finish
• Tackle impediments and issues, head-on (frustrations and moans often hide an impediment)
• If it’s not working don’t be afraid to stop and rip up the rulebook
• Find a way to see your progress – nothing gives a greater sense of achievement
• A problem shared is a problem halved – getting the team ideas and commitment is better than telling them what to do and making the commitment for them