Monday, November 20, 2017

Daily Scrum Meeting - Pitfalls and Negative Patterns | Supreme Agile

תוצאת תמונה עבור ‪Meeting problems‬‏
The daily scrum meetings are the basic platform for the team to discuss and collaborate prior to starting the workday, it’s a daily 15 minutes (MAX) meeting, where the scrum members are asked to provide answers to three simple questions:
  1. What is accomplished since the last daily meeting?
  2. What is your plan for today?
  3. What is keeping you from succeeding to deliver?

Sounds like a very simple meeting agenda, right? However, you will be amazed to see how easy it is to turn a daily meeting into another useless and ineffective meeting.

In this article, I will make a short review of the most common pitfalls and negative patterns that affect the quality of the daily stand-up meeting.   

Mistake #1 - Team Members Not Showing Up On Time

The daily scrum meeting is limited for a MAX of 15 minutes, due to this narrow timeframe, there is a Hugh importance that the participants will arrive on time, although it may look simple to make sure that the team members are attending on time, many teams are still struggling with some of their team members that come late to the meeting due to personal discipline issues.

Suggestions for addressing this issue:
  1. Make sure that the meeting will occur early as possible, but pick the time that is the most comfortable to the team members, getting the team agreement is the first step to guarantee that they will arrive on time (and one less excuse for the team…).
  2. Make sure that there is enough time for the team members between meetings that occur prior the daily and the daily itself, if that the case, make sure that you provide the team members at least 15-20 minutes so they can arrive on time.
  3. Make sure that you do not wait to team members that come late; the rest of the team should not suffer from such behavior.
  4. In case of a team member delay, do not allow them to participate (Feedback is not taken/Given).

Mistake #2 – The Meeting Starts Too Late

The Daily standup is the first meeting that the team has throughout the iteration, as such, it’s a very important to start the meeting early as possible to allow all team members to synchronize and raise any issues that affect their progress.

Mistake #3 –NOT a Status Meeting  

The daily scrum meeting is time-boxed to 15 minutes, if the team members asked to report the work they did on the previous working day, they will most likely start to add technical information that is not relevant to the meeting, as a result, the meeting cannot end at the time scheduled and will become less effective.

The main goal to execute this meeting is to allow the team members to share information and sync about their progress (Based on the three basic questions that you all familiar with), there is no reason to discuss deep technical solutions that encounter the meeting agenda.

Mistake #4 – Too Much Detail

The meeting agenda is relatively simple; the team members are just asked to answer three simple questions, although, in some cases, the answers contains too much information than needed.  If that the case, the other members will lose their attention. To avoid this pitfall, the scrum master should keep the answers short, stop the talking once needed, and take it offline after the meeting. 


Mistake #5 – Keep the Meeting Agenda

To achieve the best results for this meeting, the team should follow the basic agenda of this meeting as it intends to be, one by one, each member of the team will provide an answer to the three basic questions :
  1. What did you do yesterday?
  2. What did you attend to do today?
  3. Any obstacles?

Any further discussion that is not relevant to these questions, should be addressed and resolved (By the SM) after the meeting.  

Mistake #6 – The Scrum Master show

The scrum master “Show” is any situation where the scrum master involvement reduced the effectiveness of the meeting, In many teams there is still a wrong conception that the daily scrum is meant for the scrum master, but this is far from being true, the daily scrum meeting is held for the team to discuss their progress based on the commitments they took at the start of the iteration.

Examples:
  1. Team members speaking to the scrum master instead of other team members.
  2. While team members are speaking, their eye contact is with the Scrum Master, which will resolve the loss of focus of all the other team members.
  3. The scrum master asks questions while the team members share their answers.
  4. The scrum master starts to plan a technical solution about a work that needed to do.
  5. The scrum master directly asks people to start speaking, the team knows what they supposed to do, so there is no real reason for the SM to interfere.
  6. The scrum master starts issuing instructions to the team members.
To avoid this wrong behavior, it’s the scrum master responsibility to educate the team members about the importance of this items, in addition to that, the scrum master should take one step back (During the meeting) to enforce the team to talk one with each other. 

Mistake #7 – Choose the Right Location

In most cases, the daily scrum meeting held in the team place of work, the main idea behind it is that we want to allow the team to start working as soon as the meeting completes.

Mistake #8 – Working with the Right Tools


Another major failure that can occur during this meeting is when the meeting executed without the relevant tools such as the Task Board and Burndown chart that shows the user stories and their status throughout of the iteration. To avoid this mistake, the meeting should be held with a visible scrum board that will allow the team members to talk about their work with the ability to use the board as a reference. 

Mistake #9 – Mixing of Different Meetings

There are five known meetings in Scrum, each one of them created to address a specific need in the process, in many situations, a common mistake occurs when the team starts to involve goals and process that must be addressed in meetings that specifically designed for that purpose.

Examples:
  1. The team discusses features that should be developed by the team during the iteration (Should be discussed in the planning and Refrainment meetings).
  2. The team discusses problems that do not relevant to their current commitments (Relevant to the Retrospective Meeting).
  3. The team starts to review their completed work and present it to the other team members (Relevant to the Review meeting).

Mistake #10 - Problem-solving

The third question that is asked during the meeting is “Is there any problem that affecting your ability to work?” a common problem that I frequently see in teams, is that team members and especially the scrum master, are using the meeting time to find a technical solutions for the problems raised instead of keeping the meeting agenda. To handle such problems, The scrum master should write down all issues raised by the team, and addressed them one by one as soon as the meeting completes.  


Saturday, November 11, 2017

Things to Avoid when Writing User Stories | Supreme Agile

תוצאת תמונה עבור ‪user stories‬‏
User stories used in scrum to manage the customer requirements in software development projects, the importance of writing a good user stories is crucial to the success of the projects and therefore they must be written correctly (Small, Informative, Spark conversation  Etc. ) to allow the scrum team to reduce misunderstandings and focusing on delivering value to the customer. 

Writing user stories may seem to be simple but believe me that they are not; there are many ways you can mess it up (Incomplete, inconsistent or missing valuable parts such ass acceptance criteria/DOD), to avoid this common mistakes, I created this list of the most common pitfalls you must avoid while creating your stories.

Large stories that increasing the work effort

Although the agile methodology provides some great process and tools to handle delays and bottlenecks that may arise during the iteration (Move it to the next iteration, rework and modify the story Etc.), we want avoid this scenarios by creating stories that will allow the team to take commitments that based on short units of work. Stories that created with the original scope that determined by the team during the planning meeting and modified during the iteration may increase the scope of the story in a way that will reduce the percentage of the team to meet their original commitments.

Stories that are changed throughout the iteration are more than welcome, this is agile all about (We embrace changes in requirements to satisfy the exact needs of the customer). However, there is a way to handle these requirements by splitting the original story into two (or more) stories that will allow the team to focus on their original commitments and then handling the new stories. 

Lack of Visibility

Stories that are not visible to the relevant stakeholders can lead to many problems such a lack of communication, failure to understand the “Big” picture and most importantly the ability to make an efficient prioritization.


Technical tasks that were written as user stories

There is a reason that user stories containing tasks and no the opposites, tasks should not be added to the product backlog in a makeup of user stories; this pitfall is mainly relevant to new teams that are not familiar with the different artifacts of Scrum.

 As a result, the team members add technical tasks as user stories, which may lead to confusion among the stakeholders once they need to prioritize the product backlog or determine which stories will be added to the next iteration.

The business value is not taking into consideration


We should always remember that the importance of the user story is mainly based on the value that it adds to the customer if the user story is written without the product owner really understand the business value that this story will add to the client, how can he make a real and effective prioritization process? To be able to make an effective prioritization process, the product owner must understand the business value of each user story and why it was originally requested by the customer. 

Stories that were written without collaboration

Collaboration among the relevant stakeholders is the main key to succeeding at writing great stories. Both the product owner and the team (Developers, Testers Etc.) should all collaborate prior to wring a user story. But making this collaboration, each role can contribute his own knowledge and experience that will most likely help to create improved and efficient stories.

Stories that do not provide answers

To write a great user story, the creator should provide answers to some basic questions:
  1. What should the team develop to meet the customer request?
  2. What is the business value of this story?
  3. What is the acceptance criteria that the team members should follow prior to starting the story?
  4. What is the Definition of Done that the team should accomplish prior to them to mark the story as “Done”?
Failure to provide answers to those basic questions will lead to confusions that will affect both the quality of the team deliverables and commitments.

Saturday, November 4, 2017

Scrum Team Roles & Responsibilities | Supreme Agile

תוצאת תמונה עבור ‪funny scrum team‬‏
The scrum team in scrum process is a collection of individuals with cross-functional capabilities (Developers, Testers, Designers Etc.) working as a single unit to deliver the work they collectively committed to accomplishing within an iteration.

The effectiveness of a scrum team is determined by their capability to work together as a special unit (Think about an elite army unit) that follows a common goal and vision determined by the product owner, this factors are critical for any methodology but particularly in scrum process that embraces collaboration and respect among the team individuals.
 

In addition, we need to keep in mind that it will take some time until the team will deliver with the highest possible standards right from the beginning (Based on my experience it normally takes about 4-6 months for a team to work at the highest performance), the improvement of the team depends mostly on the team itself, but also on the external stakeholders such as the scrum master and product owner.  

What should be the size of the scrum team?

Scrum teams are self-organized teams with an ideal size of 7+/- 2 members. If the team size will be larger than the Max suggested size (Nine team members), the team communication will become less efficient from what we expect. 

Now, if we need to add more resources to the team to handle the work effort, we will split the team into multiple independent scrum teams that will collaborate and synchronize with each other to achieve the project goal.

Characteristics of great scrum teams

For a scrum team to perform at the highest level, there are some basic guidelines and rules that each member of the team should follow:

  • The knowledge and technical skills within the scrum team are balanced.
  • Team members are dedicated to the team (work fulltime in the team).
  • Team members should follow the same rules, norms, and guidelines.
  • Each team member share is knowledge with another team member.
  • Motivated people that embrace the upcoming challenges. 
  • The team is empowered and Self-Organized
  • Should respect the other team members.
  • Should follow a common goal.
  • Should believe in the process.
  • Should work together.

The responsibilities of the scrum team 

The scrum team and each of the team members have a set of responsibilities which have to be fulfilled in order to achieve a common goal:   

  • They must report for any impediments that affecting their progress.
  • They should update their daily progress in the scrum board.
  • They have to work together to achieve each iteration goal.
  • They should add real action items in the retrospective meeting that will enforce the most important rule in Scrum of continues improvement. 
  • They should break-down the user stories into smaller tasks, estimate them and make sure they are delivered.
  • They have a responsibility to attend in different scrum ceremonies (Daily, review, retrospective Etc.).
  • They have the critical responsibility to deliver potentially shippable product at the end of each iteration.
  • They should make a real-time estimation regarding the work effort they should perform in a sprint.


My Presentations