Doing Moar Together
Using Agile Methodologies to produce reference implementations for Progressive Web Apps
In spite of my team being distributed across four time zones, we generally do a great job staying in touch. We connect via Slack on a daily basis regarding team-wide concerns, conduct daily check ins, and keep each other up to date on what we’re working on. But, more often than not the bulk of our individual contributions is focused on projects that we tackle solo.
Motivations
As a team, we are very interested in the Offline First and Progressive Web App (PWA) movements, and so we decided to set an ambitious goal. We wanted to pull together to explore as many PWA frameworks as we could by building a series of simple applications.
For the uninitiated, a Progressive Web App is an app that works just like a mobile app but is actually built using web platform technologies so you can link to it on the web. You can share a PWA just like a website, but it utilizes service workers and has app-like functionalities like notifications, an add-to-home-screen button, splash screens, etc. A service worker is a script that your browser runs in the background, separate from a webpage, opening the door to features that don’t need a web browser or user interaction. Today, service workers include features like push notifications and background sync.
One app, many stacks
The big goal was to reach developers where they’re at by building the same shopping list application in a bunch of different stacks so we could compare and contrast the technologies. We decided the best way to tackle this goal was to incorporate agile methodologies by running a single two-week sprint.
Our appointed Product Owner set to work identifying the frameworks for us to target, and identified 15 different stacks, 12 different languages/platforms, and 2 different database technologies (PouchDB and Cloudant Sync). We built the same basic functionality for each app, but there were PWAs, hybrid mobile apps, native mobile apps, and even a desktop app. Then we created Epics and Tasks in a ZenHub board in the main GitHub repo for the project, so that we could track overall velocity.
Process
We held two days of sprint planning, where folks assigned themselves implementations to tackle, and we decided how each story would be tasked out. I acted as Scrum Master for the sprint, so I wrote the tasks for each story as decided by the team, tracked progress on the task board, and held everybody accountable for daily stand up. Because we span so many time zones, as a team, we decided that we’d do daily stand up asynchronously in a Slack channel dedicated to the sprint.
Over the course of the two-week sprint we were able to build 11 of the 15 apps that we targeted. We considered this a great success! But we also wanted to evaluate how our first crack at an agile process went, and how we could do it better next time.
In review
Generally, the team really liked being able to prioritize sprint work over other meetings, and getting that dedicated time to focus on diving deep into a particular technology area. We wished that we had spent a sprint planning for the development sprint BEFORE chunking out tasks. This might have given us the ability to build smaller tasks and allow for more collaboration between developers. We called the sprint “agile,” but overall people still took their own apps and ran with them, and didn’t end up collaborating in a traditionally agile process. We also didn’t end up with very much documentation because this sprint was heavily focused on development — which might mean we could have added another whole sprint built around writing documentation.
In the end, our focus was the data layer and making it possible for people who use these various frameworks to see how to make their apps into PWAs and add offline-first functionality. You can check out our work on GitHub.
The next sprint
We hope to apply agile methodologies to future work because we found that it allowed us greater visibility into what each team member is up to on any given day, and it provided an easier avenue to get help/feedback from each other. My hope would be that we do a more in-depth job building smaller, more digestible tasks for this work so that more team members can contribute to each application built, and to allow more time for cross-collaboration and maybe even pair programming. We learned that it’s not as easy to be Agile as we thought, but we found great productivity in the process of trying to implement Agile Methodologies.
