





Project Management
Tuckman’s model a.k.a. Tuckman ladder is one of the most widely-used models to describe group development which consists of five development phases that teams may go through. PMBOK claims the importance of team building to project success shown below.
Teamwork is a critical factor for project success, and developing effective project teams is one of the primary responsibilities of the project manager.
PMBOK Guide, P337
With respect to the Agile way of working, team building is the only way to achieving self-organisation and delivering the highest possible value. Hence, the model provides a reliable way for project managers, ScrumMasters, Agile Coaches and other roles to help identify the current stage of teams, so as to adopt different approaches and techniques for team building more efficiently and effectively.
The significant characteristics of the team presenting during each phase of Tuckman’s model have been categorised into PMP and Scrum respectively (collected from PMBOK Guide and “The Great ScrumMaster”). It should be noticed that the characteristics shown in the column of PMP would also be identified in Scrum teams in real practice, while the opposite would be not due to the circumstances under the specific framework (Scrum). Also, in each phase, the works ScrumMasters should focus on have been listed as well.
In 1977, the fifth phase was added: adjourning, that involves completing the task and breaking up the team (in some texts referred to as “mourning”).
In the IT area, most teams have improved during the entire project lifecycle, and the team environment and collaboration among team members would have reached higher levels. However, the project is a temporary endeavour, it is inevitable that staff would be released after the project is completed. PRINCE2 also mentioned the necessitate to reduce this loss. This is a quite interesting topic.
When a project has involved high levels of collaboration and teamwork, and the team is disbanded, it can result in a degree of ‘mourning‘ for the team members, so this should be anticipated and ideas suggested as to how reduce this.
PRINCE2 Agile Manual, P 194
As for the model, the most puzzled part for me is how to differentiate the phases of Norming and Performing. These are both the comfortable stages for teams, which show high performance and productivity. So let’s have a look of the relationship between team effectiveness and team performance during each phase.
In short, the team in the Norming phase is not bad, but not good enough. The team should still be encouraged to take ownership and responsibility and continue improving, so as to become self-organisation.
This is one of the questions I was asked most frequently during the interviews these days. And my original answer to this question was OBVIOUSLY NO! In order to make the answer convincing, let’s find out some evidence to support it.
The ScrumMaster role is deemed as a servant leader in Scrum Guide. And there are a number of specific responsibilities of the ScrumMaster listed when the ScrumMaster collaborates with the Product Owner, the dev team and the organisation respectively. With regard to “removing impediments”, there is only one point shown as:
Removing impediments to the Development Team’s progress.
However, Scrum Guide also claims that the dev teams are empowered and self-organised, which means “no one (not even the Scrum Master)” can take responsibilities of understanding, scheduling, implementing the work of the dev teams except themselves. And a dev team’s work is to deliver potentially releasable increments during each Sprint to meet Sprint Goal and to accomplish the Scrum team’s goal. Consequently, It seems that the dev teams should remove impediments emerging from the progress of delivering potentially releasable increments themselves.
Then I checked the material of the CSM course I attended. There is a clearer definition of the ScrumMaster role as follow:
Product Owner is responsible for the “What”, ScrumMaster for facilitating the “How”.
So the ScrumMaster is the facilitator to the dev team who is responsible for the “How”. And one of the works of the ScrumMaster is to “remove impediments on behalf of the team”. My tutor explained sometimes impediments may come from outside the team. As a coordinator between the team and the outside, the ScrumMaster is more capable of handling the interaction between the team and the outside to ensure the team focuses on the goal and creates maximum value. “Essential Scrum” supports this point of view as well,
The ScrumMaster is also responsible for protecting the team from outside interference and takes a leadership role in removing impediments that inhibit team productivity (when the individuals themselves cannot reasonably resolve them).
“Essential Scrum” P16
This book introduces the pathway to become a great ScrumMaster with the goal of encouraging self-organisation. As mentioned in About “The Great ScrumMaster”, ScrumMasters focus on build Agile culture from the team level to the organisation level. Hence, the author defines several models relevant to the ScrumMaster role, the Scrum Team and the organisation based on the Agile maturity respectively, such as #ScrumMasterWay, Tuckman’s Group Development, Shu Ha Ri, etc. At the initialling stage of all of these models, the author suggests the ScrumMaster should help the team understand and follow the rules of Scrum rigorously, in the meanwhile, remove the impediments identified during the day to day work if necessary. Because at the beginning of Agile transformation, creating a sense of Agile inside the group is the most important and urgent task for the whole team/organisation. And the members need to be taught and facilitated rather than coach due to the lack of the sense of self-organisation. But the ultimate responsibility of the ScrumMaster is to help the team remove impediments themselves as opposed to being an administrative position of the team. Anyway, the way of how to help the team deal with impediments depends on the level of Agile maturity and self-organisation of the team in real practice.
I supposed that it is necessary to judge whether the ScrumMaster needs to actively resolve the problem according to its importance and urgency, which can be assessed by The Eisenhower Matrix. The reason is whether using Agile or waterfall, the ultimate goal of the teams is to achieve the goals of the project or organisation. If there is a very serious problem that may affect the product to be released, whoever finds it must immediately point it out. But if the impediment would not damage to short-term goals, such as low efficiency of the dev team due to internal communication problems, then it is necessary for the ScrumMaster to help them identify the impediment, think about solutions and iteratively adapt themselves.
Last week I have discussed this question with one of my friend Esone who has been working as a ScrumMaster for a couple of years. This point of view owns his support greatly. And he also indicates one of the advantages of doing this way that I have never recognised before. He found that if the ScrumMaster finds and points out an important and urgent technical problem in actual work, team members would be more likely to respect and accept the ScrumMaster, so as to collaborate with the ScrumMaster proactively.
In conclusion, I would say this question should be discussed and answered in several situations.
Finally, do not forget the team should analyse root causes, inspect and adapt together during the retrospective meetings no matter where the team is and no matter what kind of impediments occurs.
“The Great ScrumMaster” was recommended to me during an Agile workshop I attended several weeks ago. The book is not thick which mainly introduces how to become a great ScrumMaster through building a self-organised team. As Linda Rising suggests in the foreword of this book, “this is a guidebook along the path, the way, for ScrumMasters and Agile coaches“. However, I reckon that it is not only applicable to the people who work as ScrumMasters but also to the entire Scrum team.
There are three parts of the content of this book I have divided into roughly as follows: the ScrumMaster role, team building and the toolbox including useful methods, models and techniques that can be employed to help the team become better. From the ScrumMaster’s point of view, “The Great ScrumMaster” interprets the responsibilities of this role explicitly which are all around team building. And it provides various relevant models and methods for ScrumMasters to analyse, plan and implement. The reason why this book could be applicable to all members of the Scrum team is that it can help members to understand the purpose of applying Scrum, clarify the goals of the team, and identify the current situations accordingly, so as to collaborate with the ScrumMaster efficiently and effectively.
At the beginning of the book, the author exposes a rather common but serious phenomenon that the ScrumMaster is usually deemed as a valueless role subconsciously. I suppose there are two situations that cause this kind of bias. First, the team does not have a deep understanding of Scrum. Second, the ScrumMaster does not help the team reveal any apparent improvements. As a result, the role of ScrumMaster becomes formalistic and bureaucratic and may even turn to be mixed with other roles. For example, there is a person who works as the ScrumMaster, in the meantime, as the Product Owner of the team. In this manner, there would be a great conflict between business needs and team self-awareness.
This brings up a quite interesting topic, whether the ScrumMaster needs to be responsible for delivery. In this book, the author states that the ScrumMaster only needs to serve the team and determines the team’s self-organization as the ultimate goal (while I have some different understandings on this point of view, and I will explain it separately in another post). However, I cannot agree more about that encouraging self-organization is the ultimate goal of the ScrumMaster. In the Agile Principles, it is mentioned that “the best architectures, requirements and designs emerge from self-organising teams“. Only if the self-organised team owns the competency to accomplish the work and meet its goals efficiently and effectively. Additionally, there is a fact that needs to be highlighted:
Every self-organised team is self-organised only inside the given boundaries.
As I mentioned in An Overview of Agile, Agile is a set of ideological values that can not only improve productivity but also contribute to a better working environment. However, we should be aware that it would be impossible for teams and organisations to become Agile without applying any rules due to the complex circumstances. In fact, the widely-used Agile frameworks, like Scrum, have been proven as the powerful approaches to contribute to Agile culture. Therefore, defining boundaries is necessary for any Agile teams or organisations in order to achieve the values of Agile. With regard to the boundaries of Scrum, Zuzi (the author of “The Great ScrumMaster“) suggests “Scrum boundaries are determined by the process – limited by Sprint Goals, Backlogs, and delivering working product at the end“.
Scrum is not a methodology – it is a pathway.
Ken Schwaber (2005)
I always believe that a great ScrumMaster can be deemed to a great parent who takes the right way to educate their kids. Normal parents only teach their children in a way that they understand or feel is correct, but great parents will guide and facilitate their children according to the different stages of the children and current deficiencies. Kids will always grow up. It is very difficult to face this world independently if they always live under the protection of their parents. This view also coincides with the author of this book.
Unless the ScrumMaster gives the team the opportunity to take over these tasks, she ends up as their ‘mother’ who is so loving and caring that her ‘kids’ are low-confidence grown-ups, dependent on her even in their thirties
Retrospectives are fundamental events not only in Scrum but also in various Agile frameworks as formal meetings to inspect and adapt the way and environment Agile teams work. There are plenty of interesting and attractive methods applied to determine the structure of retrospective meetings in real practices. So in this post, some of them are gathered and simply introduced.
Colouring a blob person image to depict how the sprint went. Details of Blob Football can be found in The Blob Retro.
Choosing a specific car brand to depict how the sprint went and then choosing your dream car. Details can be found in The Car Brand Retrospective.
DAKI helps the team identify specific features, behaviours or activities that the team members think they should Drop, Add, Keep or Improve. Details can be found in DAKI – Agile Retrospectives Exercise.
Using various emojis to gauge how the team feels during the Sprint. Details can be found in Emoji Retrospectives 😃.
Classifying the events each member performed during the Sprint into five categories and determining the emerged improvements. Details can be found in Retrospective #5: Fast and Furious.
Finding pictures of pirate Jack Sparrow online and using his various faces to gauge how the sprint went. Details can be found in Guest blog: Many Faces of Jack Sparrow – Agile Retrospective Exercise.
Using Kudo Cards to help deliver feedback and motivate people. Details can be found in Retrospective with Kudo Cards.
Having team members build something to represent how the sprint went. Details can be found in Agile Retrospectives with Legos.
Visualising and analogising each perspective to help the team identify the conditions they met during the sprint and discuss the solutions mutually. Details can be found in The Sail Boat Retrospective.
Using a weather metaphor to shift focus from simply looking back, to how the team expect things will go based on how things have played out so far. Details can be found in Predicting The Weather: A Weather Forecast Retrospective for Scrum Teams.
making a pie chart divided into 5 parts which looks like a starfish with a section for “start doing”, “stop doing”, “less of”, “more of”, and “keep doing”. Details can be found in Starfish retrospective and Starfish Retrospective Technique.
Saying “Thank you” to other members via a “Thank You” certificate. Details can be found in The Thank You Retrospective.
An action-oriented retrospective style, generating an immediate list of practical ideas for continuous improvement. Details can be found in Sprint Retrospective Techniques.
Evaluating how happy the team is about the different Scrum elements (roles, events, artifacts, principles, values, etc.). Details can be found in 40 ideas to spice up your retrospective
A great data gathering activity for recurring retrospectives. The Ls stand for: liked, learned, lacked, and longed for. Details can be found in 4 Ls: Liked – Learned – Lacked – Longed For.
And There are two brilliant episodes about Six Thinking Hats, just check ’em out.
由于回来之后加入了一个敏捷社区,机缘巧合下发现了这个课程。课程一共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.
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.
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.
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.
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
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.
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.
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.
Kanban-style daily stand-ups focus more on:
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.
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.
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:
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.
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?
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.