That
last posting was a little to high level. Especially for someone like me that likes things to become grounded — at least for one day! Most of my career has been in small companies building small products. Apart from places like Lotus and
Geac my employers have had less than 20 developers. This organization size has shaped my expectations of what is useful for a project to succeed.
The first document any project needs the "Product or Feature Digest" A template of which is
here. This document organizes the other documents. It is the one place everyone can read and get a grounding on the product and its implementation. If what is being built is very small then it might be the only document. Most sections of the document have an obvious purpose. However, the first two require further explanation.
I have never worked on a product or feature that did not change its goals. I doubt you have either. Most changes are refinements due to a better customer understanding, or due to initially unforeseen constraints, or revisions to feature priorities, or features removed or added, etc. The reason we keep product management's original document is that it was the locus of
everything that happened afterwards. The differences between it and the current revision gives the reader an understanding of the maturation of what is being shipped. For senior management, where their attention to the project is periodic, it helps bridge their previous understandings to a current understanding.
I like my projects to have this kind of documented grounding, but this does not make me waterfall methodology advocate. I agree completely with Kent Beck's statements in
Extreme Programming that software change is cheap. I like the agile methodologies that stem from this seed. I draw the line, however, that product management and software development is nothing more than reorganizing and implementing the
backlog. Developers need to know that what they are doing is coherent and concise. Otherwise the work becomes little more than hacking at the coal face — an endless drudgery.
Within a project I don't care much what tool you use to enumerate the work items and their dependencies. What I do care about is that the discussions related to these work items are located in that tool. If the tool's commenting interface is cumbersome then don't select it. If you do, your staff will not use it. Let me repeat that. Your development staff, as a whole, does not like to write stuff down, and if you make it inconvenient to do so they will attempt to make progress without using it [1]. When this happens the only record you will have of the obstacles found and decisions made will be in heads. When the project ends and the staff disperse you will have little from which to draw on to hold a successful postmortem. Worse, however, is that your development organization is doomed to remain, at best, at
Level 2.
Lastly, for now, where do instant messaging tools sit in a software development organization? For me, at the bottom of the communication modes. What message is so urgent that it can't wait until tomorrow morning or some other synchronization time [2]? For smaller organizations where one developer might have multiple roles the interruptions will be harder to control, but they can be controlled. The head of development needs to take control of them.
The other problem with instant messaging is that it becomes the primary mode for discussions and decisions. Instant messaging is technically an asynchronous form of communication, but it is rarely used with that expectation [3]. Instant messaging has become akin to oral communication with all of its concomitant weaknesses. It is too easy for a senior staffer to initiate, for example, a Slack conversation to come to a decision than it is to open an issue and discuss it there or simply wait until a next meeting. Or the developer who interrupts everyone to ask a question that could have been answered elsewhere with a little effort on his or her part.
At this point I am sure you are thinking I am a madman. I have the developers sitting alone at his or her desk coding and communicating only online and only asynchronously. It would be a lifeless place without actual face to face communications. Hallway conversations and meeting are vitally important to a development organization. Important enough to write about separately in another posting.
[1] Jira is a good example of a bad interface. Atlassian has put so much effort into enabling customizability that its has made the hourly effort of interacting with issues & comments to be on a par with the one time effort of creating a set of project "status" tokens.
[2] For example, place all announcements on the kitchen refrigerator or on the bathroom mirrors.
[3]
Why We’re Betting Against Real-Time Team Messaging criticism of Slack is spot on.
