Spotify Model 

Spotify model is an organizational methodology that is using guilds, chapters, squads and tribes. Squad is the underlying foundation of this framework. It is acting similar to a Scrum team. Squad will self-organize and determine the best method to work. A tribe will be made from a group of individuals who are working for a common area.

Squad in Spotify model is single project and single product focused. Product owner is responsible for managing the backlog. In the meantime, agile coach will be able to accelerate the transformation process and make it move forward in the positive direction. Tribe will be co-located along with the squad, but it is limited only to 100 individuals. Chapters will be a part of squad, where the team members are working together. Final aspect in Spotify model is the guild, which is made out of a group of individuals who share similar interests.

An agile team will tweak the formation of the team and move forward with Spotify model. It will be able to streamline the nature of work that is done.

If a client wants the development as soon as it is requested, Spotify model is the right option available to go ahead with and achieve the desired functionality.

If the team is used to traditional agile methodology, making the shift to move forward with Spotify model will be quite challenging.

Most of the multinational companies are currently using Spotify model. That’s because they want to beat the competition and deliver products quickly to customers. If a competitor is doing something, Spotify model will help to get that requirement delivered quickly to the market before competitors.

— Slimane Zouggari


Automotive SPICE in agile software development refers to a quality standard, which is providing ability for the automobile manufacturers to go ahead and assess the overall performance of the suppliers and their engineering processes. Primary objective of this is to provide ability for project management to make sure that the requirements are catered in a better way and a high-quality output is obtained at the end of the day.

The importance to maintain quality standards such as ISO and IEC 15504 have tempted the agile development teams to go ahead with SPICE. Then it is possible for them to make sure that a high-quality product is obtained at the end of the day.

Proper planning and management will be able to help the development teams to end up with a quality outcome. That’s because it will help the people who work with production to adhere to the stakeholder and system requirements. In addition to that, it is important to make sure that all the implementations and test cases are properly worked on as well.

We are living in a world where there is a strong requirement to maintain quality. You will be able to maintain quality in an effective manner with the help and support offered by SPICE.

There should be properly defined requirements to be worked with SPICE. That’s because SPICE focuses on adhering to the requirements.

It is possible to define the requirements get approval for the requirements from different entities. Then it is possible to make sure that following such requirements will give life to a quality outcome at the end of the day.

— Slimane Zouggari

Nexus Integration Team

Nexus Integration Team (NIT) is a new role that you can find within the Nexus framework. This role will be performed by a group of individuals. As mentioned in the Nexus guide, this team will be able to coach, coordinate and supervise the application of Nexus framework within the Scrum team. Along with that, it is possible to get the best outcomes of the Nexus framework implementation as well.

Primary responsibility of the Nexus integration team is to make sure that Nexus framework is properly maintained and adhered to by the team. It is important to scale the agile scrum teams. The team will supervise and see whether it is taking place properly. If not, appropriate actions will be taken for it.

The Nexus integration team has a clear understanding about Nexus framework and the role played by it within the agile scrum teams. They will closely monitor the process and introduce changes as needed.

Nexus framework is important to properly scale the agile scrum teams. Once it is implemented in the team, the team should be able to follow it and get the most out of it. If that doesn’t happen, a series of issues can take place. That’s where the Nexus integration team will monitor the process and make sure that everything happens properly as planned.

It is important to highlight the importance of Nexus framework for the agile teams, so that they also make an effort to move forward with the changes and stick to it at all times.

If an agile team is not adhering to the Nexus framework, a Nexus Integration Team can analyze the situation and provide appropriate feedback.

— Slimane Zouggari

Agnostic Agile

What is it?

Agnostic agility in information technology is the use of best practices and procedure for the efficient working of the business. It states that one framework never works best for every client, the practitioner has to address the problems of clients to achieve a higher level of agility.

What are the 12 principles?

The twelve agnostic agile principles are the following:

  • To care about the client interest first and empower them.
  • I will put my all efforts, knowledge, and practical experience that fulfils the customer’s needs at best.
  • I will focus on what the customer need is instead of pushing with is not needed.
  • I will work best to overcome all the hurdles that come in the way.
  • I will share my all experiences and knowledge to improve agile practices.
  • I will give respect to structure, work according to it, and will appreciate those who help in developing the framework.
  • If there will say something beyond my knowledge, I will accept it and seek help from other practitioners.
  • I never hide the choices that benefit the customers and mislead someone by saying I know when I do not know.
  • I will use traditional approaches as well when agility is not enough.
  • I will stay from become dogmatic because it is non-agile.
  • Sometimes the agility is not the end, so I will find the other ways that better the agility.
  • I will share my knowledge with the community and learn from it to give the benefit to the both.

Why is it useful?

Agnostic agility is useful because it helps the clients by providing them the best agility that will help to meet all the needs and fulfils all the requirements.

What is the difference with other agile methods?

You will find many other management frameworks like a waterfall, Kanban, scrum and all these have different methodologies. Scrum is a complex and rigid framework while the other two are easy to use and implement.

— Slimane Zouggari

Lego Serious Play

Do you know what the term Lego Serious Paly really is? Or how you can get started with Lego Serious play? Well, if you do not about this term and want to learn, then keep reading this article.

Lego Serious Play is a special methodology in the agile world. The Lego Group created this methodology and made it available under the open source which is a model of community-based. The goal is to be a creative thinker by using Lego bricks. Big companies use Lego Serious Play methodology to enhance their business performance through the imaginary scenarios by constructing Legos in three dimensions. Now let’s get started with this methodology.

All you need is some Lego bricks. There are multiple colors and set options to choose from.  Go to Lego meetups or organized one of your own. In these meetups, a question will be given to all attendants and each one of them will answer it by using Lego bricks. In the end, a single model will be built as a team in order to represent the understanding of the respected problem. After this action and decisions would be taken. In big organizations and companies, employs the use of Legos to represent their work with confidence and commitment.

By using Lego Serious Play one can explore connections and relationships between people and their world. Lego Serious Play guides you in an honest and freely opinion’s exchange. The tangible and physical construction will allow you to make conversation without fearing of treading upon some kind of personal feelings. This way real issues will get addressed and other people will also get a chance to see the problem with their eyes. Lego Serious play allows you to take a shortcut toward the core. Lego bricks work as a catalyst and when you will use it for metaphor’s building, the processes would be the trigger that you might not previously aware of.



— Slimane Zouggari

Popcorn flow

Around the year 2000 a new method of getting things done fast and easy was produced it was called Agile software management(IT). This was used to make groups of individuals make fast and quick decisions while continuously learning and adapting at the same time due to this method many businesses and organizations quickly adapted this approach and implemented it within their respective regimes.

However even though this was initially a success certain problems started to boil to the surface. Many teams would get stumped on certain problems and the team management would break down this occurred due to the lack of proper management and a very strict chain of command the higher ups would let the managers make all the rulers and the workers who actually had to do the job would getting fumbled and the smooth machine of a working industry would break down for this very reason a smart individual decided that change had to be brought into the works and hence he came up with POPCORN flow.

How does it work?

Popcorn flow essentially works like a fast-acting virus where teams adapt to the nature of the business and evolve along the way the concept is a small team will evolve and adapt far quicker than a huge team. Essentially popcorn flow is based on three principles. They are that one must adapt quickly, everyone must share their opinion so that the common opinion becomes fact and then they must learn as fast as well. A typical team will look at problems, find the possible options, experiment with those options commit to one then work with it review the answers and move on two the next issue. This quick and fast-moving process is how popcorn flow works. It is a fast-adaptive method that gets things done efficiently and on time.

— Slimane Zouggari

Programmer Anarchy

For the knowledge of people, Programmer Anarchy is another concept that is related to Agile. It serves as a post-Agile that’s coined by Fred George. Programmer Anarchy says that the development of software is more profound and have more chance to get success when the programmer who’s doing the job is self-organized.

The concept of what to develop manager is less environment where the programmer can still survive without the aid of the manager or the head. Programmer anarchy want to changes the professionalism and involvement of the manager of the team and the programmer takes the responsibility for the fall and success of the project. The author of programmer anarchy wants the developer to be manager less with every project that they do.

When to use Programmer Anarchy?

Program anarchy is the process of developing a product such as application with manager less and instead, they are the one who stands between the clients and the work force. You use the concept of Programmer anarchy when you are on a project, which your team does not need to have a manager that will represent you. You can observe the criteria of the agile team that works hard to meet the deadline, but the difference here is there no other professions that will serve as the manager.

When not to use Programmer Anarchy?

Programmer anarchy gives many benefits for the developers. There is still the presence of commitment needed. Since that, you do not have the manager who will give you the deadline; you are the one to motivate yourself. Most of the developers that cling to the idea are more devoted to finishing the project than the average. If you do not have the gusto to bring all your effort, better stick to the agile way.

Concrete examples of Programmer Anarchy

The author says that the manager has the power to take action and direct it to whom the developer team is. Let us say that the manager want you to rewrite the agile story and repeat the process using .NET and SQL Server. As a developer, you think that it was already written well but the manager insisted that you rewrite it. The manager can be tricky at times because they really do not change the story and makes the effort of the developer go to waste.

Criticisms about Programmer Anarchy   

Shifting to programmer anarchy can be a waterfall because of the shifting of the development team and the customers. It says that agile development manager less can be difficult for the programmer to handle and take the full responsibility. They say that programmer without managers can be stressful for the part of the developer. However, many developers switch to programmer anarchy and happy with the result that they experience.

Even though that programmer anarchy limit or do not buy the idea of manager based team, they still have the presence of agile manifesto compliant. Such as interaction with the process and the tool use, the working software present in the agile thing, collaboration with the customers, and the immediate changes to the plan. Overall, there is the agile way with manager less concept.

— Slimane Zouggari

eXtreme Programming

Extreme Programming: What is it and basic principles?
Extreme programming is an agile development methodology that is primarily aimed at increasing productivity when developing a software project. Priority to jobs that give a direct result and in which the bureaucracy that may exist in the work environment is reduced.
We have 12 basic principles that are grouped into 4 different categories:
• Feedback.
• Continuous process rather than blocks.
• Shared intellectual property.
• Shared understanding.
Test principle: the first thing you should do is set a period of acceptance testing program, in which the inputs and outputs of the system will be defined. Basically it defines what should the software developed. As if it was a black box.
Planning: The clients (or his representative) write needs to define precisely the activities that the system must perform. At this stage a document containing user stories that form the release plan, which defines the delivery time of the application in order to receive feedback from the client will be created.
In-situ client: the client (or his representative) should be part of the development team. You will be given the power to determine the requirements of the application define the functionality and prioritize certain things. Thanks to this, there will be a strong interaction with programmers, thus reducing communication time and the amount of documentation to write. The customer will be with the team throughout the project development process.
Pair-programming: These points with the above are the most radical of this methodology. It is to write code in pairs sharing a single machine. According to the experiments already carried out on this method, better and more consistent applications at equal or lower cost occur.
Continuous integration: is gradually implementing new software features. Instead of creating stable versions according to a schedule previously performed, programmers meet your code and rebuild the project several times a day if necessary.
Refactoring: by constantly removing duplicate code and / or inefficient programming teams improve the system design. The code is continuously evaluated to provide the highest possible quality.
Small deliveries: the product is tested in a real environment by placing a simple production system which will be updated quickly, ie, every 2 weeks (maximum 3) the software will be put into production.

Simple design: the best program is one that meets the requirements and simpler. It is important to provide software that meets the needs of a client. No more no less.
Metaphor: expresses the evolutionary view of the project and defines the objectives of the system through a story.
Collective ownership of code: the code has shared ownership. Nobody owns anything, even what he has developed. All programmers are “owners” of all the code. According to this methodology, the more programmers is working on a piece of code, fewer errors will.
Programming standard defines the rules for writing and documenting code, and how the different pieces of code developed by different teams communicate. The aim of this is that it seems that the code has been written by a single person.

–Slimane Zouggari


SAFe presents a single, unified view of the work to executives, allowing them to drill down for details or up for trends and analysis
A team in SAFe might be 8 to ten people, with everything they need to deliver software, end-to-end: requirements, coding, testing and deployment. Several teams create what SAFe calls a release train, which organizes around a program (more on that below). That’s a single project, or at least, one program-of-projects. It has a single line item in a budget – the company is buying one specific thing. This is the “small project” the executive talks about.
A portfolio is a collection of these programs, the total amount of budget dollars within IT going into software development. SAFe calls this “Program Portfolio Management,” and suggests that one office have the responsibility for strategy and investment funding, program management and funding.
In SAFe terms, the “Release Train” is the team-of-teams, typically 50–125 individuals. Like a real train, the release train runs on a schedule, though that schedule can be as flexible as your organization needs it to be. This Program Increment (PI) is described in more detail below. SAFe suggests that people involved in a release train be dedicated full-time to that release train, regardless of reporting structure.

The Scaled Agile Framework, or SAFe, provides a recipe for adopting Agile at enterprise scale. It is illustrated in the big picture.
As Scrum is to the Agile team, SAFe is to the Agile enterprise.
SAFe tackles the tough issues – architecture, integration, funding, governance and roles at scale. It is field-tested and enterprise-friendly.
SAFe is the brainchild of Dean Leffingwell.
SAFe is based on Lean and Agile principles.
There are three levels in SAFe:
* Team
* Program
* Portfolio
SAFe defines an Agile Release Train (ART). As iteration is to team, train is to program.
The ART (or train) is the primary vehicle for value delivery at the program level. It delivers a value stream for the organization.
SAFe is three letter acronym (TLA) heaven – DBT, ART, RTE, PSI, NFR, RMT and I&A!
Between 5 and 10 teams work together on a train. They synchronize their release boundaries and their iteration boundaries.
Every 10 weeks (5 iterations) a train delivers a Potentially Shippable Increment (PSI). A demo and inspect and adapt sessions are held. Planning begins for the next PSI.
PSIs provide a steady cadence for the development cycle. They are separate from the concept of market releases, which can happen more or less frequently and on a different schedule.
New program level roles are defined
* System Team
* Product Manager
* System Architect
* Release Train Engineer (RTE)
* UX and Shared Resources (e.g., security, DBA)
* Release Management Team
In IT/PMI environments the Program Manager or Senior Project Manager might fill one of two roles. If they have deep domain expertise, they are likely to fill the Product Manager role. If they have strong people management skills and understand the logistics of release they often become the Release Train Engineer.
SAFe defines a Scaled Agilist (SA) certification program for executives, managers, architects and change agents responsible for leading SAFe implementations.

–Slimane Zouggari

What is Agile Software Development

Agile software development is a set of principles that portrays certain requirements for software development. It comprises of solutions that evolve better through self-organizing and cross functional teams. The principles are aimed at promoting adaptive planning, early delivery, and constant improvement, and it also encourages flexible and speedy response to change. Agile was first introduced in the 1980s when the idea of technology and technological advances took off in the Western world and has since then undergone a number of significant changes. It doesn’t consist out of any specific methods, but rather a range to choose from.
Before these methods are discussed, it is important to note that in 2001 the official Agile Manifesto had been drawn up which exemplifies the certain goals and requirements of agile software development. It consists out of the 12 principles of agile software development that keeps its developers on the right track. These also influence the different methods which will now be discussed in short.
The waterfall model is more of a philosophy than it is an actual method in which the mind-set is aimed at the project. It is usually in direct contrast of the iterative approach due to their complexities and differences when opposed to each other. The main differences between these two are the ways in which the software is built and tested. The waterfall method comprises of a separate building and testing phase, whereas in iterative methods the development testing is done concurrently as it usually is done in programming. Both these methods deliver desirable results. As soon as the developer has more knowledge about the software’s functions and values, they can make more informed choices. This is especially important when it comes to scrum as this kind of software development only has an iteration of 2 weeks.
Another method that can be used is the dynamic systems development method (DSDM) which acts as a project delivery framework. This forms part of an iterative approach and embraces user involvement. This type of development has the ability to fix costs, quality, and time at the outset. It categorizes the do’s and don’ts so carefully that it has become the number 1 method of agile software development. The DSDM method also underpins 8 important principles that developers should and can follow when they are busy with such a method in order to produce effective results.
This method is more focussed at the development team than it is on the actual product and process it is working on. It is very beneficial when it comes to agile software development, because it boosts team productivity. In this approach, team members are placed within a full view of the project and each person has an assigned task to complete. Participants work in a queue where delivery time is shortened and the product is completed more effectively. In terms of agile software development it is effective in working as a visual process-management system in the sense that it shows the team what to do.

–Slimane Zouggari