How to communicate: Tools of the trade
One of the biggest issues I see on struggling software teams (although this is not limited to software) is problems with communication. Modern software is complex, and therefore our software teams can be complex. There are many groups within and external to the team that require information for successful delivery
- Developers
- Testers
- Engineering managers
- Product managers
- Business stakeholders
- Customers
- Upper level management
Here are my quick thoughts on HOW we choose to communicate.
This list is in ascending order — bias to use the ones at the top over the ones at the bottom
|
Discussion (meetings, phone, IM) |
Best for complex updates and impactful events. Maximizes understanding and reduces conflict via interactive communication. Have a whiteboard (or virtual equivalent) to ensure understanding around complex technical or business logic |
| Issue management / ticketing systems |
Best for long term item tracking, history, and status snapshot (NOT good for conveying major changes unless accompanied by discussion) |
| Wiki / OneNote / shared collaboration documents |
Best for capturing discussion outcomes and project status. May not need if tracking system offers rich enough experience to accommodate these. |
|
Best for “simple” updates. Email can point to Issues/Reports or Wiki. OK to start discussions which require documents or spec review (providing pointers to those) and then complete discussion outside of email |
I am obviously biased towards agile. The following Agile Manifesto values are represented here
Individuals and interactions over processes and tools
Customer collaboration over contract negotiation
Note on meetings
Meetings when done wrong go to the BOTTOM of the list. Specifically having too many people present who do not have a clear contribution to the meeting and/or meetings without clear goals. Bias for short meetings with small groups — a quick ad-hoc 2-person face to face (or virtual equivalent) often suffices. Then follow up with one of the other three communication tools to verify all are aligned on what was agreed, and to provide a history.
Comments
Pingback from Testing Bits — 1/18/15 – 1/24/15 | Testing Curator Blog
Time January 25, 2015 at 5:10 am
[…] How to communicate: Tools of the trade – Seth Eliot – https://setheliot.com/blog/2015/01/19/how-to-communicate-tools-of-the-trade/ […]
Pingback from Communication in Software Testing | TestknightTestknight
Time January 30, 2015 at 2:54 am
[…] by the way, but have a slightly different focus): • http://sjpknight.com/ill-communication/ • https://setheliot.com/blog/2015/01/19/how-to-communicate-tools-of-the-trade/ • http://rhythmoftesting.blogspot.de/2014/12/on-symbols-metaphors-and-understanding.html • […]
Pingback from uTest Takes: Best Testing Blogs From the Week of Jan. 23
Time January 23, 2015 at 9:53 am
[…] How to Communicate: Tools of the Trade: Simple but effective post from Seth Eliot that boils down (into a matrix) of how software teams can better manage communication, and which mediums are best for which communications (take note that while he favors meetings, many organizations aren’t holding them for the right…or any…reasons) […]