Defer commitment

At the time of starting a new agile development project, the developers often tend to make the mistake of shifting their focus on the technologies that they should use. This is where they will take a look at the solution, develop a proof of concept, and then pick the right technology. Only after few months of starting developments, the team will figure out that they have made an incorrect decision. This happens not because we take incorrect decisions. It happens because we fail to consider some of the decisions at all. This is why it is often recommended to try and delay decisions.

One of the basic recommendations that you can see in agile decision making is to defer the decisions and delay them. It is not the responsibility of the architect to make decisions. Instead, the architect should develop a structure, which is providing freedom to defer and delay the decisions as much as possible. When you delay a decision in an Agile environment, you will be able to collect more information, which can be helpful when making the correct decision.

When you defer decisions in the agile environment, you will not completely refrain from making a choice. You should have a place to start, so that you can work on the project. Selecting a technology is just one thing. However, committing to it will be another thing.

The software architects should be careful about the way how the system is designed to integrate some of the technologies. It is important to maintain flexibility in the solution, so that one integration can be replaced with another one in the future. This will help to get the most out of agile decision making process.

— 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

The change curve

The Change Curve is one of the most powerful models, which is being used to understand the different stages of organizational change and personal transition. It is important for an agile company to have a solid understanding about change management. Then they will be able to minimize the negative impacts that change can bring in. Along with that, it will be possible for those companies to end up with effective results at the end of the day as well.

The primary objective of implementing The Change Curve is to understand how people will respond to change. For example, when a new person is taken into a new software development team, he will have to work with a new client and a new leader. It is important for the team member to accept this change and move forward. Then it is possible to make sure that the change is not creating a negative impact on project success at the end of the day.

There are multiple stages in The Change Curve. The very first stage is where the change is initially introduced. It is possible to see the reactions of people in this stage, which are associated with denial or shock. The second stage of the curve is how they become critical of themselves. On the third stage, you will be able to see how doubt is creating an impact on the work that is done by the team members. They will ask a series of questions when going through this phase. Then they will move to the next stage, where they will accept rationalisation by forgetting what they have lost. Along with that, they come in to the last stage, where they focus on solving problems and accepting change.

— Slimane Zouggari

The Sahota Culture Model

The Sahota Culture Model is an important model that all the agile teams will be able to follow. It was developed in order to understand organizational culture in a better way. In fact, the Sahota Culture Model is sharing a clear understanding about the culture via identification of the different elements, which are interconnected with each other and which are responsible for shaping the culture. This will also highlight the need to focus on the structures as well as the consciousness of a system.

People who work for agile teams often tend to focus on the processes or structures, instead of focusing on people and understanding how they work together. This can eventually give life to a variety of negative consequences. The primary objective of The Sahota Culture Model is to make sure that it doesn’t happen. In this model, we are reminded of the fact that the reality is all about consciousness or the mind-set of the people, instead of processes and structures.

As per the current organizational structure, leaders are influencing the followers. They are the ones who create the processes and urge the followers to adhere to the processes and move forward with them. This kind of a culture will not be able to deliver the best possible results to an organization. That’s why it is important to move forward with a different cultural model. The Sahota Culture Model will create an ideal environment for that.

Upon the implementation of Sahota Culture Model, it is possible for the followers to go ahead and influence the leaders. Along with that, they will be able to tell the leaders that they are expecting a change and inquire how they will be able to contribute towards it. That’s where the followers will be able to introduce appropriate changes to their behaviour and get the results they expect.

— Slimane Zouggari