Modern software development includes a huge number of disciplines and approaches. From Designers through to Developers and Sales teams the number of processes required to deliver a Product can be daunting. Traditional management sees each of these processes as distinct, stand alone, “silos” of work who all need to be working as efficiently as possible in their respective niches to speed up the whole process.

This kind of thinking began in the industrial revolution when giants of manufacturing like Ford showed how mass production can be achieved. Without doubt this ushered in an age of prosperity and consumerism that still drives a lot of our modern world. Interestingly the same powers of hyper delivery that ear mark mass manufacturing are also the same things that can be proven to actually slow down and hamper teams.

Lean

Previous to 1934 Toyota was a textile manufacturing firm; in 1934 they moved into the automobile industry. Facing some seriously stiff competition against the mighty Ford and General Motors Toyota knew the nature of their territories and the investment it would take in tooling meant they could not compete in mass production. The Toyota Production System drew together several forms of typically Japanese thought into one coherent; elegant approach. The main thought process in Lean is to reduce the amount of Work In Progress at every step of the manufacturing process. 

There are several aspects to why the amount of WIP matters massively; creating and moving large batches of work between processes has several issues:

• Transport (moving products that are not actually required to perform the processing)
• Inventory (all components, work in process, and finished product not being processed)
• Motion (people or equipment moving or walking more than is required to perform the processing)
• Waiting (for the next production step, interruptions of production during shift change)
• Overproduction (working ahead of actual demand)
• Overprocessing (resulting from poor tool or product design-creating activity)
• Defects (the effort involved in inspecting for and fixing defects)

These ‘Mudas’ all have a hidden costs in efficiency that is not taken into account in the traditional mass production approach. While these appear tightly coupled with manufacturing of physical goods the thought process has found application across nearly all forms of industry and has sprung an entire following. 

The “Silo” mentality

With traditional approaches to software development companies often follow the thinking that if people in each process are working at their most efficient within their silo then projects come in on time and profit margins get larger. You only have to look at what might be called a ‘typical’ software development cycle (Agile or not) to see batches of work moving between processes.

• Designers scope and define the problem with users
• The designers pass the design outputs to the UX Designers to create how a product should look and feel
• The UX designer passes their mocks and requirements to the development team
• The development team create the code to satisfy the requirements
• The development team pass their code to the Quality Assurance team to be Tested
• The Sales team receives the final Product, a user manual and create a sales pitch
• The Support team also receives the Product and Manual and information from the Sales team as to who has purchased the Product

This process looks and sounds reasonable; many companies use it to varying degrees of success (some very successful!). When we crack open the steps and the output of each process it becomes clear we have an analogy with manufacturing. Whilst creating a new Digital Product or Service is an intensely creative process there are still ’silos’ of effort and batches of work that are passing between them. 

In the software development domain the kinds of problems caused by silos and passing batches between processes can be:

• Misunderstanding of requirements
• Communication failure
• Over commitment to unrealistic timelines 
• Poor design choices due to lack of visibility in the value of a product
• A loss of customer focus
• A team feeling disengaged and shoe boxed by not having insight into why they are doing what they are

Compounding the issues above; the larger the batch moving between silos the larger the issues become. This can be felt sharpest for the teams at the end of the cycle such as when QA get hit with tight or impossible timelines because a huge backlog of work has built up between previous silos only to come crashing down on them at the end of a project. Thankfully there are a few ways to mitigate these issues, one is clearly to manage batch sizes and we’ll go into more detail about that in another post but an additional way to remove the overhead in moving batches between silos is to break down the silos!

Cross Functional teams

Cross functional teams are those with a wide set of domain expertise in them. In the software industry this may typically mean at least a representative of each expertise is involved in as many of the steps in the process of creating a Product as possible. Of course this isn’t always pragmatic but the idea is to strive for as few barriers to communication and knowledge sharing as possible. Going back to Lean and the overhead of moving work between silos it would seem clear removing these barriers is part of making the whole system a healthier, smoother flow.

In the process of breaking down these silos and removing communication barriers all of the representatives are empowered to have input into the process. Designers get some input from down stream disciplines about the practicality of their designs and simply having more people exploring a problem space can bring out happy accidents. User Experience Designers get a deeper knowledge of the Design challenge as well as the practicalities and insight from the development team. Developers get more chance to constructively pitch into the earlier design steps and help smooth the way for better collaboration with Quality Assurance teams. The Quality Assurance team that so often feel the brunt of batch overhead benefit the most as they are empowered to check the quality of each step and they know how the application is designed so can test against that understanding.

Hopefully it’s clear that all of these efficiencies and removal of overhead ultimately shortens the time to get a valuable Product delivered. While it may seem that having so many stakeholders involved slows down the delivery the truth is that effort was always going to have to be made. The main difference in addressing the silos head on and ironing out issues early is that cost is “up front”. By making the overheads transparent they can be measured, managed and accounted for.

Conclusion

It’s easy to talk about the ideal where everyone is involved and has input into the process of creating a Product but it is difficult. There will be a manifold of opinions at each step and plenty of work to make sure everyone is seeing eye to eye. There will be times where it seems like the overhead just isn’t worth it and the temptation to drop back to silos will be strong.

It is worth pursuing cross functional teams as much as practically possible because it puts things like miscommunication, misunderstanding and disagreements up front to be dealt with earlier rather than spread silently through the process. In the end the level of ownership and fulfilment the entire team will enjoy and the value of getting the best possible solution for customers is more than worth the effort.