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.

Cross-Functional
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.

Examples:
  • 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