Agile Testing Quadrant

Agile testing will be a productive and dynamic testing type. The main objective of this testing is to go ahead with the testing work continuously with the development process. In here, the testers will need to remain in the ambiguity with related to the approaches and procedures to conduct agile testing.  While keeping that in mind, it is possible for the testers to take a look at the Agile Testing Quadrant. This is pretty much a manual or a tool that has divided the overall agile testing methodology into four different quadrants. Let’s deep dive and analyze each quadrant with examples.

The first quadrant of Agile Testing Quadrant is to ensure the quality of components and quality of code. This is done with the involvement of the developers. On the other hand, the testers will go through requirement document and come up with the most effective test cases as well.

The second quadrant of Agile Testing Quadrant is to focus on the busines driven test cases. In here, business requirements are focused to detail. During this quadrant, both manual and automated tests will be conducted to go ahead with story tests, functional testing, pair testing and simulations.

In the third quadrant of Agile Testing Quadrant, reviews and feedback from the previous testing quadrant or the phase will be considered along with the actual user experience delivered out of the software. This is where the real world user scenarios will be evaluated. Logical thinking of the tester plays a major role behind the success of this testing approach.

The last quadrant of Agile Testing Quadrant uses tools and technology to automate the overall process of evaluating a software development project. This is where the testers will tend to pay more attention to the non-functional requirements such as compatibility, security and reliability.

— Slimane Zouggari

Technical debt

Development teams in agile software development will tend to use simple and cheap technologies to proceed with their developments. Or else, they will tend to invest in additional resources to come up with better solutions. When you go ahead with low production cost and faster project implementation without focusing too much on the quality of software, you will have to deal with technical debt. In other words, technical debt refers to the cost that you have to bear for all the new work that has to be done in order to come up with a new solution, so that the system functionality can be retained.

It is tempting to use fast and cheap technologies as we are only focusing on the current situation. However, it can give life to lots of negative consequences in the future. It will not just be associated with rework. It can also include the cost that has to be born to refine and repair the product in future as well.

To refrain from technical debt, the agile software development teams should always keep in mind that there is a possibility for technical debt to incur. While keeping this understanding at the beginning of a software development project, it will be possible to take appropriate decisions. In other words, decisions can be taken in a controlled and conscious manner to eliminate technical debt from taking place in the future.

Technical debt can lead a development team towards wasting time, money, and resources unnecessarily. On the other hand, it would delay the delivery of product to the product owner. As a result, the product owner can get frustrated as well. hence, all development teams should be fully aware of technical debt and take appropriate steps to keep that away from taking place at all times.

— Slimane Zouggari

Mikado Method

Software development team often try hard to fix things, while ensuring that nothing else would break because of the change they do. All the developers who wish to overcome this struggle in an Agile development environment will be able to adhere to the Mikado Method. That’s because Mikado Method can help them to understand how to morph an existing system sand get the desired output, without having to deal with any negative consequences.

There are four major methods associated with the Mikado Method. The first method out of them is to define a goal. You will define a goal and then think about what you want to achieve in the future. After defining a goal, it is possible to understand the starting point for a change. On the other hand, it is also possible to figure out whether the method can ensure success or not.

The second method is to experiment. This is where a series of attempts are being made to end up with a discovery, which would validate a hypothesis. When it comes to the software industry, the developers will do developments and experiment with the code. Along with that, it is possible to understand what changes would make the overall system break.

Visualizing is the third step of Mikado Method. This is where you will write down the goal and all the prerequisites associated with that goal. Along with that, you will draw something called a Mikado Graph. Then you will move to the last process of Mikado Method, which is to change and restore the system, where you get that back to the working state. When you are implementing a goal, you will visualize the needs that should be changed within the system to keep it away from breaking. If the code is not in a position to deliver expected functionality, you will have to undo it.

— Slimane Zouggari

The elephant and the rider

The elephant and rider is an effective method available to motivate and move forward an agile software development team. When the team lacks motivation, team leader will be able to take a look at this concept and practice it accordingly. This can eventually help the development team to conceptualize how to make decisions and create lasting changes.

According to the elephant and rider concept, rider is referring to the rational brain. Rational brain loves to contemplate the future. However, it tends to focus more on the problems, instead of the solutions. It would look for the analysis options and patterns and then make the plans accordingly. However, the brain will usually get frustrated due to uncertainty.

Elephant refers to the emotional brain. It is dealing with stress and fear. It is possible to spook the elephant easily. However, the elephant doesn’t want to do things that don’t offer immediate gratification. Hence, the elephant always prefers to look for pleasure, so that it can avoid pain. The elephant needs reassurance. On the other hand, it can easily get demoralized and overwhelmed.

The rider is sitting on top of the elephant and it looks like the rider is setting the navigation. Therefore, people usually tend to misunderstand that elephant is bad and rider is good. We all should overcome such emotions. The emotions are responsible for providing us with motivation. Instead of taking control over the emotions and forcing them to remain silent, the elephant and rider should both collaborate each other. Then they will be able to refrain from struggling and cater to the desires pf each other. This method of thinking will motivate and an agile team and ensure the success of it.

— Slimane Zouggari

4 rooms of change

4 Rooms of Change is a proven psychological theory. We can often see how this theory is being used along with agile software development to ensure the best returns with change management. Let’s deep dive and learn more about what this psychological theory is all about.

When a software development team starts working on a new software development project, they will not be able to see the change. This is where the team will stay in the Contentment Room. The current situation will deliver a satisfying experience to all the team members. No team member will have the need or desire to change anything as well.

However, things will change along with time and this would trigger the team to move into the next room, which is the Denial Room. It becomes essential for the software development team to adapt according to the change. This is where the team would ask why it is important to adapt according to the change. Resistance to change that arises in such a situation will lead the team towards getting into the Denial Room.

Once the change is accepted, the development team would get into the Confusion Room. This is where the team goes through an emotional journey that is filled with anger, fear, and many other related emotions. That’s because the team is facing a new situation and they don’t have a clear understanding on what would happen next.

With commitment and dedication, it is possible to move to the next room, which is the Renewal Room. Everyone will have adjusted mindsets when getting into the room. In other words, they are ready to embrace the new challenges. The entire process represents the journey associated with change management in agile software development.

— Slimane Zouggari

Understanding ACI’s Agile Coach Competency Framework

The ACI’s Agile Coach Competency Framework is breaking down agile coaching to 8 different competencies as well as a coaching stance. There are three different domain competencies in this framework. They include transformation mastery, business mastery and technical mastery. Technical mastery focuses on the technical aspects of the software, such as software craftsmanship and architecture. On the other hand, business mastery is referring to product innovation, process innovation and operational innovation. Transformation mastery refers to facilitation, organization change and leadership.

Teaching and mentoring are two prominent competencies that you can find within the ACI’s Agile Coach Competency Framework as well. Teaching is all about the ability to reach people. It can be about teaching a team member about agile values or how sprint planning works. On the other hand, mentoring refers to the sharing of knowledge through experience.

You can also find facilitation and professional coaching as two competencies in ACI’s Agile Coach Competency Framework. Professional coaching has the ability to help the agile team to find solutions to most of the problems that they are facing. This is accompanied with facilitation. Facilitation refers to the process of holding impartial stance. For example, agile coaching will need to facilitate the agile development team via a retro. However, it is important to remain impartial throughout the process. The objective in here is to hold the agile team and keep them sticking to the agreed guidelines.

The last competency associated with ACI’s Agile Coach Competency Framework is Agile and Lean Practitioner. This ensures that any person who wants to become an agile coach should have a deep understanding on agile and lean. Any person who wants to become an effective agile coach will be able to follow ACI’s Agile Coach Competency Framework and get the most out of it.

— Slimane Zouggari

Trim the tail

One of the key objectives of Agile software development is to reduce the time taken to go to the market while maximizing value. This is where it is important for the development teams to focus on things that can add more value. Trim the tail is an approach that a software development team can follow to get the job done while ensuring the best return.

Trimming the tail is a strategy that is associated with three different parts. The very first step would be to figure out the known social risks and technical skills. This has to be done as early as possible. After understanding the risks, it is possible to address them while running the tested features in smallest way possible. This should be done prior to the developments. In other words, this process has to be completed while the items are still on the backlog.

The second step in trimming the tail is to figure out the backlog items that are in a position to deliver the highest business value. Along with this understanding, it is possible to assign a high priority to the work and get them done in an effective manner. They will be implemented by the development team while running the tested features in the simplest possible way as well.

The final state associated with trimming the tail is to defer feature improvements and quality improvements back into the work queue, so that the development team is working to improve the overall value of the system. In here, the development team would implement a walking skeleton of the system and then proceed with the other developments, which can add more value into it. This will help them to release the basic product to the market that can add value to the business and introduce new features to it along with time.

— Slimane Zouggari

Scrum guide 2020

Scrum was developed back in the year 1990. As of now, scrum and agile software development methodologies are heavily being used by the software development teams all around the world. The latest update to the scrum guide took place on 18th of November 2020. This update was published by Ken Schwaber and Jeff Sutherland.

One of the biggest changes that you can see in the scrum guide 2020 is the removal of software specific terminology. As a result, it has become possible to use scrum for non-technical environments as well. You can find simple terms and simple language along with less perspective.

There are some changes to the definitions as well. For example, the definitions associated with definition of done, increment, sprint backlog, sprint goal, product backlog, empiricism and scrum definition have changed.

Development team concept that was included in the scrum team is now removed. This is done with the objective of eliminating the dysfunctions that can take place in between the product development team and product owner. Along with that, the entire focus of the scrum team is on the same objectives.

As per the new definition, the scrum team is now made out of a product owner, scrum master and developers. All the people who work to create a usable product are called as developers, regardless of the specific functionalities that they have. On top of that, entire team is now responsible for the development of useful and valuable product and ensuring the delivery of that increment at the end of the sprint. To add more value to this, the terms responsible and accountable are used more consistently.

These are some of the most prominent changes that we can see in the scrum guide 2020. If you are working for an agile development team, it is worthy to get your hands on the scrum guide and be familiar with all the changes.

— Slimane Zouggari

The theory of constraints in Agile

The Theory of Constraints, which is also known as ToC explains how organizations are kept away from achieving their goals in a timely manner due to the presence of one or more constraints. The constraint that you can find in agile environment will be a production value or a product quality related issue. If you want to break these constraints, you will have to continuously improve the system, so that the existing constraints are improved or protected. Then they will no longer become a constraint in the future.

In order to overcome the negative effects created by Theory of Constraints in an agile team, it is important to follow five different steps. Here’s a quick overview of those five different steps.

The first step would be to identify all the constraints. In here, it is possible to understand all the poor practices and anti-patterns that exist within the agile team. Then it is possible to improve the system. Upon the discovery of constraint, it is important to go ahead and exploit it. This will be the second step. In here, it is possible to get a clear understanding about the product backlog, so that you can make sure that you are not sending out poor inputs that can negatively impact the developments. On the other hand, it is important to identify all dependencies beforehand and resolve them.

The third step will be to subordinate everything related to the constraint. Then everyone is aware about where the bottleneck is and they will be able to overcome the bottleneck effectively. The fourth step will be to elevate the constraint. Some methods that can be followed in here would be to improve the tools used and provide appropriate training. Last but not least, it is important to make sure that inertia is not creating a constraint as well.

— Slimane Zouggari

Nonviolent communication

Nonviolent communication, which is also known as NVC or compassionate communication is a methodology that is developed by Marshall Rosenberg back in the year 1960. This principle is based upon the assumption, which says that all the human beings have a capacity to empathy and compassionate. People tend to violate only when they notice that there is no other effective method available for them to get their requirements catered. While working in an agile environment, it is important for you to have this understanding about nonviolent communication in mind and move forward accordingly.

According to Nonviolent communication, it is believed that human behaviour is originated from the attempt to meet the basic human requirements. Then it is said that their needs are never in conflict, but they are just strategizing to meet to meet their needs and end up with clashes. In the meantime, Nonviolent communication is proposing that it is important for the people to get to know about shared needs. These shared needs will be revealed through feelings and thoughts. Then they will be able to collaborate and develop better strategies, which will eventually help them to focus on catering the needs of each other in a better way. Along with that, it is possible to ensure interpersonal harmony. Along with that, proper cooperation can be achieved.

Nonviolent communication principles can be applied to an agile software development team as well. For example, when the testers are waiting too long for the developments to be released for testing and when they notice that there is not enough time available for testing, they will end up with getting into conflicts. Instead of going for such conflicts, the testers and developers will be able to work collaboratively and come up with an appropriate methodology to get their requirements catered.

— Slimane Zouggari