The Agile Success Criteria

A successful implementation of your customized business process representation of the Agile Methodology has some minimum required success criteria.

Understanding these constraint will help ensure a successful implementation of Agile in your Business solution development culture.

If any of the below requirements are missing in your business solution initiative fulfillment process you are opening yourself up for less than desirable business results.

Here are the Modern Developer’s recommended minimum constraints:

1. Full Agile Methodology support from the highest levels of management

2. The Daily Scrum Stand-up meeting will follow a strict protocol and last a maximum of fifteen minutes

3. A commitment from all Agile groups to have at least one representative on the Daily Scrum Stand-up calls

4. Development and QA blocks are discussed in off-line meetings not during the Stand-up meetings

5. Only the Scrum Master, Developers and QA team members speak during the Daily Stand-ups

6. The Scrum Master directs all conversations

7. The Scrum Master defines the follow-up calls, and Role members, to resolve all new blocks as quickly as possible

8. Formal Design Statement of Work Documents (SOW) created by the Architect team is required for all assigned Development tasks.

9. Design SOWs are living specifications that must be updated throughout the Software Development Life Cycle

10. Test Driven Development (TDD) must be the development methodology to ensure testable code is created

11. A Continuous Integration Strategy for Deployment and “Smoke Tests” to all Enterprise Environments with the Automated Test Suites and Harness scripts

12. A diligent Design Review Board process for each Sprint design that includes representatives from Business, Architecture, Development, QA and Infrastructure must be created and implemented

13. A diligent Code Review process for TDD development and QA integration must be created and implemented

The Agile Methodology Players

The Modern Developers ideal Agile process consists of dedicated teams that have defined Roles and Responsibilities.

Each team assigns a representative for the team that ensures that the team is represented at the Daily Scum Stand-up meetings.

At least one team member is available for each Scrum call to help understand the current state of development.

The representative is then available to help resolve any Scrum Master managed blocks that have been identified during the Daily Stand-up meeting.

The Agile Sprints Teams:

The Minimum Required Teams:

The Business Team – These are the Stakeholders and Business Subject Matter Experts. They create the Business User Stories and Acceptance Criteria that defines the Business Domain requirements

The Architect Team – These are Architects and Designers that map the Business Domain to Technology Scenarios that represent the acceptance criteria of the Business Team for the Developers to deliver

The Development Team – These are the core solution developers. They design and deploy the concrete solutions that have been defined as abstractions by the Architect Team. This team manages the daily continuous Integration builds and “Smoke Tests” of the daily code base for migration to Development, QA, Staging and Production with the help of the Network Team

The QA Team – These are the team members responsible for the Test Cases and Test Harnesses for solution validated and functionality. They are members of the Design Review Board

The Network Infrastructure Team – These are the Infrastructure and hardware support team. These team members ensure that all environments are stable and functional correctly

The Key Points of the Agile Sprint Process

The below diagram details the Architecture, Development, QA and Deployment process for the Business delivery fulfillment model:

The Sprint Architecture and Design Specs

The Architect receives the Business Sprint Acceptance Criteria from the selected Backlog Business User Story and works with the Designer to create Development Acceptance scenarios that as estimated into Sprint capacity hours.

The Designer creates a formal SOW that acts as the design specifications throughout the Development and Maintenance life cycle.

The Sprint Development and Code Review

The Development Lead received the Design SOW after the Design Review.

The assigned Spring task developers accept their tasks for development and begins their TDD Unit Test development from the Design document as single unit of work test driven development.

All dependencies are created as Stubs or Mocks during this stage of development.

Development Integration and Code Review

During the initial code development all code is developed and tested to mocks.

This prevents Sprint Blocks due to missing or incomplete external dependencies.

During integration phase the developer decorates the Unit Tests as “Ignored“, for development efficiency.

The Unit Test is cloned, replacing the Stub or Mock dependency with the external dependency as the Integration Test validation of the external dependency.

A Final Thought

This process is a representation of the beliefs of the Modern Developer’s Agile Methodology.

As stated, each implementation of a successful Agile Methodology must be tailored and customized for the unique Business and culture requirements.

There are minimum requirements that will help ensure that the Business Team and the Business Domain has the best change for success.

Wisdom Pearl # 114 – Planning Ahead with Road Maps

Road Maps are Great

… But They Don’t Have Potholes Marked

…… Be Prepared for Changing Plans