Has anyone here adopted a <handbook-first approach...
# tribe
a
Has anyone here adopted a handbook-first approach towards documentation in an organization that doesn't have proper documentation practices? I'm also interested to know if anyone has moved towards async ways of working. To be specific, I'm trying to understand these things: • How do you document solutions (product related)? Is this outside of the handbook? • If you use a tool for running scrum, what do you document in tickets within this tool? • How did you bring the behavioural change in your team to move away from Slack or other IMs for sharing knowledge?
➕ 3
f
I'm following up on this. These questions @ancient-fireman-19380 asked are very relevant and I would love to know others' experiences on the same. We have tried adopting a handbook first approach. The biggest of the 3 problems (listed above) for us was that most of the knowledge sharing seems to be happening in slack (or even worse, in DMs).
h
For the 3rd point, the solution will be nothing apart from constant hawking from the leadership/management. • Keep an eagle eye out for unexpected behaviour and keep repeating the message • Maybe do weekly check-ins/reviews on issues faced by team/progress made in implementing and iterate approach/share team update as needed • You can think of incentivizing team to adopt new behaviour
b
• How did you bring the behavioural change in your team to move away from Slack or other IMs for sharing knowledge?
My org deletes Slack DMs at the end of every week. It seemed harsh at first but now I see the point. Now, Slack is only used for huddles and outcomes are documented in Asana. ‘Leave the paper trails for every decision made’ as they say. Channels are exclusively used for announcements and nothing else.
b
I can chip in a few things that I have observed at my current assignment - 1. The org has a policy that says all teams MUST adhere to the documentation policy. The policy says that all LIVE documents like product documents must reside only in version controlled documentation software, in this case Confluence. Teams are free to use Sharepoint to store STATIC documents like a PPT. The STATIC documents stop serving purpose after a small time. For source of truth, everyone is asked to refer to confluence. Email is also considered static. 2. JIRA - for Scrum - It has user stories, epics, tasks and subtasks. Its purely for project planning. All important decisions are logged as Architecture Decision Records. Code document must reside adjacent to the code in the same source control. 3. This one isn't a problem if the above two are enforced. For behavioural change, there was an effort to perform a bi-weekly sessions with the LEADS of each departments and they were given the responsibility of adherence on behalf of their own team. I hope this helps.
➕ 1
🙌 1