The Implementation Process

Summary

Test First: Automate Unit Tests

Unit tests are a direct validation of the acceptance tests defined by the client. Before delving into the depths of the implementation, the developer should code the unit tests which will prove the story is complete. Creating the tests first will also raise semantic issues, and allow them to be clarified before any potential waste occurs.

Coding

Make it happen. Developers should write the code necessary to implement the story. No effort should be wasted on anything outside the top priority story for which they have committed to deliver. The developer does not choose which order to perform the coding, the story has already been prioritized by the client and it is their duty to deliver business value in the order specified.

Peer Review

Code quality is extremely important to maintaining the software for the long term. Peer review is explicitly called out here, but in reality should be an everyday, informal occurrence, just like the approach to design. A little bit, every day keeps developers on track and reduces waste.

Continuous Integration

An automated build system should create any deliverable, and the developers will use the same tool every day, several times a day to ensure their code works with the other developer's code. Break it early, break it often. This philosophy reduces the risk of the big code merge, and instead allows us to perform it incrementally. See Appendix C: Incrementalism

Release Planning

In each release, the client controls the scope, deciding what to do and what to defer in order to provide the best possible release date. Work fits into the calendar based on the business value of the stories prioritized earlier), time estimates, and implementation velocity. Small and frequent releases provide early benefit to the client while providing feedback as early as possible to the developers.

Each release begins with the essential release planning meeting. The engagement manager, architect, developers, and client business team members should all be in attendance. The main focus should be on exploring the stories chosen by the client team to be included in the release. Determine the semantics of the application and be sure that everyone has a common understanding. This is a good time for the client to make any necessary functional modifications or clarifications. While changes can certainly be made at any time, it is more efficient to make the changes now, and the development team can more predictably deliver the desired functionality on time.

Developers may explore some of the technical details, but be sure to keep the conversations limited to the overall design. If there is a specific technical detail that could risk the time estimates, it should be raised at this point. Without laboring in the technical minutia, developers should be sure the client understands risks to the timeline that a piece of functionality may impose.

Prerequisites:

• Request was defined.
• Stories were created.
• Acceptance tests specified.
• Rough estimates applied to stories.
• Stories were prioritized.

Meeting Goals:

• Define the release end date (i.e. 1 month).
• Select stories until cumulative estimates fill the available ideal time (ideal time + fluff time meets the release date). This time should be validated by extrapolating past implementation velocity into ideal + fluff time. Percentages should be roughly equivalent.
• Explore functionality with the group, ensure a common understanding.
• Add/Subtract a small amount of stories to fine-tune functionality so that the release delivers a usable piece of software. The release due date is recommended to be a fixed date. Sliding the release date to account for unforeseen scope creep or implementation difficulties is strongly discouraged. Deliver the release, and cutout the unfinished stories.

Iteration Planning

Inside each release, several iterations are planned. While rough estimates were created before release planning, we can assume that the accuracy of those estimates will change. With each successive iteration, the team gains more concrete knowledge of the implementation details. The development team will review the stories planned for the iteration, discuss detailed plans and objectives, and validate estimates. The Metova engagement manager will communicate the progress of the previous iteration with the client, as well as time estimate changes (resulting in the deferral or addition of stories) for the current iteration. Developers will choose and commit to the stories they wish to work on, and the engagement manager will ensure proper resource coverage to complete all defined work.

NOTE: Iteration timelines are not variable. Only the stories that can be implemented within the iteration time frame should be committed to by the development team.

The Iteration Planning Meeting

Each iteration begins with the iteration planning meeting. The engagement manager, architect and developers are in attendance. The main focus should be reviewing the design to implement the functionality, creating detailed development tasks, and estimating at the granular level. Developers are encouraged to explore the technical details as they will be committing to the delivery of their chosen tasks. Applying the agile methodology, design should be discussed, but not labored upon. Design is an everyday task, not something that is done all at once.

Prerequisites:

• Stories have been chosen to be included in this release.

Meeting Goals:

• Discuss the design details for the stories to be implemented.
• Create acceptance tests for each story if they do not currently exist.
• 50/50 Estimate acceptance tests (granular). Reset the Story estimate to 0 and move the original to a new field.
• Ensure detailed 50/50 acceptance tests estimates are inline with original rough story estimates.
• Continue creating detailed estimates until cumulative ideal time + fluff time meets the iteration due date. This time should be validated by extrapolating past implementation velocity into ideal + fluff time. Percentages should be roughly equivalent.
• Raise any deviation from the original estimates to the project manager.

Change Requests

Using an iterative approach with frequent deliveries, customers often gain new insight and want to make alterations to functionality originally specified and agreed on by both parties. By providing a framework for customers to change the scope of their project, Metova can respond quickly to the changing scope and deliver a product that is more accurate to what our customers desire.

When an alteration or addition to the scope of work is required, Metova follows a change request process. The goals of this process are to:

• Provide flexibility
• Control project scope, time and cost
• Improve communication
• Maintain accountability

Change Request Process Steps

1. The customer identifies a needed change by creating an issue as a Change Request issue type within Jira
2. The customer assigns the Change Request to their Metova product manager
3. Request Scoping will be performed by Metova
4. The Change Request will then be reassigned back to the customer for approval of the tasks and their estimates
5. The customer will resolve the Change Request with a resolution type of Approved or NOT Approved.
6. If Approved, the issues may now be scheduled in an iteration