開源日報 每天推薦一個 GitHub 優質開源項目和一篇精選英文科技或編程文章原文,堅持閱讀《開源日報》,保持每日學習的好習慣。
今日推薦開源項目:《茶餘飯後 Best-websites-a-programmer-should-visit》
今日推薦英文原文:《Too Many Conversations?》
開源日報第602期:《茶餘飯後 Best-websites-a-programmer-should-visit》
今日推薦開源項目:《茶餘飯後 Best-websites-a-programmer-should-visit》傳送門:GitHub鏈接
推薦理由:閑著無聊的時候不知道看啥?這個項目應該能滿足你打發時間的需求:因為要轉一圈這麼多網站是太久了。顧名思義,這個項目是對程序員有用的網站合集,包括學習英文,入門級項目,AI 等等,作為了解新知識的指引或者打發時間掃一眼都不錯,畢竟沒準哪天就會發現新的樂趣所在——這個世界上存在的東西是在太多了,即使不局限於程序員方面,多去需求別的方面的樂趣也不是壞事。
今日推薦英文原文:《Too Many Conversations?》作者:Adam Knight
原文鏈接:https://medium.com/@adampknight/too-many-conversations-945514eaa81b
推薦理由:有一說一,經常開會真的沒啥用,除非真的有這麼多事情需要大家一起討論

Too Many Conversations?

Is criticism of a 『meeting culture』 undermining one of the key agile principles?

I was at a daily stand-up not long ago and a developer gave an update that went something like this
「Yesterday I was mostly in meetings so I didn』t get a lot of work done, I did find some time to fix a bug and do a code review.」
thereby expressing a very clear opinion on what real 『work』 was to them — and time spent in meetings clearly was not it.

This wasn』t an isolated event. I heard similar updates from the same developer many times, and I』ve worked with others who also expressed similar views. The sad thing here is that all it took to achieve the label of 『meeting』 in this person』s eyes was the presence of more than one person discussing a work related topic, or as I like to call it, a conversation.

When Meetings go Bad

Let me say right from the start that I believe a heavy meeting culture is a pain and impacts productivity. Long, regular meetings involving lots of people are an expensive business and can dominate the calendars of middle and senior managers if not kept in check. The perils of the meeting culture are well covered elsewhere (and I』ll include some links in the references at the end of this post as to the best pieces I』ve read on the subject), so I』ll stick here to summarising the three main issues I see with a meeting culture:
  • Too many people involved. It』s simply unnecessary, and expensive, to have everybody in every meeting. 8 people in a 1 hour meeting is a whole day of work. If the output wasn』t worth giving over an entire working day to, then there were too many people in the meeting.
  • Too long. Another challenge is allowing far too long for meetings that don』t merit the time. Parkinson』s Law relates to the fact that work expands to fill the time available, and rarely do I see this more apparent than in a 1 hour scheduled meeting.
  • Too frequent. If a meeting is regularly scheduled and you』re not making valuable decisions each time you sit, the meeting probably doesn』t need to be on repeat. Those of us in roles that interact with a lot of teams and departments find that their calendar is easily swamped when regularly scheduled meetings are a standard activity in a business.
I』ve been personally guilty of falling into these traps on occasion, though I find that an awareness of the problem is the first step to avoiding it. What bothers me is that the 『meetings』 the individual at the start of this post was referring to were nothing like what I』ve described here.

Conversations aren』t meetings

「The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.」
Despite being explicit in the 12 principles of the agile manifesto, I find that this principle is one that is most heavily resisted by some individuals. Some still persist with the opinion that unless you』re coding you』re not doing valuable work. It』s frustrating how people that are otherwise enthusiastic about agile principles would so strongly reject one aspect that is so fundamental to them.

It』s unsurprising that the group that I』ve seen this most commonly is software developers. I reject the stereotype that developers are an antisocial bunch, but I do believe there are some pervasive practices that promote the idea that the only valuable work is coding:
  • Some of our mechanisms to measure development 『productivity』 specifically promote at-desk coding as the sole measure of progress — yes 「source lines of code」 I』m primarily thinking you, however agile sprint velocity and kanban status columns can also be abused to the point of promoting the completion of tasks over the successful delivery of value.
  • Our hiring processes similarly focus predominantly on the purely technical. I』ve yet to see a developer hiring process that required a developer to actually speak to someone to establish the nuances and assumptions of a user problem before undertaking the obligatory coding challenge. More often we place a technical coding problem in front of them and rely on discussion with other deeply technical roles as the only means of assessing softer skills.
  • Having discussions raises criticisms and questions that take time to resolve. It』s much quicker to reach a solution based on how you see it working and defer critical feedback to the end than it is to have your thinking challenged up front. Discussions amongst stakeholders often expose the nasty, real-world complexities that undermine our nice elegant solution models and feel like they are slowing development progress (even though this kind of activity actually vastly reduces the effort needed during testing and review). It』s hardly surprising then that some folks prefer to avoid them.
With these factors driving the perspective that conversation takes away from productive work, how can we promote the need for healthy interaction to support productive development?

Rephrase the problem

There are practical ways to reduce the negative perception of meetings. Where they are needed try to encourage sessions that are :
  • Focussed on a specific decision and just long enough to make that decision. I find it useful to focus on coming together to agree direction and identify next steps rather than trying to solve all the problems at hand in one long meeting.
  • Arranged as near to the time needed as possible. Try to organise at just the right moment to prevent blocks whilst not being so ad-hoc as to impose interruptions — people need time to plan their quiet work. If you have a daily standup (is anyone brave enough not to?!) then this is an ideal time to discuss and arrange appropriate times for any conversations needed.
  • Involving only the relevant people. Have enough people in the conversation to avoid excluding people affected, but no more. In other words — invite the testers.
Keeping discussions lightweight, on-demand and just-long-enough will certainly help to avoid becoming an organisation that is paralysed by meeting culture. Sadly, as I』ve discovered, it won』t remove the challenge of the 『we have too many meetings』 argument. This is a problem that needs to be addressed at the cultural as well as the practical level.

Instead of referring to 『meetings』 try talking about 『conversations』 or 『catch ups』.

「Yesterday I had a conversation with the CTO around to decide how we were going to progress the security rollout, and a really useful catch up with Andy and Sarah to decide the final tasks needed to complete their active story.」

This isn』t just idle semantics. The word 「meeting」 conjures up images of a formal event, with pre-defined parameters that is scheduled to fill an allotted time slot. Sometimes this formality is required but often it』s overkill for the needs of software development teams. We tend to use the term 『catch-up』 in my company to imply a short, single-point agenda conversation with minimal attendees organised at the appropriate moment to make a decision. These catch ups are requested and scheduled at or just after stand-up so people can loosely plan them in on the day when they are needed. Often a catch up involves only two people, but each of those people has committed to the time to tackle the decision at hand. This commitment is key — someone wandering over to your desk or calling on Skype is an extremely effective low friction way of having discussions, but in such a situation it』s perfectly acceptable culturally to terminate the conversation suddenly for other commitments, like being overdue your 11am coffee, or hearing the sandwich van arrive. What we』re aiming for is the lowest friction, minimal impact conversation that is scheduled enough to prepare for and plan other tasks around.

Look at who you』re hiring

When using agile methods it』s critical to have people that respect the value of conversation in decision making, and enjoy collaborating with their colleagues to deliver value. If your team contains people who prefer to stay at their desks building poor software based on false assumptions, then you need to look at who you are hiring.

I』m always open to being challenged, and when there has been valid argument in the 『too many meetings』 criticisms I』ve taken it on board. Instead what I』ve seen recently was that the individuals most critical of time spent in conversations, were also the ones whose work most frequently missed the mark. They were the ones whose solutions just weren』t thought through. At best this involved having spend far more time in reworking and reviewing that was necessary, at worst it involved having to simply ditch the changes and start over. Conversation is essential in the process of having your work held to account, and avoiding scrutiny through the 『too many meetings』 argument is disingenuous. The simple fact is that you can』t avoid scrutiny for ever and the later you leave it, the harder it hits.
下載開源日報APP:https://openingsource.org/2579/
加入我們:https://openingsource.org/about/join/
關注我們:https://openingsource.org/about/love/