This week, Chapter 8 of Project to Product https://amzn.to/2WzvPac (Amazon Affiliate Link). I was presented with a scenario this week in which product, UX, development, testing, and security operated within their own boundaries with their own goals and tools — silos. Even though this was a discussion scenario it is easily one of the most common problems I observe in organizations once they begin to scale from start-up mode. Disconnected tools are both the result of silos and the cause of silos. This siloed behavior between departments can easily cascade into functions within departments. I often see teams that have different development tools, code repositories, and testing tools trying to work together to deliver a single product. A few years ago, a colleague and I identified five separate development and testing environments on a single release train. Trying to periodically create a single working version of the application for testing and review was a nightmare (the systems engineer in charge used different words). Every specialty and function wants to use the newest and shiniest tool leading to local optimization and fragmentation.
The fragmentation described in Chapter 8 has been fostered by two glaring managerial decisions. The first is failing to organize by value chain. This failure has been a constant drumbeat throughout the re-read. By not understanding the value stream and then organizing people and resources to mirror that value chain silos naturally occur. Separate organizational structures will always develop their own goals even in the presence of a higher-level goal.
Matrix management, which made so much sense in the last century, fosters even more finite fragmentation. Teams made up of specialists from functional areas and centers of excellence come with their own tool preferences and overarching goals. Significant effort is always required to sync behaviors, tools, and information flows.
All of this fragmentation generates complexity which negatively affects the effectiveness and efficiency of delivery. Much of this complexity is self-inflicted based on the conflating work in the age of software with work in the area of mass production. While there is no magic wand that will create a single toolset and platform, we can avoid the additional complexity generated by structure and competing goals. A relentless bias for identifying and mitigating barriers to both the flow of value and information is a critical survival technique for all organizations as we traverse the second half of the age of software.
Have you bought your copy? Project to Product https://amzn.to/2WzvPac (Amazon Affiliate Link)
Catch up on previous installments:
Week 1: Foreword and Introduction – https://bit.ly/39gIt0A
Week 2: Age of Software – https://bit.ly/2XYvqyI
Week 3: From Project to Product – https://bit.ly/3mhwJBb
Week 4: Introducing The Flow Framework – https://bit.ly/3lqJTwd
Week 5: Capturing Flow Metrics – https://bit.ly/3GjCffC
Week 6: Connecting to Business Results – https://bit.ly/3BTROqQ
Week 7: Tracking Disruptions –https://bit.ly/3neIs5h
Week 8: The Ground Truth of Enterprise Tool Networks –
