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.  

My Presentations