Earned Value Management

Tuckman’s Group Development

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.

Tuckman’s Model in PMP and Scrum

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

Norming vs. Performing

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.

Should the ScrumMaster be responsible for removing impediments?

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.

Scrum Guide

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.

CSM Course

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

“The Great ScrumMaster”

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.

Discussing With My Friend

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.

Summary

In conclusion, I would say this question should be discussed and answered in several situations.

The ScrumMaster should determine the current stage of the team. If the team is at the beginning of Agile transformation with less self-organisation, help the team identify, think and resolve impediments in an Agile way of working.
The ScrumMaster should identify the cause of the impediment. If the impediment is caused by the outside of the team, the ScrumMaster needs to solve it through communication and coordination with external to ensure that the team can focus on achieving the goals.
The ScrumMaster should assess the importance and urgency of impediments toward the goals of the team and organisation. If there is a big threat, say it and address it as fast as possible.
Otherwise, help the team remove impediments themselves so as to encouraging self-organisation.

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.

About “The Great ScrumMaster”

“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

So, A Great ScrumMaster should

believe in Agile and Scrum.
believe in people.
be a servant leader.
focus on observing and listening first.
aim to encourage self-organisation.
try to change the world to be better.

Methods for Retrospective Meetings

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.

Blob Football

Colouring a blob person image to depict how the sprint went. Details of Blob Football can be found in The Blob Retro.

Car Brand

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

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.

Emojis

Using various emojis to gauge how the team feels during the Sprint. Details can be found in Emoji Retrospectives 😃.

Fast & Furious

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.

Jack Sparrow

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.

Kudo Cards

Using Kudo Cards to help deliver feedback and motivate people. Details can be found in Retrospective with Kudo Cards.

Legos

Having team members build something to represent how the sprint went. Details can be found in Agile Retrospectives with Legos.

Sail Boat

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.

Weather Forecast

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.

Starfish

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.

Thank You

Saying “Thank you” to other members via a “Thank You” certificate. Details can be found in The Thank You Retrospective.

Traffic Lights

An action-oriented retrospective style, generating an immediate list of practical ideas for continuous improvement. Details can be found in Sprint Retrospective Techniques.

3Ws

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

4Ls

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.

Dr Edward de Bono’s Six Thinking Hats

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.

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.

must do daily stand-up
must do stand-up
same time every day
keep it short (not simple, but efficient and effective)
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:

What obstacles are impeding my progress?
(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:

What did I do yesterday that helped the development team meet the sprint goal?
Do I see any impediment that prevents me or the development team from meeting the sprint goal?
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.

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

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?

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?