Shaun MacRae

I’ve struggled with this throughout my career, but it’s never made sense to me until recently.

A colleague said something about operating in isolated environments so that one skill-set does not influence another skill-set. He was referring specifically to analysts not having access to development resources so that the requirements gathered from the client are true and pure and not tainted by technology. It may explain why I’ve come across so much resistance in past experiences to open and collaborative environments, although I’m sure there were also those who were just reluctant to the general concept of transparency (for other obvious reasons).

While this particular point was interesting, and I must agree that it is always a challenge gathering requirements without proposing solutions, I still think there is too much to be lost by adopting a throw-it-over-the-wall-mentality.

I’ve spoke before about the importance of transparency and I don’t think working in silos is conducive to successfully delivering quality software. First of all we end up with specialists instead of generalists. Specialists are great for some tasks (typically for review and training (especially in niche areas like UX)), but generalists are what we need in software development teams. Analysts need to understand and appreciate the complexities of the software they are using as do the business/consultants/clients. The scale will vary from one end of the spectrum to the other, but the closer we can always keep everyone together, the much better the outcome. Developers must also be close to the business to appreciate and understand their pains. The only way that all of this can take place is if we stop throwing things over the wall and start talking, start working collaboratively, start sharing ideas and visions.

One of the first things you will notice if you are in a throw-it-over-the-wall type of environment is an emphasis on contracts or agreements. When the team A lead is telling the team B lead that the most important part of the design is the interface between team A’s component and team B’s component you are in trouble. The fact that team A wants to know nothing about the design of team B’s component is a sign of silos forming.

More subtly, the contract or agreement will be between a development team and another team. The outputs of one team serve as inputs for the other team. It makes sense that developed source code goes through a quality assurance cycle performed by another team for example. But, when the tester starts to require that the software be packaged in such a way that they would never need to ask a developer a question, things have gotten out of hand. Ideally, the tester would be working along side the developer, developing the test cases at the same time or before the developer.

The other problem with throwing things over the wall is that it just takes too long. People start to hold on to things because they are scared to throw it over and have it thrown back (especially if it’s not thrown back soon enough to do anything about it). This is a bad spot to be in, and will take some time to fix. People in these environments are generally very defensive and self-serving. People need to get used of working together as a team with collective ownership of all software artifacts.

It does seem like pretty basic stuff, but the truth is it requires a lot of discipline to support this type of transparency and teamwork. We all have tendencies to just do the work ourselves and not collaborate because we think it will be easier, but there are a wealth of tools / ideas for making collaboration easier and, in some cases, making it something we can’t hide from. Things like open work spaces, on-site development, scrum walls, etc are all good examples.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.