Agile software development, the principles. Principle 6: The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
This is the sixth of 12 posts about the principles of agile software development. Purpose is to go back to the start of the agile manifesto (http://agilemanifesto.org/principles.html) and discuss the implementation of the 12 principles in real life software engineering. Goals of agility are to go deliver software of higher quality, faster, with a higher acceptance to end-users and able to follow the changing business requirements to strive for competitive advantage.
The question is: is this going to work in practice or is this only based on a nice marketing and sales story.
Principle 6: The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
The purpose of conversation/communication is to transfer a message form the sender to the recipient. In projects, conversation is either about the project process (plans, risk, approach etc) or project content (requirements). Getting your team members to understand the right information correctly is the key factor in the projects success. Being effective in this transference of information is crucial to save time and overcome misunderstanding, especially in agile projects. Face-to-face communication is in fact the most effective way of communicating your project.
Driving a 100km for a 1 hour meeting is much more effective than several teleconference meetings. Despite the technological advanced means of communication (IM, WebMeeting, Video Conferencing) there is nothing more effective than face-to-face contact.
Today multisite projects are more and more common. With fast network connections it is easy to move work to places with low(er) labour costs (eg. Eastern Europe, China or India). But also within one company/country we are used to execute projects with multiple teams on multiple sites. To facilitate the communication with the (off shored) development team, a representative of the client organisation is placed on site to assist with the communication about projects, designs and products. This approach is helpful in mostly waterfall like projects. For these projects, communication is mostly formalized in standing meetings that in most cases only handle critical issues and high level design discussions. But it is an illusion that the rest of the communication with and between the developers can be handled via IM or web-meetings. To ensure a clear and unambiguous understanding of the projects approach and requirements face-to-face communication is crucial.
Below I will state some drawbacks of “modern” means of communication and advantages of face-to-face communication. This does not mean that I consider IM, teleconferencing or web-meetings as useless. You just have to realize these disadvantages to use them properly.
Drawbacks of technologically supported meetings
Despite the advantage of bridging a vast distance easily there are major drawbacks to teleconferences, IM, Video conferencing and web meetings. The following bullets summarize these drawbacks.
* Distracton. If you like teleconferences because you are able to work on your e-mail backlog during the call, stop reading here and go back to your e-mail! Distributed web/teleconference meetings will make participants more vulnerable for distractions. Participants are invisible for the leader of the meeting who will correct this counter productive behaviour when this is a face-to-face meeting. Mobile phones, other IM sessions, colleagues walking into your office etc. will create distraction and make the participants lose focus.
* Duration. Web meetings or teleconferences will take much more time to handle the same number of topics compared to physical meetings. Participants will have to take more time to state proposals and opinions before the other participants understand them. The participants are also missing context. And a lot of time is just lost checking who is saying what (“Who is saying that, is that you John?” ….. sounds familiar.)
* Concentration. How about you sitting in a room (or even worse: in a shared office space) engaged in a complex web/teleconference about requirements of a new system with 5+ participants from around the world. This requires a lot of concentration. Not only form you but form all participants. Suppose one participant is distracted. This has an immediate result in the effectiveness of the communication with possible effect on the end-result of the whole project. The discussion leader is unable to notice this distraction and cannot validate if the participant has missed some crucial part of the information.
* Non verbal communication. Web/teleconference blocks non-verbal communication. Video confecting can overcome some of these non-verbal’s but is does not give you the complete picture. Non verbal communication is the most primal means of checking if the message is understood by the recipient. Cutting this off by web/teleconferencing will make the sender of the message blind to these signals.
* Not on the same clock / time zone. Web/teleconferences with participants that are situated over multiple time zones sometimes overlook the difference in mental setting that come with that time zone. Imagine a conference call on Friday, with participants from Amsterdam and York at noon (New York Time). Some of the participants in Amsterdam will already be celebrating the weekend (at least in their heads).
Why face-to-face communication is so important
Due to the speed of agile projects communication is more important compare to regular projects. The bullets below give the advantages of face-to-face communication.
* Whiteboards for drawing image. Face-to-face communication and being with a group in a room with a whiteboard stimulates and energizes the discussion and communication. You are able to draw anything to support your story and focus the discussion on the images on the whiteboard. A room with a whiteboard is the most powerful means of conveying information to a group.
* Non verbal communication. In face-to-face communication you, as sender, are able to verify if your message is getting through via the non-verbal communication of the group. If everyone is staring at you in a haze you know you are not transferring your message. I everyone is staring in a haze during a conference call you have no clue at all.
* Getting everyone involvement. Involvement in the discussion is a good helper in transferring information. Getting developers involved will help them see the business purpose behind requirements. Getting involvement will make the discussion and information more real for them.
* Commitment for marching routes and solutions. Agile project revolve around commitment of all stakeholders about the process (doing agile projects) and the content (requirements). Face-to-face communication will give the project manager the leverage for getting this commitment. Looking everyone in the eyes asking them “do you agree upon this approach” is really something different than letting everyone say “Yea, I agree” during a conference call.
* Help in demonstrations and getting approval. Face-to-face communication will also help during demonstrations of new models or build features. You immediately can see (or even feel) if this model or feature get’s the approval of the ambassador user of the system.
* Develop personal relationship. Face-to-face conversation will empower the development of a personal relationship (if there is a click). A team with members with a personal relationship will be more cohesive and go further to realise their common goal. And, of course, it is more pleasant to work with people you like.
Face-to-face conversation is the basis for good and effective communication. This is necessary and even essential in executing a successful agile project.
How to improve conversation during an agile project.
- When you can, prefer face-to-face communication above web/teleconferences. Even if this requires some of the team members to travel.
- Set a project culture that embraces lots of communication and conversation. Make this a topic in your project kick off (where of course all team members must physically attend).
- Make it a rule “there are no stupid questions; it is just stupid not to ask them”.
- Bring the team together on a regular basis. Create standing meetings for discussing the project’s progress, requirements and structure.
- And finally: set up an Agile project room. See the link below for the requirements of such a room. http://www.agilemodeling.com/essays/agileModelingRoom.htm
Easy and effective conversation and conveying information is the most important factor for your projects success. However in practice we think we can handle this conversation via sub-optimal technologies that introduce lots of opportunities for white nose, misunderstanding and distraction. Getting in your car and travelling for a face-to-face meeting is in almost all cases worth the drive. You will notice your projects will become more effective and successful.
Other posts about the AGILE Principles (soon to come):
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- Business people and developers must work together daily throughout the project.
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- Working software is the primary measure of progress.
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- Continuous attention to technical excellence and good design enhances agility.
- Simplicity–the art of maximizing the amount of work not done–is essential.
- The best architectures, requirements, and designs emerge from self-organizing teams.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.