Now that you’ve met the team in our last post, it’s time to talk a bit more about how these people work together to deliver releases and updates. Just like the team has grown a lot since it was just Tyler and I with our hands in the code, so has the process surrounding development. Out of necessity it has become more structured, but we still try to keep it as loose and adaptable as possible; you might even say we’re agile.
If you have worked around software development teams in the past, you have probably at least heard the term ‘agile development’ or ‘agile methodology’. Agile is a framework that got its start in car manufacturing and has since been applied to many industries, but software development is where it is most commonly referenced these days.
Many see agile as a set of rules that you must follow, but it’s actually a framework to build independent and efficient teams to accomplish necessary goals. As the development team grew at DME, it was becoming harder and harder to keep all the developers on the same page and working effectively together, so we decided to bring agile to DME.
In any industry, or even two different companies in the same industry, agile will take on its own look and feel. Not everyone follows all the recommendations, and some make their own changes. At DME, we try to stay close to the original methodology, but like any company, we have our own unique changes.
Development at DME is broken out into 2-week sprints, with each of our development teams tackling different items each sprint. At the start of each sprint, the teams will take work items from our development backlog and allocate them as the to-do list for the next two weeks. Each team also makes sure to build in some extra room for any nasty bugs that might come in, or for any high priority needs from our users.
As an aside, one of the key factors in agile is adaptability. If a particular aspect isn’t working for the team, we encourage team members to evaluate alternatives and changes that might increase productivity. As a current example, we’ve recently evaluated going to 3-week sprints because many of our more complex DVR system implementations simply can’t be completed in 2 weeks. This results in these work items rolling into the next sprint, which isn’t ideal. We ultimately decided to stick with 2-week sprints for the time being, but it is something we’re keeping our eye on and will likely revisit in the future.
Over the course of a sprint, the scrum masters in each team (Erich and Sarah) facilitate the development of items on the backlog for that sprint through daily stand-ups. Think of them as the quarterbacks. The head coaches are still calling all the plays from the sidelines, but the quarterbacks keep the team on the field together working toward a common goal during the sprint. In some situations, they might make some on-the-field decisions if needed. As work items/features get completed, the developers send the product over to the QA team to be reviewed and tested. Once QA passes them, the work item is considered complete. If QA finds any bugs or issues, they will send the item back to development for further work.
Fundamental to any sprint and agile team is the backlog and road map. Both development teams maintain their own backlog, which are fed from the overall DVR Examiner road map. It falls on Garry, our product manager, to oversee these backlogs. To revisit the football metaphor above, Garry is essentially the head coach calling the next plays. So, who decides what plays are in the playbook available to be called next? Well, it’s you – the user. The team obviously wants winning plays, and that means making sure that what we are working on meets the needs of our end users. Those needs are often constantly evolving, so Garry talks with our users and gets their input and feedback on what DVR Examiner can or should do. He then takes such feedback, breaks it into work items, and works with the development teams to estimate the amount of work each one will require. Once he has those estimates, he will prioritize items in the backlog, ensuring the highest priority items are ready for the next sprint.