Slack-ing?

Slack is a well-known instant messenger and a great way to encourage frequent and fast individual or group communication, share materials and search past chat history. Whilst useful in these ways, it can sometimes be used too often and actually take precedence over interacting in person.

One of our Principal Software Engineers once (jokingly) threatened to ban Slack within my area since it was at risk of becoming the ‘easier’ or ‘more convenient’ way to communicate, despite someone sitting right behind you or being on the end of a phone. He also commented that ‘developers used to have two screens for coding; now they have one for code and one for Slack’.

There is the reality that we aren’t within the proximity of others to talk in person 100% of the time. Just recently my team came across the challenge of how we can ensure that everyone who needs to read a message does, and how the person sending the message can be reassured that everyone has seen it. We tried out the Slack plugin @must-read but it didn’t quite cut it. This kind of challenge is unlikely to go away any time soon, even with the advent of evermore feature-packed tools.

As with all comms, we need to choose the method and participants involved carefully in order to deliver the message efficiently yet effectively. Let’s continue the use of Slack (or other instant messaging tools) but let’s not forget the exponential value of communicating face-to-face or over the phone with our colleagues if we can. If nothing else, the extra distance will add to your daily step count.

Is a conversation worth having if you don’t actually remember what was said?

Whilst frequent and face-to-face communication does bring about a world of benefit, this can raise the challenge of traceability.

I’ve always loved a follow-up email and discussion summary with key points, actions and decisions made. For most of the meetings or workshops I’m involved in, I don’t believe communication in person is enough without appropriate follow up.

Whether it be a brief summary or photos of the output, I think any form of follow up is valuable however small. How many times have you been asked ‘what did we agree again?’, ‘what was it Dave said?’ or ‘what were the next steps?’. With a traceable point of reference, at least you then only need to spend 10 seconds recovering it rather than, worst case, spending hours having to have the conversation all over again or going down the wrong misremembered path...

That all being said, it doesn’t promise an easy life. Engineers don’t want to spend time trawling through emails, they would rather be coding. People change their minds mind too; so what was a decision yesterday may no longer stand. Agile practice also encourages us to embrace and encourage change.

For me, traceability does remain important though and should be considered as an activity that parallels our interactions — albeit using common sense and experience to avoid over-documentation.

Defining processes (but don’t call them processes)

When working previously as a consultant, I (and my clients) couldn’t seem to get enough of processes. However, I’ve since experienced that there are many who shun a process or, at least, what is labelled a process. Google tells me the definition of a process is ‘a series of actions or steps taken in order to achieve a particular end’. Do we not then all go about hundreds of processes a day?

Whilst the Agile Manifesto’s value suggests ‘individuals and interactions over processes and tools’, this doesn’t mean there shouldn’t be any processes at all. This also doesn’t mean that people and processes are mutually exclusive.

The Agile community suggests user stories are ‘a placeholder for conversation’ and I see that processes can be similar. Whether it be creating a new process or improving an existing one, they can provide valuable conversations, interactions and reference points. Processes also help us ‘inspect’ our ways of working and drive continuous improvement.