We Are Going to Work Together November 6, 2019 Author: Liz Vines This blog is from a presentation at the We Are Digital Commons event on October 29, 2019. This migration is also new and exciting for us. As we move through this process we will use an agile/iterative approach. In a blog on the subject, I give a brief definition of agile as 'the ability to create and respond to change' As we discover ways to make process AND the platform better, we will integrate those changes as we move forward. We already produce in 'short, consistent work periods of no longer than two weeks', called Sprints. We will continue this process as we migrate the 65+ sites on the Digital Commons Platform. It might be helpful to hear an example of how we use sprints when someone on the Platform submits a ticket for help on their website... An example of how our team utilizes Sprints: The Problem A web manager notices that on video cards, it shows a square shape instead of a triangular one. That manager notifies his/her team lead and a ticket is created. Other team leads may also have tickets and/or we have maintenance tickets. These are all placed into an area where all tickets that aren't yet assigned a priority stay, the backlog. Sprint Planning On a Monday, some platform members of our team get together and talk about all the tickets that are pressing and that should go into the next Sprint (two-week work cycle). We then get the whole team together and based on the capacity of our developers, we decide which tickets will go into the Sprint to be worked on. Thus, during that two weeks only those tickets that were put into the sprint are being worked on. Others remain in the backlog for future sprints. Testing During the two-week cycle, as the developers complete the work on the tickets, they are put through three levels of online testing by team members. FAT (factory acceptance testing) and code review occur in which the developers make sure things work as expected. Then platform members provide UAT (user acceptance testing) and lastly, testing on Staging. We get on the platform and try out the new feature on the non-live versions of your websites. After UAT and Staging testing developers are given feedback and changes are made, if necessary. By the last Wednesday of the sprint, if the video card now shows the triangle instead of a square, and it works, it is ready to be pushed to the live sites. Prod Push (going live to all the sites!) On the last Thursday evening of the sprint the developers ‘push’ the changes to all of your websites. Immediately following the push, the rest of the team gather online and begin checking your live sites to see that the change has taken place and that there are no problems. Sprint Review The following day, the last Friday of the Sprint we get together for a Sprint Review to share feedback on the increment of work that was produced. If we find that the triangular shape wasn’t a great fit, then another ticket can be put in and the process starts over.