Kanban – a success story and a humbling experience

November 27, 2011

A success story

In 2008, I became manager of an outsourced team that did all the support, configuration and development on SAP, intranet and extranet applications for a packaging materials manufacturing company in Brazil (subsidiary of a British company), with sales around 1 billion USD/year.

My team varied in size responding to demand, but it typically contained between 18 and 25 people (on average, we tallied 3200 person-hours/month during 2009), and one typical configuration would be 5 MM analysts, 3 SD analysts, 1 FI/CO analyst, 4 ABAP programmers, 3 .Net programmers, 1 Basis consultant, 3 specialists on specific applications (HR/Payroll, MES and international commerce) and myself. The team was responsible for both support and changes – during 2009, the average was 1400 person-hours/month on support and 1800 person-hours/month on changes.

The client had a small internal IT team, that did the liaison between the internal clients and the outsourced team, did quality assurance on the outsourcing company’s work, and kept the knowledge in house to minimize vendor lock-in. The outsourced team did have direct access to the end users, but the internal analysts should always be involved on the conversations and in the decision-making process.

When the SAP ERP (v. 4.6) was implemented on 2005, new IT governance procedures were put in place. Nothing could be deployed to the production environment without a documented change request, and the CRs became the standard unit for conversation with the internal clients, deployment, work order for the team, tracking and reporting. A CR was meant to be a “minimal marketable feature” or “business value increment”, a unit that should be deployed as a whole to add value to the user. It could involve more than one system, such as the e-procurement system, the middleware (SAP PI) and SAP. The median size of a CR was 40 engineering hours, and the size distribution is given by the chart below.

Each internal analyst was responsible for one business process (order to cash, procure to pay, finance, HR, manufacturing), and each had a monthly meeting with their internal clients – the procure to pay analyst would meet with the procurement director, the logistics director, the subordinates they indicated according to the hot topics of the month, and occasionally other directors that would be affected by the CRs being discussed. A typical meeting dynamics would be:

  • Review a long backlog of CRs (several dozen), several of which would already have initial effort estimation.
  • Analyze the current workload of the SAP analyst of the specific module, and prioritize enough CRs to fill in the available time for those analysts in the following month. For instance, if there were 3 MM analysts in the team (corresponding to 12 person-weeks until the next meeting), and the CRs they were currently working on would take 4 more person-weeks, the directors would select CRs summing up slightly more than 8 man-weeks of estimated effort (usually between 8 and 16).

For each new CR, the first thing the analyst (SAP analyst and/or one of the satellite application analysts) would have to do was a scope statement document. It was usually a one to five page document describing in general terms what would be done, the business rules, and the detailed effort estimate. The configuration/development could only begin when the internal analyst (and, for a few critical months, the CIO himself) approved the scope statement. That was done for a few reasons: it surfaced misunderstandings before spending too much money, it gave the IT department an estimate on how much that change was going to cost, so they could challenge the business about the expected benefits if it smelled of waste, and, last but not least, to try to avoid doing unnecessary work. When working with SAP, the mindset is that you only do software development when there’s no reasonable way to do what you need without using code. Ideally, everything should be done using the standard SAP transactions and configuration (that’s why the programmers were less than one third of the team). When writing the scope document, the SAP analyst would validate if the need could be fulfilled without ABAP code, and, otherwise, identify which gaps needed custom code.

Our team had a software in which we tracked the engineering time and the progress on each CR or support ticket, so we had very precise historical data and had managed to calibrate our estimates so that every month our estimated X actual effort would fall between -5% and +10%, without requiring sophisticated and time consuming estimation techniques (we had become what Doug Hubbard refers to as “calibrated experts”).


Sometime in the first semester of 2009, in the Scrum Yahoo! Group (in which I was basically trolling around since I could see no possible fit whatsoever between Scrum and my context with highly specialized resources, multiple customers, and continuous one-click deployment), I read some posts about this new method called Kanban, which pointed to introductory papers and the kanbandev group. That made sense to me and it sounded like it could work in my context, so around July I called my team to a quick stand-up meeting (we were all co-located in an open office) where I explained the basics of Kanban and proposed we mapped our process and WIP on a board and started visualizing it to see what it would tell us. The investment was near 0 (two flipchart paper sheets, some post-it notes, and a couple of hours to setup an account on AgileZen and configure our process), and, at least, we would improve our visualization of our work, so everybody agreed that it wouldn’t hurt.

At first, the columns in our board were:

  •   Estimating: an analyst was doing the scope statement
  •   Estimated: the scope statement was done and waiting for approval
  •   Specification/Configuration: the analyst was configuring SAP or writing a specification document of an ABAP development
  •   ABAP development
  •   Internal test: the analyst is validating the ABAP + configuration on the DEV environment
  •   Validation: the user is validating the CR on the QA environment
  •   Done: the CR is deployed in production

We used different colors to represent the different internal analysts, and we didn’t have classes of service (that concept wasn’t even well-established on the Kanban literature on those pre-book days).
In my experience, I knew this wasn’t the best description we could do of our process, but that was the way the SAP analysts thought the process might be, so that’s how they described it – we specify, they develop, we validate.

We haven’t explicitly described our policies, but everybody seemed to agree on what each column meant, and how things should flow on the board. Very soon, several things started to emerge, even before we thought about limiting WIP or doing any other significant change:

  •  Several items were on the “Estimated” and “Validation” states
  •  Several items were on the “Specification” state, but, when I asked the analyst, she would say the spec was done, but she was waiting for a specific programmer to be free (with luck they would accept any programmer, but they tended to have their favorites).
  • Several items were on the “ABAP development” state, but, when asked, the programmer would say he was done, but the analyst wasn’t available to test it.
  • The items circulated a lot between “Specification”, “ABAP development” and “Internal test”
  • Several items were in a state such as “Specification”, but no one would be working on them because they need something like an answer from the client, or something from the infrastructure team.

Based on these observations, I proposed the team to redesign our board, replacing the columns “Specification”, “ABAP development” and “Internal test” with “In progress” and “In progress – ABAP”, meaning, respectively, that the thing was being worked on by an analyst without any ABAP programmer, and that the item was being worked on by an ABAP programmer, possibly with some analyst. Whenever an analyst was blocked on an item “In Progess” because she needed an ABAP programmer, she would signal it with a green magnet (which we represented as a “done” marker in AgileZen), and the first ABAP programmer that became free would check for these green signs and pair with the analyst. They would typically pair for some hours, in which the analyst would explain the spec and do some pair programming until the main skeleton of the program was ready, and then the ABAP developer would continue working alone filling in the details of the code. When the programmer was done or needed the analyst for some clarification, he would try to have her immediate help. If she didn’t happen to be available, he would mark the item with a green magnet on the board. When the analyst considered the item to be ready for user acceptance, she would request the development/configuration to be transported to the QA environment, and then move the item to the “Validation” state.

We also decided to mark any item that was depending on someone external to the team -except on the states “Estimated” and “Validation”, which were, by definition, responsibility of someone else – as blocked, signaled with a red magnet on the board, and with a “blocked” mark on AgileZen.
We showed our board to the client’s IT team, which not only loved the new level of visibility it gave them, but rushed to approve the “Estimated” items.

After one month, we had delivered 18 CRs, but our WIP had gone from 43 CRs to 60! In other words, 35 CRs had entered the system, but only half of them had flowed through. I considered we had enough information to take the next step, and I scheduled a meeting with the CIO for 9/11/2009.

Since it was a manufacturing company, I knew I could count on a general knowledge of Lean (the Lean manufacturing guys had even a Lean office initiative, but being myopic to all things not manufacturing, they had concluded that the only Lean tool that was applicable to the office was 5S), so I would base my rhetoric on this, but I needed some high impact data to show the problem on a deep emotional level.

Fortunately, I had several months worth of valuable data, and I come up with the metric which I considered would be closest to the CIOs heart – the price he paid (represented by the number of person-hours worked on CRs) versus the value he got (represented by the number of men-hours worked on CRs that actually got deployed on production). To avoid any misinterpretation I decided to present both the estimated ideal hours and the actual worked hours, to underline that it was not a matter of poor estimation, but of poor process efficiency. The actual graph I presented was this:

where the blue line is the number of person-hours worked on each month, the pink line is the sum of the estimated person-hours of the CRs that got deployed on the specific month, and the yellow line was the sum of the actual person-hours spent on the same CRs. The outliers in April and May correspond to a project in which several CRs were deployed en masse, and are related to the peak of hours spend in March. That anomaly aside, every other month had efficiencies below 40%!

Then I moved on to explain the causes:

  • Worked being pushed in big batched regardless of the WIP

  • Items waiting too much time on validation
  • Several blocked items

And then I proposed the solution: Limit WIP (we decided to do it at a system-level – CONWIP), Start pulling work instead of pushing and Attack the validation bottleneck. The validation bottleneck was a especially sensitive point, because, up to that point, the mindset both on the outsourced team and on the internal IT team was that, if a CR was deployed to the QA environment, the IT job was done, and now it was someone else’s responsibility. So much that, that they hardly ever mentioned those CRs on the monthly meetings with the business. Hence, I had to recommend explicitly that validation should be a joint responsibility among all the parties (team, IT and business), if we wanted to improve the efficiency.

The CIO gave me permission to present a somewhat edited version of the presentation to some key internal clients, such as the logistics, sales and procurement directors (all of which had Lean knowledge, two were Six Sigma green belts and one was a black belt). They got it right away, and were sincerely surprised by some of the data presented. They all bought in the validation taskforce, and the change on the queue replenishment policy on the monthly meetings.

Then a curious thing happened. As per my conversations with the clients, I started following up with all the requesting users (their subordinates) on the validation of all the CRs on the “Validation” state. As it turned out, more than half of the CRs hadn’t been validated so far because either the user had not been communicated that the CR was ready, or didn’t receive a basic explanation on the solution so he could validate it, or even the QA environment lacked some pre-requisite, such as enough test data, or the user didn’t have enough access. It became clear that, since the team considered its work done as soon as the technical solution was deployed onto the QA environment, but the user could not validate the solution unless he was properly communicated and all the pre-requisites were done, there was a limbo on our process, that hadn’t even surfaced up to that moment. We then defined the explicit policy that an item should be moved to “Validation” only when, if the user were available to validate it, he would be able to do it immediately. If, at any later moment, that condition ceased to be true (for instance, the QA environment went down), the item should be marked as blocked.

The following weeks saw the team, the internal IT and the users rushing to validate CRs, and the results were dramatic. Whereas we had delivered 20 CRs the month before, we delivered 33 CRs between 9/11 and 10/11, without increasing the WIP, as shown by the CFDs below (the second one is WIP-only).

After the first month, we decided there were additional measures we could implement, to improve our flow:

  • Using Little’s law, we predicted that, if we could keep our throughput and WIP at September’s level, we would reduce the average lead time from 11 weeks to 6 weeks. On the other hand, we knew that September’s throughput was somewhat artificially high, since we had started with many quick wins on the “Validation” state. So to keep our lead times low even with a slightly lower throughput, we decided to gradually reduce our WIP to 45 until the end of the year.
  • Using the Lean manufacturing body of knowledge, we knew that we needed to keep the bottleneck at our most expensive and most inelastic resource (i.e. most difficult to add extra capacity). That would be the SAP analyst. We, the contractor, had a pool of ABAP programmers so we could add an additional programmer with 1-week lead time, and for periods as short as 3 weeks. The SAP analysts, on the other hand, took on average 3 weeks to start (we usually had to bring them from other cities or hire new analysts), and had a much slower learning curve until they understood all the specific configurations of the client’s SAP, so they usually stayed for at least 3 months to pay it back. Until then, every addition to the team needed to be requested by the internal IT analyst and validated by the CIO, and was based purely on feeling, or on the imperfect scheduling mechanism on the monthly business meeting. The CIO decided to change that policy, and I was given permission to add as many programmers to the team as needed to avoid them to become a bottleneck, as long as I communicated it to him, and removed the programmer as soon as possible.
  • Additionally, since we implemented the policy of using the first ABAP programmer available, and we had a fluctuating population of temporary and sometimes inexperienced programmers, I was given permission to use the most experienced programmer on the team as a wildcard. He wouldn’t be allocated to any specific CR, but he would promiscuously pair with all the other programmers, help the analysts on estimates, and do peer reviews.

For the remainder of the year, we operated under these new policies, and we managed to sustain a much steadier flow, dramatically increase efficiency, and reduce WIP, as the charts below show.

A humbling experience

Then, at December 2009, I’ve received a job offer. The company was a consumer packaged goods company in Brazil (subsidiary of a French company), with around 1 billion USD/year of sales. They had implemented SAP 4.6 four years previously, and had several satellite systems. The new CIO had just arrived, and he had diagnosed that there were issues on the delivery process, and that a new professional should be hired, with the title of PMO manager, but whose scope of work would be not only related to projects, but to the IT processes and delivery in general. The core IT team consisted, besides the infrastructure team, of 5 SAP analysts (MM/WM, FI/CO and SD), 2 ABAP programmers, 4 satellite system analysts, and contractors that were hired either for turnkey projects or as time-and-material additional staff.

Armed with all the self-confidence the previous semester had given me, and the apparently almost perfect similarities of both contexts, I thought to myself: “Piece of cake”! A couple of interviews and the recommendation of my previous client’s CIO later, and the job was mine. In the first few weeks, I’ve lectured my boss and peer IT managers on pull systems, cost of delay and WIP limits, and how all our problems could be solved as quickly as in one semester using the magic of Kanban. At this point, I already had an earlier beta version of David’s book, and I used the Microsoft XIT case as the core of my sales pitch.

Here I am, 22 months later, and a good deal wiser, but without having anything closer to the spectacular results I’ve seen on my previous Kanban implementation. While in the other implementation we very quickly managed to reach all the 5 levels of a Kanban implementation, namely:
1. Visualize the work
2. Limit WIP
3. Manage the flow
4. Make your policies explicit
5. Improve your process using models & flow theory

now we’re still struggling on level 1.

Very naturally, despite of all our knowledge of Deming, my initial reaction was blaming the people, which in this case, was no other than myself. Of course, I was a fraud, and my initial success could only be attributed to pure luck. Luckily enough, I know better than that, and, even more luckily, not having experienced how much better we could have become, my company still considered that I’m doing a reasonably good job, so I still could do a deeper analysis of the situation instead of spend my time looking for a new position.

Looking carefully, the apparent similarity of the contexts is only skin-deep. I’ve managed to identify several relevant differences, some of them I already know how to treat, others I’m still on the process of discovering. Anyway, I think exposing these roadblocks may be valuable for other teams trying to start a Kanban implementation.

1 – IT governance

In my first implementation (from now on referred to as company A), the concept of change request was well established, the route and policy of CR submission was known and accepted by the internal customers, and this policy was enforced on the contract with the team (which was actually a legal contract between two companies, not only a implicit contract between two different departments in a single company). In my current company (company B), there’s no standard procedure for requests to come to the IT department, prioritization is achieved often via political escalation, and sometimes using shortcuts based on personal informal relationships with members of the team (under the radar).
While company A was mostly a manufacturing and logistics company, that served few big customers, and had few departments, mostly headed by engineers preoccupied with operational excellence, company B has 4 independent divisions, is focused on marketing, and see operations and processes as a nuisance, and a necessary evil between what’s really valued – innovation and marketing – and the actual delivery of products to consumers. So it’s very common for requests to come at a very late time with comments like “I didn’t realize IT should be involved in the implementation of the new sales channel of having the products parachuted to the consumer’s house anytime she mentions the product name on twitter; now we have already promised the president it will be operational next week”.

2 – Batch size

While the item size in company A was very consistent and reasonably small, in company B the dynamics of the system creates two attractors for items sizes – either big projects or very small requests that can fly under the radar. There are several factors that contribute to this:

  • The satellite system team doesn’t do any internal development, and, except for one application (SFA), doesn’t have an outsourcing contract designed for small batches. The consequence is that the demand is batched on chunks big enough to be contracted as a turnkey project.
  • The SFA vendor, even though they pay lip service to being using Scrum and/or Kanban in most of their teams, has proved to be unable to manage small batch flow. We have done 97 CRs with them in the last 12 months, we’ve planned to deliver them in 7 releases (named wave 1 to 7), that should have been delivered one a month during 7 months. They delivered waves 1, 2 and 3 on month 6 and waves 4, 5, 6 and 7 on month 12. Although I insisted that they reported to us weekly the status of each CR on their workflow, on every single report all the CRs of the same wave were in the same state. We have been trying to push them to adopt a steady flow, limited WIP process, and we’ve recommended that they contact one of the very good Kanban consultants we have in Brazil, but that’s the limit of what we can do with our current contract and leverage.
  • There are several group initiatives led by our competence center in France, such as SAP version upgrade, BI platform replacement, segregation of duties implementation, etc. They have to roll-out these programs to all 19 platforms using mixed teams, with central and local resources. It would be practically unmanageable to do that without planning each individual roll-out as a big project, and limiting the number of simultaneous projects at group-level, which constrains even more the scheduling for each subsidiary. We could still do Kanban in the project, instead of at the portfolio level, but besides the fact that our problem is not on the project level (at least on the last two years we’ve got a good success ratio on this level, that’s one of the reasons I’m still employed) – the big improvements would be on the portfolio level -, many of these projects are not good fits for Kanban (many dependent tasks on a long critical path, instead of several independent items going through short workflows).
  • Our purchasing department and our IT department have lots of experience on hiring time-and-material or turnkey projects, but little maturity on hiring outsourcing, small-batch, SLA-based contracts.
  • Small batches would be classified as operational expenses, whereas big projects are classified as capital expenses. While opex is strictly controlled by the CFO at country and group level, capex is loosely controlled by the CFO, and the CIO, both at country and group level has much more autonomy.
  • While the availability of key users to validate small changes is very hard to get, big projects may afford hiring temporary replacements and getting full-time availability of key users.
  • Since the prioritization is mostly based on political capital, big projects have the upper hand on reaching the ears and hearts of the executive committee.

All of that combine to a scheduling mechanism where the big projects are prioritized, and only some slots are reserved for treating medium-sized change requests, and even these slots often get eaten up as buffer by large projects. After starving for a long time, their cost of delay starts to kick in, and they rise enough on the food chain, to the point where someone on the executive committee change it to an expedite request, which leads us to the next issue.

3 – Too many urgent requests

Besides the medium-sized items that starved so long that they become urgent, and the demand that’s hidden from TI until it’s too late, there’s a special cause of expedite requests – fixed date legal requirements. People outside Brazil (or maybe India) wouldn’t see it as such a big deal, but here we have 27 states, and each two of them have different tax rules for each category of product, and they change them several times during the fiscal year. To make matters worse, Brazilian government implemented a really cool integrated system in which no truck can leave your company’s door without you sending an XML file to them with all the logistic and invoice information of the load, and getting back the approval XML from them, so, when rules change, either you implement it on the date, or you cannot deliver anything to your customers.

Of course, this is nothing particular to company A or company B, but, when you have IT governance issues, and the tax and legal departments get used to having their requests expedited, they tend not to be especially pressed to give IT the longer notice possible on upcoming legal changes. On company A, this was solved having a dedicated IT analyst working full-time with the tax department on anticipating the demand, and managing the analysis and prioritization of the resulting CRs.

What to do about it

When I was hired, the CIO had already started an internal development, on Microsoft Sharepoint, to start registering the change requests. While I’d prefer to start our board on a simpler and more malleable way until our process got stable, since I considered the contexts similar enough to think I already knew the final answer, and the fact we had been suffering from having the CRs on individual Excel spreadsheets on company A, I thought it would do no harm to have the Kanban board implemented on this tool (other than the physical board). So now, in order to put an item on the board, there are several fields that must be filled in and approved. While I do think we’d reach this point with additional maturity, in hindsight I’d strongly advise against doing it at the outset. Following the TPS advice on autonomation, keep it as simple as possible in the beginning, and automate when your practices become more stable.

Anyway, this isn’t a mortal sin, and we’ll probably relax just a bit the required fields to motivate people to keep the system up-to-date, and make the most of the board we already have.

The main action to be taken now is to work on the IT governance. It’s clear to me now that some level of IT governance is a pre-requisite to a successful Kanban implementation. Given this minimum level, Kanban can improve it dramatically, as my experience in company A, as well as the Microsoft XIT and Corbis cases on David’s book show; without the minimum level, however, the system just seems not to be on the basin of attraction of even a local optimum.

Investing on improving the process on the SFA contractor, and investing on SLA-based contracts with other vendors a definitely a way to go.

Regarding the under-the-radar items, we’ve changed the deployment procedure and nothing can be deployed to the production environment without my approval or with the approval of one of my peer managers, and one of the criteria for approval is to have a CR created on our system. There are still some items that are being created at the very last moment, only after the deployment is denied, but that’s the first step on making everything visible on the board.

Big projects and limited space broke our collocation, but we’re trying hard to have at least the core team back together, and have meaningful stand-up meetings, which would further reduce the under-the-radar cases and guarantee that the board is up-to-date.

Regarding the inherent differences in batch sizes, it isn’t yet 100% clear what to do. One idea is to create different classes of service and try to reserve and defend some capacity for the normal, medium-sized, accelerating cost-of-delay CRs. We’ll probably experiment a lot around this as soon as we remove the other major roadblocks out of the way.

There is a plan to have advanced posts on the divisions and the tax department to try to identify the demand before its cost of delay runs out of control, and try to better shape the demand.


  • No two contexts are equal. Trying to apply the exact solution in two different places is a recipe for disaster.
  • There seem to be some pre-requisites for successful Kanban implementations. The Kanban dynamics may have good local optima attractors with big basins of attraction (hence the motto “Start with whatever you currently have”), but there are initial conditions outside these basins of attraction.
  •  IT governance seems to be an important pre-requisite, at least for portfolio-level, whole IT implementations. There may be related findings for smaller scope implementations (project governance for project-level implementations, and so on).
  • Too many expedite items is always a smell. Look for a root cause.
  • Culture isn’t an act of God, nor should be blamed as a whole. Look for the specific things in the context that do impact you, understand the driving forces in the environment that create and feed the undesirable thing, and analyze how these forces can be changed or at least worked around.

The gods and the styles of management

February 6, 2010

According to the Greco-Roman mythology, the Olympic dynasty had two great rulers – Zeus/Jupiter, and his father Cronus/Saturn. The myths around those sovereigns have a great deal to tell about the two kinds of management I will from now on refer to as Jovian and Saturnine.

First let’s take a look at Saturn. The most intriguing thing about this god is how Greeks and Romans regard his reign under very different lights. For the Greeks, Cronus was an abominable god whose main feature was his taste for newborn sons. It was a god that was scared to death of losing his kingdom to one of his sons, so he ate them to avoid being dethroned. But he was eventually cheated by his wife into eating a stone instead of his son Zeus, who succeeded in finally overthrowing him as the god’s supreme ruler. For the Romans, on the other hand, Saturn’s reign was the Golden Age, in which people had no need for judgments or punishments, since everyone just did the right thing.

Zeus/Jupiter, on the other hand, was equally adored on both Greece and Rome – comme il faut, since he was the current supreme god. His leadership style was completely different from his father’s – he was an autocratic leader, and had no scruples on throwing his dreaded thunderbolts on whoever dared to challenge his orders. Jupiter cult is a cult of personality, he’s a god that demands personal obedience and reverence (in that, he resembles his colleague YHWH). The Olympic kingdom was kept in order by his supreme wisdom and his charisma, and he liked to remind everyone of that.

From this short overview, one can already understand what are the main features of Jovian and Saturnine managers.

Saturnine management understands that the supreme ruler shall be no man (or god, for that matter), but the law. Every one should be subject to the law, including the one that happens to be the manager. This kind of leadership is completely averse to ad hoc decisions, should they happen, they should be framed as soon as possible in a general law, that should apply to all subsequent cases and even retroactively to the initial one. On the other hand, it’s a control freak – every single thing should behave as the general rules prescribe, everything should be in order. It’s associated with the element Earth, with defined processes, with checks and balances, with quality assurance, auditing and a non-relativist moral and ethics.

Jovian management, on the other hand, understands that people are more well-equipped to deal with the uncertainties of real life than some cold and immutable law, that, for him, only applies to some ideal – as much as non-existent – world. Moreover, to be able to rule effectively, the leader must have power, wisdom and charisma. There’s no black-and-white right, a willful and strong leader can make things right, unless he’s pointing to a really doomed direction. It’s associated with the elements Fire and Air, with charismatic, autocratic and strong leaders, with trail-blazing and strategic thinking.

Besides the fact that myths are built over the deep archetypes of human psyche, there’s a more direct link, confirmed by the research of the Gauquelins – people born with the planet Jupiter close to the horizon or the mid-heaven are natural born Jovian leaders – the most striking example is the Sun-king Louis XIV himself; while the people born with the planet Saturn in the same positions are naturally inclined to the exact sciences, to subjecting the real world to the universal laws of physics and mathematics.

Saturnine types (such as myself) usually look down at Jovian types and vice-versa, but the fact is that they’re complimentary and both are needed to any enterprise’s or project’s success. For instance, it’s commonly acknowledged among astrologers that a trine (a positive aspect, in which the energies of two planets are naturally and harmonically combined in a person) between Jupiter and Saturn is a very good indicator of business success.

Maybe it’s time for Zeus to call his old dad from Tartarus and usher him in as his co-ruler.

The four elements and the five dysfunctions of a team

September 19, 2009

Continuing the series about the four elements, let’s examine Patrick Lencioni’s Five Dysfunctions of a Team and how his model relates to the elements.

According to Lencioni, the five dysfunctions of a team are, in order,

1. Absence of  TRUST

2. Fear of CONFLICT


4. Avoidance of ACCOUNTABILITY

5. Inattention to RESULTS

Each dysfunction leads naturally to the following one. When the team members don’t trust each other, they cannot expose themselves and their true feelings and ideas, so they will naturally avoid engaging fully on the discussion, fearing to let an open flank. Since they feel they didn’t have really had their views taken into consideration, they are not really bought in, and they fail to commit. Since they’re not committed, they can’t be made accountable (it wasn’t my idea to begin with). When people are not committed nor accountable, they are more preoccupied with their own status or individual objectives,  instead of with the team’s results.

Let’s try to understand how this model relates to the four elements.

The last dysfunction is related to the fire X earth dichotomy. Objective results are earth’s domain, whilst personal status is fiery by nature. So, at the end of the day, we’re trying to achieve earth. But, as the second dysfunction tells us, we won’t get to earth if we avoid using fire, in the form of conflict, to melt the ingredients of the team’s alchemy. But fire is way too dangerous to be let free. If fire is in the air, people will naturally raise their defenses, and fire’s potential benefit will all be lost. How to let people comfortable to play with fire without getting burnt? The answer is that the environment should be sufficiently humid. Watery trust and safety is the base of the building.

To summarize, you should start with Water. Water then enables Fire, and Fire enables Earth. It’s interesting to notice that, in traditional terms, Water kills Fire, and Fire kills Earth. That’s another example of the old principle that the difference of venom and medicine is just the size of the dose. The sculptor’s chisel must kill the stone to transform it into a piece of art. Water must restrain Fire to channel it into constructive conflict of ideas instead of personal attacks. Fire must challenge Earth’s inertia to remove the dust and extract the gem from it.

The four elements – Open Space Technology

July 25, 2009

Continuing the series on the four elements applied to management (see the introduction here), let’s discuss a technique called Open Space Technology (OST).

Open Space Technology (http://www.openspaceworld.org/) is a meeting organization technique developed by Harison Owen. Its stated objective is to try and replicate the kind of productive and enjoyable talks people use to have in coffee breaks. The basic mechanism revolves around three steps: In the first part, all the participants are organized in a circle, and every one that sees fit stand up and propose a topic for discussion. In the second part, the different sessions are schedule, by people selecting in which of the proposed topics they’re interested, and agreeing on times and places for the meetings. In the third moment, the actual sessions are held.

It seems to have had incredibly good results so far. Harison Owen claims to have found the key to the success of his technique, namely that it’s caused by the team’s self-organization. I have a different explanation though, and it is based on the knowledge of the four elements.

First of all, although Mr. Owen is referring to self-organization in the sense that the team itself is organizing the meeting, he goes all the way to implying that this kind of self-organization is analogous to self-organization in the sense Per Bak and others talk of self-organizing criticality of dynamic systems. That is what the Jains call Sabdanaya, the error to mistake one concept for another only because they have the same name (one of the errors that the late Wittgenstein fought so hard against).

In the self-organizing systems, there’s no organizing agent, external or otherwise. Any high-level order the system may display comes entirely as an emergent product of lower-level relations. An example is the food chain in ecosystems. No living being in any ecosystem gives a damn about the food chain, they’re busy trying to keep themselves alive (usualy by taking other living beings’ lifes), the food chain and the optimizations thereof are only a by-product of each individual trying to optimize its own survival. In an OST meeting, each participant has already a high-level objective. It’s not as if the participants are only trying to get closer to the coffee break table and voilà!, they’re sitting on a circle.

But even if we assume for a moment that, by coincidence, this kind of self-organization is good for optimization (as the other kind of phenomena that happen to have the same name seem to be), I still claim that it’s not the OST’s success’s root cause.

Let’s look at Mr. Owen’s own words to try and find another clue. In his book “Open Space Technology – A User’s Guide – Third Edition”, he claims that “[f]or Open Space to work, it must focus on a real business issue that is of passionate concern of those who will be involved”. Let’s keep this statement as Lemma 1.

Let’s look for another hint on the OST’s four principles:
– Whoever comes is the right people
– Whatever happens is the only thing that could have
– Whenever it starts is the right time
– When it’s over, it’s over.
Let’s keep it as Lemma 2.

To find another piece to our jigsaw puzzle, let’s look at Chapter X – Follow-Up. In the rest of the book, the message is: OST works, and leads to excellent results. But in this chapter, he points out that, after the meeting is over, there is the challenge to make it really generate tangible products. That’s Lemma 3.

What we can conclude from all that. From Lemma 3, it becomes clear that the results that OST claims to get, and seems to actually get very efficiently are actually results in an Airy sense. OST is really focussed on Air’s goals (good ideas), so it would be unfair to expect it to generate Earth’s objectives (concrete results). But, in the same token, if you need Earthy results, don’t expect OST to be you silver bullet. You’ll still need Earth methods at some point to get down the ideas to the ground.

But what OST does prove is that, if you want Air to blow with all its strenght, you need a good amount of Fire (Lemma 1), and you need to restrain Earth to a minimum (Lemma 2). Several other people seem to have come to the same conclusion, as we can see in other techniques such as Brainstorming. That’s the core of why OST works, IMO.

The funny thing is that Mr. Owen actually came to the same conclusion, but he didn’t go all the way with it, somehow letting himself fall into the self-organization trap.

Let’s let Mr. Owen speak:

“Whole books have been written on the Medicine Wheel, its forms and uses, but for our purposes, it is sufficient to know that many Native Americans understand each individual and all groups of people to be composed of four elements. Those elements are representes by the four points of the compass, certain animal symbols, and colors.

The north is leadership, the powerful trail breaker, pointing the direction and opening the way for Spirit to growand evolve. The animal is the deer and the color is red [My note: this is Fire]. To the east is vision, the high-flying seer of all.  The animal is the eagle and the color is blue [Air]. To the south is community, the warmth of hearth and heart, which binds all people together. The animal is the mouse (as in cuddly, warm, friendly), and the color is yellow, the color of the Sun [Water].  To the west is management. It is quite doubtful that Native Americans ever used this term, but I believe (or at leat I would like to believe) that is what they had in mind. The animal is the bear in his slow, methodical, plodding mode, best seen in the berry patch as he takes care of business. Not vey exciting, but very effective when it comes to handling the details of living in the community. The color is green, as in growing things [Earth].  

The message of the Medicine Wheel is that each individual, and all communities (organizations), have these four elements. Under the best of circumstances, there will be a balance for all are necessary, but none is sufficient by itself. In practice, however, the balance is dynamic, always changing. With the passage of time and the changing of circumstances, different elements are called to the fore: now leadership, then community. But for the people to survive, the overall balance must be maintained.

The balance of elements is affected not only by external factors but also by internal dynamics. Leaders, for example, are always suspicious of folks whose concentration is on community, heart, and hearth [My note: in traditional notation, Water kills Fire]: in contemporary jargon, the warm fuzzies. After all, what do they do really?

At the same time, bears look at eagles and suggest that if they could just come down from their heights, they might understand what the business is about [Earth kills Air]. And the eagles reciprocate by admonishing the bears to get their noses out of the berry patch and maybe the would see where they are going. Each element has its part to play, but not without a certain dynamic that leads to creative tension. But the community is lost when the elements do not work together.

Note also that there is a logical sequence to the Medicine Wheel, which requires that it be circumnavigated (walked) in a clockwise direction. One begins with leadership to the north, providing the dynamism to get the show on the road. It them becomes important to ask which road and what direction. Vision supplies the answers. Once the journey is engaged, the issue is who is coming, and community offers the response. Last but not least, a certain order is necessary for the journey, which is the jod of management. If the elements are taken in the reverse order (counterclockwise, starting with management), the net effect is to create a marvelous organization without ever considering who is being organized, what direction they are going in, or by what power. This may be the way of many businesses. When organizational structure takes precedence over the job at hand, the people, and the overall purpose, it is no wonder that the level of performance is less than optimal. 

Notice that he emphasizes that it works precisely because he starts with Fire and Air, and let Earth (and even Water) for a later moment. Since, as he himself explains, Water kills Fire, and Earth kills Air, if you want Air to blow strong, keep Earth at bay for a moment. But as he himself admits (both in this explanation and in chapter X), Earth must move in at some point, and, at this point, some Airy stuff may die (which is not necessarily bad, since seemingly good ideas may prove not to stand the test of execution). The error would be to assume that (1) OST’s final products are the organization’s final products (unless the organization as a whole plays an Airy part in a bigger value chain where other players play the Earthy roles) or (2) OST’s methods are the best way to go from beginning to end if you need an Earthy final product.

I’ve found some Airy people that seem to do that leap, basically because they, as true Air-heads, downplay the relevance of Earth’s concreteness concerns, and it sometimes seems that even Mr. Owen himself seems tempted to go through that slippery path, his own praises for element balance notwithstanding.

Another remark is that, although I see the relevance of the order he proposed (Fire-Air-Water-Earth) to his purposes (generation of ideas), the traditional order is Fire-Earth-Air-Water. That’s more relevant that it seems, since each element is followed by a contrasting element, helping to bring balance. If you begin with Fire-Air, when Water and Earth kick in, there are only ashes left, whereas by following Fire with Earth than Air and Water, you get this active-passive-active-passive cadence (exhale-inhale-exhale-inhale) that help to get to the balanced center.

The four elements

July 19, 2009

The greatest flaw of management, IMO, is failing to balance the four elements. In this and the next several posts, I’m going to elaborate on some ways the imbalance of the elements can cause the failure of a project or an organization. First of all, let’s review what are the four elements, and what they symbolize.

Fire is the element associated with the drive, the will. Fire starts things, open new ways. It’s associated with courage, but also with restlessness and a tendency to let unfinished businesses behind when a new challenge arrives. Fire will tell you difficult truths on the face, it has no time for hurt feelings or social considerations. It lights the path, but whoever gets in its way will end up burned.

Earth structures and organizes things. It’s interested in what’s concrete and tangible. You’ll know the tree by its fruits, Fire’s initiative or Air’s ideas are worthless for Earth if they don’t generate concrete outputs. Without the other elements, however, Earth tends to excessive rigidity and conservativeness. Earth rules the defined processes, laws and regulations. It always plays by the book, dura lex sed lex.

Air has the ideas. It thinks outside the (earthy) box, but, without Fire’s initiative and Earth’s organization, Air tends to be content with the abstract thoughts. Why bother with the final product, if the model is so aestethically pleasing?

Water feels. While Fire will go through you, Earth won’t hesitate to punish you if  you violate the law, and Air will probably step on your toes while looking up for the clouds, Water cares for your feelings and emotional well-being.

By now, you’ve probably painted quite a few scenarios in your mind where the elements are imbalanced and what it causes. In the next several posts, I’ll try and go through some I’ve experienced myself.