Engineering practices in Agile

There are five practices used in Agile methodology.

TDD
Test Drive Development in which developer writes unit test first and then executes each test and then starts coding against the failed test. Various tools are available for TDD like for .net, nUnit is used.

Traditionally, developer writes code and after completing a feature rush to another task in the plan after doing minimal testing. TDD emphasizes to run test and then develop code that leaves very minimal chance to skip any case that is required for the task but not developed.

Refactoring
It refers to changing the structure but not the behavior of the code.
Every time developer completes a requirement, he/she should refactor it before checking in back to repository.

• Start a refactoring backlog of all the things you want to clean up. 
• Learn the refactoring that can be performed automatically by your integrated development environment
• Set aside a time in Retrospective session to discuss refactoring with your team mates

Collective Ownership

Collective ownership encourages each team member to feel responsible for all parts of the program so that any programmer can work on any module of the program. When modifying a module, the programmer then shares responsibility for its quality with the module’s initial writer. 

If you and I are building a throwaway system over the next two weeks, it will indeed most likely be faster for each of us to own one part of the application. If, however, we are part of a much larger effort and are going to have to maintain the system for the long term, the learning, cross-training, and other benefits of collective ownership weigh heavily in its favor.

Actions to implement this in your team:

• Ensure that no developer becomes so specialized he can contribute only in one area. 
• Make certain that no area becomes so intricate that it is understood and worked upon by only one developer. 
• Pretend that the owner of any critical area is away on vacation and nearly impossible to reach. For a couple of sprints, make the deliberate decision that the “obvious person” is never allowed to take on tasks related to that area of expertise. If the area expert is needed, that expert is available by phone only—literally call the person who is sitting two cubicles away. 
• The next time you work in code that is difficult to work with, fix it—even if it was written by someone else. If you feel that this is overstepping your authority, ask the original programmer to work with you in making the code easier to use.

Continuous Integration

 Continuous integration refers to integrating new or changed code into an application as soon as possible and then testing the application to make sure that nothing has been broken. Rather than checking in code perhaps every few days or even every few weeks, each programmer on a Scrum team running continuous integration is expected to check in code a few times each day—and to run a suite of regression tests over the entire application. 

Continuous integration is usually achieved with the help of a tool or script that notices when code has been checked into the version control system. 

Some teams opt for a manual approach, in which developers initiate the build and test for each check-in. I strongly recommend against this. Although it is possible to be successful with a manual approach to continuous integration, my experience is that developers will occasionally skip the build and test. It is just too tempting to occasionally think, “I changed only two lines and it worked on my machine.” It’s also tempting to forgo the build and test when checking in code after your planned quitting time for the day

The regression test can be split into two: a smoke test and a full test. The first runs after every check-in and includes all test scripts from the current delivery milestone [sprint] and a subset of scripts from past milestones. The second runs once an hour and included all test scripts from all milestones. The first proved to be complete enough the majority of the time. Only on rare occasions did the second one fail.

Pair Programming
If occasional code inspections are good, constant code inspections are better.
Pair programming is the practice of having two developers work together to write code.

Although most studies show a slight increase in the total number of person-hours used when pairing, this is offset by a decrease in the total duration of the effort.

Pair programming facilitates knowledge transfer and is an ideal way to bring new developers up to speed on the application. It is also an effective practice for working in uncharted territory or solving difficult problems in known parts of the system.

Design : Intentional yet Emergent
A big part of an organization’s becoming agile is finding the appropriate balance between anticipation and adaptation.
Objection:
"Rework will be inevitable"
 Without a big up-front design, the team will certainly hit a point where it needs to undo some part of the design. This two-steps-forward-one-step-back aspect of iterative development can be unsettling to professionals trained to identify all needs and make all design decisions up front. Fortunately, refactoring and the automated tests created during test-driven development can keep most rework efforts from becoming very large. 

In the past, it was entirely possible that doing a large, up-front design would save time and money. After all, Barry Boehm demonstrated in Software Engineering Economics (1981) that defects are more expensive to fix the later in the development process they are discovered. But the technical practices employed by good Scrum teams can dramatically alter the equation. When a team uses good technical practices—test-driven development, a heavy reliance on automated unit tests, refactoring, and pair programming among them—it may find itself in the situation where it is cheaper to adapt to user needs by reworking the application more often than it is to anticipate those needs and rework only occasionally.

In traditional development there is a large cost on upfront analysis and design. This investment keeps down the number of later changes. But when a change is needed, it is relatively expensive to make because the change violates the primary assumption that change will be largely unnecessary.

By contrast, the Scrum view shows many more changes, but the size of each bit of rework is smaller. This is the result of anticipating that change will be needed, but not knowing exactly where. Because of that, a Scrum team pursues technical excellence, always keeping the code well factored, with as simple a design as possible, and with a suite of automated tests for early detection of regression problems. So, while there are more occasions for rework, each is less of a setback.

Things to do:

• Facilitate a discussion between the team and product owner on how much influence technical factors should have on how the product owner prioritizes the product backlog. 
• Before the start of the next sprint planning meeting, identify the top five technical uncertainties on the project and the risk associated with each. See if there are product backlog items that could be moved slightly up in priority that could create the learning necessary to eliminate these uncertainties

Conclusion:

Agile programming is design for change….Its objective is to design programs that are receptive to, indeed expect, change. Ideally, agile programming lets changes be applied in a simple, localized way to avoid or substantially reduce major refactoring, retesting, and system builds. 

Importance of Project Plan

As a new project is started, it is vital to make a plan. The plan should contain milestones, activities under each milestone with specified dates and the resources assigned. This may be simulated through MS Project.
Down the road, all changes in the project must be reflected in the project schedule and the schedule should be adjusted to incorporate the impact of change on time. This helps at later stages of the project when delay occurs and the sponsor is asked to increase the timelines of the project. Then their primary question arises as when the project will be completed. At this stage both client and the vendor present their plans to complete the project. The vendor has interest to complete it as soon as possible. The client does not show tendency to complete quickly rather take substantial amount of time specially in User Acceptance Testing. The conflicts prevails and at this time the original plan comes into action in which the timelines for UAT and deployment were mentioned with the mutual consent of both parties. So rather to derive a new plan, the original plan can be adjusted to accommodate the change keeping all the later activities remain intact.
In fact, original plan should not be changed rather adjusted to incorporate the change. But generally what happens that the original plan is changed during the execution or a new plan is developed. Then timelines are squeezed to satisfy the sponsor concern to complete the project compromising the or ignoring all the complexities and necessities in UAT and deployment of a software project.

Lesson 1: Original Plan should be well thought and cover all activities to complete the project.
Lesson 2: This plan must remain intact and the changes should be incorporated in the plan to derive the new timeline rather to develop a new plan in the middle of the project.