I was recently working as a coach for a client in the financial sector. Their ways of working were very traditional and the IT department was running on fear of failure. As a remedy, they had introduced heavy processes, rigid gates and strict approval procedures.

The proponents of Agile, me included, wanted to relax the rules and have less BDUF (Big Design Up Front). We wanted to follow work on the wall, not in an electronic tool. Backlogs could be in Excel, not in Quality Center. Decisions would be made in workshops and conversations, not in meetings and tools.

On the other side of the argument were Process Owners. They were highly respected individuals who had full authority over their process. Examples of processes were “Testing”, “Architecture” and “Project management”.

When the conflict turned so hot that no-one could ignore it, our Agile Transformation Team called together a pow-wow to discuss about the situation and steps forward. The meeting went extremely well and I want to share with you some tools we used to defuse the bomb.

Start off on the right foot

We started the workshop by asking expectations from everyone. To our surprise, the expectation was not to have own opinion winning but “common understanding about what is mandatory in the process and what is not“. This was a good start; “common understanding” was valuable currency in the discussion. Another important point was that we agreed there can be rules. Agile does not mean throwing everything into the waste basket.

Tool #1: Slicing

One root cause for the conflict was generalisation. When someone said “Testing” then everything about testing became under discussion (tools, methods, practises,documents etc). This made all discussions so huge, that common agreement about “this” over “that” was never possible.

We recognised four components related to any work:
1) Artefact: Document or other output
2) Process: Identifiable steps in the process (for example “Do X before Y” or “Create A during B”)
3) Working practice: How the activity is done (for example meeting or workshop, who need to be invited)
4) Tool: What tools are used and how

This helped to create structure in discussion. Instead saying “Financial Supervision (FiVa) requires that we have specification documents in ShareNet” we can say “FiVa requires that specifications are documented“. This opens completely different discussions.

Tool #2: The Onion

The Onion helps to break the Does/Doesn’t debate into more fruitful conversation. Most conflicts are caused by false dichotomies; arguments about “Always vs. Never” or “Black vs. White“.

The layers of the onion in our case were:
– Mandatory: Has to de done every time using the pre-defined way of working
– Alternative: Something you have to do, but you have alternative ways of working
– Recommended: Not mandatory, but a recommended practise to avoid conflicts
– Optional: Something you can do or leave undone and there are recommendations for good practises available

After introducing the two tools, the Process Owner created a list of items in their area: what Artefacts, Tools, Work steps or Practices there are and which level they are in the Onion Model. As you guess, most Mandatory items were Artefacts or Tools. However, there were great insights, for example proposing that a mandatory meeting would be replaced by workshop with less strict agenda.

At the end we had a very good list of well-argumented needs from each participant, for example:
– “Testing can be done using BDD, but in that case the tool should be JBehave” (Optional working practise with Mandatory tool)
– “In order to follow the Architecture Process, team must have discussion with Architecture Steering Group before projects starts. It is recommended to follow Architecture Process also in Agile projects” (Mandatory working practice with Recommended process)

Example of topics discussed with Onion Model

My key takeaways from the workshop and the tools were:
1) People have a desire for common understanding. Having this said in a meeting helps to find a solution.
2) People have desire to hold on to their important things and anchor them into larger entities (“I need to have requirements in written form, therefore I command a tool and process for that”)
3) Creating alternative structure and “baskets” helps people let go things that are not really important (things that are just proxies to get something that is important)
4) False dichotomy is the enemy of conversation. Offering 3 or more alternative levels facilitates agreement.

Software and service development projects do not need to be large. Knowledge work has the advantage over other domains (e.g. manufacturing or civil engineering) that we can do great things with small group of people.

Actually, doing things with smaller group is a competitive advantage: having less people during development and truly understanding the value for customer, the service or product can be done with less costs. I am not talking 5%-10% here; I am talking 5x or 10x improvement.

However, large projects do exist and their existence is defended with plausible-sounding arguments. Here are the TOP-5 arguments I hear when I propose doing things in a smaller scale.

#5: “You can not build a multi-national safety-critical air-traffic control system with a small team”

No, I can not. But what limits other people in other context shouldn’t be limitation in my work. The fact that some things may need to be large does not mean that everything could be large. Luckily this argument is more on the “academic discussion” side and easy to overcome in a discussion about a real project.

#4: “If we do a project with 20 great people instead of our normal 500 people, then will those 480 people lose their jobs?”

I don’t see how a company would fire people when it starts doing same value with less people (i.e. ROI improves). Could the other 480 people do more value in other small projects? Well, they could lose their jobs if they were hired to do things that should not be done at all.

This is a weird argument, as if someone would enjoy working as a clog in a large machine or purpose of the organization would be doing large projects. But hey, it gives an impression that manager cares about people.

#3: “Large projects are actually a good thing, cost-effective and all that”

They are not. The interesting part here is what “cost-effective” means. Yes, with 500 people you probably have smaller relative cost of setup and project management cost (visible overhead) than with a project of 50 people. But the invisible cost — internal failure demand — for large projects is huge. People sit in meetings, wait for others and fix problems that late integration brings. But that looks efficient, because everyone is busy.

#2: “Large projects are not good, unless you do it Lean” (or any other current fad)

This sounds more plausible than #3. But then again: if Lean is the magic word, would not it give even greater benefit if you apply it for a small project? You would get best of both worlds: less fixed costs + the benefit of Lean.

What is interesting here, Lean (and other) are often used to fix a problem that should not even exist. “With our Lean approach you can manage the whole value-chain” raises a question “Why did you screw up your value-chain so badly it needs management?”

#1: “You don’t have anything that would make our projects smaller overnight” (..so we continue doing large projects)

I call this “The stretch pants argument”. In other words: “I have grown out of my clothes and need to wear something tomorrow, so the only thing I can do is to buy stretch pants“.

This arguments true: There is no silver bullet. Changing from “big band, big upfront design, silo organization and tons of failure demand” is not going to be easy! It requires not only discipline but also new kind of thinking. It requires that organization stops organizing itself inside-out and start organizing outside-in, against value demand.

You can not delay your fitness program any further. If you have pressure from competition, downhill in sales and de-motivated personnel, the only thing you can do is to change how the work works. Trying to “do Agile in large projects” or “manage backlogs between the teams” is not going to take you much further.

It is unfortunate that these arguments take the discussion away from the real problems. Large-scale is a problem and it is caused by some harmful system conditions. Becoming fast, Agile and successful requires change in system conditions. Stop being big in your next project and change anything you need to achieve that. If not, what is your favorite excuse?

Imagine a supermarket. You visit there daily or weekly, buy food and beverages and other things you need in your life. The shop has a purpose for you. You probably visit the same store every time, maybe it is convenient or has the right selection or least queues.

What if supermarkets would be organized like knowledge work?

This is what happens.

The items still remain on shelves, that is a proven best practice, and you pick them to your cart. You arrive at the checkout counters and empty your cart on the belts: dairy products on belt #1, vegetables and fruits on belt #2, candy on belt #5, cigarettes on belt #11 and finally washing powder all the way at the end on belt #21.

You move on the other side of the checkout counters to wait for your purchases. A gentleman next to you holds a box of chocolate and tells you he only waits for his toothpaste to leave. A lady walks out of the door, lucky one, she only came for a loaf of bread and she got it through before the counter was closed and resources were moved to dairy line to handle the queue.

When you pack the groceries and are about to leave, you see shop personnel gathering together on the other side of the counters. They look worried at the queues and start franticly moving check-out personnel from a belt to another. Some employees are filling in the shelves, they move next to queues and start counting how many people are waiting, reporting that number to shop manager.

Next weeks things seem to have changed. Belts are now moving 10% faster to increase throughput and check-out personnel is standing so they can move items faster through the scanner. Everyone has also been to “Smile to Customers”-training, queue managers have taken 3-day Queue Management workshop and shop manager organized a well-being day for everyone because employees were feeling bad at work. “Cigarettes” belt is combined with “Diapers”, because both lines had sometimes <100% utilization.

Sounds too far fetched? Nobody would be that stupid!

Yet that is the way we organize most of our IT services and SW product development. We create competency silos and integrate very late. We split customer need into small tasks and make sure the tasks move fast. We use Scrum and Kanban and whatnot to make sure things proceed swiftly. We put time and effort to discuss about queues and make organization changes to balance workload.

But, hey, IT work is knowledge work and hence more complex than working at a check-out register at local shop? Yes, exactly. And therefore people doing knowledge work should pay even more attention to flow, customer value and getting things truly done. Instead of splitting work and managing resources, we should manage work and let people organize around the flow.

Next time you go to you local supermarket, think about how cool it would be to get your IT service out equally fast!

Lists are great and here is my list: TOP-3×3 Signs You Are In A Command And Control Organization.

The signs are divided into three categories, hence 3×3 in the title, and the categories are

The Obvious,

The Unexpected and

The Hilarious

Before the lists, let’s see what is command and control. It is a management thinking pattern that assumes the organization must have

Up-front planning

Reporting and metrics against the plan

Defined roles and responsibilities

Hierarchies that support the defined responsibilities

Best practices and harmonized work process to achieve efficiency

Command and Control is built on an assumption that people in power know what and how needs to be done, and its is their duty to inform others about this. Communication from “doers” to “decision makers” is done mainly via reporting. The other direction is work orders, tasks and evaluations.

The Lists

The Obvious are signs that almost all command & control managers create around them. Here are my TOP-3 of those.

Hierarchies. This is a sure sign of command and control mindset. This is an obsession to draw organization charts. Also phrases “reports to” or “is a subordinate” show that the hierarchies dominate.

Reorganizations. Related to the previous, organization structure is the symbol of hierarchies. Organization may have low hierarchies, but if it reacts to impulses by doing a reorganization, then it surely is command & control. Click here to see Dogbert meet with C&C boss.

Performance management. This comes in many flavors: incentives, individual bonuses, target setting and annual performance reviews. All of them are rooted in thinking that someone else knows best how to do work.

The Unexpected are signs that on the first look seem harmless, but closer look shows they are Command & Control in disguise.

Lync, Skype and other communication tools. What? These are useful! Yes, they may be good in some occasions, but these tools drive low-bandwidth communication. Once you have Lync installed, why not skip all face-to-face meetings? Phone / video fits well to giving orders and delivering reports, i.e Command and Control . Worse even, organizations tend to acquire messaging tools to hide the fact that they are not capable to put people work together.

Metrics. Again, these could be useful if they were derived from purpose and customer demand. Unfortunately, almost always these are merely process metrics: “Are we doing the things right“, “Are we on track” and “Are my commands being executed properly“. Metrics are a great antidote to learning.

Support functions. Human Resources, Premises Management, Finance&Control and so on. These are based on thinking that specialization is a good thing. But this detaches decision making from work and creates system where “someone else knows better” and “do your work so that mine is easier“. Oh, and if anyone comes to you and say they have “Agile X” (X represents any support function), then be very worried. It is just command and control in camouflage.

The Hilarious are signs that are just too absurd to be true. But they are and tell a lot about management mindset

Policies: “Nice that you are doing Scrum, but you can not purchase whiteboards without 3rd level manager approval“. And at the same time the organization buys everyone a $500 license to an Agile Lifecycle Management Software.

Access rights. Both physical world (doors) and virtual world (information systems). If you have trouble getting through doors to your colleagues, then there are significant trust issues in the organization. Interestingly, the more the leaders emphasize openness in all-hands meetings, the more difficult it is to get access rights in the real life.

Institutionalized dysfunctions. Dysfunction is something that is wrong in design and management of work. Dysfunction becomes institutionalized when management creates process or tool to go around the problem and the discussion moves from the problem to the workaround. The original problem remains. If you see a lot of weird meetings talking about things that should not even exist, then you know organization sees a tool or process as a solution to every problem. Command and Control.

None of the items in the list above (except “Performance Management”) as such are harmful to people. Command & Control is not about mis-treating people or imposing punishment (while those do occur). Command and Control is about attitude towards work and it impacts how people in power treat other people, but C&C management is not “evil”. This often confuses managers, because they think they are nice, “people-oriented” and good coaches. Sorry, doing Command and Control more “softly” is not going to help. The problem lies in thinking, not in how the thinking is implemented.

“You promised I can cut and prune ten times more trees with this“, replies the angry lumberjack, “but I barely make the same amount I did with axe and saw“.

“OK, let’s take a look“, says the shop owner. He pulls the cord and chainsaw engine starts with a roaring noise.

“Hey, what is that sound?“, asks the lumberjack.

Have you ever been in same situation? You take a new tool or a new process into use. The promise is more results or more speed or more anything you want.

Then, after a while, you realize that little has changed or things have gone worse. You fail in all new ways.

I see this when I meet with teams and managers who struggle with their work. They tell me about agility and how Scrum or Kanban is the prevailing way of doing work. “We are Agile“, they say, “but it does not help. Can you tell us what to do next?“.

I ask: “How do you know if Scrum (or Kanban) is working?“. Or more bluntly: “How do you know you are doing it right?”

The answer is almost always a silence, followed by a deep sigh and question back to me: “That’s a good question. Could you tell us how it should work?“.

Whatever we do, there must be a way to see if we are getting what we are supposed to get. It must be observable: transparency, learning or responsiveness are nice words, but not enough. How do I know, that I’m getting what I’m supposed to get.

The point of Scrum is not the rituals, backlogs and roles. The point of Kanban is not to hang tasks on the wall on colorful Post-It notes.

For me, “The Meaning of Scrum” is: If you create a potentially shippable increment at the end of every Sprint so that it tells you exactly where you are with regards to product vision, then you are doing Scrum right.