Tag Archive for Scrum

Add toppings (Engineering Practices) to your Ice cream (Scrum) to make it even tastier

I start this post with a metaphor “Your Sprint is like your Ice cream bowl“. You generally put ice cream in the bowl, and also add some toppings on top of it, why? Just to make it tastes “awesome“. I am going to apply this metaphor to the Scrum Teams to make them “High Performance Teams” through adding engineering practices on top of your backlog items delivery in a sprint.

What happens in Scrum? Teams have limited capacity in the sprint. During the sprint planning meeting, they pull items from the product backlog based on the items’ priority, team’s capacity, try to convert them into potentially shippable product increment at the end of the sprint, by following the other Scrum events (Daily Scrum, Sprint Review and Sprint Retrospective). Of course they also perform product backlog refinement activity.

But is this enough? Do all teams able to deliver potentially shippable product increments always? In my opinion, not really. It’s just that you are like a plain ice cream in the bowl, that tastes normal. However, if you want to call yourself as a high performance team (just like toppings added ice cream taste), you have to inculcate some good engineering practices.

Why engineering practices? Engineering Practices make your “Developer and Tester” life easy and happy, trust me! Reason – It helps to keep your design simple, you can keep your code maintainable, anyone can make changes in anyone else’s code without any issues, not only that you can release frequently into production seamlessly.

Okay, where do I start and what practices I need to consider for my teams? My suggestion would be first taste the plain vanilla ice cream for a few sprints and get the taste of it. Then identify what engineering practices will help you to get to the next level. You don’t need to implement all of the practices. Just find what suit your team well and add value. Pick them up during the next sprints. Remember! whatever practices you pick up, don’t try to start all of them at once, you have to be iterative and incremental in this also, after all we are talking about Agile.

Here are some engineering practices that you can try with your teams.

1. Pair Programming:

Pair Programming is one of the wonderful practices that helps your team to write code with high quality. Reason being, one person writes the code (driver) and the other reviews then and there (navigator). This avoids any design, performance, defect related scenarios while the code is getting produced. So this helps to reach “POKA YOKE” (mistake proof) from the beginning. Not only that, your team gets familiar with entire code base if you keep encouraging the pair programming practice with moving people around. Doesn’t it cost me more? Of course yes, but the amount of testing time, code review time, bug fixing time you save is much higher than this cost. So you need to see trade off and make a decision.

2. Test Driven Development (TDD):

TDD helps the teams to create a safety net around their code. If you practice TDD in your teams, they get high level of confidence to make changes as and when there are code changes needed. TDD helps keeping the cost of changes low and also to handle the technical debt. How? The automated tests will help your code as a safety net and whenever you make any change in the code, if any of these tests fail that means your code changes causing the failure so you can immediately fix the code. But make a note, you will never start your code first, rather you write your first test, make it fail, then write code to fix the test, then refactor and then continue with next test. If you write your entire code first, then write corresponding tests, it is not useful and vice versa also not useful. Tests and code must go hand in hand. Also make another important note, when you find a bug at any point of time, add it as a test to the test cases. This helps arresting the repeated defects. Make sure to create your test suite in such a way that they satisfy: Isolated, Automated, Decisive, Repeatable etc principles.

3. Simple Design:

Agile principle #11 says “The best architectures, designs and requirements emerge from self-organized teams“. Yes, it is true, but it depends on how really self-organized you are! Make sure your design and architecture progressively elaborates and keep them simple but scalable using design patterns. Follow YAGNI, DRY etc principles. I suggest to keep your system design visible using lego blocks. This helps your team to come up with optimal solutions when they need to develop new features. During backlog refinement or discussing the design changes during sprint, team can stand around the lego block design table, discuss which layer gets affected for the new features and what should be the best approach to keep it simple. Keep your modules loosely coupled through API/Web service based communication. Challenge complexity and try to simple through architectural and design principles. Less is more!

4. Refactoring:

XP (Extreme Programming) recommends “Mercilessly Refactor”. So you need to encourage your teams to refactor your code often. How often? In fact it should be part of your TDD’s third step (RED, GREEN, REFACTOR).  What happens if I do not refactor? Simple, you may hit road blocks in future and your team’s velocity drastically goes down. You will be fire fighting rather than delivering new features. Who should refactor the code in my team? It’s everyone’s responsibility to refactor their code as and when they write. Any code your team creates, it should have automated tests and should be refactored. This will help to deliver high quality and easily maintainable code.

5. Coding Standards & Code Review:

This is the simplest practice your team can follow immediately. All you need is to agree as a team on what standards you want to follow and corresponding guidelines. Just make a habit of following those standards whenever you write code. At the same time get the code reviewed by someone in the team so that it helps to see if it has any issues, two more pair of eyes is always better. You can use tools such as SONAR for finding the code review, dead code, optimization related issues and this will also save considerable amount of time. Manual review helps to enhance the knowledge on the code to the whole team over a period of time.

6. Feature Toggles:

Feature Toggles (aka: Feature flippers, switches, bits, flags) help you with hiding the partially implemented features when you work in a continuous integration environment. If you are working on 2 weeks sprints cycles and one of your features takes more than 2 weeks to complete and you want to release only after the entire feature is complete, then you can hide the feature related stories using this toggles concept. How does it work? Very simple, it works through configuration files. You create a configuration file with a set of toggles for different features that are pending or you don’t want the end user to see them. Most of these toggles will be used in the user interface layer. While using this practices, you need to make sure to few things that include: Test your code with toggle on and off, maintain these toggles in configuration file and remove the unwanted toggles.

7. Continuous Integration:

Continuous Integration helps you to be able to reach Continuous Delivery and you can make more frequent release of your software. Encourage your teams to integrate their code into a single code base every day multiple times. Why should I care? It saves a lot of time in terms of addressing integration issues. Imaging, your team is developing code in their local laptops/desktops and their code works fine in their machines. When they integrate it after huge amount of code is developed, does it guarantee that all the combined code works fine? Not always. Hence integrating often will help you to get feedback on integration issues so you can save effort and ensure your code is really potentially shippable. Remember: Agile principle #1 says “Our highest priority is to satisfy the customers with early and continuous delivery of valuable software“. Watch the two key words in the above principle: EARLY and CONTINUOUS. Also, principle #7 says: “Working software is the primary measure of progress“. How much code works fine in my local laptop does not matter, how much integrated code (features) work fine in the integrated/production environment is key. So, if you want to achieve these principle and delight your customers, you need to adopt the continuous integration practice.

8. Small Releases:

 I read somewhere, if release is a pain, do it often. So do not be afraid with release of your software into production. In the beginning you may get issues but I am sure the above principles will help you to achieve daily multiple releases as easy as eating a butterscotch ice cream :) Automation of build process, automated sanity and functional test cases etc also will help you to release often painlessly.

So why late, go ahead and add the above toppings to your scrum teams and start enjoying the awesome taste and become high performance teams.

Thank you for your time to read this post…hope you enjoyed reading this. Please provide your feedback and comments on this post…Thank you.

Approach For Large Scale Agile Transformation

This article was published in Scrum Alliance website at:


I was part of a large-scale Agile transformation recently. It was a great learning experience, and I want to share my experience of the transformation.


This document covers the information related to a large-scale Agile transformation (hereafter referred as just transformation), based on my personal experience and knowledge. I am trying to collate my experiences and I created this article thinking that it can help as a guide for others.

Definition of a large-scale Agile transformation

Where there are multiple teams working on multiple services/products/projects from various different locations having different policies, culture, time zones, and technologies being used. Most of the time, more than one team shares the same backlog with the same sprint schedule, if those teams are working on the same product.

Groundwork for the transformation

Any organization that would like to shift to Agile has to assess the need of the transformation. The assessment should include the following points:

  • Are there any issues with the current software development approach?
  • Is the current time to market helping the organization achieve the revenue targets?
  • Are the customers of the organization happy with the products?
  • Are the products that are being delivered having expected quality?
  • Are there any gaps between the product management and software development teams?
  • Is there productivity loss due to considerable amount of rework on the delivered products?
  • Is the current feedback loop not working to catch up with market fluctuations?

If the majority of the points above prove to be negative, then it is time to move to Agile transformation. Agile can help solve most of these issues in a positive way due to its simplified frameworks, engineering practices, collaborative way of working among product teams and development teams, small and colocated teams, etc.

Decide on the transformation approach

There are two ways to transform the organization into Agile. They are: Phased and Big Bang implementations. Based on my experience, it will be effective to go with a Phased approach in which we identify the teams that have less pressure on delivery and introduce them to Agile by providing a dedicated two to three days of training. Then we would provide coaching to those teams for a few sprints and get them to a stable level. This process will have to continue till all the teams of the division/organization are transformed. This is an iterative and incremental approach.

Also, you must decide which Agile frameworks (Scrum, XP, DSDM, FDD, etc.) will be suitable for the organization. If there is maintenance work, then Lean and Kanban also can be considered.

The training program will have to include the contents below as well as some class activities/games to explain the concepts in an easy and straightforward way to the participants:

  • Why Agile
  • Agile introduction and fundamentals
  • Agile values and principles
  • Lean and Kanban introduction
  • Respective framework explanation in depth (e.g., Scrum/XP/DSDM, etc.)
  • Agile estimation
  • Agile communications
  • Engineering practices
  • Other related topics

Important: There should be training planned and conducted for the product teams, and this is critical. In Agile, the product owner is the person who is responsible for the product vision, ROI, and success. So if that person doesn’t have a proper understanding of Agile values and principles — concepts such as value-based prioritization, product backlog management, working with delivery teams with a sense of collaboration, release planning — that will impact the entire transformation.

The executive management team also has to undergo some coaching and briefing to set the right expectations about the transformation. This will further help seed the mind-set change within the management team.

Decide on the transformation road map

This can be done based on the number of teams to be transformed, their locations, how much coaching they need (how many sprints), etc. Budget also plays a key role in planning the road map. If you can afford it and the time line is your key constraint, then you can bring experienced external Agile coaches in to complete the transformation within a shorter time frame. Otherwise, you can develop a few internal Agile coaches and create the road map accordingly.

My recommendation is to have at least a few external coaches because they come with previous experience of other organizations’ transformations, challenges, and best practices.

Decide on structural changes and plan for them carefully

Structure plays a critical role in changing the culture. Agile is all about mind-set (culture), so the transformation team has to consider whether there are any structural changes that need to be done as part of the transformation. They need to be in sync with the senior management team in order to manage management expectations, company reputation, employee expectations, etc.

Do not just try to fit the organization’s existing roles into Agile roles. That might not work, and mismatches could impact the entire transformation process.

Decide how to measure transformation progress

This means inspecting and adapting for the transformation process and making necessary changes based on needs. This is also a critical step because if the progress is not as per expectation, organizational strategic objectives could be affecetd. I recommend having a core team within the transformation team (maybe a lead coach and a couple of other coaches) that works together closely to make sure everything is going as per plan, and to respond to changes effectively. This monitoring has to happen periodically after the transformation starts and continue until it is complete.

It is good to have a maturity model in place, against which to measure progress. You could create an Agile Maturity Score Card with a list of areas and corresponding weight for each area, or create different maturity levels and assess the teams against those levels. For example, below is one way to assess the maturity of Agile teams using a maturity level-based assessment.

Level 1 Maturity (SHU)

  • Understand the Agile values and principles from the point of view of value.
  • Conduct all Scrum ceremonies as per the guidelines.
  • Collaborate visibly within the team.
  • Have the product team and development team work toward a common goal (vision).

Level 2 Maturity (HA)

  • The team delivers working software at the end of the sprint.
  • The team follows proper estimation methods and is consistent in terms of understanding.
  • Velocity can be measured.
  • Basic engineering practices are introduced and practiced (pair programming, TDD).

Level 3 Maturity (RI)

  • Velocity is consistent and the team tries to improve its velocity.
  • Feature teams are formed.
  • Advanced engineering practices are implemented.
  • Continuous integration is in place.
  • Teams come up with innovative ideas to improve the delivery.

Please note, it naturally takes some time to move from one level to another. It depends on several factors. Moreover, the time needed to move from one level to another may not be same for all teams. The transformation team has to keep this point in mind and plan the necessary arrangements.

Check the impact at the organizational level for various policies

There will be definitely some changes required in terms of some organization-level policies — for example, the performance appraisal process. Based on the duration of the transformation, the transformation and senior management teams have to work with the HR team to come up with a suitable process for performance appraisals.

My recommendation is to create an appraisal process whereby there will be more importance given to team-based appraisals rather than to individual-based appraisals. However, it could be a combination of the two.

Decide on the required changes to tools

Your organization may be using some tools already as per the existing software development method. Those tools may not be suitable for Agile-based methods, however. So in this case the transformation core team has to identify the suitable tools and plan to present them to the teams. The selection of tools will be dependent on the organization’s size, the number of locations from which the organization operates, etc. If your organization is small, then a simple Excel workbook will be sufficient to manage an Agile project. If your organization is large and has multiple delivery locations, then you might want to try tools such as VersionOne, HP Agile Manager, JIRA Agile, etc.

You may need to plan on a separate training session just for these tools. This training can be provided once teams complete their basic Agile training and complete a few sprints.

Start the transformation

This is the step where the actual transformation gets kicked off. In this phase, the teams that are identified for the transformation will first undergo the two to three days of classroom training, in which coaches will cover the key topics using a slide deck, some classroom activities, and games.

After the training, these teams will be assisted by the coaches for at least four to five sprints. At this point, the teams will start implementing the Agile frameworks for their projects. The coach will closely work with the teams on all the Scrum ceremonies and help them understanding the framework from a value perspective rather than a practice perspective.

During the initial few sprints, I strongly recommend that the teams use a physical task board so that they will see how the stories and tasks are moving and how the team needs to collaborate. Once they are familiar with the framework, they can move to any tool, such as VersionOne.

Keeping visible information radiators is important for the Agile teams during transformation. One idea that can get high transparency of transformation activity is to have a “coaching Kanban board” at a central location in the organization. On this you can display the teams that are pending for training/coaching, teams that are in progress for coaching, teams that have completed coaching and started sprinting on their own. This board has to be managed by the coaching team and must be kept up to date. You can also try the WIP (Work in Process) limits, based on the coaches’ bandwidth available for the in-progress column.

Also, the coaches should practice a daily stand-up at their level in front of the coaching Kanban board, so that they practice what they preach. This will influence the teams in a positive direction to practice the Scrum ceremonies effectively.

Track the progress based on the progress plan

This should be a continuous activity that happens at periodic intervals. The transformation team has to gather required data from the teams and check against the maturity levels or the score card described above. Based on the result, required amendments have to be planned in order to achieve the expected goals for all the teams in the process of transformation.

There may be few challenges you observe during the transformation, and they are discussed in a separate section below.

Make changes as and when required

As part of the tracking of the transformation, you may find some gaps or identify some improvements. Those have to be plugged into their respective areas and you can see how it impacts the ongoing process. Based on this, you might need to extend the transformation time for some teams, or you might need to continue the dedicated coaching for a few more sprints to cover maturity gaps.

Expand the transformation

Once the first set of teams is done with the transformation and achieves the maturity level you expect, you will be able to get a grip on the time needed. This you can consider “transformation velocity.” This will help you come up with required adjustments to your transformation road map and proceed further.

Decide on scaled Agile implementation

Once you complete the transformation at one location, you need to look at choosing a scaling model. There are several scaling approaches already available, but as far as I know, SAFe and LeSS are the two approaches most often chosen by organizations for scaling. Both approaches have pros and cons, so you need to review them thoroughly and decide which approach will work best for your organization.

It’s important to remember that you may have to give a short training to your teams on the scaling model that you have chosen, involving normalized story points, joint Scrum ceremonies, etc., based on the approach that you go with. Hence the teams have to have a good understanding of these topics first.

Also, when you go for a scaled approach, it’s good to have common release schedules so it will be easy to manage the ceremonies and have a better forecast. If for any reason one team falls back, then they can have either a shorter sprint or an extended one in order to catch up with the common release schedule with the other teams.

Possible challenges and corresponding solutions

1. Management buy-in and patience

  • Budget and time required for transformation
  • Fear of loss of productivity during the transformation
  • Possible push for a big-bang approach
  • Expectance of quick maturity, so an expectation of improved delivery from the first sprint
  • Forcing a return to old ways when it takes longer than expected to see results

Solution: Management buy-in is key for any transformation, so setting realistic expectations up front is critical. The transformation core team has to provide coaching and briefing to the management team so that they will have an idea of the expected outcomes and plan accordingly to choose teams for the transformation.

2. Teams might feel the new approach is more pressure-filled.
Solution: Change takes time to become visible. Set expectations for the team early, and make them start with baby steps so that they can see results quickly. Also, initially teams are not cross-functional and they will be in forming and storming stages, so it is good to take a small amount of work so that pressure will be under control.

3. Scrum ceremonies turn into any other general meetings.
Solution: If the ceremonies are not strictly timeboxed, they will become normal meetings. Also, the specific agenda to be circulated for each ceremony, and ensure that people come on time for meetings. Coaches should play an important role initially so that teams understand the value of the meetings and follow the guidelines.

4. Initial sprints may not deliver any working software.
Solution: It is natural that the teams cannot have a proper rhythm initially. So let them choose small and easy stories first that deliver at least some business value, and let them try to deliver those stories. Slowly they can expand the delivery volume while they become cross-functional. The coach must encourage the team to become cross-functional and support them in achieving that.

5. Teams may not want to become cross-functional, as they may feel their primary skill will be impacted negatively.
Solution: This is related to mind-set. A developer does not want to become tester and vice versa. The coach can help them understand the importance of developing secondary skills based on their interests and capabilities, and slowly try to get them there. Let the team try to do pairing up so that slowly it will create interest in developing secondary skills.

6. Documentation may go for a toss with wrong understanding of Agile values and principles.
Solution: One thing that has to be emphasized during the trainings and coaching is that “Agile does not say documentation is waste.” However, it is fine not to follow any template or format to document. So encourage the teams to take pictures from whiteboard discussions and record the important meeting sessions for reference, and use some kind of shared information space such as MOSS, confluence, etc.

7. Quality may be impacted in the hurry of delivering stories.
Solution: Quality and speed do not go hand in hand unless there is good practice and close collaboration. So the product owner, ScrumMaster, and the teams have to work very closely to define the Definition of Ready, Definition of Done, acceptance criteria, informal reviews based on need, etc. These will help achieve the expected quality.

8. Product owners misuse the flexibility of “responding to change.”
Solution: First of all, every change has some cost involved, and some value too. The product owner and team should discuss and then act on changes. Sometimes changes that do not have any value may be requested by the product team, and the teams have a right to ask why that change is required. So product owners have to know the value-based prioritization.

9. Teams get into a compressed Waterfall way of working.
Solution: Some people say that within a sprint we should work in Waterfall. But this is not really true; the coach has to change this thinking and make the teams work inan iterative and incremental model. They need to take the top one or two stories from the sprint backlog and complete them end to end, then move on with the rest of the stories. This will ensure that the team will be able to deliver business value at the end of the sprint.

10. Attrition
Solution: When you make changes to the structure to get a change in culture, it might create some disappointment among employees. Especially for people who worked with an authority earlier, working in a servant-leader role is not now appealing. So it is sometimes not avoidable, but along with management impact analysis, it needs to be done and proper knowledge transfer has to be done by the people who want to move away.

Some best practices

  • Initiate a “community of practices” to share knowledge and best practices.
  • While creating the teams, try to have a team self-forming activity
  • Try a pod structure to change the organizational structure.
  • Keep big, visible information radiators and keep them up to date.
  • Expose impediments through a visible board and try to close them before they impact the sprint goal. Encourage that teams resolve the impediments at the team level, and coach the ScrumMaster to solve the beyond team-level impediments.
  • Define a small set of metrics and take the teams’ buy-in for those metrics. Below are some metrics you can try:
    • Sprint goal success rate: This metric helps Scrum teams realize how continuously they are delivering value to the customer. If this is low, that indicates there is some issue within the process that has to be fixed. Reasons could be taking too much into the sprint, requirements changing during sprints, team skill-set issues, collaboration problems, or other reasons.
    • Velocity: To see the rate at which teams are delivering stories (business value).
    • Sprint burn-down: To show what is remaining in the sprint, it can be effort hours, number of stories, story points, etc.
    • Release burn-up: Helps the product owner come up with a forecast for the remaining product backlog items.
    • Cycle time (if you are using Kanban): Helps you assess the cycle time and, by using continuous improvement tools, you can come up with a plan to improve that cycle time.
    • Escaped defects: This helps the teams see how quality is managed in their delivery. If it is increasing sprint by sprint, that means quality is getting decreased, so you need to plan to improve it.
    • Team happiness index: This is another powerful metric to see how well the teams are motivated. The team’s feelings will have a direct impact on their productivity. Measure this at the end of every sprint.
    • Customer satisfaction: This metric will help you see how happy your customers are with your delivery pace and process. You can measure it through a questionnaire run on a periodic basis.
  • Do not use metrics to compare teams. Also, don’t select metrics that are easy to capture but not useful.
  • A monthly newsletter will help communicate the progress of the transformation.
  • Periodic executive management updates to all employees will also boost the transformation.
  • Try to automate build, deployment, and testing as much as possible, with alerts enabled. This will eliminate a lot of waste and you can achieve mistake-proofing.

- See more at: https://www.scrumalliance.org/community/articles/2014/december/large-scale-agile-transformation-approach#sthash.ggk3KOkD.dpuf Read more

Understand Scrum in a simple metaphor (Medicinal Agility)

I and my colleague Madhavi were discussing in general about Agile and Scrum last week. During the discussion she has suggested that it will be nice if there is a simple explanation about Scrum framework using a common language that makes the concepts easy to anyone. During the discussion we had come up with below explanation.

This article is also published in scrum alliance website:

The Metaphor:

Assume that if some falls sick, he/she visits a doctor for clinical check-up and follow the doctor advice to get well soon. So considering this scenario, we tried to explain the Scrum concepts.

1. Find out which medicine suits your body? [Which framework should I use? Scrum or Kanban?)

Which flavour of Agile is suitable to your team should be analysed first. It is as simple as just like we have various flavours of same drug like paracetamol, Colpol, Crocin for curing fever and not every medicine suits you. So what do we do? We first try with one flavour and experiment with it for some time and if it suits your body, then we continue with it until you are completely recovered.  Else we would try a different flavour.

Exactly similar, is the case with Agile. We do some initial study, start using scrum or Kanban and see how it works for a sprint and then decide whether we want to continue with it or use a different method. Of course if you clearly know you cannot plan at least for one week then you better go with Kanban model, else Scrum.

2. Find out what dosage suits your body? [What is the Sprint Cycle]

Based on various factors like age, weight and intensity of fever, we decide on the dosage of the medicine to be used. Similarly based on factors like how long backlog can be fixed, how often requirements can change etc., the sprint cycle duration needs to be worked out.

If we haphazardly vary the dosage i.e. if we take one dose of medicine today and two doses next day and skip the does in between, the ailment that we are trying to cure becomes worse and the situation goes out of control and our body may develop resistance to that medicine. Similarly, if we try to vary the sprint cycle haphazardly from 1 week, to 2 weeks and back to 2 weeks etc. frequently without having any rhythm, it would be very difficult to see the results and the project would become unpredictable and may end up in a chaos.

You may experiment for a couple of models and fix to one model.

 3. Planning and Execution as per the dosage: (Sprint Planning/Daily Scrum)

After the flavour and dosage of the medicine is decided, doctor (Product Owner) advices the exact medicine names that need to be taken and in what order as per the priority i.e. may be a multi vitamin tablet first followed by an antibiotic etc. We go ahead and take the medicines that is consume them in however way we want, i.e. some take them with water, some may make it a powder and dissolve and drink, sometimes you mix it in food and give to kids. So if you observe the scenario here, the WHAT part is being decided by the doctor and the HOW part is decided by the person taking the tablet. Similarly, in the sprint, WHAT to achieve is decided by the Product Owner and HOW part is decided by the team.

4. Re-check and Feedback on how did the medicine work (Review & Retrospective):

After the completion of the medicine course for the given period, we go to the doctor for re-check up to evaluate how the medicine worked and if the tablets or dosage needs to be changed for the next cycle if needed.

In a similar fashion at the end of the sprint you will give a demo to the Product Owner and the team will conduct a retrospective to inspect and adapt.

5. Daily alarm for the consumption of medicine (Daily Scrum Meeting):

In order to have effectiveness, you take medicine at same time and same dosage every day. For this, you may have some mechanism like mobile alarm to remind you. You might check the progress in your health day by day.

Similarly, in Scrum you will have daily scrum meeting for timeboxed duration (up to 15 minutes) and share everyone’s update and the by-product of this meeting is the status of the work progress.

Conclusion: The scrum framework is very simple common sense which we really practice day in and day out in some or the other way, so maybe we just need to make a good quick short experiment to figure out what suits our nature of the project and execute it the right way and it would really work wonders. However, do remember that it is really hard to master in Scrum unless you have thorough understanding on Scrum Values and follow the framework with a high level of discipline and passion.