Agile Culture and the Myths of the NO Organization

Since I joined a start-up in 2004, I have been a very active practitionner and zealot of agile culture and practices. Yet, there are a few limits to Agile that I believe Lean tackles naturally : this is why I joined the Lean movement about 4 years ago. One of the limit I have observed during the last few years is a culture trend whereby Agile community thinks they solve problems just by removing the issue : here comes the NO organization.

The NO organization aims to fight the pointless over-complicatedness of our organizations (which is good) by getting rid of the actual topics (which is arguable, at best) : no managers, no process, no paper, no specs, no estimates, no planning, no email, no what_have_you. One could argue it is throwing out the baby together with the bath water.

The NO organization exhales the seductive perfume of the radical approach. It resonates with the (often false) image of the open source community or Agile methodologies.

My 2 cents : this is just as irrelevant as the over-complicatedness it aims to fight. And here’s why …

Misconception #1 : Complicatedness = value

First we need to understand this terrible misconception that creates billions of euros of waste : complicatedness = value. The hypothesis behind it is that a) complex business context requires complicated business solutions and organizations and b) complicated solutions will give a strategic advantage to the company. Even if Sutton et Pfeiffer (The Knowing Doing Gap) or Jim Womack (Gemba Walks) hadn’t invalidated both hypothesis, spending a few weeks observing how any major organization work is enough to understand how irrelevant they are.

In his great paper (6 Smart Rules) which later became a successful TED talk, Yves Morieux noticed that while we were multiplying on average by 6 the number of key indicators to follow, the complicatedness of the organization was multiplied by 35. In any large organization today, for one person actually creating value, there is one controlling or managing it. Talk about waste.

Misconception #2 : Managers are useless

OK having in mind the terrible managers who have crossed your way and have made your working life miserable, this one is hard to believe. Yet, imagine a manager as a coach, whose main responsibility is to develop her people, to remove the obstacles preventing them from being successfull, to make sure they have a complete understanding of their contribution in the full picture of the business and to give them exciting challenges they are able to achieve. Now you have a picture of the 21st century manager. When I try to imagine what these 21st century managers should be, I always ask myself : how do the web giants do ? There is a great example with WordPress and the testimony brought by Scott Berkun. It is very challenging to scale a company even when it is the archetype of the 21st century fantasy company : completely distributed with people working remote : so WordPress had to have manager to scale up.

No manager = happiness ? Another arguable statement. A friend of mine who is a director of a 400+ IT organization told me this sad story : they have implemented Agile as their Agile office recommended : no role for the manager, one team member as a Scrum Master and the team self organizes. One of the guys of the team has been ostracized by the other four (the director believes because he was not as good developer and fast as the other). End result : the guy ended up in depression and 3 months off work. My friend told me : this would have never happened with the managers in charge as they know their team and would have seen what is happening. But they were not supposed to intervene, the had to stay away from the team.

Misconception #3 : Process are useless in creative work

Probably the hardest pill to swallow. It took me some time, I was so upset by processes myself. Yet, thinking about it, it appeared to me that what upset me the most out of processes were 3 things.

First one is that they just didn’t work. Second : it was imposed to us in a classical taylorist way by some expert process engineers who didn’t really know our work nor the daily problems we were facing. Third they were fossilised into some bloated Enterprise Software and any change to it to reflect the exact way we work would cost hundreds of thousands of dollars and would be delivered in 6 months time, fully bugged, with depressing response time and terrible usability. I have seen ladies going to cry in toilets out of frustration of their process tools as they were struggling just to get their job done.

People believing there is no process in software development has never tried to commit code into an open source project. I tried and I have learnt the hard way. The problem is not process per se, rather their governance. Now try to think about processes designed by the team itself to accommodate their main concerns, processes that can easily be updated and improved within a few minutes to make them work. It completely changes the perspective.

This is what visual management (yes : post-its and boards) and the use of standards improved on a regular basis bring to process implementation. Kanban Agile Methodology is a great example of this. The process is clear with the different steps (the columns), the work unit as well (user story or technical task depending on the granularity), and a clear shared understanding of who is doing what when and what are, at each step, the criteria of acceptance. Besides, Kanban provides process performance indicators (lead time) : it is not because it is not prescritptive that Kanban Agile Methodology does not help in creating very steady processes. It does not inherently provides means to improve it (that’s why it is not Lean), but that’s another story.

Misconception # 4 : the paper-free organization is liberating

The archetype image of the bureaucracy is a desk inundated with papers. OK, that’s dead uncool. Yet, paper (on the wall) is a fantastic channel of collaboration. Again, it took me some time to accept it.

As a former software programmer, despising politics and the great Corporate Comedy, I for long have seen more value in asynchronous communications (i.e. emails, conversations on collaborative platforms etc …) than in live direct communication (i.e. discussing with people in meatspace). I don’t pretend that all digital addicts behave like Aspergers, but I think I for sure have a tendency to do it. As The Collaborative Organization reminds us, it is very comfortable for people like me to communicate and collaborate like this.

Yet, as Agile Methodologies tends to prove, nothing surpasses live direct communication. And while people are next to each other watching the same 100% paper visual management, you can observe the magic of collaboration in knowledge work. The slight change here (which makes a huge difference) is that people are not face to face but both watching the same thing : indicators, product (see next section), process flow etc … This removes implicit, aligns understanding and allow for deep collaboration to take place. This is an unstoppable source of fascination for me and a strong argument to question the relevance of the paper-free organization.

Misconception #5 : specs are a waste of times

How to fight the problem of wasting so much time on specifications ? Removing specifications altogether ? This is one of the legend that open source projects have falsely spawn. From the developers perspective, the spec is the code and the unit test. Which means that there’s a barrier of entry : i.e you are a real man, you can read the code and you know what the specs are. Either you can’t and, well, too bad for you.

With the Obeya, a Lean Software Project management approach we are experts at (see my colleague Sandrine Olivencia article on InfoQ here), not only are there specs but they are on the wall. The specs are the ones defining usability and the navigation flow from a user perspective. It helps in testing interface hypothesis in the very early stage of the project with real customer in a Lean UX type of approach. Once validated, the specs are displayed on the project wall so that everyone understand what the product is, and we are able to explicitly (pink post-it) show where the current problems are.

Again using specifications like this allow to remove explicit, build a shared understanding of what the product is and where the current issues are on the product.

Misconception #6 : Estimates are disengaging people 

This one is partially true. I have worked for software organizations where year after year, product release after product release, we kept on delivering with initial estimates that failed short by a magnitude of 4 or 5. Yet, and I swear it’s true, we never did anything about this problem : never looked for the cause, counter-measure to test etc … Apart from having the PMO putting even more pressure on managers to work harder and longer (i.e. more analysis, specs etc …) to come with correct estimates. And guess what : it cost much effort, more time but didn’t improved. We were forcing an incorrect solution (estimates) to answer a genuine question : what would be deliver when.

So we decided to deal with it the other way round : rather than trying to figure out before hand through a crystal ball what the oracle would say for developing that functionality, we built predictability. We built feature teams (co-located, cross-functional teams) who were accountable for delivering fully functional User Stories. And we just counted how many US they would deliver per iteration. And then we found out that we could tell in advance by spending a few minutes weighing the functionalities to be delivered. So these are still somehow estimates but built in a far more empiric and error-prone way, estimates the team is comfortable with. And the PMO is happy as she now has the information he needs to build project road-maps.

Misconception #7 : email is evil

This is another difficult one to invalidate. Sometimes a monster, email remains an awesome tool : ubiquitous, easy, universal. it is a perfect channel of communication, i.e. for a one to one communication. The problem is how it is used. Wasting thousands of FTEs writing long email for the whole world to read just to let people know how corporatica-literate one is, and how important the work she does is, while the actual message you want to send is to someone sitting in the next office. This is the email monster. A live conversation would have been far more efficient and bothered much less people.

What I do in projects, I make sure people communicate on the Project page (I kinda like Sharepoint for this) through blog posts so that the message is addressed to everyone and can easily be found. Any email that has more than 2 recipients should be a candidate for a blog post on the project page.

Misconception #8

Can you see any other misconceptions that the legends of agility and open source software has spawn and that we should debunk ?