Case Study: Using Agile

This post describes how we helped one of our clients move from a traditional waterfall development process to agile.

Agile was first introduced  into the formal SDLC process in 2010. Starting with the use of Microsoft’s Team Foundation Server, TFS, all of the projects implemented used a hybrid model where the key concept of iterative development was enforced. Iterations were time-boxed in and then reviewed during the retrospective. The end of the iteration required that the application be deployed on its own (through a separate divison) in their own environments. This ensured all aspects of the application were working. This is the traditional “shipping is a feature” mindset.
Originally a three week iteration was used. As discussed above under approaches, while the product was released to the client in quarterly releases, the iteration approach also allowed the focus to be broken down further. Iteration 1 in the quarterly release was used for mockups of new features and bug fixes identified in the previous release cycle. The second iteration was for development of new features. The final iteration refined the features further.

Each iteration was also broken down. Week 1 was for backlog , week 2 for development and three for testing. Different lengths were also tested including two weeks ( not enough time for client input) and four weeks. This was possible because at the end of each iteration, we reviewed not just accomplishments, but also our existing processes, identifying areas where tweaks might be of value. This was also the time for team members to suggest “let’s try” type items. There were some iterations where no changes were made; other times, we played with concepts to see if they would make our process more efficient. Examples include hack days (where one day a week/iteration is wide open for proof of concepts), and strict stand-ups (no longer than 15 minutes). One key thing that didn’t change was a weekly meeting with the client. Earlier on, managers tried to limit these meetings to once a month, much like a traditional project management process. This was quickly identified as problematic since requirements DO change, even when everyone says they do not, as a product takes better shape.

We currently use a four week iteration to allow for more development time and a dedicated week for testing. Client meetings occur each week focusing on either backlog or demos so a release can be made either in QA or Prod environments monthly. We also focused separated out roles in the development team to work with deployment , scrum master,  and operations and testing. Roles were alternated each week. This allowed each team member to take on a different role.  Daily stand ups were combined with any necessary “parking lot” discussions.

In terms of traditional agile mechanisms, story points were tried as part of core user stories. But the focus was on estimated time and work types . A bug or user story had individual tasks but each task was capped in time so that it could be completed in 1-2 Days. Capping each task allows the developer to accomplish small victories which is critical when new members of the team were introduced. While more complex tasks may go over the two day period, any task taking longer forced a review by the entire team.

At the end of each iteration, the process was reviewed and tweaked. Tasks and work estimates were reviewed based on assigned tasks and how much was accomplished. After several iterations, a pattern emerged of how many user stories we could realistically complete during an iteration. Logs of each retrospective were stored online. When new team members were introduced, they were given tasks to prepare them during the first two weeks and then actual tasks. Receiving feedback during the retrospective, training videos and quizzes  were devised to assist in the learning curve. In more recent iterations, new staff moved into their roles faster and given tasks right after the first week although they were still expected to review the training videos and quizzes.  Clients were also involved in a larger retrospective after each full release to the client. This allowed them to see how the retrospective improved the overall process.

A more key piece of the agile experience was the use of continuos integration. Through the use of TFS and Azure DevOps, every commit was immediately rebuilt to correct compilation. Regular builds were also done nightly and one build was set to automatically deploy to the dev build environment so testing could be done  outside of the regular development environment.

One of the team members built an installer and the entire application was able to be built , reversions and installer built ready for deployment without any manual effort.  This was the. Further enhanced by a plug-in I designed to the Azure DevOps environment that created release notes from queries. In TFS, a similar process was used using SSRS reports. Code was stored in Azure Git Repos for all aspects including a separate repo for database changes. While a sql database project was used for schema comparisons, the database repo was maintained with custom scripts to address the handling of new data. Since the system is dynamic in nature  , scripts were required to add new records.

Some testing mechanisms were attempted with the pipelines but due to the separation of API vs UX but the need for DB access, we focused more on end to end testing using Cypress.IO.