Monday, December 25, 2017

What is a Sprint in Scrum? | Supreme Agile

תוצאת תמונה עבור ‪scrum sprint‬‏
According to the Scrum methodology, development cycles are called " Iterations" and with the other and more familiar nickname of "Sprints". These development cycles are relatively short and can go anywhere from a week to a month (Most organizations iteration with a length of two weeks).

During each development cycle, the team collaborates as a single unit to deliver a working part of the software based on the customer demands and expectations. At the end of each sprint, the team will present the accomplished work (A.K.A: User Stories) and right after that review a new iteration that based on new tasks can start.

What is the idea behind this short development cycles?

The answer is simple when the team needs to take commitment to a long-term task they will not be able to see when it ends. Now, in most cases, the team will provide an Eta, but the problem remains the same, the team does not have the ability to take real commitment because no one can foresee the problems, challenges and new tasks that can arise during this time that will reduce the focus from the main task.

To resolve these problems, scrum uses short iterations that are restricted in time and in the number of tasks that the team will perform which will allow them to remain focused on short-term tasks without the need to foresee the future work month ahead. 

In addition to the above, we can see some other great advantages for using the method of short development cycles:

  • There is more room for handling issues that arise during the iteration.
  • The team will determine the amount of work that they will do per iteration, this sense of ownership will help to increase their sense of commitment. 
  • The team will commit to only the amount of work that they can deliver. 
  • The team will use a set of structured meetings: Daily Scrum that will allow them to remain focused on the iteration main goal, Planning meeting that occurs at the start of the sprint to understand the requirements, challenges, and expectations prior to taking any commitments that based on the team capacity and velocity, Retrospectives to improve and adapt the process for maximum efficiency, and review meeting that will allow them to get real feedback about the quality of their work.


The Main Phases of a Sprint 

Phase 1: Determine the Sprint Backlog and Team Commitments

Every sprint begins with a planning meeting (Pre-Planning meeting may be also used), which involve the entire scrum team, during the meeting the team discuss which user stories should be added to the sprint backlog, the decision is made based on the prioritization of the items in the product backlog (PO) and the team velocity that determines the amount of work that the team can handle in a single iteration.

The sprint backlog is a set of stories that should be delivered by the team at the end of the sprint, each story that is added to this backlog should be approved by the team prior to taking any commitment to deliver it.At the end of this phase, we have prioritized sprint backlog, updated product backlog, known goals, and set of commitments made by the team.

Phase 2: Sprint Execution

The team will work together to finish their commitments for succeeding to meet the iteration goal. Their work will include different activities such as Design (HLD/LLD), Coding (TDD/Continues integration Etc.) and testing (Risk Based testing/Exploratory and Automated testing on different layers of the code (Unit, Component, Integration, and System)).

In addition, this phase also includes the daily scrum meeting that will help the team to synchronize about the remaining work and to ensure that everyone stays in focus regarding the iteration goal. 

Phase 3: Iteration Results

Once the iteration is completed (2-4 weeks), the team will demonstrate the potentially shippable product increment to the relevant stakeholders (Product Owner, Customer, Etc.).

Phase 4: Continuous Improvement

At last, the team also performs a retrospective meeting at the end of every sprint to discuss on how things went and what can be improved in future sprints.    

Wednesday, December 20, 2017

The Burn-Down Chart as a Fundamental Metric in Agile | Supreme Agile

תמונה קשורה
The Burndown chart is a fundamental metric in agile, the metric presents the team progress in completing the committed user stories and it provides a quick view of when we can expect to be done. The main parameters in this graph are the amount of work reaming (usual story points or days) and the time remaining until the end of the iteration.

The Burndown chart should consist of:
  • X-axis to provide information about the iteration working days
  • Y-axis to provide information about the remaining work
  • Ideal effort as a basic guideline for the effort need to be completed.
  • Real team progress of effort

The burn-down chart is the main tool of the team to provide viability about the state of the project because it can answer the main questions that asked during any project: 

Types of Burndown Charts

Sprint Burndown Chart

The Sprint Burndown chart is a visual measurement too, that provide a quick insight into the completed/remaining work per day for the current sprint.  Benefits:
  1. Provide a quick review of the team effort.
  2. Will allow the team stakeholders to take fast decisions based on the graph results (that will help to remove impediments that are affecting the progress).
  3. Provide daily feedback on the team progress.
  4. Provide transparency to the team performance.
  5. Help to determine if the team can accomplish the sprint goal.
  6. The main communication tool for customers and product owner. 

Release Burndown Chart

In scrum, the release is determined by the delivery of a product from development to the customer. A release Burndown chart helps the stakeholders to get a very good view of the release progress by determining the amount of the remaining work (X-Axis = No of sprints, Y-Axis – The remaining effort). 


How the Burndown chart is built?

The Committed Work (Y-Axis)

Prior to starting a sprint, the scrum team first selects a number of user stories they want to accomplish, the process of analyzing, Prioritizing and Estimate the PBI's is done in a dedicated meeting called "The Planning Meeting" that is done prior to the start of each sprint. To get the work estimations, we need to combine all estimations of the PBi’s committed by the team (Y-Axis).

The Iteration working days (X-Axis)


The X-axis represents a unit of time (2-4 weeks) represented by days, by following this axis, we can determine the amount of work completed for a specific time. 


What is the Total Work Estimate?

The total work estimate is the sum of the efforts (Hours) of all the user stories which the team is committed to.

What is the Remaining Work Effort?

This question can explain why this graph gets its name (“Effort Burndown Chart”), by looking at the graph, we can get an instant look at the effort made by the team per day.

What is the Amount of Working Days?

The question can easily be answered by just looking at the graph that shows the total days of commitment of workdays (Sprint Duration).

How Much Work Done by Now?

The graph also presents the amount of work that the team accomplished through a period of time (This data can be also used to predict the iteration future progress).

What is the team velocity?

The graph can provide an instant look at the current team velocity, the calculation is made based on the work done for a given period of time.

Can the Team Add More Stories to the Iteration?

If the PO decides to add more work to the iteration/project, the team can instantly review the burn-down chart and see the impact that the new demands on the current delivery date.

Burndown Chart Team Scenarios

Although the Burndown chart contains only two lines, there is a major importance to understand the different situations they describe. These situations are probably the most common (Depends on the quality and experience of the team):

The Role Model team

This team characterized by two major qualities:
  1. Has the relevant experience (Technology/Agile).
  2. The team is familiar with the importance of agile commitments.
  3. The team can adapt interruptions that may arise during the iteration.
  4. The team embraces the retrospective meeting to achieve continues improvement per iteration.

Although the team started with some gaps, they manage to resolve all issues and complete the iteration on time. In addition, the team will use the retrospective meeting to resolve all issues appeared in the last iteration to become better in the next iteration. 



The Ideal Team

The Ideal team characterized by three major qualities:
  1. The team is able to organize itself.
  2. They know their velocity and boundaries, and therefore will not commit to a number of user stories that will lead to “Over-commitment”.
  3. They have the ability to estimate capacity correctly to remove the unnecessary loss of working days.

The Burndown chart of this team will indicate that the team has finished all commitments on time. 

The Average Team

The average team is a team that is able to complete their commitment and iteration goals. Based on the represented graph, we can see that the team is able to adapt to the delay they had during the iteration and work harder to complete the remaining work.

This graph is more common for experienced agile teams for the following reasons:
  • They don’t panic once they have an unexpected delay.
  • They know how to adjust to the new challenges and hard work that they will need to perform to meet the iteration goals.
  • The team knows how to prioritize the iteration stories (Low prioritized stories return to the product backlog).

They have good communication skills that allow them to take decisions immediately as they see the delay from the beginning of the iteration. 

The Team that Can Do Much More 

There is a good reason way team commitments are so crucial in agile software development, the main reason is that once the team is committed to delivering a set of stories, the expectation from the other stakeholders is that the team will deliver what they committed to, simple as that.

The Burndown chart can reflect unaccomplished commitments in a very easy and graphical way, but in addition, it can tell us when the team fails to adopt the iteration scope to a work level that will allow them to meet the top prioritized stories.

It is very important for the team to take active corrections once they discover that they cannot handle the work capacity (you will see it once there are a few days of slower progress), the most common corrections are:
  1. Move user stories to the product backlog (for re-estimate/Prioritize).
  2. Move user stories to the next iteration (If the priority remains high).
  3. Split stories to smaller units.
  4. Reduce the next iteration capacity (There is no reason to set the same capacity if the team cannot handle the work effort).


The Nonfunctional Team 

The graph of such team will present a scenario that represents a catastrophic picture about the team performance that may arise from many reasons:
  1. The team is not committed to the process.
  2. The team is not coached enough to track progress on a daily basis.
  3. The product owner does not care about the work done by the team and therefore does not ask any questions.
  4. The scrum master fails to enforce the agile spirit and practices throughout the iteration.
  5. The team does not update their daily progress on purpose.
  6. The team does not do an effective retrospective meeting that mitigates wrong behavior. 

The Team that Ignoring Work Estimations

In this scenario, the iteration Burndown chart will indicate that user stories (and the associated tasks) were not estimated during the iteration-planning meeting and added to the iteration without time estimations.

To fix this situation, the team should immediately arrange a planning meeting, estimate the user stories, include them in the sprint according to their velocity and start the sprint.

Team With Over Commitments

This graph represents a team that took a scope of work that is too big for them to handle, as a result the team fails to meet the iteration commitments.

The Team that Overestimated the Scope of Work

This graph represents a team that finishes its work earlier than they expected but didn’t take corrective actions, such as work on additional stories from the product backlog (Although they had the capacity to handle it).

The Team that is Not committed Enough

Although the team will succeed to finish their commitments and meet the iteration goal, the Burndown chart display a problem in the team behavior, this problem is related to one of the following reasons:
  1. The team is less committed and took a break in the middle of the sprint (Although they have more capacity to extend the work effort).
  2. The team committed to fewer user stories, although the team velocity allows them to add more work.

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