Silos and the “Triple-Crown” of Agile Product Delivery Communication

In the past, I’ve experienced a lot of cases where silos existed within companies and organisations. More recently, with my work with communications service providers, the silos between product management (part of the CMO organisation), business systems (BSS, part of the CIO organisation), and operations (OSS, part of the CTO organisation) illustrated the problems in delivering their products to customers.

More recently, I was reminded of this during last week’s meeting of the OPMA (Ottawa Product Management Association, which also includes program and project managers) and an INCOSE Canada (International Council for System Engineering) symposium. These silos certainly appear to be the norm in many organisations – and seldom to beneficial effect!

The problem with these silos is that they encourage the transfer of information through documents that are passed “over the wall”. Although this could be seen as a sign of collaboration (e.g., “I provided the requirements, my job is done!”), it is not truly conducive to all parts involved in the product delivery process understanding and meeting the needs of the stakeholder (“the customer”). It also does not promote the adoption of an agile approach, especially when the needs of the customer change or are better understood.
I have come to think of this problem as on of “3-Cs”: Communication, collaboration, and cooperation.

There has always been a lot of talk about communication being essential to everyone knowing what needs to be done. Unfortunately, the silos tend to make this communication one-way, and I do not see that as communication! Communication that just goes one way is publication, even publicity in some case (e.g., “See, I know what the customer wants!”). Publication also tends to be a point in time occurence and not continuous. What is needed is communication that is a continuous dialogue that occurs regularly until the product is delivered – not just at the start and end. Participants need to be able to ask questions and get answers in order to get to a common understanding of what needs to be done, of what the customer problem and needs are and and how they will be solved.
But communication is not enough. There also has to be collaboration during that dialogue – it can not only be a question and answer exchange. Participant need to provide insight from their own knowledge and experience. This collaboration will help the company achieve the best solution for the customer’s problem.

And even that is not enough – we also need cooperation. Collaboration has a tendency to only occur during specific communication events, e.g., meetings. Cooperation happens when communication and collaboration happens spontaneously. In many cases, it is the result of the synergy that happens when communication and collaboration become almost symbiotic, when the team knows enough about the whole product that, when new information becomes available, they are already thinking about new ideas to meet the customer’s needs and they already know who to talk to – there is no more need to way for the next meeting or to create a new document. At this point, the silos are broken and success is assured.

I do realise that I am taking some liberties with the formal definitions of my 3-Cs, and I make no apologies for that. It is an easier mnemonic to deal with (especially since it seems to have already been used often as such).
The important thing in all this, after all, is to remember that when developing products, we all need to become more agile and dedicated to meeting the customer’s needs and solving their problems. If we don’t, we will take longer and risk losing the customer!

Advertisements

2 thoughts on “Silos and the “Triple-Crown” of Agile Product Delivery Communication

  1. Great commentary – I fully agree.

    It’s worth mentioning that there’s another similar “3Cs” that is the foundation of the “user story” concept from Extreme Programming(XP). Unfortunately, many that use the term “user story” omit these key concepts, and lose most of the benefits.

    Card – The written portion of a user story should be brief enough to fit on an index card. It should be a statement from the end-user’s perspective, and WILL NOT contain enough information for development to implement it. Implementing the story will require…

    Conversation – This is the most important part (the “story”), but is unfortunately the most often neglected. The conversation could produce many artifacts – diagrams, models, notes, etc. These conversations continue as the product is developed and result in learning for both the developers and customers (and all the groups in between). It may be that what the customer really wants is not what they communicated at the start, or it may be that the development team completely mis-interpreted the customer’s needs. My experience is there’s usually some of both, and the only way to avoid disappointment is to have this continuous conversation. Models and prototypes help too.

    Confirmation – High-level criteria that will confirm that the user story is complete. This could be done through examples of what the system will do when it is complete or even executable tests. Like the ‘card’, these are not meant to be exhaustive, and the customer (“product owner” in scrum) is free to reject the user story if it doesn’t satisfy their needs (so you better talk to them a lot!).

    It’s not without intent that if the above is done as described, it greatly closes the gap between groups that are silo-ed in traditional companies. Of course, as we know well – moving in that direction in an established company is not without its challenges.

    • Thanks Jamie!

      I’m glad you enjoyed the post and thank you for bringing up that good example from XP!

      There are many “CCC” abbreviation, including the old military “Communication, Command, and Control” (which is now C4ISR, so I’m not sure if it still counts…).

Comments are closed.