Agile Scrum Delivery Model

 

We leverage a fully extended agile scrum delivery model, complete with end-to-end QA integration and executive transparency reporting. The three ‘keys’ to successful implementation of agile scrum:

Sprint Planning / Planning Poker   – ensures unanimous agreement for the estimate of each story, greatly enhancing the probability of accuracy. Points are used instead of time to enhance the ability to ‘compare’ the relative difficulty of one story to another.

Wedge Team   – we provide all of the key, high-level roles that are not needed full time on the project but are essential to success. This team acts as a ‘startup’ team to ensure the project is foundationally sound – and the team continues on throughout the project, attending sprint planning and review sessions as they occur. This team includes: Architect, Engagement Manager, Scrummaster, and QA Manager.
Product Owner   – the single most important factor in the success of a project is the involvement of the Product Owner. This representative of the client is responsible for communicating and collaborating with the Swan team to ensure that the vision is implemented and the priorities are established.

Tech Lead/Architect divides Project into high level stories and estimates them.
Tech Lead/Architect is working on DB Architecture, API is starting to be developed.
Developing user story using TDD approach, doing Code review.
Team estimates points for each User Story, breaking larger stories into stories that can be covered in a day, Tech Lead divides tasks between team members.
QA working on Automated tests coverage.Dev Done/ Code Review - Unit and Automated tests are executed on CI server.
Tech Lead performs Code Review and merges to main branch on BitBucket.
QA Manager involved in filling in the Requirements Document.
QA Manager together with Architect define User Stories that will be covered with Unit Tests, QA prepares Acceptance Criteria for the Sprint 1.
Team estimates points for each User Story, breaking larger stories into stories that can be covered in a day, Tech Lead divides tasks between team members.
Developing user story using TDD approach, doing Code review.
QA tests each User Story separately and does regression testing by the end of the sprint, Unit and Automated tests are executed on CI server.
QA working on Automated tests coverage.Dev Done/ Code Review - Unit and Automated tests are executed on CI server.
Tech Lead performs Code Review and merges to main branch on BitBucket.
QA tests each User Story separately and does regression testing.
If task passed all QA - QA moves it here.
QA Manager involved in developing Wire Frames for the project.
QA Manager involved in filling in the Requirements Document.
Tech Lead/Architect divides Project into high level stories and estimates them.
Client signs Statement of Work which includes estimate of the project and price.
Client reviews design and defines what final changes should be made to it.
Team estimates points for each User Story, breaking larger stories into stories that can be covered in a day, Tech Lead divides tasks between team members.
After each sprint Client has 1 week for UAT using Acceptance Criteria document to determine any defects or changes needed
Readying user story using TDD approach, doing Code review.
Client approves each story once the story passes QA
Client has 2 weeks for final (end-to-end) UAT and approves final production product - project enters the production phase

 

 

DevOps

 

DevOps is about continuous collaboration between developers and operations throughout the entire process – Design | Development | Production.

DevOps eliminates  the silos between development and operations and extends Agile principles beyond the boundaries of “the code” to the entire delivered service.

Agile software development prescribes close collaboration of customers, product management, developers, and QA to fill in the gaps and rapidly iterate toward a better product…DevOps adds service delivery – how the app and systems interact are a fundamental part of the value proposition to the client.

Our Best Practices for DevOps:  We are using Agile principles, Design and Planning, Executive Transparency Reporting, End-to-End Fully Integrated QA (including Black and White Box testing), Cloud Services Setup, Production Support and many others. We are using the best DevOps tools to accomplish our goal to deliver and support a quality product, such as BitBucket for Source Control Management, Jenkins for Continuous Integration, and TestRail for Test Documentation management. These tools all help us to be flexible to requirements changing, deliver software frequently, select the most effective methods and techniques within development, deployment and supporting of a product.

What does it mean for our Customers:

Faster delivery of shippable features

Highly productive and stable operating environments

Improved service quality

Reduced deployment failures

Better defect detection

Eliminate bottlenecks due to a better designed architecture

 

 

Source Code Management

 

Version Control System.  We are using Version Control Systems such as GIT or SVN for managing our development process. This allows tracking of any code changes and makes code review easier with pull requests. A key ‘best practice’ is that each user story is developed in a separate branch.

Master – Production Server Branch

Only Tech Lead pushes into Master branch
Master should contain current Production code
Code should be pushed To Master only from Staging Branch after regression QAT on it and UAT Hot Fixes

Staging – Staging Server Branch

Only Tech Lead pushes into that branch
Master should contain current Staging Server code
Tech Lead should push to this branch from Sprint, UAT and Hot Fix Branches

Sprint # – Branch for each sprint (for Test Server)

Tech Lead reviews and merges pull requests from Team members
Demo is done from that branch during sprint review
Current sprint branch should contain code that is on Test Server
Each new Sprint branch should be created as a copy of Last Staging branch version

Story#/Bug – Branch for each story

Each team member creates a branch for his User Stories (as a copy of Current Sprint Branch)
Name of the Branch should start with User Story JIRA ID
If the Sprint branch was changed before dev finishes his User Story – it should be pulled to his Story Branch
After Story branch contains final code – Dev should create a Pull Request to Sprint Branch

UAT Hot Fixes

Create a separate UAT Hot Fix branch from Staging Branch
Once Hot Fix completed then merge it into Staging Branch and update Staging Server
Once merged and approved by client – merge Hot Fix Branch to Current sprint branch

best-practice-img.png

 

 

 

Quality Assurance

 

Quality Assurance. Our entire culture is built upon QA. Everyone in the company is part of our QA team, including our executive team. The QA process is tightly integrated throughout the entire engagement process, beginning with a test plan in the Design sprint and carrying through to delivery of the final product.

Test Plan.  The Architect and QA Manager collaborate during the design sprint to determine the Test Plan. This document determines Test processes which will be executed on a Project. It includes Guiding Principles, Quality and Test Objectives, Test Scope, Test Types needed, Test Environments. QA is assigned to the project and keeps this document up-to-date according to latest changes.

Acceptance Criteria. Creating user stories is a great first-step in a Feature Driven Development (FDD) process, but can still produce some ambiguity in the requirement. Our QA team will write the acceptance criteria for every story, using the industry standard “Given/When/Then” model. This process (combined with user stories and planning poker) contributes to creating requirements that have been thoroughly defined according to the client’s needs. This document is then passed on to the client to be used for User Acceptance Testing.

TDD. We use Test Driven Development as our Best Practice Development approach, meaning that our developers write Unit Tests before developing the actual code. Developers applying the TDD approach are likely to write less complex code, more smaller units (methods and classes), more tests and achieve higher test coverage than they would write with a non-TDD approach.

Black Box and White Box Testing. We define Black Box testing as testing from the user perspective, and White Box testing as testing from a code perspective. Our QA team performs Black Box Testing based on Acceptance Criteria along with negative testing techniques on all supported environments. White Box testing includes such activities like Code review, Automated testing, and Unit Testing.

Continuous Integration. A critical component to our process is the continuous integration server (CI server), which is running Automated and Unit Tests on a daily basis. This eliminates a large amount of issues during the development process and minimizes the time needed for troubleshooting problems.

Code Review. This is performed by highly experienced developers (team leads) to minimize amount of code duplicates or memory leaks, and to keep code clean and smooth as well as fix any issues in the code. All code must pass review before being tested by our Black Box QA personnel.

End-to-End Quality Integration Process

 

 

Executive Transparency Reporting

 

A ‘pure’ agile scrum environment says that decisions will be made on a sprint-by-sprint basis, and executives are asked to ‘trust us and the process.” To that, the typical executive response is “you want me to give you carte blanche control over the budget and timeline? No thanks!” Swan addresses this area by providing a ‘Custom Project Dashboard’ containing three components that, when combined, provides a snapshot of the status of the project and the expected timeline to finish. This dashboard ‘fully extends’ the agile scrum delivery model to include Executive Transparency Reporting. These three components are:

 

Burn Down Chart.   This chart can reflect the current sprint or indicate the status of the entire project-to-date.

project burn down | Swan Software Solutions

 

 

 

 

 

 

 

 

 

 

Resource Metrics Report.   This table indicates the velocity of each individual in the team as well as the team itself. The green/yellow/red dots indicate whether the velocity is as predicted, within 10% of expected, or outside the 10% range.

Best practices | Swan Software Solutions

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Progress Bar.   Shows the status of the project and the expected date of delivery.

Best practices | Swan Software Solutions

 

Portfolio Dashboard

Used when running multiple concurrent projects. Each project is summarized in a thumbnail version on the Portfolio Dashboard. User has the ability to ‘deep dive’ on each project by clicking on that project’s thumbnail and being directed to its Project Dashboard.

Placeholder | Swan Software Solutions