今日推荐开源项目：《茶余饭后 Best-websites-a-programmer-should-visit》
今日推荐英文原文：《Too Many Conversations?》
今日推荐开源项目：《茶余饭后 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.
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.
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.
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/
