Agile Zone is brought to you in partnership with:

Tom discovered Agile Development in 2003 and spent the next 8 years, together with his team at www.biomni.com, improving their process and blogging about his discoveries. He has a particular interest in the psychology of keeping Agile agile and not letting it slip back into the evil old ways! He believes a Scrummaster should also be a developer and codes ASP.NET and C# most of the time. Tom is a DZone MVB and is not an employee of DZone and has posted 42 posts at DZone. You can read more from them at their website. View Full User Profile

Openness

04.09.2013
| 1559 views |
  • submit to reddit
The purpose of a Silo is to protect the contents from being disturbed or damaged from  external foreign bodies. Creating a Silo is reasonable if you are the farmer protecting your grain from insects but surely they are not necessary in an organisation where we should be supporting each other? Unfortunately working culture can be hostile and silos are everywhere. If we want start breaking down silos and seeing the openness required for an organisation to learn effectively we need find better ways of treating each other.

Silos are destroying our ability to work effectively together. Silos allow people inside to hide their activities from the outside, whilst this protects us from judgment when something goes wrong it also protects us from vital feedback resulting in us spending much of our time doing the wrong thing.  Silos allow us to carry on working with dysfunctional relationships. Silos hide corruption and abuse. Silos are everywhere and we take them for granted, they are killing our organisations large and small.

Agile Development and the extended learning organisations requires openness. At first glance a Scrum team may look like a Silo, we protect the team from outside interference. But Scrum teams are different because they are (or should be) open. The reality of our work at any time is exposed on a large board that anyone can see. Our daily standup should be able to be viewed by anyone. Openness means if we are doing the wrong thing someone can tell us about it, if they care.

But have you noticed how most people don’t care? It’s because other departmental silos are protecting themselves from the reality around them, preferring to live with a more idealised view of how others should be working, and blaming when the ideal fails to materialise. A common example is Sales teams rarely pay attention to how product development is actually progressing preferring to rely on a fictitious plan. Managers often prefer to see a whitewashed report rather than gritty reality. When reality does finally unravel we respond with blame, punishment and sackings giving us good reason to reinforce our silos

So what can we do to get the openness and collaboration with the rest of the company that product development desperately needs?

Silos protect people from hostility so if we want to remove them we must stop treating each other in a hostile way. The way people treat us depends largely on the way we behave towards them. You cannot expect somebody who you judge and blame to be open with you about their needs. The sales team will not openly share with me what their customer’s need if I accuse them of selling the wrong thing. Their life is difficult and full of failures, if we want them to be open we must first empathise and once we understand the problems they face we can start to develop the trust that is required for effective collaboration.

Is there anything else we can do that will help others be more open with us? How about being welcoming? Showing appreciation? Is there anything we can stop doing that will help others be more open with us? We need to stop blaming. When we are asked an unreasonable request we need to stop putting up with it and becoming frustrated and resentful, we need to take the time to explain and together, discover better ways of working.

This is the kind of behaviour that could spread but it needs to start with us.

Published at DZone with permission of Tom Howlett, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)