Agile Manifesto and Creating Quality Products

The driving concept behind the Agile Manifesto Principles is a paradigm of “Product Delivery” over “Product Delivery Process“.

This paradigm shift is a major change of philosophy for upper and middle management that have been “Frozen in the Waterfall” methodology.

A Code Development Processes is Required to
Create Continuous Quality Products

The TMD Code Review Process

The Modern Developer’s Sprint Code Development Process enables the Scrum Master to ensure that the product developed produces the highest value to the Client at the lowest Total Cost of Ownership (TCO). 

The highest level of quality is accomplished with a Three Stage Code Review Process. 

The first stage validates the high level Design Objectives defined by the Acceptance Criteria.

The second stage validates that the Development Team is using the TDD Process with Mocked or Stubbed Dependencies and are complying with Code Standards and Best Practice Design Principles.

The third stage partners the QA Testers with the Development Team to validate that the developed code meets the Acceptance Criteria based on the QA established QA Objective.

The Three Development Code Reviews:

The Internal Design Review – Validates the understanding if the requirements of the Sprint User Story after it has been decomposed into Sprint tasks.

This review looks at risks to legacy code and exposures to possible integration issues along with defining dependencies and database requirements that are known at the time.

The Delivery Review – Validates the initial Code Development in the Development Environment.

The code is validated within the Test Assembly as true Test Driven Development (TDD) code.

The tests are true Unit Tests that consume Mock and Stub dependencies.

The code have “Happy” and “Sad” path unit tests that validate all know error conditions and exception possibilities.

The code have moved through the RED, GREEN and YELLOW stages of TDD.

The Code complies will all Code Standards, Design Principles and Project Design Patterns as the YELLOW stage of TDD.

The Integration Review – Validates the developed Code development in the QA Environment.

The Unit Tests are copied and placed in a Code Region with the “IGNORE” attribute to prevent them from executing during Continuous Integration builds and Smoke Tests.

They are available for bug resolution and new feature / functionality requests but do not add redundant overhead to the Automated Testing process.

The original Unit Tests dependencies are replaced by System dependencies such as Databases, Data Services and Cloud Services.

The tests are striped of any “Asserts” that validate the creation and initialization of the Act result as to prevent validation of the Objects ability to be consumed as the Unit Tests already validated that.

The criteria for acceptance of the code base is the successful execution of the QA Objective.

This objective consists of the QA Teams Test Suite, Test Cases and Test Data just as they will be validating it when passed to QA within the Agile Sprint Work Flow.

This process guarantees that the number of senseless bugs are found by the Development Team before QA as to allow the QA Team to spend its time and the Client’s money on finding issues that neither team thought of during development and QA planning.

The Code Review Activities Check List

Development Code Review

The delivery review ensures that the initial development of the Sprint User Story’s Tasks have followed protocol.

This process will lower the cost of maintaining the code over its life cycle.

This includes true “Unit Tests” and code that meets the Code Standards and Design Principles. The use of accepted Design Patterns will be assessed as well.

A strict adherence to theses standards should not be implemented during the first few Sprints.

The initial Code Reviews will primarily act as a co-programming training session during the “Forming, Storming and Norming” phases.

When the teams attain the “Performing” stage of the Tuckman Model the Code Reviews will be more strict as to reduce the time and cost of Code Reviews.

The developer must have QA Objective available from the QA Team before the Integration Development phase. A clear understanding of how to run the QA Test Suite is essential.

A clear understanding of how to implement the QA Objective as the acceptance criteria for the User Stories must be understood by the Developers.

This will allow us to move to the Integration Development Stage and the Integration Review.

The Code Review Roles

There are Four Roles that Pertain to the Code Review Process:

1. The Code Review Manager – There is one Code Review Manager and this role is responsible for an efficient Code Review Process.

   This role assigns the Code Review Leads and Technologists for the Sprint reviews.

   These assignments should be a Client resources, if possible
   

2. The Code Review Lead – This role leads the review and guarantees that the success criteria defined in the items below are met.

   The Code Review Lead is the 3^rd level of code base understanding and is available for development work should the Primary and secondary development resources are not available for bug or feature / functionality change requests.

   This role should be a Client resource, if possible.
   

3. The Code Technologist – This role monitors all activities of the Code Review and ensures that a clear understanding of the code base is created in their mind.

   The Code Technologist is the 2nd level of code base understanding and is available for development work should the Primary development resource are not available for bug or feature / functionality change requests.

   This role should be a Client resource, if possible.
   

4. The Code Developer – This role has developed the code and brings the QA Objective requirements to the Code Review along with meeting the prerequisites stated below.

   The Code Developer is the 1st level of code base understanding and is the Primary development resource for bug or feature / functionality change requests.

    

The Delivery Review

Each Code Review requires the following items to be validated.

Most of them are self-explanatory.

This list should act as a “Check List” during the Code Review:

After the Sprint User Story Development status is moved from the Code Review status to the Code Integration status the developed code is migrated to the QA environment.

The QA environment for Integration Development and QA Objective validation will help to ensure that any infrastructure dependencies are consumed in a fashion similar to the Client-facing Environments.

Exercising the QA Objective in the same environment as the QA Team helps to minimize the “Bugs” that should be found by the Development Team and not left to the QA Team to identify.

This should deliver code to QA that exceeds the 95/5 percent paradigm of success.

This process leaves the QA Team with the time and resources to find issues that neither the Development or QA Teams had thought of during the Sprint Development Process.

The Integration Review

Each Integration Review will validate the replacement of Mock and Stub dependencies with real Infrastructure dependencies.

This list should act as a “Check List” during the Integration Review:

The successful completion of the Integration Review will set the SpecFlow Web display to GREEN.

This will be the state that is required to move the development tasks out of the IN PROGRESS Status to the IN QA Status.

When a bug is discovered the development task is returned to RED. When all bugs are resolved and the “Definition of Done” is met then both the Development and QA SpecFlow report will be set to GREEN.

This status signified that the Sprint User Story is a candidate for Stakeholder Demonstration.

In Conclusion

This post is a supporting follow-up to the Delivering Quality Code: Code Reviews post.

This augments that post with the detail implementation of the Code Review Process.

The information is designed as a “Check List” for initial understanding of the steps required for managing Development Code Quality during the Sprint.

It is designed as a starting point and should be modified, as required, for your environment.

Code Quality is the responsibility of the Scrum Master
and should be managed by the Sprint Team Lead
and internalized by all Agile Team members

Wisdom Pearl # 122 – Open Your Mind to Possibilities

There are Generally a Hundred Ways to Accomplish some Task

… But Only a Handful of Good Ways

…… Have an Open Mind to other Possibilities