Tuesday, June 26, 2018

What testers should perform to stay relevant in agile teams | Supreme Agile

Let's put it on the table, traditional software testers must step up if they want to remain relevant as testers in agile teams. You cannot run from it, agile is here and most probably will continue to be the leading SDLC methodology that will lead the industry in the upcoming years.

Testers must step up and add more skills to their arsenal to meet the new challenging environment of an agile team. Testing in an agile team has much more than what testers have used to have in traditional testing. It's no longer about working in one bug QA team that testing features once development phase is done.

Agile testing means more communication with different stakeholders (External/Internal), Faster testing with more advanced test methods (Exploratory and Risk-based testing are the classic once) and many other challenges that demand testers to develop themselves to really be able to contribute to the team and stay relevant.

The classic scenario

It usually starts when the organization understands the Hugh benefits that agile has to offer and decide to move forward and make the agile transition in the organization. Once the announcement arrives at the different departments, many questions are a raised and uncertainty becomes the employees worst enemy.

Now, if you’re a tester in a testing team the uncertainty becomes even hire and some of the most classic questions are thrown into the air:
  • How this transition will affect the testing team?
  • What should we do in the new agile teams?
  • How can testers and developers will work in one small team?
  • Who is responsible to ensure that the quality will not affect? 
This is just a narrow list of questions that I see in almost any agile transition, and we can understand why moving from traditional testing to agile testing is not obvious to testers that used to own the responsibility on testing the product that now spreads to the all agile team.

The expectations from testers on an agile team

So now it’s a fact, your organization started the transition to agile and as a tester you have a great amount of uncertainty of what does it really means to be tester in agile team, in the following paragraphs, I will review some of the mandatory tasks that any tester is expected to perform as part of the team.

Collaborate with other team members

Collaboration is one of the key principles of agile, as such, we can expect to see it from any team member and testers are not different. Testers should have the personal capabilities to communicate with other team members inside the team and also with external stockholders that are part of the project.

  • Help other team members to write tests on all level of the application (Starting from unit, component and integration tests that will make the testing process more efficient and reduce the manual testing effort).
  • Conduct test review, create test designs and reduce duplicate tests on the different testing layers.
  • Work together with the team developers to report on design issues that may raise major quality issues. 
  • Help other team members to complete a user story that hasn't progress as planned (It can be testing, writing code, and set-up the test environment). 

Help with Testability

Testability is one of the most important items that testers are expected to contribute to an agile team. Testability will help the team to increase the software quality but no less, it also helps to improve the discipline and communications.

Testability is a major part of any user story that the team will want to deliver and known as one of the five pars of the commonly used "INVEST" model for writing user stories (Each PBI should be independent, negotiable, valuable, estimable and testable).

Testers must be involved in all parts of this model but especially on the testability side, they must help the team to understand how and what they need to be able to test this story, which will increase the contribution of the other team members to the testing effort.

Another aspect of testability is that testers are now working closely with the team developers to ensure and advice on all testability aspects. As part of this discussion, the team will decide the test design, strategy (Automate/Manual) and who execute which tests.

learning is not an option

I think that it not really matters what you do in the software industry or in any other job, but just to be on the safe side I will say that for any member in agile teams and especially for testers learning is not an option it must do. Testers have just too many areas that they must contumely improve at, including testing methods, tools, coding skills, technologies, agile itself and to keep up with the production they are testing. 

Take an active part in defining "Done"

This is just a classic example of how the world of testers has changed when moving to agile teams. In traditional testing, testers had to wait for some time to the completion of the first phase (Requirements Analysis) before they even can start thinking on the test plan, Strategy and ensure all requirements are covered (It's just easier when you get one SRS document containing all the application requirements).

Now, once testers are integrated into agile team that follow the basic values and principles of the agile manifesto, any team members (including testers) are part of the all process of defining user stories, adding them to the project backlog and helping the product owner (the business owner of the product) and the rest of the team to define the relevant criteria that must be fulfilled prior the team can mark user story as "Done."

Definition of done from testers perspective is not so different from any other testing project, if they have the most experience and knowledge among all team members in this medium, they will need to ensure that the DoD will include all quality aspects that guarantee that the user story is delivered at the highest quality

From a quality perspective, a DoD of a user story may include the following:
  • All functional and nonfunctional tests with priority X, Y are executed and approved.
  • All bugs are fixed and verified (Product owner approval is needed for all bugs that are differed in future sprints).
  • All tests are automated to reduce future technical debt.
  • All major flows of the software are tested on production environment
  • The code is covered with 90%+ unit tests.
  • All major risks are mitigated with corresponding tests  

Estimate work

Same as other team members, testers will have to have the skills that should be allowing them to estimate the scope and size of the testing effort of each user story that the team will need to deliver in an upcoming sprint.

The testing effort should be estimated by the testers and the other team members in a way that the team will agree, this is crucial aspect of any estimation in agile team because it is part of the overall estimation of the size of the user story which also includes different activities such as coding, design and sometimes even research.

Provide fast feedback 

One of the most important advantages of agile software development is being able to deliver in short iterations that will allow the organization to face the increased challenges of the software industry. to be able to work in an environment of quick releases, the team must have the ability to get quick feedback on each one of their deliverables and make the necessary changes accordingly.

Again although the entire team is responsible for the quality of the product, in most cases testers will be the one that will deliver the quick feedback about the quality of the written code, testers must have the ability to  test fast and to determine the real health of the application (As fast as defects are reported, the faster the fix can be made).

Testers can share their feedback with the team while using different forms such as:
  • Bug reports. 
  • Code and Test reviews.
  • quick sessions of exploratory testing. 
  • Design and monitor quality KPI's.
  • Pair Programming. 

Fail as long as you learn

One of the biggest advantages in agile teams is that you can fail and that's just fine as long as you use it as another step for continued growth for both the individual and the rest of the team. In traditional development, the room for mistakes Is almost not exists due to the nature of the separate phases of the traditional SDLC that increase the impact of each mistake made by the involved engineers. 

Help the team to automate

When it comes to automation, Agile testing is not different from traditional testing. Automation has a major part in the team able to run a more rebuts and efficient test process while keeping future technical debt to the minimum.

In agile development environment that runs on short iterations, automation is the main option to test all the small increments functionalities that added per spring, these small changes that added per sprint will not allow the team to run the same manual tests over and over again (The software is continually changing) and regression test will become a Hugh risk to the team able to deliver in time.

The only way that an agile team can confront this issue is by using automated frameworks on all layers of the application including unit, Component and system tests and do it as much as possible (Manual tests should reduce to the minimum).

As a tester in the team, you must have the capability to write these types of tests and to contribute to the overall testing effort. That does not mean that the tester will write the automated frameworks (Again, depends on his coding skills) but he most defiantly assists in writing the test scenarios, writing them in code (It is more than accepted that the team developers will assist and educate their testers to do it).

Due to the importance of this item, I will add a real example from one of my consultant activities, and the story goes like this; I once invited to organization with more than 40 working agile teams, 35 from these teams were able to deliver on time but the remaining 5 continually fail to do so. After a week that I was reviewed how these teams have worked, I found many failures in different aspects including many HR issues among the members of the team. But the one thing that was really critical is that in all of these teams there were only two testers on a group of 10 engineers.

The bigger problem was that these testers were expected to write and execute tests without any real knowledge in automated (in-house) framework and as a result, all tests were executed manually and in the good case automated by the team developers.

To overcome this problem, I used this situation as a leverage to resolve many other HR issues that were affecting the team; First, we raised this issue in retrospective and let the testers to share their technical issues in addition to their feeling of lack of help of the rest of the team members.

Second, we let the team decide how they can help their testers to become more professional in the company automated frameworks (Per sprint, a new user story was added for this purpose, to provide the team the necessary time to help their testers).

The result of these two simple items was the trigger to major success in future sprints, after four sprints of investment in the team testers, they gain the respect of other team members, the team started to meet the stories DoD and from delivery of 40% they started to deliver in almost 90% per sprint.

  • As a tester, you will help the team to search and acquire the most suitable testing tools.
  • As a tester, you will help the team to minimize the execution of manual tests.
  • As a tester, you will help the team to reduce regression tests and technical debt.
  • As a tester, you will help the team to create different automated metrics. 
  • As a tester, you will help the team to write, execute and analyze the results of the automated tests.
  • As a tester, you will help the team to decide which tests should be automated (per testing layer).

Help the team to determine different metrics

There is one quote about metrics that I love to use in my teams, the quote is "if you cannot measure it you cannot improve it – William Thomson, Lord Kelvin". This short quote can explain why metrics are so important to any project and especially to agile projects that based on continues improvement of the process, Quality and the team itself.

In traditional testing, the metrics were very important from an organization perspective, such as the number of reported bugs, Number of executed tests etc. Now in agile, we are looking at a new world of metrics that the team must track as part of an agile working environment.

The classic metrics:
  • Sprint Burndown.
  • Release Backlog.
  • Velocity.
  • The frequency of changes once the sprint has started.
  • Team happiness 

Open and Verify defects

It's the bread and butter of any tester to report on new defects and verify them once the bug was fixed. Now, although it doesn't sound new, there are some major differences between traditional and agile testing I summarized in this table:

Traditional Testing
Agile Testing
Fix time
defect fixes might be made by the dev department days, weeks and even months ago
Bugs are fixed during the sprint (Max of 4 weeks, Min of 1 week)
Similar to bug fixes, verifications are made department days, weeks and even months after the fix was made
Verifications are made based on the PBI definition of done (So almost all bugs should be verified within the sprint)

In some cases, defects are moved to a future iteration.
Usually by the project manager/Dev Manager
Prioritization is made by the product owner and the team
Build for verifications
Verifications are made on formal builds that are created every few days.
With a good CI system, builds are available within the hour and there is no need to wait for a formal build

Be ready to handle the frequent changes

One of the biggest differences between agile and traditional testing is the frequency of the changes that the development team and especially their testers should face during the sprint. if you remember the 4 agile values than you know that it’s something that is expected from the team "Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage."   

In traditional testing, the room for changes in the testing phase are very narrowed and almost does not exists (Each disruption can severely affect the project and jeopardize the whole project) which allow the testers to work on their test strategy without the need to change it once they start to test.

As a tester in an agile team, you must be able to work in an environment that will arise many disruptions and new challenges during development that arrive from new customer requirements, changes in prioritization and many other streams that will increase the risks but without affecting the whole project (Remember that we are talking about short iterations and contuse refrainment of the product backlog that based on the exact demands of the customer). 

Thursday, June 21, 2018

The barriers to successful agile adoption by software Testers | Supreme Agile

I think that almost any major changes in life face barriers to success and in an agile transition, the story is not different. Once the organization decides to start an agile transition, he expected to face multiple barriers that arrive from many areas and especially from the organizational culture.

Let us examine the organizational culture from the eyes of the QA teams. Think about a QA team that has already established a strong organizational culture about quality, this team is now committed to the culture, which makes it extremely hard for them to drop it for the new culture that is a mandatory part from any transition to agile.

In this article, I will focus on some of the most common barriers to adoption of agile development frameworks that you can expect to see in your testers and QA teams. 

The uncertainty of their new role as testers in agile teams

There are many differences between agile and other traditional software development, the role of testers in agile teams is just one of them but yet a very important one. Testers that integrated into agile teams must have the preliminary knowledge of what are the boundaries, expectations, and responsibilities that they will need to follow in their new role. 

This is the only way to allow those testers to reduce the amount of uncertainty prior to the start of the agile transition, a tester that will not gain this important information will most likely have much more difficulties to perform at its highest performance and to be a productive team member.  

It is not just about testing anymore

Agile teams built from a set of individuals that work together to achieve a common goal. Each team member will have to use is knowledge, experience, and technical skills to help the team with the many challenges that involved in the environment of agile development.

To become really valuable team members, testers will have to take more responsibilities and roles than what they used to have in the old traditional environment. Besides the obvious activities that involve in testing, testers will have to understand the true needs of the team and take an active part in resolving them, just for example:
  • Work closely with the analysts and developers right from the very beginning of the project.
  • Help the product owner to design and determine the acceptance criteria.
  • Help the team to move forward to complete the iteration goal.
  • Interact with the product owner to clarify the business requirements.
  • Help the team to estimate stories, define ‘Done’ and assess testability. 

Relying on negative past experience

Hold your horses….past experience is critical for anyone and especially for test engineers when I analyze common pitfalls of integrating testers into agile teams, I can see one common issue that repeats numerous times and that’s software testers that have been through changes that did not succeed.

As a result, from this bad experience, testers are kept focused on their previous unsuccessful patterns and start the agile transition with a negative approach that will defiantly not help them or their new team members. Questions like “Why should I do it again?”, “I already been in this process and saw how it fail” are just classic examples and big red warning signs for this issue. 

Loss of Identity

I can write thousands of words about this topic alone, but for this article let us keep it simple. In traditional testing, test teams and each individual tester are working in an independent group with known barriers, responsibilities, and goals. 

Now that they need to move to small agile teams that built from more developers than testers, this change alone is enough to trigger many fears from the tester's side, for example: 
  • Fear of losing their ability to affect the quality process.
  • Fear of losing their job during the agile transition.
  • Fear of losing their ability to affect the prioritization of quality items.
  • Fear of being less productive in a continually changed environment.
  • Fear that they do not have the relevant skills to work in agile teams.
  • Fear that they will not get the support they will need to do their work. 
  • Fear of losing their QA identity (Now that they need to invest time in many other activities).

Bad Attitude

Is there really need to explain why bad attitude can be devastated for software testers that now need to work together with their associated developers?  By using the wrong attitude, testers will up to face major challenges in integrating into their new teams, here are some of the classic examples:
  1. Testers that does not participate in the day-to-day activities.
  2. Testers that perform only the minimum tasks without taking more responsibilities.
  3. Testers that use bad attitude towards the deliverables of their associated team members.
When the organization faced with a transition to agile frameworks, many engineers have a bad attitude that does not allow them to give a real chance to the new agile process, the results. In most cases, this engineers will leave the organization at the start of the transition or after a few weeks of the implementation process.

Although agile development has many advantaged over traditional methodologies, we need to keep in mind that agile development is not for everyone, but using the right education, training and the removal of many uncertainties can really help to mitigate engineers with the wrong attitude.

Lack of Training (Methodology/Technical)

Training is one of the most important things for testers prior they integrated into their new agile teams; the training sessions should focus on two main aspects:

Methodology – This is relevant to the entire organization that will need to get the necessary training about what is agile and how to work in this new environment. However, for testers there should be an additional educational layer that will help them to succeed in their new teams, this layer should allow the testers to visualize their future in their new agile teams and how can they contribute to the success of the team.

Technical - There is a Hugh difference between traditional and agile testing, testers should get the necessary technical training that will allow them to stay relevant in their new teams. Just, for example, a good training of programming languages will allow the testers to handle many automation challenges such as writing/using the automated framework, writing and debugging tests and share a common language with the rest of their team members.

After many years of involvement and directing agile transitions, lack of training is one of the most common reasons of failures to integrate testers into agile teams, so there is a Hugh important that your testers will gain all the training and knowledge they need prior and during the integration into their new teams. 

Thursday, June 14, 2018

The Qualities and Characteristics of a Great Scrum Team | Supreme Agile

תמונה קשורה
Don’t have any Scrum Ceremonies
This characteristic is relevant only for the most advanced teams and not relevant in any other case. So how can we do scrum without using its ceremonies? Well, this team will use scrum ceremonies (Limited in duration and performed at specific times) as opportunities for conversations that relevant to all aspects of the framework such as synchronization, planning and taking the right decisions.  

Believe in Collective Ownership
It’s very simple, you cannot build a strong team without the basic understanding the collective ownership is one of the major keys that allow the team to be really committed to the team success.

Having some Slack
There is one factor that can be seen in many great development teams, this factor is based on the ability of the team to find some slack within their sprint that is overloaded with commitments and day to day pressure. This slack allows the team to relax and to remain focused on the sprint goals. This is why we need to allow the team to make some fun to ensure that the team can keep their motivation and dedication to perform at the highest level.  

Can deliver Features Earlier and Continuously
The basic scum process is well known, the team takes commitments (User Stories) and deliver them at the end of the sprint (Presented at the review meeting). Great teams are able to deliver their commitments prior (Continues Feedback is made with the customer Whenever the story is 'Done') and continuously (The iteration time-frame become less important for them).

Deliver value in the first sprint
In Scrum, teams will usually use sprint '0' as a "Kick-Off" to the project so the team does not deliver any deliverables that create business value for the customer. A great team doesn't need a sprint '0' to start to deliver business value right from the beginning. 

Don't need a Definition of Done (DoD)
Definition of Done is used to ensure that each user story/Feature delivered based on the expected standards. Great teams, has the understanding of what DoD really means and can deliver their deliverables at the highest standards without the need to follow specific document (The can keep it only to provide visibility to other stakeholders).

The entire team Responsible to Refine the Product Backlog
The product owner has the main responsibility regarding the shape of the product backlog, but great development teams understand that the quality of the product backlog is crucial to their success and therefore will make sure that the PO receives help from all team members to ensure the product backlog is maintained in the highest quality. 

Share Knowledge and Experience   
A simple factor that can determine how good the team is performing, is by looking at the knowledge sharing by its team members. Strong teams are based on team members that sharing their knowledge, experience, and lesson learned with others. This factor is so important due to the expected benefits that the team will achieve such as; Increases efficiency, better communication, and appreciation by other team members. 

Collaboration with Respect and Trust
True great teams will have team members that respect and trust each other, this is just the basic foundations for any successful team. 

Non-Functional Requirements
The product backlog is a container of both functional and non-functional requirements, the functional requirements delivered by the product owner based on the customer demands. The non-functional requirements are another type of work units that are written by the team to reflect technical aspects of user experience (UX), Performance Etc.

Do Not Criticize People
Wrong Criticism can be devastated if directed to the wrong areas, self-organized teams that should work together as one unit should use a constructive criticism that can actually contribute to the improvement of the team. 

Using Spikes for Better Commitments
A spike user story is a great way for scrum teams to handle large, complex user stories that they do not have the knowledge, experience or expertise to solve. Responsible teams will use spikes as an approach to do the necessary research prior to taking any commitments on stories that they do not understand. 

Now, due to the nature of this requirement that does not provide a direct business value, there is a Hugh important for the scrum team to be able to explain the business value to the other stakeholders and especially to their product owner to ensure that these non-functional stories are added and prioritized in the product backlog.

Although it's very hard to build a truly cross-functional team, it’s very important that we will go in this direction. Great teams have the right composition between the different roles that allowing the team members to gain a real focus on the goal and challenges of each sprint instead of wasting time on talking about each other responsibilities.

Knows their Real Customer
As described in the agile manifesto, the customer is the most important link in any SDLC project, the customer is the one that determines the requirements and approves the team deliverables. Great teams, knows their customer and what he really "Wants" and even more important what he really "Needs".  This is the only real way for a team to be able to meet the customer expectation and develop the right product for him. 

Does not use Estimations
This factor is only relevant for the most experienced teams, those teams have the technical excellence, knowledge, and experience that allowing them to make commitments on user stories without estimating them. 

Aware of possible dependencies
In most cases there will be more than a single team that involves the SDLC, a great team will be aware of all possible technical dependencies and interfaces with other teams and manage these by themselves. 

Understand the business value
Great teams understand the business value of their deliverables and how they contribute both to the customer and for the organization. I think that it’s a basic thing for a team member to understand how each commitment can affect the Business value and what can be the consequences of low-quality deliverables. 

Free the Time to Make Some Fun
There is always room for more work to be done, but sometimes the team needs to find the room to make some fun that will help them to increase the personal relationship and to release the day to day pressure.

Make an Efficient Retrospective
The retrospective meeting allows the team to discuss all issues that need to be resolved in order to improve both the team performance and the overall process. Great scrum teams will understand the importance of this meeting and use it to ensure that they improve sprint to sprint.  

In addition, the retrospective meeting can be devastating for the team morale if it became a "Blame" meeting (which indicates the low maturity of the team). A great team will perform this meeting with a positive and creative approach that ensures that all members will want to contribute and share their insights. 

Master the concept of Team Swarming
In Scrum, the team should deliver an incremental working functionality per each iteration, the delivery should base on stories that will provide the best ROI to the customer. to do so, we need to make sure that the top prioritized stories will develop first, team swarming is an approach that allows the team to work on a narrow list of user stories (Usually the TOP prioritized stories). 

Using this approach, the team can focus on specific stories (in some cases even one story) and work together to finish them quickly, this will allow the team to increase the % of delivering the most important stories first rather than working on a series of stories that may cause delays and reduced ROI.

Monday, June 11, 2018

The red lines of Contributors and Observers in Scrum | Supreme Agile

Image result for be part of the solution not the problem

If your organization is starting with the transition to Agile, then your team may start to attract a lot of attention. Often external stakeholders of the team will want to take part in your Agile activities. Often these stakeholders are motivated by curiosity, interest in the team deliverables or just want to understand the different phases involved in such transition.

An Agile team can gain many benefits from these external stakeholders. It is important to remember, we need to keep in mind Scrum teams need their time to become "Self-Organized". This is especially true when they are new to Agile. The main challenge is to maintain the interest of those stakeholders without affecting the team capability to become "Self-Organized". Allowing the team to take full ownership of their deliverables.

The SM is a specific role in the Scrum framework who is responsible to set the scrum activities and to ensure that only the right stakeholders will contribute. During those activities, they need to make sure that only the right people are talking (Contributors) and the right people are listing (Observers).

Based on my experience, it is not a good idea to tell a senior manager they can only talk during the team activities if they share knowledge and ideas that can contribute to the team. This is even if it may contradict the pure scrum guidelines regarding on how to execute Scrum activities. 

It is very important to always watch for external stakeholders (Including senior management) who attend team activities on a regular schedule. By attending these meetings, it makes it very hard (near impossible) for the team to function as we expect from them. 

The only way that we can help our scrum masters to handle similar issues, is to set standards early in Agile projects. Those standards must define the different Agile activities as well explain the differences between the contributors and 'observers (Any stakeholder who has an interest in the team activity but does not belong to the scrum team. Therefore should not interfere while the activities are in progress).  

This may sound simple, it’s not. As a ‘Scrum Master’, it's difficult to keep "observers" from talking. The SM needs to defend the Agile activity.  Agile activities discussions are limited to a specific “time boxing” period and therefore is vulnerable to being “hijacked” by an observer who asks questions.

Of all the activities the daily scrum meeting is the most likely to be hijacked by an observer, this meeting is "Time-Boxed" to 15 minutes and that's a very narrow time frame for the development team to synchronize, share their impediments and to focus on the iteration goal.

It is, therefore, of utmost importance that during this meeting the SM ensure the meeting is not “hijacked”. Only the "Contributors" (Development team) will talk while the other "Observers" will not interfere (Scrum Master, PJM, Management and the Product Owner).

Keeping the observers from talking is a crucial part of a well-executed Agile activity. The SM must set the standards and expectations as early as possible at the start of the transformation. This will help both the team and the organization to save a lot of headaches. 

Note: Contributors refers to any stakeholder who is expected to contribute as part of the scrum team. Observers refer to any stakeholder that has an interest in the team activity, but still does not belong to the scrum team and therefore does not expect to interfere while the activity is in progress.  

Sunday, June 3, 2018

The Challenging Personalities in the Daily Scrum Meeting |Supreme Agile

Anyone who ever participated in a daily standup knows how difficult and challenging it is to run a good and effective meeting. The challenges can arrive from internal issues such as:
  • Team members coming late or unprepared
  • Team members do not share their real progress
  • Team members arrive at meetings just because they have too, but without any real wish to contribute.
In addition, there are other challenges related to external factors e.g. external managers interrupting the meeting or view it as a status meeting.

The SM must pay attention and be aware of these obstacles.  He must ensure these obstacles are removed in order to allow the team to meet the goal of the meeting. Based on my experience, the external challenges are easier to handle. A good SM will ensure these obstacles are removed from the team (usually after 2-3 meetings).

The internal challenges related to the team itself are more challenging for the SM and can take a long time until they removed. This is dependent on a number of factors e.g. team culture, motivation, commitment an, maturity. 

Now, even without these destructions (Internal/External), it is hard for a group of people to meet every day, at the same time and performing the same ritual daily.

The scrum master should know each team includes various members who have their own personalities and characteristics. This can either help the team grow or can cause many problems.

As the scrum master, you may have seen how these members cause problems during the daily standup, and if you do not know, by the end of this article it will become a lot clearer. 

The Challenging Personalities on Development Team 

The Late Riser

The daily standup usually occurs at the start of the day to allow the team to synchronize and raise their impediments as early as possible. As a result, team members need to focus early in the day. Now for most team members, this request will go through without any problem. However, in some cases, one might find some team members have difficulties remain focus during these times.

Late risers can be easily identified as they arrive late to each standup. Based on my experience, they always arrive the meeting holding a cup of coffee they prepared to start the day.  

Typically, an Agile team is built from 5 to 9 team members. Each member should answer three basic questions during the day. This creates a lot of information for any team member to absorb, especially for a late riser who has difficulty keeping focused in the morning.

Another aspect of the late risers is once the standup ends, they typically do not talk to anyone. They sit in front of their workstations to start working on their tasks. This behavior will not allow the late risers to gather the important information generated after the meeting with the rest of the team. Remember; during the meeting team members share import information extract required action items based on it.

What can the Scrum Master, do to improve this situation? Not much, from my experience, moving the meeting to the later hours of the day will not help the specific team member.  It might actually affect the effectiveness of the meeting. Therefore, the only thing the Scrum Master can do is to make sure that this specific member will keep their focus during the meeting. This can be done by randomly changing the order of the talkers, the location or changing the way that the meeting is executed (you will become amazed to see that it’s actually working).

The Talker

The agenda of the daily standup is very simple, all one needs to do as a team member is to answer three basic questions that will help the team to synchronize. In addition, the meeting is relatively short compared to the rest of the Agile activities.

These two basic factors can explain why there is no time to waste, but sometimes we have team members who ignore these factors and take time to answer questions (wasting precious time). As a result, this affects both the meeting effectiveness and the time boundaries.

There are many reasons that can lead to this behavior such as:
  • Lack of discipline and focus.  
  • Lack of understanding of the meeting agenda and its goal.
  • Team members with low confidence take the time to share their information.
  • A New teams that have limited Agile experience.
Now, as you already know, it's the Scrum Master’s responsibility to keep the Agile process moving forward and to assist the team improves day after day. In this scenario, the SM should remind the team and the particular member (after the meeting!) the purpose of the Daly meeting.

The Uncommitted Member

If you are the Scrum Master of the team, the daily standup is a great place to see the team progress throughout the process. It is also a place to see those team members who are more committed than others are.

You can recognize the uncommitted team members simply because they do not hide their thoughts and behavior throughout the standup. These members have no considerations about how their behavior may affect the rest of the team.

  • They are unwilling to collaborate with the rest of the team.
  • They consistently interrupt other members talking.
  • They come unprepared with the required answers.
  • They do not reveal the truth about their real progress.

The uncommitted team members are the ones the SM must take care of first and soonest. This is because these members can affect others. Furthermore, it reduces the team's ability to grow as a self-organized team. As the Scrum Master, one should talk with these members and try to understand the reasons for their behavior. You must ensure you assist them to overcome them in a way that will increase their commitments and contribution to the team.

The Blamer

Blamers are just another type of difficult team member who can affect the daily standup. As discussed earlier in the article, the daily standup is the place for the team to discuss and synchronize. There is no room for team members to point fingers at someone else when the work is not progressing, as it should be.

Typically, the blamers are the ones that constantly interrupt the meeting by shift responsibility to others whenever they can. They never take the blame when they encounter problems to meet their commitments. They do not responsible for their mistakes, bad decisions or sometimes even poor performance.

The Scrum Master must recognize these team members. He/she must work with them to remove this negative behavior. The SM must redirect their attention away from blaming others and toward facts that can actually help the rest of the team to understand the problem and collaborate towards finding a solution. 

My Presentations