An Intro to Agile

Hey everyone! Back again with another dev dive. Today, I want to talk about how dev teams work together and with the rest of the company, as well as what that means for you. Punchmark has been growing our team and our platform, and to help coordinate all of our efforts, we've recently started working in a framework called agile.

Agile is an approach to project management that is used by dev teams in companies of all sizes. Instead of working toward large, nebulous goals, agile strives to break every development task down into small, manageable pieces. Everything touched by the development team - new features, bug fixes, client requests, etc. - is broken down into pieces that take no more than a few hours each to complete and put into a backlog of tasks to pull from. Every week, members each team get together and prioritize which issues in the backlog are most important to complete - this is the chance for our customer success team, design team, and marketing team to all have input on which issues they want the dev team to tackle. Then, once we have a prioritized list of issues, the dev team picks issues from the top of the backlog based on the amount of time they have for the week and which issues they're best suited to tackling, and puts them into a sprint that serves as their to-do list for the next 7 days. Once the sprint is planned, that's it for the week - any issues that come up during the week, unless absolutely necessary, are kept in the backlog for the next planning meeting.

So what is it about development that makes agile work so well? One reason is that the development team can easily prioritize requests from all teams at once. In cases where there isn't a centralized place to plan, it can be difficult for the development team to keep track of every open issue. In addition, it ensures that most of the necessary planning in order to tackle issues is done before any work is actually started. Large features have to be broken down into component pieces in order to make it into our week-long sprints, and bug fixes have to have enough investigation to know what will be required to fix them. This means that once a sprint is planned, the dev team can quickly go in and cross items off of their list without having to take more time out for clarification or further coordination with other teams.

What does this all mean for you? Now, when you have an issue or request to bring to our team, you'll pretty much always hear your account manager tell you to submit a ticket. These tickets are put directly into our backlog, and your account manager serves as your advocate in backlog meetings to make sure that your issue gets prioritized appropriately. Rather than having your account manager give a strict deadline for when they believe the issue will be fixed, they'll often instead let you know approximately how many sprints it will take in order for your issue to reach the development team. Once the dev team adds your ticket into a sprint, it's very likely that your issue will be resolved within the next 7 days.

Because so much of the agile process revolves around careful planning and prioritizing, the best thing that you can do to ensure that your issue gets solved is to provide as much information as you can when submitting your ticket. If a ticket comes to the dev team that doesn't have enough information, we can't put it into a sprint until your account manager has reached back out to you for more details, which will inevitably cause a delay.