WThe Vaporsith the roots of lean and arguably Agile in the Toyota Production System and Scrum first mentioned in ‘The new new product development game’ there are many Japanese terms used in Agile today.
My concern is the barrier this creates to understanding and the perceived learning ramp for those interested in Agile. In a pragmatic scrum vein I have listed the most popular Japanese terms, a replacement term in English and a brief explanation.
This post is a bit different from usual, dictionaries do not have pictures (once you’re over four at least) so this post looks sparse. I am also not going into the detail or history for each word (however interesting), only how it is relevant today for Scrum. So in alphabetical order lets begin…

  • AndonVisual Indicator – A display, siren or other indicator to communicate information and encourage immediate resolution to problems. A live build and test dashboard on a wall-mounted monitor is a good example.
  • DojoTraining Place – A coding club in which to practice exercises (Kata), often by group practice.
  • GembaWorkface – The place at which value is created, the colocated (ideally) team area in Scrum. Management visit the workplace, look around and ask questions to understand what is being done (gemba walk).
  • Genchi GenbutsyGo and See – Similar to management by walking around the principle is going to the source to find the facts, make decisions and build consensus to achieve the correct goal.
  • HanseiSelf-Reflection – Recognise and reflect upon mistakes in order to not repeat them. To objectively and critically evaluate tasks to find avenues for improvement.
  • JidokaManaged Automation – Automating processes to stop when an abnormal condition occurs allowing a developer to eliminate the root causes of an issue. Automation with a human touch has the steps detect, stop, fix immediate concern and investigate to prevent future issues. Continuous integration is an example of Jidoka enabling quality to be built-in.
  • KaizenContinuous Improvement – Change for the better with small improvements over time accumulating into big results. The retrospective in Scrum is the key point at which to identify improvements and drive the improvement cycle.
  • KanbanSignboard – Scheduling system for work based on pull. In software Kanban is a separate methodology growing in popularity at present.
  • KataExercises – Short practice sessions repeated regularly to perform standard exercises with the aim of broadening understanding and improving thinking. Frequently coding the same pattern allows different methods to be experimented with and the short feedback cycle drives improvement. See the code kata website for example coding exercises.
  • Stages of Learning:
    • ShuCopying – Beginning stage, concentrating on repeating what is being taught.
    • HaReflecting – Expanding upon basic practices by learning the underlying principles and integrating knowledge from other teachers.
    • RiExtending – Adapting and creating knowledge from your own practice and circumstances.
  • The Three Ms of Lean:
    • MudaWaste – Activities not creating value, reducing waste is a key just-in-time method to improve profitability.
    • MuraUnevenness – Unfair demands on process, machines and employees reduces overall productivity.
    • MuriOverburden – Unnecessary stress to process and employees targeted by the Agile manifesto with sustainable development at a constant pace.
  • Niko-nikoHappiness Index – A tool used to track the mood of the team. Often a calendar on which developers draw a smiley on as they leave work to indicate their average mood for the day. Note that this produces useful source data for retrospectives.
  • ObeyaWar Room – A room used by a project to display all project charts and plans, acts as a single location for the team in optimising a project. Visualisation and a shared space improves team interaction.
  • Poka-YokeMistake Proofing – Prevent mistakes from occurring or detect them quickly so that they are fixed immediately during development. Examples in software include designing dangerous features out of a language (automatic garbage collection in Java), reminding users there is no title on an e-mail before sending or highlighting invalid commands within an IDE.
  • The 5S Methodology –
    • SeiriSort – Removal of unnecessary items and removal of obstacles.
    • SeitonSystematic Arrangement – Arrange necessary items to make workflow smooth and easy.
    • SeisoShine – Keep the workplace safe and easy to work within plus use the cleaning process to also maintain required equipment.
    • SeikutsuStandardise – Create processes to reinforce good practice, maintain orderliness and organisation.
    • ShitsukiSustain – Perform training and regular audits to keep the workplace efficient.

That’s it, please send me any other Japanese terms to add to the list along with the English alternative.

Team Pyramid

Colocation, let me just start by saying colocated teams are more successful period. Far-located teams have a success rate of 60%, near-located 72% and colocated 83%. Given the increase in success rates it is surprising that still less than half of Agile teams are colocated.

I am looking in this post at the ideal for most individual teams and why we should all strive for it.

Location, Location, Locationlocation location location

As Phil and Kirstie know location is key, between team members a coach length away may as well be a coach trip away for the reduction in communication caused.

Ideally the scrum team needs to work together in a common space, all within around six meters of each other. By sitting close together you can have a quick discussion without leaving your desk or having to raise your voice.

We Need To Talk…We Need To Talk

The main reason for colocation is to make communication richer, more open and simply quicker. By maximising face-to-face communication we gain quick clarification, resolve issues faster and avoid wasted time waiting for answers to e-mails and messages.

Phone calls, video-conferencing and collaboration applications are all great but do not beat the immediacy of being able to overhear a conversation and instantly spin around your chair, jump in and help. The context and depth of interaction is also reduced when the speaker is not physically present, 60-90 percent of communication is non-verbal (gestures, posture, tone etc.).

Alistair CockburnAlistair Cockburn succinctly states “The speed of the project is the speed at which ideas move between team members”. Another term coined by Alistair Cockburn in his book Crystal Clear: A Human-Powered Methodology for Small Teams is osmotic communication where information flows in the background hearing of team members who pick up and respond to relevant points as required. This selective tuning-in and tuning-out is further explained as selective attention or the cocktail party effect.

What’s The Problem?Trolls Frozen

From cubicles creating barriers, functional groups forcing formal handovers and the lack of trust increasing valueless documentation companies seem to go out of their way to hamstring teams.

Further benefits of colocation include:

  • Cross-functionality: Integrating functional disciples within a single team reduces silo mentality and promotes cross-disciple working. In Agile we seek to encourage generalising specialists and T-shaped people.
  • Removal of travel time: Distributed teams need to travel to shared meetings and potentially find ways of working across time zones. It is quicker to organise and attend meetings when everyone is in the same place.
  • Trust: Closer working relationships develop faster when working alongside colleagues. It is easier to build trust when you can see the actions of others in response to agreed actions or commitments.
  • Improved team behaviors: Tribal behaviors develop team working and reinforce positive collaboration.
  • Co-operation: The opportunities to assist each other increase with colocation and helping each other increases trust and team working by means of a positive feedback loop.

Let’s Talk About The IssuesIssues Title

Hey, this is a pragmatic scrum blog and not everything even in ‘Pure Scrum’ is going to be perfect – sorry to break it to you now.

There are potential problems with colocation, especially initially:

  • Forming teams separates people from their functional groups (HCI, databases, test etc). Effort is required to still share knowledge across multiple teams, this is usually performed by communities of interest (or Guilds at Spotify).
  • Background noise can be distracting. Colocation in scrum leads to a raised level of conversation that the team and those surrounding them need to get used to. Note that pair programming can reduce the acclimatisation time for those involved.
  • Working on multiple projects is still common; colocation can reduce the ability to multi-task. Providing hot-desks within each team area for shared resources can alleviate this issue.

This Is How We Do ItHow do we do it?

First we talk with the stakeholders; I want project management and the full team to buy-in to colocation. We really need their support to move people within offices and ideally prepare the right environment. Gain agreement from HR, product management, finance and whoever else is required to make the changes.

As well as the usual requirements I want to see lots of whiteboard space, paint the walls with whiteboard paint or even better install long magnetic whiteboards. If you are low on wall space use wheeled whiteboards, static roll whiteboards or whatever else you can create to provide information radiators and big spaces in order to design and discuss work.

Work with facilities management to create room for the team. Try for a shared area, close desks, quiet spaces and a meeting room with a projector and tele-conference/video-conference facilities (as required).

When planning desks, aim for programmers to sit together with the testers (assuming they are still different people at this stage) to sit alongside. Sit domain experts and HCI engineers close enough for questions. The PO and PM (most Agile teams still have one) are usually located close enough to be aware of the teams work but far enough away as to not annoy the team with their constant talking on the phone.

Are we restructuring the entire company into teams with their own perfect environment – no, and even if we could this big bang approach is fragile and risky. Start small, show success and then scale incrementally, this takes time. Each team is different as each person is different, this needs to be recognised. Do not force change on people, they will leave.

Environment is easy, what about the team themselves? We are moving from individuals working separately to teams co-operating and collaborating. Work with a coach to focus on soft-skills within the team, encourage interruptions, prioritise helping others and share knowledge and skills.

PragmatismTeam Table

So can we still use a distributed team, yes of course but it will not be as productive as one that is colocated. We will need to utilise webcams, video-conferencing, co-operative tools and a willingness to travel to attempt to compensate.

It is essential to get the team to drive the colocation and work with the local powers to make it happen. Guerilla tactics, weekend desk rearrangements, booking hotel rooms for six months and re-purposing conference rooms were all great methods ten years ago but the worlds moved on. Persuade your management, pull down the cubicles and remove the barriers (physical, structural and mental) to successful teams.

And finally, in the worst possible situation remember Bas Vodde’s remark “change your company, or change your company”…

Thanks for reading and I would love to hear from you if you think of other benefits or issues involved with colocation of an Agile team.