Monday, December 11, 2017

Proper Product Backlog Prioritization | Supreme Agile

תמונה קשורה
The backlog prioritization process is crucial for any agile project, during this process, the product owner will decide the importance of the user stories resides in the product backlog and prioritize them in a way that the most valuable stories are at the top of the list and the less important stories will be ranked at the end of the list. 

Without the prioritization process, there is a slim chance for the team on not delivering what the customer really needs, and that's not reflecting the agile spirit of delivering real value to the customers, By the agile manifesto:

"Our highest priority is to satisfy the customer through early and continuous delivery of valuable software."

Now it makes sense that we want to deliver value to the customer (After all, he's the one the pay the money…), but in addition to that, the prioritization process will also help the scrum team to understand the customer expectation and basic guidelines for the work effort they will need to invest per iteration. 

Who's responsible to prioritize the product backlog?

As I mentioned in the beginning, it's the product owner's responsibility to ensure and validate that the product backlog is prioritized which make sense due to the fact that the PO is the one that has a direct approach to the customer. 

Now, can the product owner do the prioritization process without involving the team? No, like any other refactoring activities, the prioritization process must involve the entire scrum team, this is the only way to guarantee that the prioritization process will become more productive and effective.  

When to Prioritize?

The backlog prioritization process should be performed continuously throughout the project, there are no "Best Practices" for it, the prioritization will start once you create the initial product backlog and add the user stories, and continued prior to each iteration.

The prioritization factors

The product owner and the scrum team should prioritize the product backlog prior to the start of each sprint (Usually in the refinement meetings), but what are the main factors that they are using to decide which user stories are more important for the next iteration and which will be left in the product backlog?

The value to the customer

The first and most important factor that should be used in the prioritization process, is the Value that the user story adds to the customer, simple as that stories that have the bigger value should get the highest priority. In scrum, the team has iterations of 2-4 weeks, therefore the team must be focusing on delivering the highest value in relatively very short time.

A user story becomes more valuable based on the amount of contribution in bringing the project to life, if the user story has a low contribution in promoting the project deliverables than it becomes less valuable (These stories are Re-prioritized and placed in the bottom of the product backlog) than stories that contribute more in promoting to the future incremental releases.

Now, the "Functional" stories that add value to the customer are crucial, but that's only one side of the story, the second side is the "Non-Functional" stories that mostly added by the scrum team and does not add a direct value to the customer, these stories are added by the scrum team to improve productivity, handling external interruptions and another type of task that does not add a direct value to the incremental release but help to improve the team ROI.   


Risks and Uncertainty

The risk factor implies the amount of "uncertainty" that mostly caused by the team lack of knowledge. The less the team knows what to develop and how they should do it, the higher the risk and uncertainty. 

User stories with high risk and uncertainty have a major influence on the project and especially on the team commitments that must be delivered within a very narrow time frame, therefore those stories should be marked with high-priority to accelerate the generation of a new team knowledge in this area of expertise, Remove uncertainty and eventually to reduce risks early as possible.

Costs and ROI

Costs are a major factor in the product owner's (PO) ROI calculation. The main reason for that is that in some cases the most desirable stories might cost too much to develop, which resolve a negative ROI. 

The ROI calculation has a major value once the product owner needs to decide which stories should be delivered first, based on my experience, two equally important stories are often prioritized by costs; the story that has the lowest-Cost and positive ROI is given higher priority.

Dependencies

Dependencies in the product backlog are a fact, although we should aim to create standalone stories, there will always some dependencies among them, the dependency can be related to both "Functional" and "Non-Functional" stories. Dependencies must be taken under consideration once the product owner should decide how to prioritize the product backlog because, in some scenarios, high profile stories cannot be developed because of a dependency that must be removed prior the team can start to work on that story.


Monday, December 4, 2017

The Agile Manifesto - 4 Agile Values Explained | Supreme Agile


תוצאת תמונה עבור ‪agile values‬‏
The agile software development approach was created back then in 2001 with the publication of the Agile Manifesto, a document containing the principles and overall spirit of this new approach. The agile manifesto contains four main principles that are used to this day in any software development process that based on one of the agile methodologies (Scrum, Kanban, Extreme Programming (ET) Etc.).

The four principles are:
  1. Individuals and Interactions more than processes and tools
  2. Working Software more than comprehensive documentation
  3. Customer Collaboration more than contract negotiation
  4. Responding to Change more than following a plan
By creating these principles, the creators determined the although the values located on the right are very important, we still need to prefer the values from the left. Now, a very important thing that we must raise, is that this approach is relevant only in case of conflicts that may arise during the project. 

In this article, we will try to understand the logic behind each one of these principles:

Individuals and Interactions more than processes and tools


In order to promote a project, the stakeholders must use a dedicated and specific process and management/Development tools that will help them to accomplish the project goals. 

That's just a simple fact that we cannot deny.  However, the agile approach reminds us that there some aspects that even more important such as face to face communication, Trust among the relevant stakeholders, Self-Organized teams and more. 

Without these basic aspects, we will most likely fail to promote the project agenda that based on human resources, regarding the quality of the process and tools used on the way. 

Working Software more than Comprehensive Documentation


The traditional software development methodologies are built on the belief that there is a need in heavy detailed documentation process to handle each phase of the project. This could be fine and appreciated, but the biggest problem occurs once the documentation becomes the main goal of the team instead of focusing on delivering a working product.

The value of a "Working Software" is one of the most important concepts in agile, and therefore it gets a Hugh focus throughout the agile process. 

The main example that demonstrates this issue, is the concept of providing an increment software release in a very short development cycles (2-4 weeks) without the need to invest a major effort to document every step in the way that leads to it.

Customer Collaboration more than contract negotiation


To achieve success in almost any field, we first need to understand the expectations of the other side, this is the same thing in software development process, where we need to collect the customer requirements (Expectations) that are used as the baseline for the future development process. In traditional software development methodologies, those requirements are defined at the start of the project subject to the contract signed between the customer and the company. 

Sounds good, but what happens if the customer needs to change the preliminary requirements once he realizes that there is a gap between the original requirements and his current needs? Well, this is the problem! Due to the original contract signed between the two sides, each modification in requirements will resolve a contract modification, that in most cases will be denied by the company and will not allow the customer to get the product he really needs.

In agile, we still use contacts, but with one major difference, now the contracts are signed with the purpose to work with the customer and based on a collaborative communication that will allow the customer to modify the preliminary requirements without the restrictions as we saw in traditional models.


Responding to Change more than following a plan



In the traditional software development methodologies, we had clear phases that include a massive amount of planning that we will use for the entire lifecycle of the project. If we look at the "Waterfall" methodology that is probably the most commonly used in companies that are not using agile frameworks, we will see that there are five phases (Requirements -> Design -> Implementation -> Verification -> Maintenance), that are used during the SDLC.

Now, although each phase makes sense in the SDLC, there are some major problems that are driven by the nature of these models, Examples: 

1.   There is no option for to start a next without fully completing the previous one.
2.    There is a Hugh amount of planning per phase.
3.    There is almost zero tolerance to absorb modifications in project requirements.

So, what is so different in agile? The main thing is the understanding that ongoing changes in requirements are just another way to allow the customer to get the product that he really needs, therefore, the spirit of agile is to accept and embrace the ongoing requirements and the deep understanding that this is the best way to provide the best and most suitable product for the customer. 

The true agile spirit is based on the capability to flow with ongoing changes and not blocking them, by following this spirit, we will allow the organization to achieve some Hugh advantages that will provide a solid ground for greater collaboration with the customer.  

Saturday, December 2, 2017

Scrum at a Glance | Supreme Agile

תוצאת תמונה עבור ‪and that. gentleman, is scrum‬‏

The methodology of Scrum, is the world leading agile methodology for managing product development, especially because it's very lite, simple and flexible method to manage projects. The scrum framework provides a set of roles, ceremonies, and activities that based on the 4 values and 12 principles described in the agile manifesto:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

You can review the 12 principles as described in the Agile Manifesto: http://agilemanifesto.org/principles.html

Why it Called "Scrum?"

The origin of the term "Scrum" related to the world of rugby which is a team sport, the official definition is "Restarting play after a stoppage which has been caused by a minor infringement of the Laws".

So how it’s related to the world of software development? Well, there is one Hugh aspect that we can consider as crucial for the success of any team, and that's the "Human Spirit" that allow the team to rise above any barrier that can affect their success.

This factor can easily reflect the main idea of Scrum, of creating a cohesive team that will combine sets of individuals that will work with harmony and collaboration that will increase the efficiency of the team compared to a set of individuals that concentrates on their own success.  

Scrum Uses four Main Principles: 


Iterative Approach

Based on this methodology, the teams will now use short iterations that will include the same activities as we saw in traditional models, the main idea that similar to "Scrum" is that the team will start a new iteration (With new tasks) right after the previous sprint has finished.

Incremental Releases

After each iteration, the team will deliver an incremental working release of the product.

Building Team in scrum

The scrum team is built from sets of individuals that each one of them can perform tasks related to different areas, the team is self-organized and can handle tasks based on the iteration capacity.

Empirical Process control

Scrum uses an empirical process control that bases on the real-world progress of a project and not based on guesses or long forecast as used in traditional methodologies.

What differentiates Scrum from other methodologies?

The Scrum framework is differentiated from both agile and traditional models due to the following reasons:

Real Agility

The main advantage of scrum is that it allows the organization to manage projects with the ability to make adjustments based on the current progress and completed work.

The roles

Scrum has three core roles that are responsible for the main aspects of the projects, the roles are Product Owner (PO), Scrum Master (SM) and the Development Team. By using only three main roles, the framework provides a great simplicity that will reduce the bureaucracy and time to make project decisions.

Iterative Model

Both large and small projects are divided into small iterations (2-4 Weeks) that allowing both the team and the customer to make sure they deliver the product asked by the customer.

Communication and Collaboration

The scrum framework contains a few basic ceremonies that increase the close communication between the project stakeholders. The ceremonies are known as Daily meetings (Help to increase the communication among the team members and to make sure they all share the right goals), Planning Meeting (Determine the amount of work that need to be done to provide an incremental release of the product), Review meeting (Help the project stakeholders to review the work done by the team and to decide how to proceed ) and Retrospective (Help the team to achieve a continues improvement).

Continues Delivery

At the end of each iteration (A.K.A: Cycle), the team will deliver an incremental release of the product.

Increased Visibility

The scrum framework provides a great mechanism to allow an increasing visibility of all aspects of the project by using the built-in artifacts such as the Product Backlog, Velocity, and Burndown charts. 

When Scrum is Less Efficient?

There is no doubt that scrum is the leading agile framework used by most organizations, but scrum can still be less efficient in some cases, for example:  

  • The organization does not understand the meaning of the transformation.
  • Regression tests were done manually, which will increase the technical debt.
  • Development teams do not use continues integration (CI) method.
  • The organization does not ready to change its current structure.
  • The organization does not ready to change its culture.
  • There is no framework for an automatic build system.
  • The transition made without the relevant training.
  • There are expectations for instant results. 


My Presentations