10 Ways For Teams To Do More Useful Stuff

Most managers, most of the time, have a job to do; mostly we manage a team to do stuff.

Sometimes we sit in meetings where ideas flow, sometimes we do deals. However, the nuts and bolts of business is just that; putting together nuts and bolts for other people to buy. (Or in recent years - bytes and bits).

After 20+ years of "getting stuff done" these days as a COO I'm still learning every day about what works. How to organise and coordinate teams in the most effective way. By effective, I mean in the way that creates most value for customers.

If a new manager were to approach me early in their career and ask today, "David, how can I really manage work flow well?", I'd give them the following ten tips. They are what I aspire to myself every day.

Whether it's managing software development teams, call centres, HR projects or staging events, I've found these principles to work. Until recently I hadn't been able to express them clearly. Reading about Japanese production methodologies has helped me reflect on what has worked for me and why.

So, here's my ten tips for getting stuff done well...


1. Make the work flow public

Get the work on the wall. In real time.

These days there are plenty of software solutions to track the status of a project but sadly even the best software fails when it comes to improving team effectiveness. That's because looking at a computer screen is generally not a public process and public processes create peer pressure.

Simply getting the status of the project on a wall and updating it on a daily basis creates awareness amongst all team members and prompts discussions such as, "why is everything stuck in the design phase", "we're not going to hit our target so what are we going to do" or "we're doing well". For example, use post-its that represent tasks that move along between phases of a project, columns for these phases and rows for individuals or sub-teams. Or, in the case of service environments data points such as open cases today, calls waiting, calls successfully answered within 3 rings.

By making the data public and keeping it updated the team starts to work together to address the challenge.

You might think that post-it notes, whiteboards etc are an extra layer of information processing that you don't need if you already track on a computer. Even if there is an extra cost or maintaining real time public work boards I've found the productivity gains to be worth the extra effort. It's counter-intuitive but like most things counter-intuitive it has a surprising effect.

Visual controls. They're very very effective.


2. Go and see the work

You can run all the metrics you like but a good manager needs to be close to the work.

As a Senior Manager this is not practical to do with all the teams that you manage but you still need to periodically "go and see". And literally spend time watching. It's these observations (supported by relevant data) that allow you to make the smart decisions. What's important to fix right now. What's causing the delay / error / problem. Who can help me improve this situation.

A manager is focused on what's closest to him or her. So go to where your customers are and you'll end up focusing on your customers.


3. Be your own customer

I use the word customer in the very broadest sense. Customer can mean consumer, the purchaser of the product or service. Or - a customer could be a supplier. Or - a customer could be a colleague in another team. Basically, if you deliver a service or product to anyone internally or externally, they are your customer.

For example, the finance team are customers of the HR team because they require payroll data from the HR team. The worker getting paid at the end of the month is the customer of the finance team.

Being your own customer can really expose you to the experience of being that customer. What problem is it that you need solved? What does it feel like to have that problem solved by your company? What could be better and why?

At the end of the day, people pay for products and services to solve a problem that they have. E.g. making phone calls (telephone), keeping on touch with friends (social network), self-esteem (fashion), hunger (food), family time (holiday).

If you don't experience the problem and solution yourself you cannot achieve the same level of understanding. Go and be your own customer as a customer would experience it. That helps you to see the value and see the improvements needed.


4. Be able to do the work yourself

Simply sitting with a team creates an awareness that you can't get by sitting in an office next door. Even better, you need to have done the work to truly appreciate what could be improved.

If you can shadow a team member for a day or two, see what it's like to receive the information that they receive, use the tools they use, you are so much more aware of what's important, possible or needed.

Some of the very best managers are those that worked their way up through the organisation from knowing the work in detail from the ground up. They are indeed "grounded" yet have managed to take on senior manager roles. This gives them the ability to have a "helicopter view" and a "ground level view" and they can switch between the two quickly and at will.

This is why it's so important to develop people within a team and train the next generation of leaders from within if at all possible.


5. Reduce work in progress

This is one of the most important and effective principles of all and it's one of the most difficult to achieve. Often we will hear of the importance of focus. Focus is all about deciding what not to do rather than about what to do. It actually about reducing work in progress.

If you have 10 tasks that you are simultaneously working on, you will be switching between tasks a lot. If you have 2 or 3 you can generally work through those in some detail and do them properly. You will actually end up doing more and doing it better. Fact, trust me.

Easy to say, not easy to do. Why?

Think about email as an example. You have a number of projects on the go. You reply to emails, you send emails and that's often because you're collaborating with others to achieve a project goal. Rarely do we work completely alone. The emails that are "sent" go out into the world and one day they might come back with the information you need and you can carry on. In the meantime what do we do? Go to meetings and collect new "to do" actions, plus we reply to whatever is in our inbox. This creates more threads and open items. Everyone else you're working with is doing the same thing and before long the organisation is multi-tasking and task switching adding more and more tasks that get slower and sometimes don't finish at all.

To combat this, discipline is needed. One way to achieve this is to periodically meet as a work group (daily or weekly depending on the group) and identify the top 3 things that matter for the common period and work together on those first every day until they're done. Not 10 things but 3 things.

Work through those 3 things and (here's the important bit), do not start anything new unless you've finished what you can on those 3 things.

You can always create a "queue" to have agreed items next in line once you have spare capacity to "pull" new work onto your schedule.

If you force a limit on the number of items in progress at any one time, the ones in progress move faster and the overall speed of the team improves.

I've found a useful online tool for organising projects and limiting work in progress for this purpose is Kanbanery.


6. Document the process

By writing down your process you have a point from which to measure and optimise it. In fact I would argue that the main purpose of documenting a process is so that you can change it in the future.

The process of documentation (whether it be in words or diagrams) exposes the process to the eyes of the team. You can start to see opportunities to optimise it. Do we really need to do that bit? If we bypassed step 4 would it speed up the process? How many people are involved and could we reduce that? (See point 10).

Go back to the process on a regular basis and ask, "how can we make this process better for our customers?"

Once a team understand that a process is there to be changed and not to be blindly followed without critiquing, it can be very empowering.


7. Measure the flow

How long does it take for a task to go from initiation to completion? Measuring the speed of work but also the variance of work demand is essential to speed up and smooth out the flow. And speeding up and smoothing out the flow (see point 9) leads to better value for all involved.

An example for an HR team; from job requisition approved to offer made, what is our average lead-in time? (And following on from that, what causes the delay in the process and how do we improve that without reducing quality of hires?). If you can measure the flow you can improve it. So go figure out how to measure.


8. Design processes starting with the customer

In any system, there is some kind of end result. Software shipped. Employee hired. Customer enquiry answered. Expenses paid.

When designing processes start with the end customer (either internal or external customer) and figure who sits directly before them in the process. Then who sits before them. And so on. The end customer is "downstream" and the initiator of the process is "upstream".

The process needs to be designed so that the downstream people get what they need when they need it. Then work backwards. This is known as a "pull system". A true pull system provides the quickest path to providing value for the customer.

So many organisations and teams work the other way around. They push things through and you end up with bottlenecks, delays and stress.

This a really tricky principle to pull off well and it requires the buy in of decision makers involved to make it happen. I can't claim to have mastered this myself in all areas of my work. I have however seen it work very well in software development teams that I've managed.


9. Level the flow

What does levelling the flow mean?

In software it means a steady stream of (pulled) productive work without overloading the team with spikes of (pushed) deadlines.

In contact centres it means predicting inbound consumer demand and matching staffing schedules to meet those predicted demands rather than being quite on slow days/hours and overwhelmed on busy days.

Sometimes you'll pull ahead of demand, sometime you'll catch up but all the while your people are steadily adding value in a productive way.


10. Reduce the number of people involved in a task

If a task has 2 people involved and 4 steps it will much faster than if there are 4 people and 4 steps.

If a task has 2 people involved and 4 steps it will be faster than if there are 2 people and 6 steps.

Reducing the steps and the people increases speed and, as long as quality is not decreased, increases value.

Modern companies tend to evolve to create division of labour. This is very useful in fact. A lawyer is better at being a lawyer than a software developer and vice-versa. So for some tasks you need experts. But for others there is division of labour because it's easier to train one person to do one thing than train one person to do many things. Plus, you can pay less for the low value tasks.

So, a simple question to ask is, do I really need this division of labour on this task or do I just need to invest in training?

As customers we hate being passed from one person to another. So as business owners we need to do that only when needed and create multi-talented well trained team.



Recommended reading

The Toyota Way by Jeffery Liker
The Power of Less by Leo Babauta
Kanban by David Anderson
Switch by Chip & Dan Heath

If You Knew You Couldn't Fail, What Would You Do?

Have you ever seen a baby learning to walk?  Of course you have.  Now, tell me how they do it.

I'm lucky to have four kids.  I didn't teach them to walk.  They didn't teach each other.  They just got up and had a go.  First of all they started to figure out how to pull themselves up to stand against the furniture.  Then they made one or two steps.  A few weeks later and they were walking.


We all first learnt by trial and error.  


Later in childhood, we start to learn from others.  We are taught.  We go to school.  It's quite amazing to have my eldest daughter read a book to me.  She's six.  6 months ago she couldn't read.


We are taught.


There's a third phase.  Once we know how things work, we can go figure things out for ourselves.  Some kids spend hours playing tennis, some spend hours programming, others spend hours and hours making things.  Some of these kids will become the best in the world at what they do.  Literally the best in the world.  In this phase we practice.  We seek guidance, we practice some more.  We put hours and hours in.  We make mistakes and learn from them.  We practice some more.


We are self-taught and we practice.


But then - we become adults.  Some people continue with trial and error (It's called 'learning on the job' in the business world.  Some are taught (it's called 'training' in the business world).  Some practice, work long hard hours, push themselves and become the best in the world at what they do.  I'm not sure what we call these people, but I admire them.


I am more thirsty for knowledge now than I have ever been in my life.  The more I learn the more I realise there is to learn.  And I want to be the best in the world at what I do.  Why?  It's simple.  There's very little in life that beats the feeling that you get when you say 'today I did what I do best!'


Today I will do what I do best.  Will you?


Imagine a team where every person can say that.  Can you imagine what that team would be able to achieve?  It would be extraordinary.  World beating.  In fact just writing this makes my hairs stand on end - it really is something special.  It's like watching the Oxford Cambridge Boat Race and seeing the winners win.  It's awesome.  


The thing about great teams is, 1 plus 1 equals 3.  The sum of the parts is greater than the whole.  Only it's not guaranteed.  Sometimes two egotistical geniuses equal less than two because they haven't figured how to collaborate well.


So - on a practical note then, how do we build great teams where every person does what they do best and on top of that build a winning team?  


How do we make that team possible?


Here, I think are the 5 main ingredients;


1. Allow people to make mistakes.  


If we make more mistakes, we learn more.  I'm not saying that we should aim to fail.  Rather we should always be 'doing'.  Doing something means you have the opportunity to learn.  If you don't do anything you won't make any mistakes, but then again you won't learn anything.  This is the thinking behind the phrase 'fail faster'.  It's not that you should aim to fail - instead, you should 'do more faster' - because that's how you'll learn.


Fear holds us back though.  We are afraid to make mistakes in case it's not seen as successful by our peers and egos.


My wife and I were talking the other day about why she is successful at what she does.  She does business development for a recruitment firm and she needs to figure out how to book meetings with HR Managers and then persuade them to use her firm's services.  She said that you can't book meetings without making phone calls, so she has to be very persistent to keep calling until she gets the meeting.  She will keep calling way long after other people have given up.  Most people fear the rejection, whereas she doesn't.  


Her motto is "if you knew you wouldn't fail, what would you do?"  Great advice indeed.


So - as a manager, I will always say to my team, 'make decisions and do stuff.  Better to do lots and be right 95% of the time than to do a little and be right 100% of the time'.  You'll learn faster and so will I.




2. Trust your colleagues and help them to learn from their mistakes


You can only truly build a successful team if there is true openness.   I need to be open with my intentions, emotions and reasoning.  By doing so, my colleagues can help me identify what I'm doing well and what I can do better and I will learn faster.  If I do this though I am opening myself up.  I am doing exactly the opposite of what most people do in business.  It needs mutual trust, respect and willing - and it needs to start at the top.




3. Design learning structures


A great example of this is how we used to run our software development cycles in one of my previous companies.  We planned our work in two week cycles.  This was pretty effective in terms of getting things done.  The important ingredient I think that actually made it successful was that after every cycle ('sprint') we set up a 'retrospective meeting'.  This was a simple meeting where we simply asked, 'what went well, what didn't go so well and how will we in future do more of the good stuff and less of the bad stuff?'  Doing this systematically requires a regular meeting slot in the diary, an agenda and a habit.  It requires structure.


Good teams consciously create these structures to become learning teams.




4. Hire people that can handle this culture


This is critical.  If you believe that you want to build world class winning teams you need to hire accordingly.  Sure you need talent and experience.  I say they're over-rated.


Just because someone has knowledge and ingredients to make a great cake it doesn't mean that they will.  And just because someone was motivated to bake great cakes in the past doesn't mean that they will do so again in a different kitchen.


What really matters is
- does this person know how to apply themselves to a challenge?
- is this person willing to open themselves up and be fully transparent with their emotions, reasoning and intentions?
- are they able to give feedback to others in a helpful way?
- are they thirsty to be the best in the world at something?  




5. Go with the flow


You cannot tell people what motivates them.  In my experience, people do best what they are interested in, not necessarily what they are good at.  I might be quite good at filing and organising paperwork, it doesn't mean I'm interested in it.  Give me a reason to be interested in it or find me something to do that I am interested in and I will do it well.  Really well.


So - as people develop in your team, find opportunities for them and help them where possible to grow in your organisation to do what they do best.   Build the team around the capabilities you have and seek out new team members to fill the gaps if they exist (and make sure you follow the points in point 4).


To conclude


Great parent allow their children to make mistakes, they teach them all they can, and they give them wings to fly and pursue their own dreams.  


In a team, we must think of ourselves as parents of each other.


And every day, if we strive to be the best we can be in what we do we'll need to push ourselves to the limit and make a few mistakes. It's the mistakes that lead us to truth.


Benjamin Franklin once wrote, 


'Perhaps the history of the errors of mankind, all things considered, is more valuable and interesting than that of their discoveries.  Truth is uniform and narrow; it does not seem to require so much an active energy, as a passive aptitude of soul in order to encounter it. But error is endlessly diversified'


Fail faster. Act like a child and a parent at the same time. Be the best in the world at something every day.

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

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