Thursday, January 4, 2018

Who is the worst enemy of an Agile implementation | Supreme Agile

You have selected your new scrum masters, and they are ready to do their job as key stakeholders in your scrum teams. The project starts and everything looking great, the ceremonies are happening, the team works as a single unit, the velocity increase per iteration, so we can say that the team performs at the highest level. Then, without an early notice, the impediments are starting to raise and affect the team ability to keep the same performance as they succeed to do until now. Well, what can we do...? It is the Scrum Master time to step up and help the team to remove those impediments that affecting their work; this is probably the highest priority of a scrum master that need to ensure that the team can perform at the highest level.

“A manager's most important work is helping the people doing the work. Give them a goal and let them work. Remove any impediments that get in their way. Do anything that may make them more effective or productive. Then the organization can capitalize on the fruits of their work.” KEN SCHWABER

Impediments, what does it means?

Prior to reviewing the different types of impediments that may arise during an agile project, we first need to understand what an impediment is. The dictionary value of “impediment” described as “something that makes progress, movement, or achieving something difficult or impossible:”

And if we want to see how the formal definition is related to agile, we can use these specific definitions (There are more, just run a quick search on google :) ):

  • "A hindrance or obstruction to doing something. Frequently used to describe some issue or blocker that is preventing a team or organization from performing Scrum in an effective way."
  •  “An impediment in Scrum is a factor that blocks the Development Team in its creation of a valuable piece of software in a Sprint, or that restricts the team in achieving its intrinsic level of progress.”

Knowledge is power

In scrum, impediments can come from different areas and in all shapes and sizes, therefore, there is a Huge importance that the scrum master which responsible to remove them will have the relevant knowledge and familiarity to handle them.

Let us review some of the most common impediments that arise in almost any project:

Unstable builds

The scenario goes something like this, the team created a great sprint backlog and they are ready to conquer the world, the progress is great and suddenly the build is corrupted due to 1000 reasons, what should they do now? Well, you guess it right; the scrum master should ensure that the team would get a working build by promoting it with the CI team as the highest priority. 

Process Issues

In some scenarios, the team should work when the process is not fully implemented or implemented inappropriately.  The impediments in that area related to all issues that related to the process and affect team able to do their job. Examples:
  • Integration between teams not defined, and cause bottlenecks in the day-to-day work.
  • Missing ceremonies or technical knowledge to perform them.
  • Scrum masters/Product Owners that do not know how their role.
  • Key Stakeholders are not contributing to the process as they supposed to do.
  • The team does not know how to estimate that work prior to taking their commitments. 

Blockers for a user story

User stories are planned and committed at the start of the iteration, but they cannot predict which problems may arise once they start to work on it (Risk Assessment is one way to increase the percentage to try to predict it). Blockers can arise from both external and internal locations; the scrum master responsibility is to ensure that those blockers removed to allow the team to continue their work.

Lack of technical knowledge

In some cases, the team needs to deliver stories that they just do not have neither the experience nor technical knowledge to handle them. The scrum master responsibility is to ensure that the team will get the missing knowledge that they will need to handle similar challenges. Few Examples:
  1. Ensure that an expert will attend the planning meeting to share his knowledge with the team.
  2. Add another member to the team that can balance the necessary knowledge and experience needed to handle similar stories.
  3. Provide technical training for the team in areas that they do not have the necessary knowledge.

The process is not enforced

There are just too many examples of impediments that arise from this area; the scrum master responsibility is to ensure that the organization will follow both the scrum process and its spirit.

Technical debt

I hate this one, technical debt is a situation where the team cannot take new stories until they succeed to remove the technical debt that they allocated until now. A great scrum master will analyze the reasons that led to this situation and will make the necessary actions to reduce this debt and in some cases even to remove it completely (Automation, Automation, and automation!).

Negative Approach

There is always that person who thinks he knows everything and based on his knowledge, agile is a complete waste of time, and therefore he is not willing to be committed to the process. Now, because agile based on self-Organized teams that work together to achieve a common goal, such team members that possess a negative approach may affect other team members similar to a bad apple in a basket. 

Sickness of a team member

You base the team commitments based on two major factors, the first one it the team velocity and the second one is the team capacity. Now, you know these two factors at the start of the iteration, but you cannot predict how the capacity would change once you start the sprint and one of your team members will not arrive to work for one, two or maybe an entire week.

Now, there is nothing that you can do here, sickness of a team member is not something that you can forecast, but a good scrum master will become aware of this impediment and will help the team overcome it by involving the PO and the team regarding the work that they may unable to deliver as they intend to do at the start of the sprint. 

The physical working Place

The physical working Place should allow the team to perform at the highest level, if that’s not the case, it is the scrum master responsibility to ensure that the team will get the most suitable physical working Place that will help the team to maximize their abilities.

Unstable working environment

Working environment includes impediments that arrive from the hardware, software, and tools that the team needs to use to perform their work. it’s the scrum master responsibility to ensure that such impediments will remove soon as possible due to the massive impact that they may have on team progress.

External interruptions  

The team performs a daily meeting and suddenly a manager of another team arrives and start to interfere with the meeting agenda, sounds familiar? Therefore, in that case, it is the scrum master responsibility to ensure that the team will not suffer from unwanted interruptions that come from external resources.

Common questions regarding impediments

Question: Can the team start a sprint with impediments?
Answer: Yes, as long that there are no critical impediments that entirely blocks the team. 

Question: What do the team should do in the case that there are many impediments?
Answer: Continue to work on other user stories until the impediments removed by the SM, in any case, that the team cannot show a real progress, they can set a meeting with the PO to review current progress and expected deliverables.

Question: Who should fix an impediment?
Answer:  The most suitable stakeholders (Engineer, Product Owner Etc.) that can remove the impediment as quickly as possible.

Question: Can an impediment stop the sprint
Answer: In rear cases yes it does, for example, The sprint based on an external supplier that does not available for the team and therefore the team cannot proceed. 

Question: What is the SM responsibility regarding impediments?
Answer: I already explained it, but the SM should summarize, tack and ensure that the relevant impediments removed. He can do it by using other stakeholders or do it directly (Pending is own set of skills).

Question: Who responsible to determine the prioritization?
Answer: The team has the best knowledge about which impediments are more crucial for them and therefore should have the responsibility to share it with the team SM. The SM has the responsibility to ensure that the team will do the ordering and the reporting. 

Question: What are the main factors used in the prioritization process?
Answer: The basic factors that I love to use are as follows;
  1. The Amount of risk by Removing/Not-removing the impediment
  2. Effect on the iteration goal
  3. Impact on team motivation
  4. Impact on velocity

Questions to consider prior to handling impediments

So, as the servant leader of the team, the scrum master should be responsible to remove any impediments that affecting the development team’s progress. Now that we say the obvious, let’s remember that the scrum master as another critical responsibility to create a self-organized, cross-functional and committed team, by removing impediments that the team can resolve themselves the scrum master can actually create more damage than a real benefit.

Therefore, now that we understand these two major responsibilities, we need to understand how the scrum master should react to impediments that arise from the team and what are the questions he should answer prior to automatically mitigate them.

My suggestion is to follow these set of 10 questions:
  1. Is the described impediment is the symptom of a bigger problem?
  2. Is this impediment describe the real problem? Is it contains all the relevant data?
  3. How this impediment affect team progress?
  4. Is this impediment must be removed at current sprint compared to other impediments?
  5. Do we really need to resolve this impediment?
  6. What is the Risk of not removing this impediment?
  7. Can the team resolve this impediment without the help of the SM?
  8. Can we use this impediment as a guiding example for the team?
  9. Is this impediment relevant to an internal conflict between team members?  
  10. Is it really an impediment…? 

What tactics can the SM use for removing impediments?

There are some basic tactics that the scrum master can use to handle impediments, let’s review some of the most commonly used tactics: 

Keep the Active approach

In most cases, the impediments raised during the daily scrum meetings as a key part of the meeting agenda; this is good enough in most cases, but sometimes it can be too late. An active approach of an SM can find these impediments even prior to the meeting. Remember that the scrum master is part of the team and therefore can see impediments that affect team performance without the need for the team to report it.

Ask the right questions

Not all the reported impediments indicate for a real problem; sometimes team members can raise an issue as an impediment without even trying to resolve it. Therefore, once the SM understands it, he should ask the team a set of questions that will allow them to understand what they can do to resolve this issue by their own and without waiting for him to do it for them.

Impediments as an advantage for improvement

For me, this is what differentiates great scrum master from the mediocre once; a great SM can take impediments and use them as an advantage for educating and promoting team knowledge.

Give the Tools instead of a quick solution

The scrum master should provide the team with the necessary tools to handle the same future impediments without the need to wait for him, once he succeeds; team members can resolve their own problems and reduce the bottlenecks through the sprint. 

Mitigate the Root Cause

This is similar to any other RCA process where the investigator should not resolve the symptoms but instead should drive to find the real root cause that led to this symptom. Remember that resolving a symptom without resolving the real Root Cause will most likely not prevent from the same impediment to rise again in future iterations. 

Increase transparency and continues improvement

There is a major benefit in showing what, where the impediment that affect team performance throughout the iteration, therefore the scrum master should document the number of impediments that were raised, how they affect the progress and what was done to remove them.

Prioritize first

I think that anyone that was part of a scrum team will agree that in most cases there are many impediments that arise per iteration and especially in new teams and large complex projects. Due to this reason, there is a major importance of the scrum master to prioritize the impediments prior to run and resolve them. My suggestion is to consult with the team regarding which items are more important and always compare it to the iteration goal (High priority is given for impediments that affect the team’s ability to meet it). 

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 present 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.

My Presentations