Scrum Best Practices Tutorial

6.1 Scrum Best Practices

Welcome to lesson-6 of Simplilearn’s Agile-Scrum training program. Till now, we have covered pretty much everything that is mentioned in the original Scrum guide as Scrum practices. In this lesson, we shall extend the basic theory to some common best practices that are helpful in making Scrum projects successful. Some of these practices are drawn from other Agile methodologies like extreme programming. And some others based on common sense and might be useful irrespective of which methodology you choose to use.
We will look into the agenda in the next slide.

6.2 Agenda

Let us now look at the detailed agenda for this lesson. We start off by looking at the practice of continuous re-factoring, which is one of the XP practices. Then we talk about pair programming and continuous integration, which are also XP practices, but useful regardless of which methodology you use. In this context, we shall also touch upon the importance of configuration management. Then we look at Agile testing and some practices around testing that will help make Scrum successful. This leads into the topic of test-driven-development, which is a worthy goal to have from a testing and quality perspective.
We round up by explaining “done criteria”, which is a simple checklist, but very powerful in enforcing some basic rules within the Scrum team.
Now, we will proceed to the next slide to start with the Refactoring.

6.3 Refactoring

Refactoring is basically a “code clean-up” activity. It changes code without changing the core logic or the interfaces (inputs or outputs). The purpose of such activity could be any of the following.
-Improve readability of the code
-Optimize the processing logic
-Improve maintainability (for example by modularizing)
-Improving performance
-Complying with the design best practices
Re-factoring is a good practice regardless of Agile/Scrum or not. It is especially important in Agile though, because the code gets built incrementally over a period of time and we need to make sure that this does not end up compromising quality. It also helps to ensure that we are always building on top of a firm foundation.
The team should write the stories that point to the need for re-factoring and request the product owner to prioritize them based on the urgency. Re-factoring relates to the Agile principle “Continuous attention to technical excellence and good design enhances agility”.
Next, we will talk about Pair programming.

6.4 Pair programming

Pair programming refers to a practice where two people share a terminal while working on a task. One person is the active programmer (driver) and other is an active reviewer (navigator). While the programmer is coding, the other participant thinks about strategies, looks for potential problems or better implementations.
At face value, it might seem wasteful to have two people working on an assignment instead of one. Research suggests that it results in 15% lesser throughput. But this is more than compensated by the fact that it leads to better quality and better up-front design. It also helps ensure succession planning (by ensuring that each line of code has been seen by more than one person) and it provides a great way to train the newcomers in the team.
It is especially useful while someone working on complex technical problems and debugging hard-to-solve” problems.
Let us learn about Continuous integration in the next slide.

6.5 Continuous integration

Continuous integration is one of the twelve extreme programming practices. The basic idea behind continuous integration is to keep everybody’s code integrated at all times and builds release infrastructure along with the rest of the application. It is a good practice regardless of methodology, but especially valuable in an Agile methodology like Scrum, because as the code is getting developed, we need quick feedback whether the new development impacts any other area of the application.
To ensure this, it is important to ensure frequent integration with other modules and check the sanity of the system at all times. Quick feedback helps the team address any issues that may arise faster.
In the next slide we will discuss on Practices of continuous integration.

6.6 Practices of continuous integration

Some of the best practices that enable you to move towards continuous integration are as follows.
-Maintaining a single source code repository
-Automating the build process (including compilation, linking, packaging, creating an installer)
-Make the build self-testing (report failures)
-Everybody commits their code to the main branch every day
-Every commit should build the mainline on an integration machine
- Make the build very fast
-Test the build in a sand-box (clone of the production environment)
-Make it easy for everybody to get the latest installer with all the latest changes included in it
-Everybody can see what is happening (even if the build fails or the tests fail)
-Automate the deployment
-Now, we will understand about Configuration management in the next slide.

6.7 Configuration management

Configuration management ensures that all the artifacts of the project that need to be controlled are under active management. This means they are kept in a safe environment that is backed up regularly, that changes to those artifacts (configurable items) are maintained and recorded, having the ability to recover a previous version of those artifacts, etc.
Good configuration management is the foundation for successful projects regardless of methodology. It is particularly important in Agile, wherein the code is in a state of flux and the testers are working in close collaboration with the developers to work on inter-mediate builds.
Some of the best practices around good configuration management on Scrum projects are as follows.
-It helps to invest in good tools that automate the build and release processes and also the tests
-Enforce discipline around code check-ins (e.g. everybody checks in every day, all checked in code must have been reviewed and unit tested and must integrate successfully with other components, developer checking in a change must submit unit test and code coverage reports, etc.)
-Use static code analyzer tools that help identify potential issues up-front and prevent them at source
-Use tools that allow multiple people to work on a file and help to merge the code safely
In general, it would be very useful to have a trained and skillful configuration, build and release manager for your team. Such a person can help automate the processes around these and then gradually recede into the background (i.e. the processes happen pretty much on auto-pilot).
Let us now proceed to the next slide and focus on quality in agile.

6.8 Quality in Agile

Quality may be defined as conformance to specifications and fitness for use. Quality has the following facets.
-The extrinsic quality is the quality as perceived by the customer and is measured by the customer realizing the expected value from the delivered feature
-Intrinsic quality (sometimes called technical quality) is the quality as perceived by the team
-Technical quality includes many aspects like maintainability, supportability, reliability, scalability, usability, etc.
-Extrinsic quality is certainly non-negotiable (customer will not accept something that does not deliver the intended value). However, intrinsic quality is also important to ensure that the team can continue to deliver value.
We will now discuss on Scrum quality – home truths in the next slide.

6.9 Scrum Quality Home truths

Here are some best practices with regard to quality on Scrum projects.
-The goal of achieving near releasable quality in Scrum is difficult – but it is a worthy and important goal.
-On Scrum projects there is just one team and every member of the team has one goal. To deliver the working software with near releasable quality at the end of the Sprint. Having separate Development and QA teams with their traditional adversarial relationship is going to be counter-productive. Quality is everybody’s responsibility.
-Quality has to be built into the development process. It is difficult – well nigh impossible to test or inspect quality into the product.
-It is very difficult to achieve quality objectives unless you have a very good set of automated tests that can be run very quickly and at low cost. Therefore (unless you already have it in place), be prepared to make a heavy investment in test automation.
-Because we are always working in a very short time-box, it is important to start testing early and then test continuously. If you leave all the testing till the end of the Sprint, it is difficult to complete it before the end of the Sprint.
-Both verification (making sure the features are built correctly) and validation (the right features are getting build) are important and must be part of the quality processes.
-In the next slide we will look into a figure illustrating the planning for a sprint.

6.10 Planning for a Sprint

This picture illustrates the fact that design, code and test have to be planned to run almost concurrently throughout the Sprint. You cannot plan to go on coding till the bitter end, and at the same time you cannot plan not to start testing until all development and design is complete.
Let us now talk about Test-driven development in the next slide.

6.11 Test driven development

Test-driven development is a good goal to have for any software development team and especially important for Scrum teams. It is also sometimes referred to as test first programming .These practices are common in Extreme programming, which believes that “If testing is good, test ALL THE TIME”. TDD is TFD combined by continuous refactoring.
It is an evolutionary approach to software development, wherein the developers must first identify and specify the tests that must be passed by the system before they start writing the code. Further, these tests must not be simply specifications written in a document, they must ideally be executable tests (in automated mode). So not a single line of code gets written until there is an automated test that is programmed. This works as follows.
The tester may initially write a basic set of acceptance tests based on the bare elements of the functionality. The developer then writes the code to pass these tests. The testers then think of some additional or exception scenarios that must also be satisfied. The developers then proceed to write code to pass those tests as well, and at the same time re-factor their code so that it remains efficient.
This cycle may repeat many times, as many times as necessary until the testers can no longer visualize tests that may fail the code.
Next, we will understand the Test-driven development.

6.12 Test driven development

This flowchart indicates how TDD works.
1. The tester first quickly adds a basic test, just enough to cause the tests to fail.
2. The test suite (or a subset of it) is executed to verify that the tests are indeed failing.
3. The code is then updated to make the tests pass.
4. The tests are run again. Hopefully this time they will pass.
5. If the tests still fail, then repeat steps 3 and 4.
6. If the tests pass, then the testers think of some more tests that might fail and the cycle (1 through 6) repeats until the testers can no longer think of any tests to write that might fail. Meanwhile, the developers must continue to re-factor the code to keep it efficient.
Let us now go through the Advantages of TDD.

6.13 Advantages of TDD

TDD enforces the principle of Just-In-Time design at the time of development before writing the code, rather than indulge in a lot of design up-front.
It ensures that the team always has automated tests to execute against the code (actually even before it is written), so that the testing is easy and fast.
It gives the developers confidence to re-factor the code. This confidence arises from the fact that if they do make a mistake in the process of re-factoring, there is always an automated test to catch the mistake and provide instant feedback. Getting instant feedback means that developers can fix the issues quicker.
Research shows that TDD will substantially reduce the number of errors in the code; because the process of building the code itself guarantees that the tests pass (rather than fail).
The same process can be extended to test and document external interfaces unambiguously and clearly. This will guard against mistakes that may inadvertently creep into the system.
In the next slide we will understand the definition of Done.

6.14 Definition of Done

It is useful to make it known to the entire team what constitutes the understanding of “done”. These guidelines would typically come from the Scrum Master, who is the scrum guru of the team.
For example, a story can be considered as done, only when –
-Design is completed and reviewed by the technical architect
-Coding is complete and 100% of the paths mentioned in the story are implemented
-Testing (unit and system) are completed with good code coverage
-Regression testing is done to ensure that other areas are not impacted
-All the bugs identified are fixed
-Technical and user document is updated as necessary
By no means is this a complete list nor is it meant to be a prescription. The Scrum master comes up with this in consultation with the team so that everybody is clear what they need to do within the time-box of a Sprint. Similar done criteria can be evolved for Sprints and releases.
Let us take some quizzes now.

6.15 Quiz

Let us quickly test our understanding of this lesson through this quiz.
Which of the following is the BEST description of pair programming?
A-A tester and developer working together on a story
B-Product owner and developer discussing a story
C-Two programmers working on the same terminal
D-Programmers implementing happy path and exceptions at the same time
Answer is C: Pair programming involves two programmers working at the same time on the same task on the same terminal.
A team finds that it is taking too long to run the automated build, hence it is difficult to implement continuous integration. What is the best way forward?
A-Find ways for the build to run faster
B-See if the build can be run at least on a fortnightly basis
C-Work on unofficial builds and patches to unblock testing
D-Break the application into smaller parts and test independently
Answer is A: Rather than work around the problem, it is important to fix the core problem, which is the slowness of the build. All other solutions are unsatisfactory.
Test driven development means all of the following EXCEPT:
A-Tester writes the test specifications as the developer is working on the code
B-Tester and developer first jointly interpret the requirements and agree upon the tests
C-Not a single line of code is written until there is an automated test available to test it
D-Re-factor the code after all the tests pass
Answer is A: TDD does not mean tester merely writing the test specifications. They actually have to write the tests in executable form before the code gets written.
If new features are being added in a 3 week Sprint, when should the testing for the features be done?
A-In the subsequent sprint
B-As soon as the developer completes the feature or part of the feature
C-During the last week of the sprint
D-When all features are code completed and a formal build is handed over to the QA team
Answer is B: Test early and test often is the principle to be followed.
We thus end this lesson on Scrum Best practices. We hope that this has been a pleasant experience for you. Let us move on to the next lesson. The next part covers seventh lesson of this course which is about Scrum Planning.
Happy learning!