Latest Entries »

Facebook V Twitter

Facebook and Twitter offer very different environments for Marketing. Facebook is an immersive and deep experience where the average user spends 7 hours per month. Twitter has been regularly described as a cocktail party, where users will dip in and out of their Data Stream.

There is a great new Infographic (see below and by Digital Surgeons which dissects the audience of Facebook and Twitter. As you might expect from a micro-blog platform, Twitter users are far more active in updating their status – 52% update daily versus 12%.

Facebook’s advantage is it’s extreme stickiness. Facebook users are twice as likely to log-in to the system as Twitter users.

The question of which is the best channel for Marketing rages on.


Further articles, discussions and data is available on my Storify story:

Any thoughts? What is your experience of Marketing on these channels?





Gamification is part of a new vocabulary which seeks to describe the fusion of different disciplines. As I’ve read more deeply about Gamification, I’ve come to realise that the concept is easily identifiable within the Scrum Framework. For an example the Daily Meeting has many facets which seek to open channels of communication through Gamification. The Daily Meeting is built around a few simple rules which you can easily set in to a game metaphor (in bold):

1. The same time every day – The fixture
2. All the team must attend – You must be part of the team to play
3. Team stands-up and huddles – Many games engender a sense of proximity to ensure involvement and to provide an immersive experience
4. Takes place in the same place – The pitch
5. Time-boxed to 15 minutes – The game is time-limited to promote intensity
6. Early meetings should adhere to three questions – Simple rules promote inclusion and participation

  • What did I do yesterday
  • What will I do today?
  • What’s in my way?

7. Use a speaking token – A ball or baton is thrown from player to player
8. Signal the end – The whistle is blown and the game is over

The Scrum Master acts as a referee facilitating the meeting but not interfering or running the meeting. The Daily Meeting is a perfect example of how Gamification can help us be more effective at delivering a ‘product’, managing our time and transforming the world of work.

The Scrum Framework introduces Game Mechanics to the workplace and by doing so delivers business advantage.

Have you used Gamification in your products or workplace? Is ‘Gamification’ part of a new vocabulary or empty hyperbole?

Further information on Gamification

A great place to start looking at real world examples of Gamification is this article by @adachen:

Sharleen Sy has written a good article on why Game Mechanics work:

Seattle’s Tech Flash has a great article on how Gamification has impacted business and science:

Microsofts Ribbon Hero is an example of Gamification of software applications:

I previously wrote about the benefits major marketing agencies were experiencing by implementing Agile techniques within their business. Taking that concept one stage further I’ve re-engineered Mike Cohn’s ubiquitous Scrum framework diagram to show how Teehan and Lax’s six steps to Adaptive Marketing can be applied to this process.
Mike Cohn’s Scrum Framework Copyright 2005 Mountain Goat Software
Adaptive Marketing Using The Scrum Framework  – Diagram
Creative Commons License
All work is licensed under a Creative Commons Attribution-NoDerivs 3.0 Unported License.

The Six Steps are as follows:

1.     Product Backlog

The agency and client define the objectives of the engagement and establish several key performance indicators. The first step is all bout establishing the vision with the client and producing a product backlog with the team.

2.     Sprint

The creative team is dedicated to the project for a set period of time allowing them to focus on the task. Creating the Sprint is a familiar concept to Agilists and it makes perfect sense in the context of a marketing campaign.

3-5.     Meetings

Steps 3 -5 are encompassed in the Empirical framework of Scrum. Ideas are rapidly developed, tested and deployed
Ideas evolve and adapt over time. Performance is closely monitored allowing the team to make adjustments.

The combination of Sprint Planning, Daily Meetings, Sprint Review and Sprint Retrospectives all support an inspect and adapt approach to marketing.

6. Sprint Review and Retrospective

Project success is determined by achieving the KPIs. The Sprint Review meeting covers the necessary KPI’s to ensure that all activities match a state of ‘done’ and whether the process and campaign were successful.

Using the Scrum Framework gives transparency to the Adaptive Marketing process, a corner-stone of the Agile approach.

Do you practice Adaptive Marketing or have you implemented Agile at Enterprise level? Have you used the Scrum Framework outside of Software Development? How did it go?

Due to the volatility of our developer resource we recently decided to opt-out of Scrum and adopt Kanban. Kanban is an Agile technique that is less prescriptive than Scrum. There are many similarities between the two systems including the use of white-boards and post-it notes to track progress. An important difference is that the white-board is owned by the process not the team. The board makes transparent, the flow of work through the team.

The white-board has similar columns: not done, in-progress, done. The columns have an agreed limit on how many jobs can be in each column. We agreed on up to two per developer.

Kanban does not have any notion of a Sprint. Kanban limits the number of items that can be in-progress by WIP (work in-progress). WIP limit is the key method to tweak and optimise the flow of work.
So the response time (how long it takes to respond to a change of priorities) of a Kanban team is however long it takes for capacity to become available. Capacity is measured by the general principle of “one item out = one item in” (driven by the WIP limits). You don’t have to wait for the next Sprint to progress work and testing, deployment and review are all a continual process. Due to the emphasis on experimentation and the Scrum mentality to ‘Inspect and Adapt’, we decided to include Daily Stand Ups’ in our version of Kanban.

The basic steps we took to complete the adoption were:

1. Agree Kanban adoption with Dev Team Manager

Senior management was concerned about compliance for audit purposes and the possible breakdown of process. We allayed any fears by emphasising the similarities with Scrum process.

2. Agree with Product Owner

The P.O had previous experience of Kanban in a production environment and was therefore happy to adopt the process and added value based on their own experience.

3.Training session and agree column names and WIP limit with team

There was some trepidation and a lot of discussion around WIP limits and whether the whole process offered anything better than ‘just a list’. I emphasized that though Adaptive rather than Prescriptive Kanban offered the opportunity to maintain process and measure flow.

We had a planning meeting and jumped in. The interesting thing is that quite quickly we identified that testing was a bottle-neck. We knew colloquially that this was the case but the Scrum board had never exposed the relationship between testing and deployment. We tended to remove all the jobs at the end of the Sprint and the tasks that had been awaiting test or had been tested and not deployed would be forgotten. We adjusted our working practices and white-board to clearly show whose responsibility it was to test code in Development and in our Main environment.

Our team has become less volatile recently and we have returned to the more familiar territory of Scrum. Utilising Kanban was beneficial and we have reverse engineered some of what we learned back in to our Scrum process.

Have you had any adventures in Kanban?

E-book – kanban v scrum.pdf

In 2010 it was clear the Internet had splintered with a plethora of devices, resolutions, platforms and delivery methods. At the Web Trends conference in October, Joe Stanhope from Forrester described the volatility of the environment as the Splinternet and used the simple table below to quickly show how things have changed.

Designers and developers have responded to this challenge by looking oustide of the industry at how architects have adapted living spaces to be responsive to changing needs. Ethan Marcotte wrote earlier in the year about taking this concept and using it for the web. Ethan titled his piece ‘Responsive Web Design‘.

Responsive web design is the solution to designers and developers who are now presented with a myriad of screen types and resolutions to design and develop for. As I read the article I felt the same feeling I had when I read Jeffrey Veen’s – “The Art and Science of Web Design”  Jeffrey opened my eyes back in Y2K to fluid and flexible layouts. Essentially Responsive web design takes this one stage further with the added ingredient of media queries that can adjust layouts to a variety of resolutions and re-size images accordingly.

Kayla Knight published an article on Smashing Mag. The article further explains the techniques that are being used to address the challenges presented by the Splinternet.

A common website cited by many designers is Simon Collison’s. To show how the website works I took a screen-shot of the desktop version of the site and a quick shot of the site on a small smartphone.

Site on smartphone

Site on the desktop

The site renders beautifully on these disparate devices and shows the real power of designing and developing using the Responsive approach.

How do you feel about Responsive web design? Is it the way forward or will the sticky plaster fall off?
Find below a handy round-up of links from the the articles mentioned:

David Cole listed the following as must-have resources in his recent blog:

Fluid grids and Fluid images

Responsive web design book

Rethinking the mobile web – superb presentation
A responsive mind and responsive enhancement

The following sites are examples of sites using the Responsive approach
8 Faces


Bryan James

Tee Gallery

Think Vitamin

The Baker Street Enquirer

Simon Collison

Garret Keizer


Shelf tumblelog theme

CSS Tricks

Robot or Not

UX London



Handcrafted Pixels

Hardboiled Web Design


iPhone Therefore I Am – Part 2

To design my first app we used my Moleskine notebook to create lots of templates on a whiteboard and sketched out the pages. It was fun and I highly recommend this method. We erased and changed things constantly as we mapped out the app.

I used Photoshop as a tried and trusted tool to then create those designs digitally and manufacture the graphics. Teehan and Lax offer a great Photoshop template file which contains all the standard Apple UI components.

They also provide the component in a sketch format for Illustrator use:

Although it is possible to create your own controls, Apple is keen for designers and developers to use the standard controls (see my earlier comments on the HIG). It makes good business and usability sense to follow this advice, as it instantly gives the customer an understanding of how to navigate around the app without having to learn the UI. I worked closely with an Objective C developer to prototype the app in a kind of Pair Programming capacity and hope to increase my understanding of Interface Builder and X-Code to further facilitate this process in the future.

The app prototype is looking great and I’m looking forward to the fun and games of getting it approved and on the app store.

I’ve blogged before on the role of being a designer in a Scrum Team. I thought it would be interesting to micro-blog my actual experiences of participating in the Sprint.

Day 1
First day of being back in the Sprint with the developers. I’m feeling the subtle pressure (or is that motivation?) to get my tasks done on time. We are working on a high-profile project and I can’t afford to hold up development by not having the design work completed.

Day 2
The wireframes have been created but the layouts are all wrong, so I need to pull my finger out! The CSS framework is a great help in the creation of the wireframes.

Day 3
I forgot to update my tasks before I left last night. Consequently we are behind on our Burndown Chart. I have to confess to the team that I didn’t practice what I preach. A humbling experience and I will definitely remember tonight and also cut some slack to my team in the future if this happens on the odd occasion.

Day 4
Chris Brogan recently said that “doing is more fun than planning”. Turns out he’s right. I’m enjoying keeping track of my tasks and having the opportunity to move my post-its across the board to ‘Done’. I think if you haven’t been in the Scrum you are losing a vital perspective on how the Sprint dynamic encourages a feeling of success.

Day 5
The post-its that have been bought from a local supermarket keep falling off the board. I had heard the team mentioning this, but hadn’t completed appreciated how annoying it is. The next purchase of post-it’s will be the genuine thing.

Day 6
I’ve cheated and added some additional screens to an existing task. I can’t decide whether this is utilising Scrum in a flexible way or I’m committing a Scrum sin. I’ll pick up the issue in the retrospective with the team.

Day 7
The Sprint has blipped. We have a developer unexpectedly out for two days. That’s a lot of ground to make up and we may need to take something out of the Sprint to compensate.

Day 8
In the Pre- Sprint Planning Meeting with our Product Owner we discussed a new design for a Blog Template. I promptly forgot to include that in the task so now I have to make up the time. In this situation wireframes are a great solution. Wireframes provide the developers with the information they need to get going whilst buying some time to complete the design.

Day 9
Being more physically involved in the Sprint has made me realise that the whiteboard could do with an overhaul. The board should be at the centre of the team, radiating information out to the wider business.

Day 10
I’ve gained final approval the last of my design work so my active tasks in the Sprint are set to Done. I’m back to the role of Scrum Master but I’ve learned a lot and been reminded of how it feels to be ‘in the Sprint’.

Day 11
I was reading ‘Agile Coaching’  and came across the following link:
Combined with my recent interest in visual thinking, this opened my mind to the possibilities of expanding the purpose of the current whiteboard. The current board is simply a ‘task board’ and there is a clear opportunity to make it a ‘team board’.  We are shortly transitioning to VS 2010 Agile 5.0 templates. After that change has been completed I’ll talk to the team about shaking up the whiteboard.

Day 12
It’s the last day of the Sprint and we managed to bring it in on-time. This is a great achievement as we lost some resource and velocity mid-sprint. I will be including my work in future Sprints, as it’s been a great reality check.

Are you a designer in a Scrum Team? Should design work be included in the Sprint? Let me know what you think.

What I have quickly found is that it’s really hard to protect developer’s time on Blue Sky Days. We had two issues which I would have usually rushed through, but this is the first time I had awarded Blue Sky days to the team. It would have completely undermined the concept if I’d asked them to do this work. I made a pragmatic decision to hold back the work but it was difficult not to interrupt their day.

I ensured that the team understood that they had the time to investigate new development work or any technology that interested them. In my absence a developer was approached with a serious pricing issue – I was glad to hear on my return this had been dealt with in a timely manner. I was also gladdened that the principles of self-organising had shone through. It does show however that the Scrum Leader has to be ever vigilant to protect developer’s time if the concept of Blue Sky Days is to have validity.

The pot of gold is somewhat elusive but if we allow teams the chance to explore, they might just find one.

Are Blue Sky Days worth their weight in gold?

Six steps to Adaptive Marketing

Marketing like UX is a balance of Art and Science. The role of marketer is like an architect, musician, conductor or cinematographer. This is the message I brought back from this year’s Web Trends conference I attended in London.The complexity and flux which has become synonymous with the Marketing landscape naturally dove-tails in to an Agile approach. That approach produces ‘Adaptive Marketing’.

The phrase ‘Adaptive Marketing’ was coined last year in a Forrester report and describes how Agile practices can be utilised to facilitate the marketing process. There’s a great definition of how Scrum works for marketing purposes, hidden in an article on the Teehan and Lax site:

  1. The agency and client define the objectives of the engagement and establish several key performance indicators
  2. The creative team is dedicated to the project for a set period of time allowing them to focus on the task
  3. Ideas are rapidly developed, tested and deployed
  4. Ideas evolve and adapt over time
  5. Performance is closely monitored allowing the team to make adjustments
  6. Project success is determined by achieving the KPIs

Adaptive Marketing is further defined by:

  • Removing the formal annual budgeting process
  • Removing medium to long-term media buying
  • Adopting short, measured, iterative plans
  • Allocating money for high-level visions not specific media
  • Adapting based on real-time consumer feedback and other data

An Agile approach to marketing reacts to the heart and soul of what the brand stands for. The catalyst for this is defined by the pull of brand influencers in the Social Media space and is not pushed by the business.

Agile offers the opportunity to create technology driven, data-fuelled campaigns that respond in real time to the shifting Social Media and Marketing landscape.

Do you think there is a place for Agile practices in Marketing?

Further links on Adaptive Marketing:

So what exactly might ‘Adaptive Brand Marketing’ be?

The practice of Adaptive Marketing

The Forrester report

Razorfish embrace Agile:

Below is a link to a Blog Post by Robert C Martin. He is colloquially known as Uncle Bob and was a pioneer of XP practices. I’ve recently been booked on to a Scrum Leader Certification course and have seen many posts on the perils of employing Certificated Scrum Leaders with little or no commercial experience.

Uncle Bob goes further in his critique claiming this trend could create the type of elitism that made the Waterfall software development model implode. In an explanation of why waterfall failed he says:

“There were the elite Architects, Designers, and System Analysts who did the real engineering by satisfying the first two phases of the waterfall.  And then there were the grunts who actually had to make everything work in the final phase.  When the project got behind schedule, it was the grunts who worked overtime.  When the project failed, it was the grunts who bore the blame.”

I believe I fall in the justifiable category of existing professionals who are seeking Certification to further my knowledge of Agile/Scrum. As Scrum Leaders we need to be mindful that we are here to serve the developers and help them get better at what they do by applying those practices.

Give it a read, we can all learn from the mistakes of Waterfall.

Uncle Bob followed this up with a definition of a valid certification route:

Are you getting Certification for the right reasons?
As an employer would you choose a Certified Scrum Leader over a more experienced uncertified candidate?