Just saw this new site in beta. www.everyscape.com
Defintely worth checking out. It's a mapping site with a difference. You can browse a location as if you are inside it. You can walk into a restaurant in New York City and walk past the diners to the back, turn around and walk out again. Kind of like those 3D virtuals tours. Nothing new right? Wrong. This time you get to walk out the resturant, along the street and check out another building by going in the front door. Very cool.
You also get to see the 2D map to the right in a side panel to see where you are walking.
They've got trial versions of 4 US cities at the moment.
There's some pretty interesting revenue opportunities here for them if it takes off. Hoteliers, ticket brokers, restaurant booking agents, travel agents, they'll all want to get linked it if gets critical mass.
Tuesday, 30 October 2007
Monday, 29 October 2007
Try This In Your Next Team Meeting
You want to say "well done" more to your team?
I know I do. However, I'm just not a gushing type. Every management course I've ever been on emphasises the need to praise, to recognise, to make folks feel valued. The idea being of course is that feeling valued is motivational and sustains a team. Most of this I agree with of course.
Essentially, you want your team to do a good job. Giving praise is only a tiny part of that equation though. For some people, praise is their fuel, their driving force. Praise them and they'll do anything. For others, it's not so simple. Sure, I like to be told I'm doing a good job. Who doesn't? But does it get me out of bed in the morning? Nope. For me it's all about being engaged. Being engaged in what you're doing and feeling that your effort has some real value. Being engaged, plus doing every day what you do best. Learning new tricks and solving challenges, that's good too. Oh yeah - and a "well done" afterwards is a good bonus. Did I mention the money?
Anyway, you see my point - praise isn't the magic ingredient in management. It's not going to do much if all the other motivational factors are not in play. It's the icing on the cake. (Except for the few people that get so high on praise that it's their wonder drug - give them praise and it will be like a turbo charge).
It's hard to praise well. For me this is because firstly, the person needs to feel like they deserve the praise and secondly, the best praise is delivered in front of others. Tricky.
So - here's my idea. I've tried it out and it seems to work.
At the beginning of your team meeting, ask each team member to write up on a white board (or flip chart) one thing that they or the team (or another team member) did well last week and that helped them work towards achieving their objectives.
It's great! The team write up on the board things they know are worth highlighting. They are happy enough that these achievements are worthy of praise. So - problem one is solved, the person feels the achievement was praise worthy.
Often, team members will highlight things that they have done that aren't actual deliverables but are changes to the way in which the team works together. This is good, because it highlights process optimisation, communication and/or infrastructure improvements.
On other occasions they might highlight softer things like new starters joining the team.
And sometimes they praise each other rather than themselves. A double whammy - public and peer praise!
One interesting thing about this technique is that the team are creating a sense of positive behavioural re-enforcement. By writing the achievement on the wall, they are committing themselves to a viewpoint that this achievement was a good thing to do. Writing something down commits the person in a very strong way to continuing to behave in the same way in the future. It helps form their identity.
The process is unusual. By adopting it the team create a ritual that is a way to mark them out from other teams. Although it's not a big deal, it's an act that they share that others don't. So it strengthens the team identity, and it does so in a positive context.
Once everyone has had a go (I would go last), I then ask each team member to write on a post-it the item that they think was the best achievement of the week. We post the notes together on the wall at the same time. Usually one achievement stands out and I can then spend a few moments praising that effort in front of the whole team.
With everyone in a good mood and in a "team" mode, we then set about the rest of the agenda.
Saying "well done" has never been so easy or so much fun!
I know I do. However, I'm just not a gushing type. Every management course I've ever been on emphasises the need to praise, to recognise, to make folks feel valued. The idea being of course is that feeling valued is motivational and sustains a team. Most of this I agree with of course.
Essentially, you want your team to do a good job. Giving praise is only a tiny part of that equation though. For some people, praise is their fuel, their driving force. Praise them and they'll do anything. For others, it's not so simple. Sure, I like to be told I'm doing a good job. Who doesn't? But does it get me out of bed in the morning? Nope. For me it's all about being engaged. Being engaged in what you're doing and feeling that your effort has some real value. Being engaged, plus doing every day what you do best. Learning new tricks and solving challenges, that's good too. Oh yeah - and a "well done" afterwards is a good bonus. Did I mention the money?
Anyway, you see my point - praise isn't the magic ingredient in management. It's not going to do much if all the other motivational factors are not in play. It's the icing on the cake. (Except for the few people that get so high on praise that it's their wonder drug - give them praise and it will be like a turbo charge).
It's hard to praise well. For me this is because firstly, the person needs to feel like they deserve the praise and secondly, the best praise is delivered in front of others. Tricky.
So - here's my idea. I've tried it out and it seems to work.
At the beginning of your team meeting, ask each team member to write up on a white board (or flip chart) one thing that they or the team (or another team member) did well last week and that helped them work towards achieving their objectives.
It's great! The team write up on the board things they know are worth highlighting. They are happy enough that these achievements are worthy of praise. So - problem one is solved, the person feels the achievement was praise worthy.
Often, team members will highlight things that they have done that aren't actual deliverables but are changes to the way in which the team works together. This is good, because it highlights process optimisation, communication and/or infrastructure improvements.
On other occasions they might highlight softer things like new starters joining the team.
And sometimes they praise each other rather than themselves. A double whammy - public and peer praise!
One interesting thing about this technique is that the team are creating a sense of positive behavioural re-enforcement. By writing the achievement on the wall, they are committing themselves to a viewpoint that this achievement was a good thing to do. Writing something down commits the person in a very strong way to continuing to behave in the same way in the future. It helps form their identity.
The process is unusual. By adopting it the team create a ritual that is a way to mark them out from other teams. Although it's not a big deal, it's an act that they share that others don't. So it strengthens the team identity, and it does so in a positive context.
Once everyone has had a go (I would go last), I then ask each team member to write on a post-it the item that they think was the best achievement of the week. We post the notes together on the wall at the same time. Usually one achievement stands out and I can then spend a few moments praising that effort in front of the whole team.
With everyone in a good mood and in a "team" mode, we then set about the rest of the agenda.
Saying "well done" has never been so easy or so much fun!
Sunday, 28 October 2007
Dunbar's Number, Cross 150 With Caution
Do organisational structures need to transform once they exceed 150 members in number?
In the fast growing companies of the dot com boom, and now in boom 2.0, many companies must experience the aggressive growth that takes them past the 150 team member mark without them realising what's happening to them.
Why 150? What is it with 150 that makes it significant?
The idea was first floated by British anthropologist Robin Dunbar (b. 1947), but subsequently popularised by Malcolm Gladwell in his book "The Tipping Point".
Known as "Dunbar's number", the number 150 is a theoretical maximum number of individuals with whom a group can maintain a social relationship where each knows who each other is and how they all connect socially.
So - in a group of 150, it is still possible to know everyone else, understand their roles and their relationships with each other. Beyond that, forget it.
This number is pretty significant therefore when it comes to shaping organisational structures. With a team of 150 you can still manage with a relatively flat reporting structure, fairly informal communication processes and decision making.
Once you cross from the "medium" company threshold into "large", the old ways just don't work any more. You need a different way of managing communication, direction, decision making. What's more the people that worked well in that environment most probably aren't the same type of people that work well in the smaller team. "Things aren't the same around here any more", "It's not what it used to be"... suddenly you've got 30% attrition and a super stressed out recruitment team.
Gore Associates (makers of Gore-Tex among other things) apparently keep their manufacturing plants under 150 persons. They found this size keeps people in touch with each other. If they need more production capacity, rather than expand a plant that's at the 150 limit, they'll start a new one.
Army regiments work in a similar manner. And just for good measure, Dunbar's surveys of settlements in ancient times show a tendency to be limited at about the 150 number.
Good companies require effective teams to succeed. Most companies however grow organically and rarely do leaders stop and ask how the social relationships in their teams work and what the effect of growth on those relationships might be.
So, a word of caution: if you are a small company doing well, and aim to hire employee number 150 in the coming months, start thinking about what your world needs to look like as you become a medium sized company.
See also: Wikipedia, Dunbar's number
In the fast growing companies of the dot com boom, and now in boom 2.0, many companies must experience the aggressive growth that takes them past the 150 team member mark without them realising what's happening to them.
Why 150? What is it with 150 that makes it significant?
The idea was first floated by British anthropologist Robin Dunbar (b. 1947), but subsequently popularised by Malcolm Gladwell in his book "The Tipping Point".
Known as "Dunbar's number", the number 150 is a theoretical maximum number of individuals with whom a group can maintain a social relationship where each knows who each other is and how they all connect socially.
So - in a group of 150, it is still possible to know everyone else, understand their roles and their relationships with each other. Beyond that, forget it.
This number is pretty significant therefore when it comes to shaping organisational structures. With a team of 150 you can still manage with a relatively flat reporting structure, fairly informal communication processes and decision making.
Once you cross from the "medium" company threshold into "large", the old ways just don't work any more. You need a different way of managing communication, direction, decision making. What's more the people that worked well in that environment most probably aren't the same type of people that work well in the smaller team. "Things aren't the same around here any more", "It's not what it used to be"... suddenly you've got 30% attrition and a super stressed out recruitment team.
Gore Associates (makers of Gore-Tex among other things) apparently keep their manufacturing plants under 150 persons. They found this size keeps people in touch with each other. If they need more production capacity, rather than expand a plant that's at the 150 limit, they'll start a new one.
Army regiments work in a similar manner. And just for good measure, Dunbar's surveys of settlements in ancient times show a tendency to be limited at about the 150 number.
Good companies require effective teams to succeed. Most companies however grow organically and rarely do leaders stop and ask how the social relationships in their teams work and what the effect of growth on those relationships might be.
So, a word of caution: if you are a small company doing well, and aim to hire employee number 150 in the coming months, start thinking about what your world needs to look like as you become a medium sized company.
See also: Wikipedia, Dunbar's number
Thursday, 25 October 2007
The Long Tail and Brand Communication
The Elongating Tail of Brand Communication: An Approach to Brand-Building Incorporating Long Tail Economics by Iqbal Mohammed, Ogilvy & Mather Advertising, January 2007
You know when you get sent a link or article, and you're kind of interested, but you just don't have the time to digest it all? Usually, you skim read it, get the general idea, and then just move on?
When I received a link to this paper earlier this year, it stopped my day. I sat there and read it, word by word for 45 minutes. Wow - a really well articulated idea relevant to our changing world!
The main idea behind the article is that there is a real side effect from our increasing media diversity and multi-platform advertising. It is a fundamental shift to the way we should consider brand-building.
Based on Chris Anderson's Long Tail theory, the paper presents the case why the single-minded brand proposition is out of date and will fail in the future. A brand needs to be many things to it's audience. How can you use "long tail" thinking to build complex, layered and engaging brands through advertising?
Download the paper, it's available at SSRN:
http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1007403#PaperDownload
You know when you get sent a link or article, and you're kind of interested, but you just don't have the time to digest it all? Usually, you skim read it, get the general idea, and then just move on?
When I received a link to this paper earlier this year, it stopped my day. I sat there and read it, word by word for 45 minutes. Wow - a really well articulated idea relevant to our changing world!
The main idea behind the article is that there is a real side effect from our increasing media diversity and multi-platform advertising. It is a fundamental shift to the way we should consider brand-building.
Based on Chris Anderson's Long Tail theory, the paper presents the case why the single-minded brand proposition is out of date and will fail in the future. A brand needs to be many things to it's audience. How can you use "long tail" thinking to build complex, layered and engaging brands through advertising?
Download the paper, it's available at SSRN:
http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1007403#PaperDownload
Wednesday, 24 October 2007
Planning Poker
Planning Poker is an unsual method of estimating tasks that I came across and have tried it out on a few projects. It's a good way to get maximum accuracy from minimal effort and it sounded interesting enough to have a go.
Objective: to estimate time required to complete projects not yet started
Why Planning Poker works
It brings together multiple expert opinions to do the estimating. Because these experts form a cross-functional team from all disciplines on a project, they are better suited to the estimation task than anyone else.
A lively dialogue ensues during planning poker, and estimators are called upon by their peers to justify their estimates. This has been found to improve the accuracy of the estimate, especially on items with large amounts of uncertainty.
Studies have shown that averaging individual estimates leads to better results as do group discussions of estimates.
Planning poker works because it’s fun.
How to play
1. Each member of team is given a deck of 6 cards.
Cards have the following values: 1, 2, 3, 5, 8, Joker
Numbers on the cards represent days.
A Joker = more than 8 days (unknown)
2. For each user story (see: Introduction to Scrum) to be estimated, the moderator reads the description. Any questions arising are then answered.
3. After all questions are answered, each person privately selects a card representing their estimate. Cards are not shown until each estimator has made a selection. At that time, all cards are simultaneously turned over and shown so that all participants can see each estimate.
4. If the estimates are close, a consensus is reached and players move to the next user story. If the estimates vary wildly, the team can discuss their reasons for their estimates. They are only allowed 2 minutes to do this and then a new round is played and cards are put on the table again. This time limit is absolute. No exceptions.
This continues until a consensus is reached.
More information
You can now play planning poker online for free. Try it out at www.planningpoker.com
The orginal idea came from Agile Estimating and Planning by Mike Cohn
Objective: to estimate time required to complete projects not yet started
Why Planning Poker works
It brings together multiple expert opinions to do the estimating. Because these experts form a cross-functional team from all disciplines on a project, they are better suited to the estimation task than anyone else.
A lively dialogue ensues during planning poker, and estimators are called upon by their peers to justify their estimates. This has been found to improve the accuracy of the estimate, especially on items with large amounts of uncertainty.
Studies have shown that averaging individual estimates leads to better results as do group discussions of estimates.
Planning poker works because it’s fun.
How to play
1. Each member of team is given a deck of 6 cards.
Cards have the following values: 1, 2, 3, 5, 8, Joker
Numbers on the cards represent days.
A Joker = more than 8 days (unknown)
2. For each user story (see: Introduction to Scrum) to be estimated, the moderator reads the description. Any questions arising are then answered.
3. After all questions are answered, each person privately selects a card representing their estimate. Cards are not shown until each estimator has made a selection. At that time, all cards are simultaneously turned over and shown so that all participants can see each estimate.
4. If the estimates are close, a consensus is reached and players move to the next user story. If the estimates vary wildly, the team can discuss their reasons for their estimates. They are only allowed 2 minutes to do this and then a new round is played and cards are put on the table again. This time limit is absolute. No exceptions.
This continues until a consensus is reached.
More information
You can now play planning poker online for free. Try it out at www.planningpoker.com
The orginal idea came from Agile Estimating and Planning by Mike Cohn
An Introduction To Scrum
Getting things done using Scrum - an introduction to the Scrum software development framework.
Manager: "I want my work delivered when you say it will be delivered"!"
Tech guy: "Stop changing the goal posts every few days and just let me get on with it!"
Sounds familiar?
One process that aims to address these frustrations is "Scrum". "What on earth is that!", you may well ask.
If you are a manager in an internet company you may or may not have heard the technical team talk about "Scrum" and "Agile Development". You may have wondered what it is and why it's becoming so popular. It's actually quite a simple way of organising work into (usually) 2 weeks blocks. To do this a number of roles are created and a number of meetings happen to keep things moving. I'll explain these, but first - why do it?
Benefits of Scrum
Managers get a clear process to prioritise the work flow
Managers can be sure that the team is always working on the highest priority work items / projects
Developers give commitment to get the job done
The development team muck in together to solve problems and share work
Developers are not continuously interrupted and can focus
There is a relentless focus on quality delivery
It does not require complicated technology or tools
Terminology
There's some terminology unique to Scrum. The word Scrum for a start. Yes, I know it's a rugby term, but in this case it doesn't mean anything in particular other than a word to describe the process framework.
At the most basic level you need to understand that work is organised into periods of time called sprints. A sprint is usually a two week period, although it could be almost any time between 1 week and a month. It depends on what works for the team. We found that 2 week sprints worked well for us.
The team commits to deliver a specified amount of work in the upcoming sprint. The resulting work-list is called a sprint backlog.
To describe the rest of the process, I will focus on the following 3 areas:
Roles
Meetings
Time frame
Key roles in Scrum
1. The Product Owner
This is the person responsible for specifying the changes required. They may do this by themselves or they may represent a wider group of business owners. Their purpose is to scope out the work and arrive at a single list of priorities. The list of priorities is known as the product backlog. Each item on the product backlog is known as a story.
2. The Scrummaster
The Scrummaster is a facilitator. They are usually one of the team and have equal status to all others on the team. They are however responsible for ensuring that the team knows what is expected of them and leads the various meetings to make the process work. They also are charged with working to remove any impediments to progress that are reported by the team.
3. The team
The team is usually a group of developers and related functions (e.g. designer, testers). For Scrum to work well, you probably need at least 4 people, and no more than 10. These are not strict limits - Scrum is just a framework that you need to adapt to make it work for you. In my experience a team of 8 or 9 works great. If I had 20 people I would create two teams rather than have one huge team.
Meetings needed to make the process work
1. Sprint planning meeting
The day before the sprint starts, the team meet to plan the next sprint. They figure out from the product backlog, what tasks are required to deliver each story. They then estimate the time it will take them for each task. Knowing this they can then take on add a number of stories (in priority order) to the sprint backlog.
2. The daily scrum
This is a meeting that happens at the same time every day. In our case we chose 09.30, but it could be any time that works for the team. Every day means every day and it's not optional.
Each team member answers 3 questions in turn,
i) what did you work on yesterday?
ii) what will you work on today?
iii) what is blocking your progress?
The team organise their work around the sprint board. We mounted a white board on the wall and used post-it notes of different colours to represent the tasks. We used different colours for design, development and test. I've also seen magnetic boards that use magnetic post-its. Both work.
The board shows all of the work for the current sprint. (Click to enlarge)
You can see from the board that each story is broken down into tasks. These tasks are placed on the board according to their status. They are either in the queue, being worked on, being tested or are complete.
3. Sprint review
The sprint review is a meeting where the team present their completed stories to the product owner.
4. Sprint retrospective
This meeting happens at the end of the sprint and allows the team to discuss what went well in the sprint, what could have gone better and what they will change for the future. This allows for issues to be addressed and allows for a self-optimising team and process.
Time frame
The length of your sprints can be what you want it to be. Usually a 2 or 4 week cycle is chosen depending on the type of work you receive.
The start day of the sprint does not have to be a Monday. You can start say on a Wednesday and run your sprints Wednesday to Tuesday. Whatever works best for the team.
On a 2 week (10 working day) sprint you might do the following
Day 1 (am) - Sprint planning
Day 2 to day 10 - Daily Scrum
Day 10 (pm) - Sprint review
Day 10 (pm) - Sprint Retrospective
Why does it work?
The team have a clear set of priorities that they have committed to deliver over the coming sprint. They have thought through was required of them, they've discussed it in detail and they've agreed what they can achieve. Once committed, the team work together to maintain their collective reputation by delivering on their promises.
The management start to see stuff getting done. Every 2 weeks they see results. They know that the most important stuff is being worked on first. They know the team are not wasting their time on things that are not a priority for the business.
What can go wrong?
The process only works if the team are not interrupted once the sprint has started. New work should not enter into the current sprint unless the team agree it is possible to take it on. Otherwise, if the priorities really have changed you need to stop the sprint and start a new one. Management need to get used to the fact that they need to plan ahead. Will it wait 2 weeks until the next sprint starts? (In reality, the answer is usually yes).
The other important factor is that the team really need to believe in the structure. All team members need to be behind it and support it. Having one resistant member will spoil the party.
Rituals and rites
One way of rallying human behaviour around a cause is to introduce rituals. Religion of course has done this for centuries, but all social groupings have their rituals and behaviours. Songs and scarves (football supporters), national holidays (counties), opening ceremony (Olympics), holy days (religions).
What's interesting about Scrum is that the meetings, the terminology and the routine give a sense of shared identity to the Scrum team. Through following this process they re-enforce their sense of being a team. It's a very useful by-product of the efficiency of the process.
How to get started with Scrum
I was first introduced to Scrum by Tobias Mayer. He gave a simple but compelling overview of the Scrum process to our team. This planted the seed from which we grew to explore and adopt Scrum. It was simple enough for the key decision makers to "get it" and interesting enough for developers to want to learn more. If you want to introduce Scrum to your organisation, he'd be a good person to do this.
You need to start with one of two key individuals that are keen to get involved. They will be your champions. Get them trained on a Scrum training course. A good course to start with could be Rachael Davies' Scrum Awareness Course. Then get them back in the business and think through with them what needs change in the organisation if you are going to give it a go. Who will take up each of the key roles?
Then, you most definitely need senior management buy-in. They cannot just come to the team and demand work requests - they will also need to channel their requests in the right way, through the Product Owner.
Most importantly for Scrum to work the team needs to dedicate themselves to it's implementation. All the team need to feel that it is a benefit to work this way. Also - it needs to work in a way that suits them, their obstacles, people, goals and company organisation.
It takes a while to get right. We found it took us about 6 months before we really got going and had a clockwork process in place.
I found that the results though were worth it. I had a predicatble process to work with, my team were energised, they took ownership for their work - and most importantly - stuff got done.
Further reading:
Controlchaos.com - Ken Schwaber, The man who wrote the book on Scrum.
Scrum Alliance - Scrum community resource centre
Scrumworks Pro - software to manage your Scrum work flow
Conferences / Events
London Scrum gathering November 2007
Manager: "I want my work delivered when you say it will be delivered"!"
Tech guy: "Stop changing the goal posts every few days and just let me get on with it!"
Sounds familiar?
One process that aims to address these frustrations is "Scrum". "What on earth is that!", you may well ask.
If you are a manager in an internet company you may or may not have heard the technical team talk about "Scrum" and "Agile Development". You may have wondered what it is and why it's becoming so popular. It's actually quite a simple way of organising work into (usually) 2 weeks blocks. To do this a number of roles are created and a number of meetings happen to keep things moving. I'll explain these, but first - why do it?
Benefits of Scrum
Terminology
There's some terminology unique to Scrum. The word Scrum for a start. Yes, I know it's a rugby term, but in this case it doesn't mean anything in particular other than a word to describe the process framework.
At the most basic level you need to understand that work is organised into periods of time called sprints. A sprint is usually a two week period, although it could be almost any time between 1 week and a month. It depends on what works for the team. We found that 2 week sprints worked well for us.
The team commits to deliver a specified amount of work in the upcoming sprint. The resulting work-list is called a sprint backlog.
To describe the rest of the process, I will focus on the following 3 areas:
Key roles in Scrum
1. The Product Owner
This is the person responsible for specifying the changes required. They may do this by themselves or they may represent a wider group of business owners. Their purpose is to scope out the work and arrive at a single list of priorities. The list of priorities is known as the product backlog. Each item on the product backlog is known as a story.
2. The Scrummaster
The Scrummaster is a facilitator. They are usually one of the team and have equal status to all others on the team. They are however responsible for ensuring that the team knows what is expected of them and leads the various meetings to make the process work. They also are charged with working to remove any impediments to progress that are reported by the team.
3. The team
The team is usually a group of developers and related functions (e.g. designer, testers). For Scrum to work well, you probably need at least 4 people, and no more than 10. These are not strict limits - Scrum is just a framework that you need to adapt to make it work for you. In my experience a team of 8 or 9 works great. If I had 20 people I would create two teams rather than have one huge team.
Meetings needed to make the process work
1. Sprint planning meeting
The day before the sprint starts, the team meet to plan the next sprint. They figure out from the product backlog, what tasks are required to deliver each story. They then estimate the time it will take them for each task. Knowing this they can then take on add a number of stories (in priority order) to the sprint backlog.
2. The daily scrum
This is a meeting that happens at the same time every day. In our case we chose 09.30, but it could be any time that works for the team. Every day means every day and it's not optional.
Each team member answers 3 questions in turn,
i) what did you work on yesterday?
ii) what will you work on today?
iii) what is blocking your progress?
The team organise their work around the sprint board. We mounted a white board on the wall and used post-it notes of different colours to represent the tasks. We used different colours for design, development and test. I've also seen magnetic boards that use magnetic post-its. Both work.
The board shows all of the work for the current sprint. (Click to enlarge)
You can see from the board that each story is broken down into tasks. These tasks are placed on the board according to their status. They are either in the queue, being worked on, being tested or are complete.
3. Sprint review
The sprint review is a meeting where the team present their completed stories to the product owner.
4. Sprint retrospective
This meeting happens at the end of the sprint and allows the team to discuss what went well in the sprint, what could have gone better and what they will change for the future. This allows for issues to be addressed and allows for a self-optimising team and process.
Time frame
The length of your sprints can be what you want it to be. Usually a 2 or 4 week cycle is chosen depending on the type of work you receive.
The start day of the sprint does not have to be a Monday. You can start say on a Wednesday and run your sprints Wednesday to Tuesday. Whatever works best for the team.
On a 2 week (10 working day) sprint you might do the following
Day 1 (am) - Sprint planning
Day 2 to day 10 - Daily Scrum
Day 10 (pm) - Sprint review
Day 10 (pm) - Sprint Retrospective
Why does it work?
The team have a clear set of priorities that they have committed to deliver over the coming sprint. They have thought through was required of them, they've discussed it in detail and they've agreed what they can achieve. Once committed, the team work together to maintain their collective reputation by delivering on their promises.
The management start to see stuff getting done. Every 2 weeks they see results. They know that the most important stuff is being worked on first. They know the team are not wasting their time on things that are not a priority for the business.
What can go wrong?
The process only works if the team are not interrupted once the sprint has started. New work should not enter into the current sprint unless the team agree it is possible to take it on. Otherwise, if the priorities really have changed you need to stop the sprint and start a new one. Management need to get used to the fact that they need to plan ahead. Will it wait 2 weeks until the next sprint starts? (In reality, the answer is usually yes).
The other important factor is that the team really need to believe in the structure. All team members need to be behind it and support it. Having one resistant member will spoil the party.
Rituals and rites
One way of rallying human behaviour around a cause is to introduce rituals. Religion of course has done this for centuries, but all social groupings have their rituals and behaviours. Songs and scarves (football supporters), national holidays (counties), opening ceremony (Olympics), holy days (religions).
What's interesting about Scrum is that the meetings, the terminology and the routine give a sense of shared identity to the Scrum team. Through following this process they re-enforce their sense of being a team. It's a very useful by-product of the efficiency of the process.
How to get started with Scrum
I was first introduced to Scrum by Tobias Mayer. He gave a simple but compelling overview of the Scrum process to our team. This planted the seed from which we grew to explore and adopt Scrum. It was simple enough for the key decision makers to "get it" and interesting enough for developers to want to learn more. If you want to introduce Scrum to your organisation, he'd be a good person to do this.
You need to start with one of two key individuals that are keen to get involved. They will be your champions. Get them trained on a Scrum training course. A good course to start with could be Rachael Davies' Scrum Awareness Course. Then get them back in the business and think through with them what needs change in the organisation if you are going to give it a go. Who will take up each of the key roles?
Then, you most definitely need senior management buy-in. They cannot just come to the team and demand work requests - they will also need to channel their requests in the right way, through the Product Owner.
Most importantly for Scrum to work the team needs to dedicate themselves to it's implementation. All the team need to feel that it is a benefit to work this way. Also - it needs to work in a way that suits them, their obstacles, people, goals and company organisation.
It takes a while to get right. We found it took us about 6 months before we really got going and had a clockwork process in place.
I found that the results though were worth it. I had a predicatble process to work with, my team were energised, they took ownership for their work - and most importantly - stuff got done.
Further reading:
Controlchaos.com - Ken Schwaber, The man who wrote the book on Scrum.
Scrum Alliance - Scrum community resource centre
Scrumworks Pro - software to manage your Scrum work flow
Conferences / Events
London Scrum gathering November 2007
Tuesday, 23 October 2007
Search Engine Strategies Conference 2008
Want to understand SEO? This is a good place to start.
I've been to the Search Engine Strategies London conference for several years now. It's a 3 day event that focuses on both PPC and SEO (natural and paid search).
For 2008 it will be held at the Business Design Centre, Islington (North London).
For a fiver less than a grand you get to attend for all 3 days (February 19-21, 2008). I suggest that you carefully plan your visit to focus on the areas that you're most interested in. Once you're there, don't be afraid to leave a session that isn't giving you what you need.
You should come away from the conference having built up a very good awareness of the key issues to address when optimising a site. At the end of the day it's pretty simple: if a site is built well it will be both well optimised for users and for search engines. They are not mutually exclusive.
If you need a hotel or accommodation in London during your stay, try hotels in London from Expedia.co.uk. They have a good range of hotels to choose from at good prices.
I've been to the Search Engine Strategies London conference for several years now. It's a 3 day event that focuses on both PPC and SEO (natural and paid search).
For 2008 it will be held at the Business Design Centre, Islington (North London).
For a fiver less than a grand you get to attend for all 3 days (February 19-21, 2008). I suggest that you carefully plan your visit to focus on the areas that you're most interested in. Once you're there, don't be afraid to leave a session that isn't giving you what you need.
You should come away from the conference having built up a very good awareness of the key issues to address when optimising a site. At the end of the day it's pretty simple: if a site is built well it will be both well optimised for users and for search engines. They are not mutually exclusive.
If you need a hotel or accommodation in London during your stay, try hotels in London from Expedia.co.uk. They have a good range of hotels to choose from at good prices.
Monday, 22 October 2007
Online Copywriting Best Practice
So how should you write for the web? Here's some top tips to get you started.
1. Keep sentences short
Short sentences are easier to digest. They require less brainpower. Your visitors are one click away from your competitors, so don't make it difficult. If your sentence can be written simply, write it simply.
2. Get the message across quickly
You can get the essence of your communication across in the first few words. Don't make someone read through a whole paragraph to get to the point - they'll not get that far.
3. Use the words of your audience
Your vocabulary needs to use the words that your readers are familiar with. There are 2 good reasons for this. One: it's easier to understand. Two: these are the words most likely to be typed in by your visitors to Google. If you put these words on your page, your copy will already be on the way to being optimised for search engines. Use Google's keyword suggestion tool to research what words to use.
4. Keep paragraphs short
A good example of this is the BBC news site. Each paragraph is simple, short and easy to digest. Long paragraphs are just hard work.
BBC example article: Facebook's developer platform
5. Use good grammar and spelling
It sounds simple, and it is. I don't claim to be perfect either. I do however see sites that lose credibility at the last hurdle with a spelling mistake.
6. Be consistent in your style
By style I mean the way in which you use numbers, abbreviations, dates and terminology. It just makes your site more coherent.
7. DON'T USE UPPER CASE
It's so much easier to read sentence case!
8. Use headings, subheadings and bullet points
This gives your article structure, makes it easy to scan read. Website visitors rarely read every word - they need to be able to scan through quickly and select what copy they feel like engaging with. Ask yourself the question: "can I see at a glance what this article is about from 5 feet away?"
Related articles
- Interesting article from Jakob Neilson: Passive Voice Is Redeemed For Web Headings
- Fantastic site for online copy writing: Nick Usbourne's Excess Voice - copy writing tips for the web
Friday, 19 October 2007
Essential Reading for Ecommerce Leaders
I enjoy understanding social influence - the effect we all have on each other.
Online pursuasion. It's the basis of conversion. In fact, you could say it's a way of thinking. Once you start seeing your website as a pursuasion tool and not as a shop window you're getting somewhere.
You see - an ecommerce site is both the shop and the shop assistant. It's also the sign posting to get there (SEO).
To get you in the right frame of mind, here is my recommended reading list for budding internet retailers. Individually they may not all directly seem relevant. Put them all together and you'll get a viewpoint that will help you move forward with conviction.
If you want to get into my head, these are some of my favourite books...
Influence - Robert B. Cialdini
The tricks of the trade. What techniques are used by folks to influence each other, why do they work, and how can you "protect yourself" from these techniques? Equally as useful if you are selling or if you are being sold to. Fascinating.
Why we buy - Paco Underhill
This guy has spent decades observing consumer behaviour in retail outlets. He helps you understand just how smart some shops are, at the same time you start to understand how so many could be so much better. I look at shop space now with a whole different view.
Freakonomics - Steven D Levitt & Stephen J. Dubner
Using economic methodology to try and understand social trends, this is a fascinating collection of studies. Two of my favourite were; the trends found in baby-naming, and the reason for the drop in NYC crime: abortion. Read it to find out more.
The Pyramid Principle - Barbara Minto
I read so many poorly written emails, presentations and documentation. This book helps you avoid doing so too by taking a very structured approach to your communications. Written by an ex-McKinsey consultant, the basic message is very simple (of course), but it's quite tricky to get right in the real world. If you've ever used MindManager software to map out your ideas, this book helps you craft communication from your mind-maps.
Now, Discover Your Strengths - Marcus Buckingham
We're all different. We all have different strengths. I guess you know that. Do you know what your strengths are? I thought I did, and then I read this book. With the book comes access to an online questionnaire that you complete to create your profile. The results made a lot of sense. The important message here is that you should focus on what you're good at and excel. Leave what you're not so good at to others, or at least do some training for damage limitation. In the end you are who you are - make sure you spend time on being the best you.
The Paradox of Choice - Barry Schwartz
I cannot recommend this book highly enough. Barry gets you thinking about just how you make choices in life. Choosing requires mental energy and can become a burden. The paradox is that we continously hail consumer choice as a good thing when in fact on many occasions, less is often more. A what cost do we pursue perfection?
The Search - John Battelle
The story of Google. More specifically, how a new business model emerged where advertisers only pay for results. You know about Google of course, but what I didn't know before reading this was the human story of how they grew, what deals were made and what the future might hold. Anyone who works in the online industry needs to read it.
Call to Action - Bryan Eisenberg
If Paco Underhill (see above) studies the real world of retailing, Bryan Eisenburg studies how to influence customers online. The book is not particularly well structured, but he presents case studies that make you realise just how tricky it is to get it right online and when you do, just how powerful it can be. At the crux of this book is how you persuade people in an interactive medium where the website is just one part of the experience.
The Tipping Point - Malcolm Gladwell
In this book you are treated to real life examples where a "tipping point" was needed in order create an overwhelming self-perpetuating phenomenon. From shoe trends to diseases, what is needed to create the momentum?
Don't Make Me Think! - Steve Krug
If you have any responsibility whatsoever for a website - as a manager, designer, developer - any role in fact - you need to read this book. It's a really simple introduction to the ways in which you can screw up a customer's experience without much effort. What takes effort is to keep it simple. Steve shows you how.
The Concise 48 Laws of Power - Robert Greene
There is a longer version of this book, but this concise version serves the same purpose. This book demonstrates 48 different ways in which powerful people gain and hold on to power. I must admit, much of the methodology goes right against how I prefer to treat people. In any company, society or family, some of the methods described here surface, so if anything, it's useful to be aware of what's going on and what you can do to avoid being screwed over.
Blink - Malcolm Gladwell
Another one from Malcolm Gladwell. This book has a really simple central idea and goes through many chapters to illustrate it over and over again. The simple idea is that your gut reaction (the one that you have before you've got time to think something through) is most likely to be the right reaction - IF you have enough experience in that area to fall back on. Firefighters, pilots, drivers, art experts - they are all highly experienced in their area, and their intuition makes for some pretty good reactive decision making. It made me confident in my own decision making and not needing to analyse every option before comitting to course of action.
Online pursuasion. It's the basis of conversion. In fact, you could say it's a way of thinking. Once you start seeing your website as a pursuasion tool and not as a shop window you're getting somewhere.
You see - an ecommerce site is both the shop and the shop assistant. It's also the sign posting to get there (SEO).
To get you in the right frame of mind, here is my recommended reading list for budding internet retailers. Individually they may not all directly seem relevant. Put them all together and you'll get a viewpoint that will help you move forward with conviction.
If you want to get into my head, these are some of my favourite books...
Influence - Robert B. Cialdini
The tricks of the trade. What techniques are used by folks to influence each other, why do they work, and how can you "protect yourself" from these techniques? Equally as useful if you are selling or if you are being sold to. Fascinating.
Why we buy - Paco Underhill
This guy has spent decades observing consumer behaviour in retail outlets. He helps you understand just how smart some shops are, at the same time you start to understand how so many could be so much better. I look at shop space now with a whole different view.
Freakonomics - Steven D Levitt & Stephen J. Dubner
Using economic methodology to try and understand social trends, this is a fascinating collection of studies. Two of my favourite were; the trends found in baby-naming, and the reason for the drop in NYC crime: abortion. Read it to find out more.
The Pyramid Principle - Barbara Minto
I read so many poorly written emails, presentations and documentation. This book helps you avoid doing so too by taking a very structured approach to your communications. Written by an ex-McKinsey consultant, the basic message is very simple (of course), but it's quite tricky to get right in the real world. If you've ever used MindManager software to map out your ideas, this book helps you craft communication from your mind-maps.
Now, Discover Your Strengths - Marcus Buckingham
We're all different. We all have different strengths. I guess you know that. Do you know what your strengths are? I thought I did, and then I read this book. With the book comes access to an online questionnaire that you complete to create your profile. The results made a lot of sense. The important message here is that you should focus on what you're good at and excel. Leave what you're not so good at to others, or at least do some training for damage limitation. In the end you are who you are - make sure you spend time on being the best you.
The Paradox of Choice - Barry Schwartz
I cannot recommend this book highly enough. Barry gets you thinking about just how you make choices in life. Choosing requires mental energy and can become a burden. The paradox is that we continously hail consumer choice as a good thing when in fact on many occasions, less is often more. A what cost do we pursue perfection?
The Search - John Battelle
The story of Google. More specifically, how a new business model emerged where advertisers only pay for results. You know about Google of course, but what I didn't know before reading this was the human story of how they grew, what deals were made and what the future might hold. Anyone who works in the online industry needs to read it.
Call to Action - Bryan Eisenberg
If Paco Underhill (see above) studies the real world of retailing, Bryan Eisenburg studies how to influence customers online. The book is not particularly well structured, but he presents case studies that make you realise just how tricky it is to get it right online and when you do, just how powerful it can be. At the crux of this book is how you persuade people in an interactive medium where the website is just one part of the experience.
The Tipping Point - Malcolm Gladwell
In this book you are treated to real life examples where a "tipping point" was needed in order create an overwhelming self-perpetuating phenomenon. From shoe trends to diseases, what is needed to create the momentum?
Don't Make Me Think! - Steve Krug
If you have any responsibility whatsoever for a website - as a manager, designer, developer - any role in fact - you need to read this book. It's a really simple introduction to the ways in which you can screw up a customer's experience without much effort. What takes effort is to keep it simple. Steve shows you how.
The Concise 48 Laws of Power - Robert Greene
There is a longer version of this book, but this concise version serves the same purpose. This book demonstrates 48 different ways in which powerful people gain and hold on to power. I must admit, much of the methodology goes right against how I prefer to treat people. In any company, society or family, some of the methods described here surface, so if anything, it's useful to be aware of what's going on and what you can do to avoid being screwed over.
Blink - Malcolm Gladwell
Another one from Malcolm Gladwell. This book has a really simple central idea and goes through many chapters to illustrate it over and over again. The simple idea is that your gut reaction (the one that you have before you've got time to think something through) is most likely to be the right reaction - IF you have enough experience in that area to fall back on. Firefighters, pilots, drivers, art experts - they are all highly experienced in their area, and their intuition makes for some pretty good reactive decision making. It made me confident in my own decision making and not needing to analyse every option before comitting to course of action.
Tuesday, 9 October 2007
50 Ways to Make Google Love Your Web Site
Steve Johnston has just published an ebook called 50 Ways to Make Google Love Your Web Site. It is a great SEO read for webmasters.
Who is Steve Johnston? He's a Google Consultant, he specialises in getting under the skin of your website and making sure that you know what you need to do to get your site ranked in Google and to do it in a way that it above board with no hidden tricks. I've employed Steve on a project and was pleased with his professionalism, work ethic and advice.
Who is Steve Johnston? He's a Google Consultant, he specialises in getting under the skin of your website and making sure that you know what you need to do to get your site ranked in Google and to do it in a way that it above board with no hidden tricks. I've employed Steve on a project and was pleased with his professionalism, work ethic and advice.
Wednesday, 3 October 2007
Scottish Mountain Biking
At Scottish Mountain Bike my brother Andrew created a fantastic site where you'll find everything you need to plan your cycling trip to Scotland's mountain bike centres.
This was his first website, and I'm impressed! Go go little bro!
This was his first website, and I'm impressed! Go go little bro!
Tuesday, 2 October 2007
Making a Decision Without All The Data
"You don't need a weatherman to see which way the wind is blowing" - Bob Dylan
I heard this on my ipod the other day and it got me thinking. In business you can often get to "analysis paralysis". By this I mean where leaders only make decisions when they have a full set of data, a fully developed business model, risk assessment models, etc etc.
In many cases making decisions on a well research data set is the right thing to do.
Yet there comes a point where gathering more information is not going to get give you significantly more insight.
Example: for usability testing, Jakob Neilson has shown that it only takes five users to give you enough information to work from. See his article Why You Only Need to Test With 5 Users. Five users can identify 80% of the usability problems. To get 100%, you need to test 15 users. You can get working quicker on resolving the issues if you just test 5, fix them, and then re-test.
Going back to Bob Dylan. The point is this... you can't predict the weather without specific data, but you can predict the seasons. Summer always follows spring, and it's usually warmer. You know this from your experience. Your experience feeds your intuition.
The role of your experience in decision making is considered in more detail by Malcolm Gladwell in his book "Blink". See my recommended reading post for more details.
If you have experience in an area, sometimes you just need to take a view and go with it. You'll probably be right.
I heard this on my ipod the other day and it got me thinking. In business you can often get to "analysis paralysis". By this I mean where leaders only make decisions when they have a full set of data, a fully developed business model, risk assessment models, etc etc.
In many cases making decisions on a well research data set is the right thing to do.
Yet there comes a point where gathering more information is not going to get give you significantly more insight.
Example: for usability testing, Jakob Neilson has shown that it only takes five users to give you enough information to work from. See his article Why You Only Need to Test With 5 Users. Five users can identify 80% of the usability problems. To get 100%, you need to test 15 users. You can get working quicker on resolving the issues if you just test 5, fix them, and then re-test.
Going back to Bob Dylan. The point is this... you can't predict the weather without specific data, but you can predict the seasons. Summer always follows spring, and it's usually warmer. You know this from your experience. Your experience feeds your intuition.
The role of your experience in decision making is considered in more detail by Malcolm Gladwell in his book "Blink". See my recommended reading post for more details.
If you have experience in an area, sometimes you just need to take a view and go with it. You'll probably be right.
Subscribe to:
Posts (Atom)