Last week, Director of Project Management, Sean Shahrokhi shed some light on the value of our daily stand-up meetings. This week, we’re taking a more in-depth look into the methodology behind those meetings, and we’re giving you a behind-the-scenes look at our truly agile development model. What does it mean to be agile?
AgileMethodology.org explains, “Agile development methodology provides opportunities to assess the direction of a project throughout the development lifecycle. This is achieved through regular cadences of work, known as sprints or iterations, at the end of which teams must present a potentially shippable product increment.”
Because technology and business both change so rapidly, it is critical that we implement a system that supports swift changes in direction. This is why Sean is quickly turning our entire team into a group of agile-minded developing ninjas.
Here at The Control Group, Sean manages our workflow and categorizes all tasks and projects into two main areas using a project management software called Jira. These areas are our Sprint Board and our Kanban Board. Both are organized in the same fashion with a few key protocols—the user story (issue), the pending requirements, the development, testing, and finally deployment.
The Sprint Board is where large scale development projects that have a target date for completion are organized. For example, when we want to add a new page to our website for a new service or functionality by the end of the month, that would qualify as a sprint. The project involves several aspects of development and has a clear objective. We would then plan the process at an epic level (the full scope of the project) and break each aspect into different user stories. We then arrange a 1 to 3 week sprint (1 to 2 weeks is ideal) in order to focus on completing that one project. At the end of the sprint, anything that is not completed is put into our backlog and reiterated until completed. That’s the beauty of agile—we can continue iterating through an issue until it is completely addressed.
Our Kanban Board is where we file high priority issues that are not part of a larger development project and need to be addressed right away. These are issues that are handled at an individual level, and they never move to the backlog. They are prioritized and handled as needed. For example, if one of our servers goes down, that would be addressed on our Kanban board and handled immediately. Bug-fixes and one-off issues would also fall onto this board. Tasks can be released individually here as opposed to as groups on the sprint board.
With Sean’s guidance, we’ve quickly seen the positives of using this model to accomplish our ongoing list of projects. One of the biggest benefits has been the ability to scale this model to accommodate our ever-growing team. Using this methodology, we’ll have no problem organizing 50, 100, 500, or even 1,000 developers—now that’s seriously agile.