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.
PMBOKGuide, 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.
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.
“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.
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.
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.
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.
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?
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?
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.
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 (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
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.
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’.
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.
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.
The term ‘Agile’ was created in a meeting sited by a group of software developers in 2001. They only produced the Manifesto for Agile Software Development, whereas did not explain what ‘Agile’ means. “The only concern with the term agile came from Martin Fowler (a Brit for those who don’t know him) who allowed that most Americans didn’t know how to pronounce the word ‘agile’“, Jim Highsmith noted this interesting story in History: The Agile Manifesto.
As mentioned above, 17 ‘independent thinkers around software development‘ came together to talk, ski, relax and eat on February 11-13, 2001. But after this small conference, they had done a landmark work that found an alternative to the traditional heavyweight, document-driven processes and produced the Agile Manifesto at the end. Today, ‘Agile’ is very broad and is interpreted in the agile community in several different ways. For instances, AgileAlliance defines Agile as ‘the ability to create and respond to change‘; ScrumAlliance suggests that ‘the term agile describes a specific set of foundational principles and values for organizing and managing complex work‘. And as far as I’m concerned, Agile is a set of ideological values that can not only improve productivity but also contribute to a better working environment compared to the traditional development methodology.
On the other hand, I do not agree with some basic views of Agile. For example, the author of The Agile Samurai, Jonathan Rasmusson, presents a definition of agile in website Agile in a Nutshell as ‘Agile is a time-boxed, iterative approach to software delivery that builds software incrementally from the start of the project, instead of trying to deliver it all at once near the end‘. In my view, Agile should not be seen as the Scrum framework (a time-boxed, iterative approach to delivering software), which is just one of the well-known Agile frameworks! Moreover, we can see that there are also many well-known behaviours, concepts and techniques associated with Agile frameworks, while they only can be represented as being part of the Agile way of working, instead of the Agile.
Manifesto
The symbolic output emerged from the meeting and signed by all participants was the Manifesto for Agile Software Development, or the ‘Agile manifesto’ as it is more commonly known. It should be emphasised that the meaning of the final two lines of it is crucial to understand: it is a case of the relative importance of the values, and not a case of ‘good’ or ‘bad’.
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over Processes and tools
Working software over Comprehensive documentation
Customer collaboration over Contract negotiation
Responding to change over Following a plan
That is, while there is value in the items on the right, we value the items on the left more.
1. Our highest priority is to satisfy the customer through the early and continuous delivery of valuable software.
2. Welcoming changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
3. Working software is the primary measure of progress.
4. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
5. Business people and developers mustwork together daily throughout the project.
6. Build projects around motivated individuals, give them an environment and support they need, and trust them to get the job done.
7. The most efficient and effective method of conveying information to and within a development team is face-to-face communication.
8. Agile processes promote sustainable development. The sponsors, developers and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity, the art of maximising the amount of work not done, is essential.
11. The architectures, requirements and designs emerge from self-organising teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adapts its behaviour accordingly.
Features
As presented above, Agile has not been defined in a specific and unified way, while there are many mindset (behaviours or values), concepts (fundamentals) and techniques (practices or tools) that are treated as being part of the Agile way of working. There are some examples of them (obviously, not all of them) shown subsequently as follows.
Mindset (Behaviours)
Customer-focused
Embracing change
Being collaborative
Self-organising
Empowered
Trusting not blaming
Respect each other
Being confident
Empiricism
etc.
Concepts
Prioritising what is delivered
Not delivering everything
Communicating continuously and clearly
Working iteratively and incrementally
Continuous integration
Limiting WIP (Work in Progress)
Time-focused
Inspection and adaptation
Kaizen
etc.
Techniques
Timeboxing
Backlogs (Product and Sprint)
User stories
Planning poker
Burn charts
CFD (Cumulative Flow Diagram)
Retrospectives
etc.
Frameworks
It is an interesting fact that some processes, approaches and frameworks focusing on improving iterative and productive capabilities had been created and applied in practice before the term ‘Agile’ created (in 2001), such as XP (eXtreme Programming), Scrum, DSDM (Dynamic Software Development Method), ASD (Adaptive Software Development), Crystal, FDD (Feature-Driven Development), Pragmatic Programming. And actually, Agile was initially introduced by the representatives of these frameworks above, so that they are all included in the family of frameworks being agile basically. Although Agile and most frameworks of it were originally applied in the software development domain, some of them have been recognised as successful frameworks beyond software development nowadays. In addition, there are also some commonly known hybrid approaches having been used in more challenging situations.
There are some typical frameworks in the Agile frameworks family introduced as follows.
widely-used
Scrum. The Scrum Guide defines Scrum as ‘a framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value‘.
Kanban. A method to improve flow and provoke system improvement by visualising the workflow and limiting work in progress.
Lean Startup. It is a methodology for the development of businesses and products aimed at shortening lifecyclesof product development and discovering the viability of the proposed business model quickly. Lean Startup approach was originally employed for starting up companies, while now is applied to any business.
IT only
DevOps. A collaborative approach combining the work and even the teams of software development (Dev) and information-technology operations (Ops), which aims at creating a product or service through shortening the systems development life cycle and providing continuous delivery with high software quality.
XP. It stands for eXtreme Programming that is an iterative software development methodology focusing on improving the quality of software products and the capability of responding to the requirement change. XP can be employed solely while commonly used in conjunction with Scrum or Kanban, where XP involves software development and Scrum or Kanban is utilised for the management of work as an overall structure.
SAFe. It’s the abbreviation of Scaled Agile Framework. SAFe is an application used to guide the organisation proceed to work with sufficient size or level of difficulty in scaling lean and agile practices.
Hybrid
Scrumban. It is an application Kanban where the underlying process is based on Scrum. This combination, a mixture of the structure of Scrum and visualisation of Kanban, enhances the ability to adapt and respond to change without being overburdened.
PRINCE2 Agile. PRINCE2 Agile is the world’s most complete agile project management solution, combining the flexibility and responsiveness of agile with the governance of PRINCE2. This approach provides a solution for managing the holistic project process by blending the strengths of PRINCE2 and Agile, that concentrate on the areas of project direction & management and product delivery respectively. It should be noticed that unlike other agile frameworks, PRINCE2 Agile are only suitable for use on projects.
Agile Today
Agile is Trending
Agile has become more popular in software development contexts. “Looking back over the years, it is incredible to see the changes and additions to the report, as Agile adoption has grown and evolved“, CollabNetVersionOne suggests in its blog based on the released 13th Annual State Of Agile Report. The report collected and analysed the information of states of agile from 1,319 responses around the world. It points out that 97% of responses that now use agile are listed in the report. Nonetheless, only 22% of respondents say that their teams are agile, 26% more than half and 48% less than half. One remarkable benefit coming from adopting and implementing Agile is ‘Accelerating software delivery’ (74%). And there are many advantages that can be seen, such as ‘Improving team morale’ (34%), ‘Reducing project risk’ (28%) and ‘Better managing distributed teams’ (19%). The result also indicates that a 71% rise in ‘Reduce project cost’ compared with the previous year is the key explanation for agile adoption.
In regard to the domains beyond software development, Agile has made a significant impact as well. KPMG has released Agile Transformation – 2019 Survey On Agility with responses from more than 120 participants from 17 countries. The survey shows that more organisations are aware of the term Agile according to ‘Agile being scaled with 70% of respondents indicating an ambition to integrate both Business and IT-enabled Agile transformation in the next 3 years‘. Agile is trending!
Agile is Dead
Just like Agile born, when the influence and popularity of a new method continue to rise, it may always bring opposed opinions. These theories against agile are not just derived through theoretical derivation or guessing, but come from the feedback and experience gained by using agile in practice. The tendency of anti-Agile has increased with the influence of Agile. This situation emerged from the birthplace of Agile and has now occurred in many countries and industries. The earliest and the most famous event of anti-Agile is the presentation Agile is DEAD by Dave Thomas, one of the creators of Agile Manifesto. He illustrates that nowadays “Agile” has been defined as the practice of recklessly performing a set of rigid rules and bureaucratic procedures. However, the original Agile means “break all the rules”, while delivering high-quality products, do the most valuable work in a specific environment to achieve the highest production efficiency.
Nic 