So where do most software development methodologies focus on? I guess it’s about the process and not about people. A framework like Disciplined Agile Delivery includes lots of best practices in the people and team area. Scott Ambler and Mark Lines wrote it down really well. I will try to explain some concepts in my own terms in the upcoming blog posts. The first part is about the concept of creating a big fat highway for information between people.
High bandwidth communication
Software development is about building software for which stakeholders are asking. And those stakeholders aren’t developers. So you need to get multiple thoughts out of those heads and converted into code. This requires transfer of information between people. The more people between converting thoughts into code the more risk of errors. And if you need to transfer information between people it’s better to do this in collaboration style (working together and interacting) than writing it down and handing off the documents to the other. This is a high bandwidth concept. A document is a low bandwidth concept.
Understanding of other disciplines
So communication is all about getting stuff from one mind to the other. Understanding the world of the receiver is therefore important. So you need to understand the other discipline in your software development team. You can understand what format the other discipline requires and come up with better ways of transferring information. Or maybe even help a developer write the code while sitting next to him and telling him what to build instead of handing a document to him how to built it. Transfer by collaboration. This all increases effective use of you as a resource and reduced reliance on formal documentation and handoffs. So also be flexible in the documentation handoff format. A reason Disciplined Agile Delivery doesn’t focus on specific roles like a business analyst or tester.
Learn your discipline to the other
So you need to know the other discipline a bit better. You can read some book of course. But there is also the concept of teaching your discipline to the other person in your team in order to get communication bandwidth improvements. So be open and not afraid of sharing your knowledge. It will improve your team. The concept of “generalizing specialist” therefore works both ways. If you teach the other team member some of your discipline you will become less of a specialist because the other team member becomes a bit more of a specialist!
Integration of workspaces
So increasing the bandwidth is done by communicating closely. People on the same team creating the same solution should be near each other. A single physical workspace therefore will improve communication. But it also affects your virtual workspace! If you are using a directory structure on a shared network drive for example you need to be aware of documents being “near” each other when it’s about the same project. Changes to documents need to communicate to the team as fast as possible so you can communicate about them and do the impact analysis early. Think about what it means for your workspace.
Did you ever noticed that when your team is in the same room and you hear a few team members discussing and it get’s your attention because they have a wrong interpretation document? You immediately intervene and tell them what. Maybe it wasn’t made explicit enough? Getting people in the same room solves a lot of tacit knowledge issues because you “hear” things going wrong. This sort of communication is also possible over a chat application. So if you haven’t got a collocated team, consider a team chat room. E-mail often fails in these areas if you don’t send the e-mail to all your team members.
Just a few notes about communication bandwidth. More about the people part in the next blog posts.