Water-Scrum-Fall is a software development methodology that combines the elements of both Scrum and waterfall development methodologies. Most agile organizations out there in the world are currently following the Water-Scrum-Fall procedure because of the effectiveness associated with it.

Back in the day, waterfall was the most common development methodology. However, organizations understood the shortcoming associated with sticking to a waterfall methodology. For example, they were spending too much of time unnecessarily on the project upfront. On the other hand, they had to face numerous challenges at the time of implementing change as well. However, those organizations were not ready to go fully agile as well. That’s where they started using a combination of waterfall and agile methodologies, which is known as Water-Scrum-Fall.

Water-Scrum-Fall can be considered as a flexible approach available for development of a product. That’s because it is helping the development teams to fully understand the problem that has to be solved, while providing them the opportunity to come up with a practical method to solve it. Organizations that follow Water-Scrum-Fall methodology are adhering to the waterfall method when they are planning, project management, and budgeting. However, the development teams are adhering to agile in their day to day developments. This will eventually benefit the development team to get their work done.

One of the most important aspects that you can find in a Water-Scrum-Fall environment is that the project would still need high-level project planning. However, it would have governance and approval gates, where it is following a traditional approach as per the waterfall method. In the meantime, the development team would adhere to non-agile interactions with the project and front end teams. This would eventually help them to adhere to the Dev-Ops and continuous delivery principles, while ensuring smooth transition in between all deliverables.

— Slimane Zouggari

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 18^th 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

When working on a software development project while adhering to the agile framework, it is important to have a clear understanding about Scrum anti-patterns. An anti-pattern is following a process that doesn’t adhere to the guidelines of agile methodology. When such a method is followed, it will not be possible to achieve positive results as a scrum team. The scrum team will be making the life harder when moving forward with the software development project. Due to the same reason, it is important to have a clear understanding about the Scrum anti-patterns and take appropriate measures to get rid of them.

Here are some of the most prominent Scrum anti-patterns that you can find in agile teams. When you are aware of these Scrum anti-patterns, you will be able to take appropriate measures to overcome them.

Absence of a product owner is one of the most common Scrum anti-patterns that you can find. Even if a product owner is present, he might be absent during most of the sprint. Then it will not be possible to answer the questions that the development team will come up in a timely manner. As a result, a micro-waterfall approach will be created. The development teams will never be able to release their developments in a timely manner. Due to the same reason, it is important to make sure that the product owner is present during the entire development phase.

Lack of flexibility shown by the product owner is another example for Scrum anti-patterns. In here, the product owner should be flexible to adjust the acceptance criteria, especially when the initial requirement cannot be achieved due to technical limitations. If there is no impact on the business, product owner shouldn’t worry too much about it and the product owner should change acceptance criteria.

— Slimane Zouggari

Nexus spring backlog will be created at the time of Nexus sprint planning. This is a visualization of the work that has to be done throughout the Nexus, which contains all dependencies. Primary objective of Nexus sprint planning is to properly coordinate the activities of the scrum team within a single sprint.

Implementation of Nexus model within the agile scrum team to scale it properly will make Nexus spring backlog possible. It will help the scrum team to get to know about the dependencies and volume of work that has to be done.

When it comes to Nexus spring backlog, the entire product development roadmap will be visualized. Then it is possible to get a clear understanding on what kind of developments will come up in the future and how to prepare accordingly. Along with that, it is possible to visualize all the dependencies as well.

We tend to go ahead with Nexus spring backlog in order to make sure that all the upcoming developments are properly aligned with planning. This will also help us to manage the dependencies effectively. Along with this understanding, proper scaling of teams can be done.

In order to get the most out of Nexus spring backlog, you need to make sure that you are getting the most out of Nexus sprint planning. That’s because Nexus sprint planning will determine how the backlog items are properly utilized for the developments.

Nexus spring backlog is used when the development team, or the product owner has a clear understanding about the development roadmap available in front, but needs to properly scale the development team, so that developments can be completed timely.

— Slimane Zouggari

Nexus is a scaling framework that you can find in agile. If you want to scale the agile teams within your company, this is the right approach available to move forward with. This framework focuses on how to organize teams to deliver a project that has a large scope.

Scrum model has bottlenecks when delivering large projects within a short time period. That’s where Nexus comes into play. This framework can help a company to get two or more teams involved to complete a project. Along with that, it is possible to deliver the large scale project within a short time period.

If a large project has to be completed, one team will not be able to work on it and deliver it within a short time period. This is where the help of more than one team is required. Nexus comes into play in such a situation. You can easily scale two or more teams through this framework and get them to work collaboratively ensure timely delivery of the project.

Scaling teams is important to get most work done within the limited time. Therefore, it is important to go ahead with the Nexus framework and properly scale the teams to complete a large project with tight deadlines.

When two or more teams are working to achieve one common objective, misunderstandings can happen. Hence, it is important to understand how to overcome them.

If a development has to be completed within a short time period, it is important to overcome overheads. Overcoming such overheads will become an easy thing to do with the help of Nexus model. That’s because it has got the ability to eliminate the bottlenecks and deliver positive results.

— Slimane Zouggari

Those who are working in agile community they have had come across this new new product development game a lot of times. This white paper was published in 1986 and it is still valid and it does helps the businesses. Having a look, we see that there are six key principles of this paper which are connected to each other.

When we see the traditional approach while developing a product then it will move like a relay- race as the baton is passed from group to group. Now, when we see the new new product development game then it will be like rugby, where the team is having the ball and they pass it to each other and take it to the desired place. The most used framework scrum is also inspired by it.

Six key Principles

Let us take a look on the key principles of new new product development game:

1. People are quite possessive about the business or work plan in the traditional approach, and they control and monitor day to day activities for others. But, this new new product development approach themselves. While talking about scrum, the race is an agreement between the development team and management. Product owner and the others will decide how to work and where the flexibility is needed.
2. Project teams which are self-organizing if exhibit these three conditions will be ideal. The conditions are autonomy, self-transcendence and cross fertilization.
3. Overlapping the development phases, that will enable the team to absorb the noise or vibration generated throughout the development process.
4. Multi-learning, now this is said that it is a two-dimensional learning i.e. 1) Multi-learning across multiple functions. 2) across multiple levels. Are we clear with the vision? Is the right product selected or being built? In scrum there is a learning opportunity as the team working on the product interacts with each other and learn from the market trends.
5. If we say that a person has both “control through peer pressure” and “self-control” then we can say that he is having subtle control. The sprint goal should be inspected by the development team so that they can adapt the sprint backlog in accordance.
6. The transfer of learning should be done on organizational level, spring and scrum should make it sure that the team members share knowledge with each other.

— Slimane Zouggari

Spike

A task particularly aimed at collecting information or answering a query instead of delivering shippable outcome. Sometimes user story that is generated and cannot be properly estimated until a development team executes some actual works geared towards resolving design problems or technical questions. The solution is to actually make a “spike” wherein some work have the purpose of providing a solution or answer. The word “spike” comes from Extreme Programming or XP wherein this means “A Spike Solution is an ultimately simple program for exploring potential solutions”.

Spike in Agile Software Development

In the agile software development, architecture actually evolves in order to address the needs of Product Backlog Item or PBI’s forecasted on the given Sprint. This is lean. Unlike a skyscraper or a bridge, establishing business software does not really require defining the entire architecture upfront. Remember that spikes are invention of XP and are considered as special types of stories that are used in driving out risks and uncertainties on project facets or user story. It might be necessary to spike on the perfect persistence option however, implementation of spike must be wrapped to a PBI.

Spikes by definition got maximum time box sprint size. That tends to be your upper bound. At the sprint’s end, spike is either done or not really done same as other stories. Spike is the technical investigation to produce answers with regards to certain criteria on PBI prioritized on upcoming sprints. This is an excellent way of mitigating risks earlier and promoting fluid iterations later on projects. This also allows team to ensure feedback and develop clearer understanding on upcoming complexity of PBI.

Why Doing It?

Spikes are done for the following reasons:

• The group might not know about another area, and spikes might be utilized for fundamental research to acclimate the group with another domain or technology.
• The story might be too huge to be estimated accurately, and the group may utilize a spike to analyze suggested conduct, so they can part the story into respectable pieces.
• The story might contain essential technical risk, and the group may need to do some examination or prototyping to pick up trust in a mechanical approach that will permit them to commit the client story to some future timebox.
• The story might contain noteworthy functional risk, in that while the purpose of the story might be comprehended, it’s not clear how the framework needs to communicate with the client to accomplish the implied benefit.

Just like other common stories, spike is actually put on backlog, sized and estimable to fit perfectly in iteration. The spike results vary depending on the type of the story as this generally produce information instead of working code. Spike can be used and can result to decision, proof of concept, prototype and other partial solution which tends to help in driving final results.  In an instance, spike must be developing just the sufficient information to be able to identify and size stories concealed beneath the spike.

— Slimane Zouggari