Ameba Teams and Amoeba Management

I’m probably going to upset some people with my spelling here but as far as I can tell, there are two ways to spell the unicellular lifeforms most of use learn about in school: Amoeba and Ameba. I believe Amoeba is the more, shall we say, classical way of spelling the name but Ameba is also acceptable. I tend towards using Ameba because I’m lazy. On this occasion its useful to have two ways to spell the same word.
What, you might be asking, has all this to do with software development?

For a while now I’ve been talking about the concept of Ameba Teams. Specifically I talked about this in my Conway’s Law and Continuous Delivery presentation (SlideShare and an earlier version on recorded on Vimeo). In my model the team is a self-contained entity:

• It contains all the skills necessary for under taking its task: developers, analysts, testers, what-ever.
• Ideally the team extends all the way into the business, there is no them-and-us divide.
• The team is responsible for its output.
• The team crosses the finishing line together - developers don’t win while testers lag behind, analysts don’t win while developers struggle too keep up, they win or lose together.
• Team and management should aim to minimise - even eliminate - dependencies on other teams.
• Work flows to the team.
• Teams start small and grow as they are seen to work.
• Initially teams may start understaffed, even with key skills missing, a Minimal Viable Team (MVT).
• A team contains more than 1 person (name me a sport where team size is 1 please). That probably means a team must have at least 3 people, but applying MVT the minimum size for a team is 2. (With the anticipation that it will either grow or die.)
• The team may work on more than one product or project at one time - actually the concept of project should be avoided if possible. See #NoProjects - why projects don't make sense and #NoProjects becomes #BeyondProjects.
• Everyone aims for team stability: yes people occasionally leave and join but we aim for a stable team.
• The team can grow when there is more work and contract when there is less work. Growing takes time if it is not to undercut the teams productive capacity so needs to be done steadily over time. Shedding staff can be done quickly it is difficult to recover capability after the event.
• The teams historic past performance is used as a benchmark and to judge (velocity) how much work the team can take on and even forecast end dates.

We start small and grow to work with, not against, Conway’s Law. If you start with a larger team, with more skills and roles defined in anticipation of what the team must then the software design is set by the team designers.
Although I don’t say “Ameba” explictly this is the thinking behind teams in Xanpan - and I promise to say more about Ameba teams in ‘Xanpan Volume 2: Management Heuristics” which I’ve now started work on.
Yes there is a tension, a friction, here: I say you want a fully staffed team but I then tell you to have an MVT. Life isn’t easy! You start with an MVT and if they can produce something useful you decide what other skills they need and add them when you find the need.

I’m happy for teams to grow relatively large, say up to 15 people. Because:

• Larger teams can handle greater variability in workload and task variability and still have useful data.
• It is easier to justify full time specialists (e.g. UXD) on a larger team.
• Larger teams aren’t so susceptible to unexpected events (e.g. people leaving).
• Larger teams lose less of their capacity when they have a new person joining them.

Once a team gets to a critical mass, say 14 people, then the team - like the creature - should split in two. The two resulting teams need not be equal sizes but they should each be stand alone. Each should contain all the skill necessary to continue their work.

My thinking on team splits comes from reports of Hewlett-Packard I read a long time ago (and I’ve lost the reference). When a successful HP unit hit a particular size the company would split it in two so that each unit was manageable.
The tricky bit is finding where to split the teams. We need to respect Conway’s Law. Ideally each resulting team would have its own area of responsibility. So if a large team looks after three similar products they might split into two teams, say 5 and 9 people each with the smaller team taking responsibility for one product while the larger team retains responsibility for the other two.
What you must absolutely avoid is splitting the team so that one team now depends on the other. For example: one team is the UI team and the other the business logic. Shipping anything requires both to complete work. That means co-ordination, it means complication, it makes work for managers to do, it means expense and it means moving at the pace of the slowest team.
The ideas behind Ameba Teams have formed over the years in my mind. In fact I started using the expression several years ago. So when, nearly two years ago, I came across someone else describing Amoeba Management I was a little crestfallen. Fortunately the ideas are compatible and I’ve recently gone back and re-read the article. It therefore seems the right time to bring it to the party. (I’m sure the article has influenced my thinking since I originally read it too.)
Amoeba Management: Lessons from Japan’s Kyocera appeared in the Sloan Management Review in late 2012 - you can buy the article from Amazon too. You can find more information about it both on Wikipedia and on Kyocera’s website. And there is a book I’ve yet to read: Amoeba Management: The Dynamic Management System for Rapid Market Response.
According to the Kyocera website the objectives of Amoeba Management are:

1. “Establish a Market-Oriented Divisional Accounting System: The fundamental principle for managing a company is to maximize revenues and minimize expenses. To implement this principle throughout a company, the organization is divided into many small accounting units that can promptly respond to market changes.
2. Foster Personnel with a Sense of Management: Divide the organization into small units as necessary, and rebuild it as a unified body of discrete enterprises. Entrust the management of these units to amoeba leaders in order to foster personnel with a sense of management.
3. Realize Management by All: Realize "management by all," where all employees can combine their efforts to participate in management for the development of the company, as well as work with a sense of purpose and accomplishment.”

They look very compatible with everything in Agile to me, they look compatible with Conway’s Law and Continuous Delivery too.
Some other highlights from the MIT Sloan Management piece

• “Kyocera is structured as a collection of small, customer focused business units”
• “Each unit, generally made up of between five and 50 employees, is expected to operate independently and to develop its own ways of working with other amoebas to achieve profitable growth.”
• “Like other decentralized management systems, amoeba management is designed to spur market agility, customer service and employee empowerment.”

There is also some hints at Kyocera’s accounting systems. They use a simplified system for transparency and leave details to teams. While this is a long way from Beyond Budgeting it does suggest, like Beyond Budgeting, that sophisticated long range budgets get in the way for actual performance.
The article does point out that Amoeba Management, indeed any management approach, depends on the context. This is an important point that is often missed by Agile-folk, although one may forgive them as long as they confine their believe to software teams where there is a lot of shared context.
Rather than go on about Amoeba Management right now I’ll let you read about it yourself - although that will cost, the article and the book. Although right I promise to return to this subject in the near future.
Right now let me conclude with two thoughts.
Ameba Teams (my ideas) share a lot in common with Amoeba Management (Kyocera), my thinking has been influenced by Amoeba Management but frankly I don’t know enough about them (yet) to speak with authority so I retain the right to define Ameba Teams in my own terms.
While Agile and Lean people have been watching Toyota (the company that gave us Karōshi, death by overwork) another Japanese company has some interesting ideas we should consider.