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.
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
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.
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.
Progress Bar. Shows the status of the project and the expected date of delivery.
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.
