一个项目管理实践课程的学习

由于回来之后加入了一个敏捷社区,机缘巧合下发现了这个课程。课程一共20讲,一共用时20天。这20天对于我来说其实增加了不少焦虑感,每天的固定安排是1.复习PRINCE2 Agile,2.阅读The Lean Startup,3.观看Development That Pays的视频,4.学习这门课。感到抱歉的是没有多余的精力看一些额外感兴趣的书了,原因应该就是那份增加的焦虑。比起其它三个的学习,这么课程对我来说可以算是每天的放松环节,说实话它并没有给我带来过多的新的知识,而是将我之前所经历的所学的简单并系统地进行串联,但是受益匪浅。

课程体验

雷老师制定的这门课程以PMP框架为基础,通过她实际工作中所经历的事件和想法对项目管理如何在实际工作中系统应用做了解释,其中还加入了一些敏捷开发以及工具方法的介绍。其实这算是我第一次接触到PMP的具体知识,虽然它早已存在于我之前多年的工作当中,我想无论是作为一名开发还是产品经理,当看到5个过程和10个领域的时候都会猛然发现原来之前早就干过这些事情。可问题就在于,是否有正确地执行每个过程,是否有恰当地完成每个领域的工作,我想经历过的项目或者工作中发现的、暴露的、无法忍受的那些问题便是答案。

一提到PMP,我总想拿此与PRINCE2做比较。曾经看过网上有人回答为何PRINCE2在国内水土不服,而PMP却扩展迅速,他把原因归咎于国内企业的管理方式上。单从这两种框架的结构上比较(只是从现在看来,还没系统地学习PMP,可能之后的观点就不一样了),PMP主要以围绕PM为中心开展的项目理论,而PRINCE2中PM的角色出于中间层,他的权利来自于其上层的Project Board的授权,对上需要接受Project Board对项目的指导,对下需要直接管理项目。相比之下PRINCE2对项目经理之上的角色做了系统的定义,因此对应的权利和责任也有了明确的划分。PMP把需要管理的领域区分地更为细致,而PRINCE2通过将过程分割成多个stage来完成阶段性的管理工作。不过在我现在这个阶段还暂时无法完整地回答为什么在中国PMP更有优势这个问题。

相比于之前在学校以及准备考证的过程中的理论学习,这个课程更贴近实际工作,无论是在硬技能和软实力的介绍中雷老师都用到工作当中实际的例子进行说明和解释。从这些直观的故事中第一个感受就是原来项目管理如此简单,原来工作中所发生的问题都不是困难。这种错觉时常发生,就像读完The Lean Startup后就可以完美创业,读完The Practice of Management之后就可以掌控一家企业,读完Das Kapital就可以领导无产阶级大革命一样自负。可很显然的是,当然不行。存在这些错觉的真正原因在于,并没有尝试过将学到的理论和技能应用实际。雷老师有一讲专门提到了这个问题,掌握知识只是第一步而已。

其实在实际应用之前,也就是还在学习的过程中,我已经有非常多的疑问并未想通的问题。比如小勤通过规范制定好规划后项目就显得十分顺畅,小云经过一个阶段的思考后就显得进步飞快。我的意思是,在案例展现了运用我们所熟知的技能和技巧之后卓有成效的结果,但从实际经历来看,这些成功感觉十分地突兀。不可否认雷老师的课程内容十分有意义并且对我帮助很大,但针对这些所列举的案例只能说明如何应用相关的管理技能和工具以及如何在自身已经具有一定实力后在项目管理过程中的成效,而并不能完整地说明成功的原因。就像一位大夫拿着一颗药丸说,吃了病就好了。不过另一方面这也更加促进了结合课程知识和实际经历的反思和进步,每当看到一个案例时总会先想之前遇到这种情况是如何应对的,现在学完了之后是如何应对的,并且能否在案例中给出的解决方案进行升级。

接下来

准备PMP认证考试!

不可否认,从最直接的好处来看,多一个专业证书对工作很有帮助,更何况是一个在中国认可度最高的项目管理证书。但我更希望的是通过对PMP的系统学习,能让自己看清之前工作中的不足,能让自己从多维度思考问题,能让自己离个人的愿景更近一步。至于我对未来定义的个人愿景,我希望是:

To build a productive and enjoyable working environment.

Daily Standup in My Notes

Purpose

According to a pile of evidence shown in the Daily Scrum in the Scrum Guide, such as

The Daily Scrum optimises the probability that the Development Team will meet the Sprint Goal.

and

This is a key inspect and adapt meeting.

, I would say the fundamental purpose of Daily Scrum is

to help the team meet the Sprint Goal

through

inspecting progress since the last Daily Scrum

and

adapting the way of working during the upcoming Sprint work.

Basic rules

Five essential rules of Daily Scrum have been concluded in the playlist of Daily Stand-up Meeting (aka Daily Scrum), within which you can dive in the detailed explanations of these five basic rules. Although there are quite a lot of controversies about some of the rules, I do agree with all of them which are listed as follows.

  1. must do daily stand-up
  2. must do stand-up
  3. same time every day
  4. keep it short (not simple, but efficient and effective)
  5. stand up

And there is one additional rules that I would like to add to the list, which is

6. Each turn, only one person talks

As far as I’m concerned, why this rule is deemed as one of the bases can be answered from the following prospectives. Firstly, one of the Scrum Values guides the team members should respect each other, and one of the specific ways of respect is listening and not interrupting others’ speaking. Secondly, uninterrupted speaking ensures the meeting finished in the fix timescale, rather than lengthening the meeting duration in order to in-depth discussions. Then, the whole team would focus on figuring out the progress and blockers toward the Sprint Goal in this manner. Lastly, the clearly identified issues could improve communication and collaboration after the meeting accordingly toward completing the work as a team in the Sprint Backlog.

Attendees

The Daily Scrum is an internal meeting for the Development Team. If others are present, the Scrum Master ensures that they do not disrupt the meeting.

The Scrum Guide

Speaking Order

This is an often ignored but important point of the Daily Scrum. An appropriate mechanism of speaking ordering will facilitate the Development Team members concentrating on what others are presenting as opposed to preparing speaking or thinking of other things, so as to improve communications, identify impediments and promote quick decision-making efficiently and effectively and so forth. Therefore, I suppose if the speaking ordering of each attendee would not reveal until he or she speaks, it should be working well to conflict with this potential tendency. The detailed discussion can be found in The Talking-in Order during the Daily Standup.

Being Late Penalty

In order to the agreement that the Daily Scrum MUST start on time, there may be attendees showing up late for the meetings. With regards to the penalties for the late arrivals, there are some of the most common rules including gold coin penalty, singing or doing push-ups, etc. However, Kym Gilhooly has recognised the drawbacks of these penalties and pointed out that these penalties cannot eliminate the problem of arriving late ultimately in 6 basic things you shouldn’t be doing during daily stand-up. Hence, the punishment for individuals being late is not a rather good solution. Conversely, it is better to let participants fully relieve their anger due to their time not being respected.

Structure

The Three Questions

The first one is the classic three questions (Yesterday-Today-Obstacles) around the work has done and will do, and the identified blockers. This is the most commonly used structure that has been introduced as a typical example in the Scrum Guide. And I also found an example IBM Agile Academy: Daily Stand-up Meeting that an Agile team conducted the meeting in this manner in IBM. The three-question structure provides a process for the meeting keeping participants pay attention to the work toward the Sprint Goal, as opposed to talking about all kinds of things that don’t relate to the team.

The Kanban-style

Kanban-style daily stand-ups focus more on:

  1. What obstacles are impeding my progress?
  2. (looking at the board from right to left) What has progressed?

In the episode Agile Daily Standup – How To Walk the Board (aka Walk the Wall), the interpretation of looking at the board from right to left has been indicated.

The Combination

It was pointed out that the three questions structure may cause members to focus more on their personal work, while the task-based structure may lead to the scattered speaking content. I reckon the combination of the two structure could eliminate the concerns. The specific process is each participant answers three questions sequentially according to the relevant tasks on the board from right to left.

In this manner, the three questions may still be used but will be from the perspective of the work item, rather than the person. As a result, knowledge transfer and internal communication would be greatly promoted and the Development Team members could take more opportunities to ask for help or collaborate ultimately.

The Three Questions again

The order

Let’s go back to see the purpose of Daily Scrum. I found this to be a progressive process, which is from reviewing the work that has been done to plan the next work in turns to optimising the possibility of achieving the Sprint Goal similarly to the Build-Measure-Learn feedback loop introduced in the Lean Startup framework. Consequently, I would say that the plan for the next work produced during the Daily Scrum should consist of two parts: the developing work and adaptations. In this case, the done work has been done and the spotted impediments need to be clarified before the plan is determined. So the priority of the three questions I suggesting could be:

  1. What did I do yesterday that helped the development team meet the sprint goal?
  2. Do I see any impediment that prevents me or the development team from meeting the sprint goal?
  3. What will I do today to help the development team meet the sprint goal?

The Fallacy

When I read some introductions and guidances of Daily Scrum, there may be something wrong I feeling. The above screenshot is the example indicating the three questions used in Daily Scrum. Will all questions be answered around the individual work? This is a misleading utterly. Although there is only a nuance between the questions displayed on some websites and the questions on the Scrum Guide literally, working as a team and helping to team meet the Sprint Goal should be strongly emphasised. This has been proved by the comment left by Dwayne Stroman in one of the misleading introduction episodes of Daily Scrum.

The 3 questions can easily lead this into a status meeting. The team should already know progress through collaboration. The daily scrum is about a new plan for the day, not a report of what I did and what i’m going to do. The questions should be “what progress did we make as a team?” and “what should we focus on today as a team?” and “What impediments do we face as a team?”

So, just use the version of the three questions presented in the Scrum Guide and keep working as a team in mind.

  1. What did I do yesterday that helped the development team meet the sprint goal?
  2. What will I do today to help the development team meet the sprint goal?
  3. Do I see any impediment that prevents me or the development team from meeting the sprint goal?

关于我买到了一本盗版书

准确来说,我买到的这本书其实连盗版都算不上,这是一本影印书。

一个多月前我被推荐了这本Essential Scrum,其实之前也有大致了解,书中内容覆盖了推行Scrum过程中遇到的多数问题的解决方案以及工具和方法推荐。我想这正是我现在需要的。因为我从系统地接受敏捷开发的理论都是通过英文的形式,因此这本书的英文原版成为我的购买目标。

在中国各大网站搜寻一遍后发现有出售这本书的商家并不多,因此我选择在某猫上好评较高且号称国企的中国国际图书专营店中代购此书。下单后被告知因为海外购买且是疫情期间需要等待,60天内将会发货,这对我来说并不是什么问题。一个多月的时间后,也就是最近,当我收到这本书时却感到十分愤怒。作为一个了解常识且判断力正常的普通人的我,对于这本书的第一反应就是:我花了几百块钱等了一个多月结果买到了一本影印版?

书为A4大小,无论是封面还是内容页四周都有留白2厘米左右;第一张封面图并非照片像素问题,而是肉眼可见的印糊了;书的书脊空白,完全没有内容;书中的插图质量十分模糊;书的背面除了二维码以外全部空白。这就是我通过这家国企商家代购到的英文正版书籍。

拿到书的第一时间我同商家联系,商家以负责产品的同事已经下班为由让我明天再联系。第二天他们主动找到我,但始终坚持书是从美国购回,并且将书本出现此类问题归咎于出版商。最后让我无力反驳的是他们真的提供了一张采购证明。

证明中所显示的信息,包括日期、书名以及编号都能与该书对应。我表示深深佩服,已经十分明显的一本影印书最后还真成了正版书了。我想过联系国外供应商和出版商,但发现十分费时费力。最后我只能选择退货退款,自己还倒贴了五元运费。

没错,发这篇文章纯粹是为了表达我的不满。最后再次强调本次购买这本书的销售方是号称国企的:中国国际图书专营店

The Talking-in Order during the Daily Standup

When I search for some cases of Daily Standup, there is a very interesting point that people usually concern with, which is the talking-in order. Two questions emerge from it commonly as follows.

WHO IS THE FIRST?

and

WHO IS THE NEXT?

The Scrum Guide introduces the rules of Daily Standup meetings so simply, in which there is even no emphasis on the speaking order. So why? Are the answers to these two questions important? I reckon YES.

Firstly, I would say if there is no team member who has considered these kind of questions, there must be a fallacy among the Agile team. Who can decide which one’s speaking triggers the current Daily Standup meeting? And who can take charge of prioritising the speaking sequence of the development team members? Nobody can, not even the Scrum Master, but only the Development Team itself. The Scrum Guide indicates that

The Scrum Master ensures that the Development Team has the meeting, but the Development Team is responsible for conducting the Daily Scrum.

As a self-organising team, the Development Team should make an agreement on the speaking order. If each member is asked to talk in sequentially by the facilitator, then it would be a bureaucratic report meeting.

Secondly, The Scrum Guide defines the Daily Standup is a 15-minute time-boxed meeting. The Development Team should inspect the work and plan for the next in such limited timespan in order to optimise the probability of meeting the Sprint Goal. Hence,

conducting Daily Standup meetings efficiently and effectively

is a crucial work the entire team has to contribute to, as opposed to performing simple status meetings. This is also the fundamental purpose of raising the two issues mentioned above.

Let’s have a look at some widely used approaches applied for the speaking order introduced by Jason Yip. Who is the person talking in first? One conventional solution is that last arrival speaks first, while Jason has also pointed out a tendency that “the last arrival is also likely to be the person who is least prepared to start off the meeting well“. With regard to the priority techniques (also includes picking up the first speaker), Jason lists three of them in his post It’s Not Just Standing Up: Patterns for Daily Standup Meetings, which are predictable ordering, unpredictable ordering and ‘Take a Card’ game. The detailed rules, benefits and drawbacks have been identified in the post. Although Jason did not point out the shortcomings of ‘Take a Card’ game, I do not think that this approach can help the team accomplish the fundamental purpose proposed above. There may still be a tendency to prepare or think of other things rather than pay attention to what others are saying in this manner.

As far as I’m concerned, a simple random system could be considered to build. Since the team has been formed ready, the Scrum Master input the names of all development team members into the system. At the beginning of Daily Standup meetings, the last arrival presses the button to produce a member’s name randomly who will speak first. After he or she finished, press the button to introduce the next member to talk in, and so on. I suppose the system could help each member focus on the current speaking and facilitate the efficiency and effectiveness of the meetings. Any suggestions?

Calm Down Please

Let’s talk about one of the bad news today.

I was informed that one of the job applications has been rejected. The company I applied for is one of the few firms that meet my expectations: well-known, large-scaled, IT industrial, doing Agile, etc. etc. But I was not surprised by the result because I have realised there will be a struggle again for me to seeking an ideal job when I search for opportunities online. The biggest obstacle is that one requirement of the positions I would like to apply is having abundant experience in Agile practice in business, while I have only obtained some certifications but little experience with working as such a specific position.

I admit that I am a ‘perfectionist’. Due to the lack of relevant experience, the only thing I can do to make myself ‘perfect’ is grabbing the theoretical and empirical knowledge from books, articles, videos and so forth. It’s completely true that the accumulation of theory cannot make up for the lack of experience. But at least keeping learning helps me keep thinking. In fact, I am not in a hurry to find a job right away, because my goal is to do the things I expect, not just a normal job. More precisely, the only factor that makes me feel anxious now is not that I can’t find a job, but that I can’t immediately inspect and adapt my thinking in practice.

Anyway, I believe the passion for my next career will always exist in my heart. And thanks again to the stranger who posted the sentence below which means if you are missing yourself, choosing the more struggling path to go. This has inspired me once, and it gives me courage again.

关于《罪与罚》

其实这本书在我的书架上已经有几个年头了,最近让我重新翻起这本书是因为另外一本诺贝尔文学巨匠鲍里斯·帕斯捷尔纳克的《日瓦戈医生》。虽然这是一本发生在上个世纪初的故事,但旧时代俄国的文学像一个充满魔力的世界不断吸引着我。

这本著作的灵感来源自当时的一起发生在法国的诉讼案,陀思妥耶夫斯基在自己主办的杂志上发表了对这起案件的看法:“卑劣的天性和对贫困的畏惧,使他变成一个罪犯,而他竟把自己说成是自己时代的牺牲品”。我想这也是他对《罪与罚》这个故事的主观说明。但在第一遍阅读此书时,直到我读到这本书的第六章(本书包含了六个正式章节以及尾声部分)之前,不知出于何种原因,我的内心一直不相信主人公是出于如此错误的且直接的观念。这种观念指的是书中所描述的拉斯科尔尼科夫提出“超凡的人”与“平凡的人”的理论。我想可能的原因有两个:第一,书中第一次描写罗佳对他的这种想法的内心感受是对于自己能有这种可怕的想法并且已经想了一个月感到“肮脏,下流,卑劣”。可与此同时他又被一股“无形的力量”所引导去将这种想法变成现实。而在这件事发生之后,他同样在自首和苟活之间摇摆不定。这让我觉得主人公可能是出于可能是出于其它更深层次的想法才会如此反复。可我未曾注意到的是,主人公的名字拉斯科尔尼科夫,俄文愿意是“分裂”,指具有分裂的性格。他不止善良,而且邪恶。第二,从拉斯科尔尼科夫的身上我看到了自己的影子。我想这是最重要的一点,我承认在自己的内心深处曾有过这种矛盾的想法,却不敢正视一个同我有一个想法的人竟会做出如此卑劣的行径。主人公所发生的故事就像是自己犯下的错,因此想拼命为自己辩解。有趣的是,最近深受大家喜爱的罗翔老师在前些天也做了一次关于这本书的分享,他提出了一个问题是:我们每个人是不是都有非常自我的时候。另外,当谈及这种“超人”主义理论时,大家总会想起尼采,可值得注意的是,这本书在尼采提出精英超人理论前就已经面世。其实有关这一类的话题常出现在各类动漫中,我第一个想到的是当年风靡一时并引起巨大讨论的《死亡笔记》,这是一个讲述在现实世界中一位男孩获得了一本一旦写上名字就会导致死亡的笔记,并借此笔记杀死那些逃避法律制裁的罪犯的故事。显然,从一开始的主观视角来看,这是一件大快人心的事情。但事实上这早已无视了人类的基本道德法则,任何一个人都不能拥有决定其他人生死的权利。另外一个类似的故事发生在近几年十分火爆的《复仇者联盟》系列电影中。但相比之下,《罪与罚》的故事更贴近现实,更能让我感受到那种身临其境的偏执和错误。因此,这本书给我最大的收获并不是让我意识到“超人”理论的谬误(至少虽然我曾有过类似想法,但始终认为社会基本道德是无法违背的),而是生而为人,对于理想的执着可以是偏执的,但在付出实践的过程中切勿忘记那些关心和愿意为你付出的家人和朋友,一个以自我为中心的、自私的理想和实现理想的过程是毫无意义的

这本书最吸引我的部分是第一章和第六章,这章分别主要描述了罗佳(主人公的小名)在实施犯罪前以及认罪时的心理活动,以及书中的每个主要角色的刻画。正如此书的译序中所说,陀思妥耶夫斯基在这本书中的非凡功力体现在人物刻画上。因此,我想主要基于这两章的内容,从我的主观视角讨论其中几个我最印象深刻的角色。

马尔梅拉多夫

九等文官,马尔梅拉多夫,俄文原意是”水果软糖“。他认为贫穷和酗酒并非罪恶,而行乞却是。理由是乞讨是对自己人格的出卖,精神的侮辱。但于此同时,因为他对自身以及家庭的不负责任,导致他与前妻所生的大女儿索尼娅被迫获得“黄色执照”来赚取支撑全家的生活费,并且水果软糖还从她那索要金钱用来继续喝酒。这是多么讽刺的一件事情,马尔梅多夫的形象从很多方面的矛盾点中被刻画得十分可怜却可恨:他爱自己的女儿,但他却宁愿让自己的女儿做出比行乞更加罪恶的同时出卖精神和肉体的事情;他爱现任的妻子以及他们的孩子们,却每天只能给她们带来更多的物质压力和精神折磨,“一个月前,当列别贾特尼科夫先生动手毒打我妻子的时候,我却酒醉醺醺地躺在床上,难道我就不感到痛苦吗?”、一边夸赞着自己的妻子并且深受苦难一边拿妻子的物品换酒。他“总是尽力设法为自己辩白,如果可能的话,甚至试图博得别人的尊敬”。可能我的目光着实太过短浅,在我看来马尔拉梅多夫的形象是这本书中最令人厌恶的。

拉祖米欣

书中初次对拉祖米欣的描写是:“善良到了憨厚的地步”,“他的酒量大得没谱,喝起来可以不休无止,但他也能滴酒不沾”,“任何失败也从来不会搅扰他内心的平静,任何恶劣的环境似乎也无法使他感到沮丧”。或许他并不能算是罗佳的对立面,而是一种超凡脱俗的人格的存在,一种绝对理想化的人物。因此,在我印象中拉祖米欣是这本书中唯一一个只“活在”书中的人。他与罗佳相识一年半,却愿意为这个自甘堕落并时常恶语相向的朋友牵肠挂肚。不像索尼娅,虽然在书里她是作为“神的信仰”一方的存在,可她所做的事情,例如为了维持家中生计选择出卖肉体,为了罗佳自愿跟随到远东监狱等等,都是来自她所处的社会、她所生在的家庭等多方面因素作为铺垫。我想,唯一一个让拉祖米欣看起来像“人”的地方在于他对杜尼娅的爱慕之情吧。

波尔菲里

这位负责这起凶杀案的警察局侦查科长的戏份在第六章才多了起来,并且几乎每次都是以与拉斯科尔尼科夫的交谈或者对峙的形式出现。在我看来波尔菲里代表着罗佳心中对基本伦理道德的恐惧和对“超人”理论的质疑的一面。

罗佳在事件后依然保持着缜密的思维和清晰的想法在某些事件上,包括和妹妹原未婚夫的首次见面(虽然确实因为他的心理混乱导致粗鲁的相处方式)以及还是彼得,陷害索尼娅时现场他的说词等。但他与波尔菲里的每次见面都十分紧张,相比之下,波尔菲里却表现出如常的轻松(可在警局他的办公室中,虽然也是如此,但是最后被男主发现了他也紧张到哆嗦)。过程中一直没有从波尔菲里的角度透露他对罗佳的看法,并且都是从罗佳的角度刻画他内心是如何怀疑波尔菲里看穿这一切的。在作者不断描写罗佳精神上的强烈活动的对比下,以及他们每次交谈的过程中罗佳的愤怒和波尔菲里的圆滑,让人在阅读的过程中一直担心他说设想的一切会不会像上面所提到的那些事件一样正确,还是说他与罗尔菲里的对决只存在于他自己的脑子里。在波尔菲里提出关于罗佳逃跑的可能性时,他自答罗佳肯定不会做出这种事。只有“庄稼汉会逃跑,时髦的教派信徒会逃跑”,因为他们是别人思想的奴隶。与其说是托尔菲里攻破了这起案件,更像是罗佳自己内心深处的挣扎的结果。托尔菲里从毫不知情到最终的真相揭晓,他都像是一个倾听者和引导者,使罗佳一次次主动透露线索。

维斯德里盖洛夫

这是我最喜欢的角色。

第六章之前他基本上都是在别人的描述中存在的角色,从拉斯科尔尼科夫的母亲以及妹妹的信里、话语里开始。在罗佳的母亲的信中交代了杜尼娅所遇到的痛苦经历的经过,这让人先入为主的认为维斯德里盖洛夫是个彻底的混蛋。可最后提到正是因为维斯的“幡然悔悟”,才交出了证明杜尼娅清白的关键证据,一封杜涅奇卡为了拒绝维斯的信。维斯真是出于“怜悯杜尼娅”而这么做的吗?一种可能是他原本根本不想让杜尼娅遭罪,因为他是真的爱她。

在波尔菲里直接在他面前表明情况后,罗佳的第一个想法是去找维斯德里盖洛夫,有两方面原因,第一他将能为自己逃脱责任的最后机会寄托在这个混蛋身上,第二是为了警告他消除对杜涅奇卡的幻想,希望能在最后替妹妹解决这个潜在风险。这次见面没有过多的对罗佳的心理描写,不不像之前见面中那些气愤、憎恶等情绪不断的显露,就算听到维斯德里盖洛夫说起他混蛋的往事以及他和杜涅奇卡之前发生的纠葛。这显然对于通篇故事多数时间都在暴躁焦虑情绪下的主人公显得十分奇怪,如果说真是因为罗佳贪生,虽然说得过去但是这未免显得太低俗。因此在他们整个对话过程中我反而更希望罗佳能像第一次与维斯德里盖洛夫见面时宣泄着直接且饱满的厌恶。

维斯德里盖洛夫可以算是一个普通人或者说普通读者,从他的角度看待罗佳的行为和想法属于浮于事实最上层的内容,即使他同样偷听到罗佳向索尼娅说述说的真是心理想法和变化过程。维斯将罗佳杀死她们的全部原因描述成抢劫财物,当然这是既定事实的一部分,罗佳在杀人之后第一件事就是搜寻高利贷老太太的财产和那些抵押品。不过这也是正常人以及现代正常社会对待一件杀人抢劫案最真实的想法表达,即使杀人犯有多伟大或者多卑微的理由,最终结果永远不可否认。这也是折磨罗佳的其中一个原因,他的心理状态在作为拿破仑和一只蚂蚁之间往复徘徊,而这不断变化的过程正是他本身对于是否有人能凌驾于社会法则之上这个问题的思考。
对于偷听来的罗佳的内心想法,维斯则理解为如果做一件坏事就能成全一百件好事的话,那么这便是无可厚非的。对于平凡的人和非凡的人(尼采)的分类的理解,维斯同样显得浅显且武断,而这只是罗佳在同波尔菲里的辩论中波尔菲里同样提出的疑问观点。最终,他把这些罗佳的自我理论归咎于虚荣心和自尊心作祟并且只是一个自命不凡的伪天才。

在与杜尼娅说明情况后同时提出了解决方案,可条件是得到杜尼娅。面对杜涅奇卡的威胁,他却一直在诉说往日与她相处时自己的感受。对于杜尼娅而言,他所描述的只不过是自己意淫出的情感,但从维斯的回忆中透露的更多的是他心中对美好的杜尼娅的向往。在得到坚定的拒绝后他选择从心里放走她。照着他过往的‘事迹’来看并不像是一个能做出果断放弃的人。在杜涅奇卡丢掉手枪后有一段对维斯的心里描写:“似乎有诗萌东西已下载从他的心头掉下来了,也是这不仅仅是死亡恐惧的重压,而且此时此刻他未必会产生这种感觉。这是摆脱了另一种更悲伤、更阴郁的感觉之后的一种心情,他自己也无法完全弄清”,我想正是因为他体会到了某种心情才促使杜尼娅能在关键时刻逃脱,而这种心情在后面维斯的经历中逐渐揭晓。在阿德里亚诺波尔酒店中的夜晚,维斯做了两个截然相反的梦。在前半夜的梦里,梦在温暖美丽的环境中中开始,各式鲜花占据了环境描写的一半笔墨,这些花儿象征着他这一生中所爱慕过的、追求过的、交合过的女人们。但在鲜花丛中却躺着一个心早已破碎的小女孩,这很容易和因为他而遭污蔑的杜尼娅联系起来。维斯对杜尼娅的感情早已超越他所经历的所有女人,可没想到却给心爱的女人带来灾难。第二个梦是关于照顾一个可怜的五岁小女孩,这在他心里是女人们纯洁而又柔弱的象征。在他心生怜悯伸出双手后,女孩却将俗媚和淫秽完全袒露在他面前。可正是这些他往常所沉迷的所享受的,在此时却极其抗拒和反感。过往的经历后,在维斯的心里更奢望的是女人所发出的单纯明亮的光芒。而在追求这个光芒的最后一次尝试失败后,他更想做的是尽早逃离这个充满诱惑而又恶心的世界。最后在阿喀琉斯的见证下顺利地去了美国。他的故事在书中末尾才算真正开始,可结束地十分利落。

拉斯科尔尼科夫

看了两遍后,我对拉斯科尔尼科夫的印象“大有改观”。现在我对罗佳的印象是:70%生气+胡思乱想、20%生病+睡觉+胡思乱想、10%善良。

这里我想特别说明一下我对罗佳“善良”这一品格的看法。首先先把我认为的占最少部分的善良罗列一下:1. 罗佳在送水果软糖回家后离开前给他们一家留下了一把铜币,虽然他马上因为考虑到自己的处境而感到后悔,但又想到索尼娅和他们一家的情况,最后还是认为自己的做法是正确的;2. 掏钱为差点被侵犯的年轻姑娘叫马车;3. 去找拉祖米欣的路上喝醉酒在灌木丛中做的梦:孩童的他遇见众人在折磨一只拉着大车的小母马,罗佳对于母马的遭遇十分不忍;以及在别人口中所提及的之前在火灾中救人等等。但在我看来,其中一半的善良并非值得称赞的事情,至少包括全部慷慨解囊的故事。正如书中所描述的社会背景以及拉斯科尔尼科夫的出身,他的家庭并非富裕,甚至可以说是贫困潦倒。他的父亲早已过失,母亲靠着政府一年发的一百多卢布生活,妹妹因为工作受到误解和诬陷,最后甚至差点被迫嫁给了一个彻头彻尾的混蛋,罗佳自己也只能苟活在一间“船舱”里并且长期拖欠房租。可反观罗佳,他拿着妹妹和母亲挤出来的钱不顾后果地救济他人,甚至施舍给一面之缘的妓女。我当然认为乐于助人是美好品德,也认为那些为了他人无私奉献自己的人十分伟大值得尊敬。但罗佳在帮助那些“需要帮助”的人时从未考虑过自己周围的人,并且每次的“帮助”都是那么不顾后果的“大方”。难道为了救助别人而理直气壮拖欠房租的人、为了帮助别人而让自己的家人受苦的人、为了帮助别人而连朋友的救助都不值得感恩的人值得值得称赞他的善良吗?

再谈为何我对拉斯科尔尼科夫如此厌恶,仅次于对水果软糖的厌恶之情。这些都是发生在我看完第六章之后的想法。

在卢仁与罗佳的第一次见面时,卢仁为了彰显自己,表达了一段感言。其中他说到:“我仅仅为自己发财致富,实际上也是为大家发财致富”。虽然罗佳和拉祖米欣对他的言论,甚至从根本上来说,对他这个人从一开始就没有好感,但卢仁所表达的这一观点实际上与罗佳不谋而合。罗佳在谈话最后的结论是:“把您刚才兜售的那种理论稍加引申,结论就是:杀人是可以的”。事实上,我们看到的是罗佳将自己视为“超凡的人”,认为自己有能力改变社会现状,让广大民众受益。这表达在他对杀死老寡妇姐妹的目的上,他认为这个对社会毫无贡献的蝼蚁如果能死去,那么那些受她压迫的人们就有了翻身机会。可说到底,在我看来这只是他满足私欲的一个说辞,为了自己的生活,为了尊严,为了家人。并且罗佳在这自圆其说的大道理中越陷越深。

我对他为什么选择只向索尼娅倾诉一切,主观认为是在他心中索尼娅和他一样是在为他人而牺牲自己的,从另一个角度来说,他认为索尼娅是污秽的,有罪的,他们是同一种人。在杜尼娅在罗佳面前提到洗清罪行,罗佳的反应让我失望透顶。他认为“这只是一种笨拙的行为”。“我杀死的事一只可恶的、十分有害的虱子,是一个对任何人都没有益处的放高利贷的老太婆,一个饱吸穷人献血的吸血鬼,杀了她,四十桩罪都可以赎清,这也能算罪行嘛?”。“我干这件蠢事,只不是过想使自己赢得自立,跨出第一步,筹足经费,然后就用无数的好事来弥补”。此时在我眼里原本不愿相信的一个极端自我的人展露无遗,我并不认为他是一个可怜的人,而作为他的亲人朋友才是真正可怜的。维斯在他的对比下反而显得富有担当。与此同时有个疑问在我心中产生,为什么他在与母亲交谈时却请求母亲能在上帝面前为他祈祷,他想从祈祷中获得什么呢?既然并不承认自己的罪行,那也没有请求上帝宽恕这一说。

无论杀人的这个想法在罗佳最后的描述中有多么伟大,就像是自己在成为拿破仑的路上捏死一只蝼蚁一般,但其实部分原因总能归结到他的自私和偏执上。在看完母亲的来信后,从他的判断中得出的结论是不能让妹妹因为母亲的生活和自己的未来而牺牲这一生。可他也十分清醒地意识到当下自己对这一切的无力,他认为以现在的状态无法兑现对家人的美好承诺,不过我认为这是他“自以为的”。此时玛尔拉梅多夫的关于“走投无路”的问题像是在干燥森林中出现的那一点火星,让罗佳点燃了那个荒谬做法的决心。其实从这方面看来,罗佳和马尔拉梅朵夫的共同点显而易见。他们虽然意识到了当下的困境,却依然沉浸在过往的辉煌中;他们虽然从心里爱着自己的家人,但又无法做出因为家人而努力的进步,更不用说那份决心。所以,他们最终都选择了最为自私却又冠冕堂皇的方式,并认为这是“无路可走”时的唯一的选择。


2020年5月23日凌晨2点26分,吃完宵夜后。

关于拉斯科尔尼科的想法和行为我又有了另一种思考方式,这是一道电车难题

关于电车难题的真正了解的时间是在去年其中一门研究生课程,当时引起我极大的兴趣并且已经准备好写一篇关于这个问题的思考的文章,虽然由于各种原因至今还没写好。言归正传,我所理解的罗佳的想法的前提可以类比成一边是绑着年老体弱并且依靠放高利贷压榨百姓的老太太和一边绑着众多被生活所迫,被社会现状所迫,而且还被老太太欺压的人们,当然其中也包括了主人公本人。无论是出于道德主义还是功利主义的角度作出选择的话,其实罗佳的选择可以说是“最优”的解决方案。但我想罗佳的这一想法前提本身就不成立。首先,如果让电车驶向老太太的话,那么另一个轨道上的人们理应得到拯救。可现实并非如此,上方也提到,造成人们以及罗佳自己的生活困境的根本原因并非由老太太单方面构成,因此即使杀死了老太太也最多只能解决不用还高利贷的这个问题,可困苦的生活依然在继续。再则,依然是“超人”理论的不适用性。拉斯科尔尼科夫作为一个普通人,并没有权利从主观选择电车的方向。这也是我对电车难题的大致观点,对我来说这是一道我没有办法解决的问题。


书中一些有趣的观点

  • “人在病态中的梦境往往异常鲜明、清晰,并且与现实生活惊人地相似。有时会出现极其可怕的情景,但这情景及整个发展过程却如此真实可信,并且带着一个个如此逼真准确、出人意料而又很艺术地与整个情景十分吻合的细节,以致做梦着即使是像普希金或屠格涅夫那样的艺术家,在醒着的时候也无法构想出这样的细节。”
  • “只要喝一杯啤酒,吃一小片面包干,立刻就会精神健旺,思路清晰,意志坚强”
  • 谵妄:一种以兴奋性增高为主的高级神经中枢急性活动失调状态,在仪式清晰度降低的同时,出现定向力和自我认识障碍,并产生大量的幻觉、错觉。临床主要表现为意识模糊、注意力变差、定向力丧失、感觉错乱、躁动不安、言语杂乱、睡眠-清醒周期混乱,常常伴随着妄想(例如相信有人要害他)、幻觉(例如看到不存在的东西,过世的亲友)。这是卡斯科尔尼科夫在杀害伊万诺夫娜姐妹且昏睡醒来后的 状态。
  • “胡说八道是人类在所有生物中享有的唯一的特权。胡说八道是通向真理的途径!”
  • “最后便使出了堪称万应灵丹的一个征服女人心的最高明的绝招,这个绝少从不会让任何人失望,而且对任何人都绝对管用,无一例外。这个绝招五人不知,它就是阿谀奉承。” (21世界有一个新的词汇用来形容这种绝招:舔狗)

关于《管理的实践》

其实在这两年的学习过程中,无论是学校中的管理课程,抑或是额外的项目管理、敏捷开发等课程,在教材或者案例中都会提及彼得·德鲁克所说过的话。很可惜的是直到现在才真正入门了这位现代管理学之父所构建的管理学知识。得知这本书是因为我很喜欢的一位老师,余亮老师的一档节目《从书说起》。其中一集的标题和封面非常让我想知道余亮老师是通过哪本书回答这个在2019年特别有话题性的事件。这集的标题是《遇到一个会管理的好领导,才是真正的“福报”》。遗憾的是余亮老师并没有给出他对这个事件的看法和解答,但很幸运的是我收获了这本书。

视频的刚开头,很多人都提出了一个相同的问题:管理不是领导的事吗?余亮老师的回答是:每个人都需要判断自己的领导是否是一个合格的管理者。他作为一位非专业的管理人员,从这本书中收获的是:如何做判断,如何判断他人,判断自己,判断事情,判断问题。正如德鲁克先生在序中所说的,他希望通过尽量简单通俗的语言让读者能深刻理解管理学在实践中的应用。显然,这本出版在上个世纪五十年代的著作不仅成功帮助了全世界的管理者和企业,也帮助了各行各业的人们,并且至今都非常受用。德鲁克先生使用了丰富的实际案例来解释他的理论,几乎穿插在书中的每一章节。例如余亮老师提及的“西部铁路恐怖案件”,“每天早上谁下楼买咖啡”和“IBM”的创新等。而给我留下最深刻的印象的是二战后某国如何保障就业的例子。这个故事讲的是由于战后经济崩溃,政府颁布了一项法令,规定除非企业面临严重的经济困境,否则严禁雇主解雇正是员工。这本是一项最直接的保障就业的方式,可结果却适得其反。由于这个政策,导致企业或者公司不敢雇佣员工,从而放弃了许多拓展市场、企业规模的机会。当我们对问题做出应对措施时,需要从目标入手,并且需要衡量解决方案可能带来的后果,而不是直观的认为从方法上最直观的方案就是最有效,有时可能会加剧了问题的严重性。当然,从这本书中我所收获的不止是管理学的入门知识,我想更多的是其它方面的感悟。

其中对我启发最大的是,如何思考问题。首先,正如德鲁克先生所说的“目标管理”,分析问题需要抓住核心,思考需要围绕问题要解决的目标。其次,应从多角度思考问题,正如在谈论企业的管理时,应当从企业、管理者、员工三方面进行剖析。我想如果以后有人问我项目管理是什么时,我应该会从对企业、项目以及项目成员等角度进行回答。

第二个启发是回答了一个现实生活中大家非常习以为常的问题:为什么要工作?在这之前,我所接触到的同事、朋友,对于这个问题的回答无一不是为了收入为了提高生活水平。但德鲁克先生非常明确地帮我从内心深处挖出了想要的答案:工作不只为了物质收入,还有在职位上发挥所长,建立地位、通过公平的升迁机会实现社会正义以及做有意义有价值的事。

再则,因为对自己未来的职业规划,这本书帮我系统地总结了作为一名合格的管理者需要的能力。管理者最应当具备正直的品格,分析能力,综合能力以及想象力。德鲁克多次强调了诚实正直的品格对管理岗位的重要性。‘管理者不只通过知识、能力和技巧来领导部属,同时也通过愿景、勇气、责任感和诚实正直的品格来领导’。并且想象力在决策过程尤为重要,由于决策的目的是解决问题,但决策人无法在获得所有信息而做出100%正确的决策。因此在基于最重要的信息获取后,决策人应当根据合理的想象制定可行性的解决方案。提及决策,决策(28章)不仅是管理者应当具备的能力,每个行业每个岗位甚至每个普通人都应当学习。这是一种分析并解决问题的重要能力。

最后,虽然现在的我也没有能力完整地阐述开头所说的对去年很火的那个话题的见解,但从这本书中我找到了不少对于这方面的明确表达。在此斗胆引用:

  1. “一个人如果‘只为公司而活’,那么他的人生实在太狭隘了”
  2. “管理者受企业委托管理,同样应当履行其社会责任”
  3. “针对每个政策和每个决定,企业管理者都应该自问:如果产业界的每个人都这么做,大众会有什么反应?如果这种行为代表一般的企业行为,会对社会大众产生什么影响?”
  4. 企业对社会的其中一个责任:“不可以对公民不当施压,要求员工绝对的忠诚”
  5. “公司不能自称(绝对不可自称)是员工的家、归宿、信仰、生命或命运。公司也不可以干预员工个人的私生活或者员工的公民权”
  6. 等等。

当提及如何解决此类问题时,德鲁克先生的看法是:“设法让能增进公众利益的事情也成为企业的自我利益”。我想造成这个问题的根本原因可能并不在于企业本身,还有国家、社会、文化等众多因素的影响。但不可否认的是所造成的结果的严重性。我们能做的是不断学习,不断思考,为自己的理想生活努力,为社会贡献绵薄之力。至此,我已看完了《管理的实践》的中文版本,接下来我将继续阅读这本著作的英文原版,希望能得到更多的启发和想法。

下图是我整理的书中主要内容的概要。

Efficient vs. Effective

One of the Principles of Agile Manifesto is:

The most efficient and effective method of conveying information to and within a development team is face-to-face communication.

When I try to keep memorise these principles, it’s always the best way to understand the real meanings of each of them in practice before keeping them in mind. However, these two words, ‘efficient’ and ‘effective’, have confused me for a while. One reason is that they both represent the meaning of ‘with great effect’ in Chinese when I use most translation applications. So let’s grasp the distinction between them.

First of all, the definitions of them in Oxford English Dictionary are shown below.

Efficient:

achieving maximum productivity with minimum wasted effort or expense.

Effective:

successful in producing a desired or intended result.

We can see that ‘efficient’ is used to describe a kind of status of the process, while ‘effective’ focuses more on the result.

Then, based on it, these two words may be easily associated associate with ‘Doing the right things and doing the things right’ literally. In this manner, we can say ‘doing the right things’ is effectiveness and ‘doing the things right’ is efficiency. However, when you are doing the right thing, you cannot 100 per cent sure that you are doing it well. Also, when you are doing a thing well, it doesn’t mean that this thing is meaningful to you. There are some examples presented as following.

  • With his power, Mumen Rider could not transport all injured people to the hospital effectively, while organised rescue operations efficiently.
  • Genos can effectively defeat the monster with his trick, but he needs to spend a lot of time to accumulate energy to use the trick, which is not efficient.
  • Saitama has become too powerful as that he can defeat any monster in the most efficient and effective way – just with a single punch.

In addition, I also found the episode Effective – Efficient. They mean different things in English, which is very helpful to understand the meanings of ‘efficient’ and ‘effective’.

Scrum Q&A

This is for recording the questions I met during learning and practising Scrum framework. And I will update more questions and try to present my own opinions continuously. If anyone catches something wrong in the content or has different views, please do not hesitate to discuss with me and I would appreciate greatly.


Questions

  • Q: Scrum is a rule-based framework. Does complying the Scrum’s rules conflict to Agile Manifesto?
    • A: Nope. There are three reasons I have found shown below.
      • ‘Individuals and interactions over processes and tools’ is listed at the first of the Manifesto for Agile Software Development. But it also indicated that it is a case of the relative importance of the values, and not a case of ‘good’ or ‘bad’.
      • The original purpose of Agile is to replace the heavyweight, document-driven processes that existed at the time. Concerning Scrum, it is a lightweight, iterative and incremental framework for managing complex knowledge work. Scrum challenges assumptions of the traditional and sequential approach to product development, and facilitate teams to become self-organise.
      • As one of the Agile Manifesto creators, Jim Highsmith has explained in Agile Manifesto History that ‘the Agile movement is not anti-methodology‘ and ‘we want to restore a balance‘. Such Agile frameworks and methodologies as Scrum, Kanban and XP (eXtreme Programming) have realised the balance by keeping their rules and practices to a minimum given the circumstances but focused on empowering developers of all kinds to collaborate and make decisions together as a group quickly and effectively.
  • Q: How many members made up a Scrum Team is appropriate?
    • A: As we know, a Scrum Team consists of three roles, which are the Scrum Master, the Product Owner and the Development Team. The Scrum Master and the Product Owner must be a sole person respectively. With respect to the Development Team, the Scrum Guide has claimed that the number of team members should be at least three and at most nine. Hence, the total number of a Scrum Team should be controlled from five to eleven. However, one specific condition indicated in the Scrum Guide should be considered is that the Scrum Master or the Product Owner can be one of the Development Team members if he or she also participates in the work of the Sprint Backlog. The PRINCE2 Agile manual introduces a typical guide of the Scrum Team size that it should be seven, plus or minus two.
  • Q: Is there any effective way to monitor progress during a Sprint?
    • A: There is no specific methods or tools mentioned in the Scrum Guide for monitoring Sprint progress. It’s because the duration of a Sprint is comparatively short, around two to four weeks. So it would be easy to track the progress for the Development Team during this period. However, in order to improve transparency and let everyone know the progress easier, it is a good idea to visualise the Sprint progress like monitoring the progress of the entire project. The burn-down chart is a typical technique that can be employed.
  • Q: Should the Sprint Review and the Sprint Retrospective be placed after a Sprint cancelled?
    • A: Once the Product Owner determines to cancel the Sprint, the Scrum Team should review and assess the work has been done and has not been done from the beginning of this Sprint to the present. This is one of the most essential tasks listed on the agenda of the Sprint Review. Although the Scrum Guide does not specify that the Sprint Retrospective needs to be sited at this time, I believe it is appropriate to inspect and adapt the work through this formal event. The actual duration of the Sprint would be less than its fixed duration basically if cancelled, consequently, the duration of the Sprint Review and the Sprint Retrospective should be shortened respectively.
  • Q: Will the Increment of each Sprint be released or deployed immediately?
    • A: It depends on the Product Owner. As the sole person accountable for the product, the Product Owner should organise the time to release each Increment in order to maximise value. Thus the Increment delivered during each Sprint must be deemed ‘Done’ and in useable condition regardless of whether the Product Owner decides to release it.
  • Q: How many improvements should be implemented during the upcoming Sprint appropriately?
    • A: The Scrum Guide has claimed it should be at least one item selected into the next Sprint Backlog. And I suppose that it is a good idea to prioritise the identified improvement tasks according to their urgency and estimated effort, and then select the items with the highest priority and within the tolerable effort based on the result. In this manner, the Scrum Team can ensure that only a few improvements to the process are suggested, as opposed to working on too many of them at the same time.
  • Q: Can the sprint end early if all tasks in the Sprint Backlog have been completed and the Sprint Goal is reached?
    • A: No. The Scrum Guide illustrates that ‘Once a Sprint begins, its duration is fixed and cannot be shortened or lengthened’. However, there would be the case if the Scrum Team members have accomplished all work before the Sprint end date. In this situation, the Scrum Team must keep self-organising to find out and work on correct work in the remaining duration. There is a typical list of the work the Scrum Team can perform during this time.
      • Continuously refine Product Backlog items to ‘Ready’;
      • Identify and implement activities that improve quality or productivity or work;
      • Participating in practices or trains to adopt and understand Scrum and Agile better;
      • Learning or improving other relevant skills to become more cross-functional;
      • etc.
  • Q: Can the duration of a Sprint be shortened or lengthened?
    • A: Yes. The Scrum Team can make the decision for changing the Sprint length together as more is learned. Scrum is founded on empiricism and there is no specific limit of shortening or lengthening the Sprint duration if the Sprint has not commenced. Hence, changing the Sprint duration can be seen as an action that is identified and recorded in the improvement list for improving work and fitting the Scrum Team’s goals better during the Sprint Retrospective. In addition, each event must change its duration according to the new Sprint length.
  • Q: Can the duration of an event within a Sprint be shortened or lengthened?
    • A: Yes. The Scrum Guide demonstrates that ‘The remaining events may end whenever the purpose of the event is achieved, ensuring an appropriate amount of time is spent without allowing waste in the process‘. Consequently, if the Scrum Team has recognised that the prescribed length of a specific event is too much enough or too little for achieving its purpose, the Scrum Team should reset the event duration in the Sprint Retrospective for the upcoming Sprint. But the team should comply with the rules that define the maximum duration of each event in the Scrum Guide. Moreover, there is another situation that the duration of each event must be changed as mentioned in the previous question.
  • Q: Can the content of Sprint Backlog be modified during the Sprint?
    • A: AgileAlliance has presented its answer when introducing Scrum, which is ‘Once the team and product owner establish the scope of the Sprint as described by the product backlog items no more items can be added to the Sprint Backlog. This protects the team from scope changes within that Sprint‘. But I DO NOT agree. Let’s take a look from the following perspectives.
      • Sprint Goal. This is an objective defined in the Sprint Planning by the Scrum Team that the team MUST satisfy by the development work throughout the Sprint. And the Scrum Guide suggests that ‘The Sprint Goal gives the Development Team some flexibility regarding the functionality implemented within the Sprint‘.
      • Sprint Backlog items. During the Sprint Planning meeting, the selected Product Backlog items are broken down into a set of tasks presenting the HOW of the Sprint Goal met.
    • In conclusion, we can know that one thing must not be changed within the Sprint, which is the Sprint Goal, instead of the scope. And the Sprint Backlog items can be modified during the Sprint to satisfy the Sprint Goal better. There is also some evidence supporting my view in the Scrum Guide, such as ‘Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned‘ and ‘If the work turns out to be different than the Development Team expected, they collaborate with the Product Owner to negotiate the scope of Sprint Backlog within the Sprint‘.

Remaining Questions

  • Q: Can the Sprint Goal be modified during the Sprint?
  • Q: One of the elements included in the Sprint Review is ‘the development team discusses what went well during the Sprint, what problems it ran into, and how those problems were solved’. Is it more likely to be done during the Sprint Retrospective instead of the Sprint Review?

Scrum in My Notes

Overview

Definition

The definition of Scrum in Scrum Guide (2017):

Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.

According to this, the key information can be extracted:

  • Scrum is a framework that people can employ various techniques, methods and tools that facilitate the working process but are not in conflict with the rules of Scrum;
  • Scrum is appropriate for being used to address the complex and adaptive problems. ‘Complex’ means the relationship inside the problem can only be understood in retrospect and is addressed by ’emergent practise’ which may evolve to a new way of working (Cynefin framework). And ‘adaptive’ refers to the situation of the problem would change dynamically over time;
  • Scrum aims to maximise the value of the products. This scenario satisfies the customer’s real needs by focusing on value instead of the output. The entire Scrum team should be aware that the very first principle of the Agile Manifesto refers to delivering value; and
  • Scrum relies on productive and creative workflow. High-productivity accelerates iteration and feedback loops resulting in assessing value quickly. And creative work, such as experiments and spikes, provides more opportunities to learn and reduce risks from a technical or customer viewpoint.

Essentials

Scrum is instituted based on empirical process control theory, a.k.a. empiricism. It means that ‘knowledge comes from experience and making decisions based on what is known‘ (The Scrum Guide), which means improvements toward the right destination could emerge from what has already happened accordingly. Based on this, products, team and working environment will be improved throughout the iterative and incremental process of Scrum. All implementations within the Scrum framework are advocated by empiricism that is founded on the basis of ‘three pillars’ (3 principles). And there are three vital components (roles, artifacts and events) surrounded by five values of Scrum within which people can implement the framework successfully. The Scrum Guide illustrates that ‘The rules of Scrum bind together the roles, events, and artifacts, governing the relationships and interaction between them‘, while in my view, complying the Scrum rules prevents the efficacy of all essentials of Scrum from internal and external disruptions. All essentials identified in the Scrum Guide are listed as follows.

  • 3 Principles
    • Transparency
    • Inspection
    • Adaptation
  • 5 Values
    • Commitment
    • Courage
    • Focus
    • Openness
    • Respect
  • 3 Roles
    • Development Team
    • Product Owner
    • Scrum Master
  • 3 Artifacts
    • Product Backlog
    • Sprint Backlog
    • Increment
  • 5 Events
    • Sprint
    • Sprint Planning
    • Daily Scrum
    • Sprint Review
    • Sprint Retrospective

Practice

Basis

Scrum framework is used to manage the development process of a complex adaptive project. The entire project process is constituted by a series of Sprints. A sprint commences immediately when the prior sprint is done. Each sprint aims to produce a potentially releasable increment of ‘Done’ product based on its Sprint Goal as one of the inputs to the upcoming Sprint. Also, the improvements are identified at the end of each Sprint and implemented during the next Sprint. In addition, Sprint Zero, the first phase shown in the above figure, is a specific sprint at the beginning of a piece of work in order to address many upfront activities, while it is not defined in the Scrum Guide.

Sprint Zero (Optional)

As mentioned above, Sprint Zero can be employed as the first phase to address the upfront activities. This is because such activities must be done and some artifacts such as the Product Backlog and the Definition of ‘Done’ should be built before the first Sprint commences. Consequently, Sprint Zero is one of the optional solutions to accomplish the initialisation systematically. It should be noticed that there is no formal standard for Sprint Zero and it is considered both positively and negatively by the agile community. The activities can be conducted during the Sprint Zero include:

  • Visioning
    • A process of coming up with breakthrough ideas;
    • Producing the project’s vision which is crucial for the whole team to understand, collaborate and commit towards the same goal throughout the entire project.
  • Forming a team
    • Building a cross-functional team in place;
    • Allocate responsibilities to each member.
  • Initialising Sprint environment
    • Developing a Scrum board;
    • Setting-up the duration of each event, the site and time of Daily Scrum;
    • etc.
  • Drafting the Product Backlog
    • Adding initial epics or user stories;
    • Estimating and prioritising them;
    • Conducting detailed requirements communication probably;
    • etc.
  • Defining the Definition of ‘Done’
    • A baseline for assessing the completed work.
    • Providing suggestions to the Development Team on how many Product Backlog items can be selected.
  • etc.

Sprint

Sprint is the heart of Scrum. As a container, Sprint limits the duration of implementing all the events inside it from 2 to 4 weeks basically. These events are executed by specific roles identified in the Scrum Guide independently and sequentially. Sprint Planning is the first event used to develop a plan and a Sprint Goal guiding the work during the Sprint. Daily Scrum, as well as stand-up meeting, is held for reviewing and planning the work each day. The output of the current Sprint would be discussed in the Sprint Review. And the Sprint Retrospective aiming to evaluate the work starts after the Sprint Review and prior to the next Sprint. In addition, cancelling a Sprint occurs if the Sprint Goal is no longer valid.

Sprint Planning

During the Sprint Planning, the Scrum Team need to address three questions: what to do, how to do this Sprint and what is the Sprint Goal.

For the first question, the Development team and Product Owner mutually addresses it. The highest ordered Product Backlog items with more detail are considered by the Development Team based on the various aspects including the conditions of the last ‘Done’ increment, the projected capacity of the Development Team, Definition of ‘Done’, etc. While the Product Owner will discuss and negotiate with them in order to commit the team to deliver the highest possible value. But only the Development Team can assess what it can accomplish over the upcoming Sprint.

With regard to how to achieve the work, the Development Team takes accountability for it solely via estimating, converting and decomposing selected items to tasks in the Sprint Backlog. During this step, the Product Owner can help to clarify the selected Product Backlog items, re-negotiate and make trade-offs.

A list of tasks representing the HOW of the increment created
=
the Product Backlog items selected for the Sprint
+
the plan for delivering them

In addition, the Sprint Backlog must contain at least one improvement task identified in previous Sprint Retrospectives.

Sprint Backlog 
= 
A list of tasks representing the HOW of the increment created
+
at least one improvement task from previous Sprint Retrospectives

The most important output of the Sprint Planning is the Sprint Goal which is ‘an objective set for the Sprint that can be met through the implementation of Product Backlog‘. Sprint Goal has the following characteristics:

  • A baseline for detecting undesirable variances;
  • Cannot be changed before the Sprint done or cancelled;
  • Gives the Development Team some flexibility regarding the functionality implemented within the Sprint;
  • Provides guidance to the Development Team on why it is building the Increment.

Development Work

The Development Team, as a self-organising team, performs the development work iteratively and incrementally throughout the Sprint based on the Sprint Backlog. During this period, the Product Owner continuously collaborates with the Development team to satisfy the Sprint Goal. The deliverables of the development work are the potentially releasable functionalities or increments which must be in useable condition and meet the definition of ‘Done’.

Refinement

Refinement is an activity implemented with the development work simultaneously. Unlike the development work, the target artifact of Refinement is the Product Backlog. Only the Product Owner takes accountability for modifying the items in the Product Backlog based on the latest requirements from the customer, the current situation of the project and also the estimates and advice provided by the Development Team. A revised Product Backlog with more detailed and re-ordered items will be delivered to best achieve goals and missions.

Daily Scrum

Daily Scrum, a.k.a. Stand-up Meeting, is:

  • a key inspect and adapt meeting toward the Sprint Goal;
  • in 15 minutes stringently;
  • placed at the same time and site each day stringently;
  • a meeting during which only the attendees from the Development Team can present;
  • used to synchronise activities acting as reporting progress and updating relevant information on the Scrum Board;
  • used to create a plan for the next 24 hours;
  • used to identify and implement improvements informally.

A widely-used meeting structure is kind of question-based which guides each attendee answer three questions around the work has done, the plan and the identified blockers. And it is also a typical example introduced in the Scrum Guide. But I personally prefer the task-based structure of Daily Scrum, within which the development team member responsible for each task on the Sprint Backlog presents the progress, plan and blockers accordingly and sequentially. Compared with the sample structure introduced in the Scrum Guide, each member could take more concentration on the information in other members turn.

Obviously, there is no enough time for attendees to have further discussions in order to commence the next work and address problems. Hence, the team members should meet immediately after the meeting for detailed discussions, or to adapt, or replan, the rest of the Sprint’s work.

Sprint Review

Sprint Review aims to review the output of this Sprint resulting from the work of the Development Team to elicit feedback. Concerning this output, it has a specific name in Scrum: potentially releasable Increment, which means the output should be always available regardless of whether the Product Owner decides to release it. The Product Owner representing the customer’s interests is fully responsible for the product. Therefore, the major attendants consist of the Development Team, the Product Owner and also some key stakeholder invited by the Product Owner. During the meeting, attendants collaborate and discuss the following topics:

  • the development progress of the product;
  • the problems appeared during the process of delivering the product;
  • the Increment and the Product Backlog;
  • the next development plan;
  • the internal and external situations, including the marketplace, customer’s feedback, timeline, budget, etc.
  • etc.

The Sprint Review results in a revised product backlog identifying the possible product backlog items for the following sprint. Overall the Product Backlog may also be modified to satisfy new opportunities.

Sprint Retrospective

Sprint Retrospective is the final event of a Sprint. This is a structured opportunity for all team members, including the Scrum Master, to look back and reflect on how the team performed to strengthen the way they performed in the near future. The aim of Sprint Retrospective is to build a productive and enjoyable working environment for the Scrum Team.

Feedback typically comes in two ways during a retrospective: the facts and the feelings. Typically, facts are objective and measurable. And, in general, feelings are subjective and more difficult to quantify. There is an appropriate approach named ‘Sad, Mad, Glad‘ that can contribute to this event better. Ben Linders introduces that ‘it helps teams to look for things that make them happy, sad, or drive them mad, and to decide how they want to address these things working together as a team‘.

A final step in a retrospective could be to reflect on how well the retrospective process worked, which is sometimes called ‘the Retrospective of Retrospective’. At the end of the Retrospective, a list of improvement tasks will be delivered. And at least one item will be moved to the Sprint Backlog based on the urgency and estimated effort during the next Sprint Planning.

Sprint Overview

Overall, Sprint is a basic process unit of the Scrum framework. And it is also a container for the Scrum events operated by the different roles toward a specific Sprint Goal defined at the beginning of the Sprint. Each sprint processed independently and sequentially will produce a potentially releasable Increment of “Done” product iteratively and incrementally and also revise the Product Backlog based on it. And the capability and working environment of the Scrum Team will continue to improve simultaneously.

Cancelling the Sprint

As mentioned above, a Sprint can be cancelled by the Product Owner only if its Sprint Goal has been obsolete. However, this kind of situation rarely happens and is the last resort. Once the Product Owner decides to cancel a Sprint, there are the activities occurred including:

  • assessing the ‘Done’ work if it can become the potentially releasable functionality or increment;
  • reviewing the Sprint Backlog with the assessment of work;
  • revising the Product Backlog based on completed and incomplete work;
  • revising the Product Backlog items to maximise value given the new circumstances;
  • Starting a new Sprint or enclosing the project;
  • etc.

Summary

  1. From the articles or videos about Scrum on the Internet, Scrum has the characteristics of lightweight and simple to understand as stated in the Scrum Guide. Most Scrum introduction videos can roughly explain the scrum process in five minutes. But at the same time, different to understand, they did not talk about too many workflow details and solutions to various situations in practical applications. Even in the Certified Scrum Master training courses, considering the practical application, I still have a lot of confusion. On the other hand, this is one of the basic principles of agile. Each business activity or project is unique, and there is no method or framework that can fit a specific activity or project 100 per cent. As the term ‘Empiricism’ advocated by Scrum, it is appropriate to find a solution suitable for corporate activities and projects through practical learning and experience.
  2. It needs to be clear that the application of Agile frameworks such as Scrum, is a tool for organisations or project teams to better achieve their goals, while is not the goal itself. Just like Ken Schwaber said: ‘Scrum is not a methodology, it is a pathway’.
  3. I personally see Scrum as a phased target management framework. It defines goals for each Sprint and achieves the overall goal through accomplishing each phased goal sequentially. And each Sprint provides a degree of flexibility without conflicting to the goal, which allows the development team to leverage the scope and quality of products better. On the other hand, this phased implementing method has greatly reduced the risks from many factors, such as changes in customer’s needs and changes from the marketplace and other conditions. This reflects the first and second items of Agile principles well.
  4. In each sprint, the Scrum Master does not participate in a specific event as the main identity, whereas he or she facilitates the entire Scrum process. As a servant leader, the main job of the Scrum Master is to build the work of the entire team on three pillars and helps every member continuously focus on the five values during the work process in order to achieve both product and team improvement. He is the soul of the Scrum team.