Agile project management is a multifaceted topic, and as such, there is far too much information to cover in one article. This article is the second part in a series to go over the benefits, approach and structure of using agile project management methodology. For more information on this topic, read Developing your agile analytics approach.
Author: Nathan Olson
Agile project management takes an iterative approach to management and software development that relies on continuous releases by incorporating customer feedback into each development. The principles of agile run deep down to how teams are organized and how development work is delivered back to business users. At the center of this is the desire to eliminate unnecessary overhead and get value churned out to the business early and often. To accomplish this, agile methodology is defined by the roles which make up the scrum team and the mindset with which that team operates.
Project work is not just creating data models and writing code. Most of the time you are spent in meetings with business users, swirling on design discussions and fighting off competing priorities. To operate efficiently, agile divides responsibilities into the following roles:
Developers: The developers on a scrum team form the core engine for delivering business value. They are the data engineers who can build systems to store and process data, the reporting experts spinning up dashboards and tools for the business and the data scientists who are analyzing data and creating models. The other agile roles exist to get the most value out the developers, guarding their time and brain space from the overhead of running the team.
Product owner: This individual is responsible for defining high-level priorities of the development team. They understand the goals of the business and can distill requests into a consolidated and prioritized list. Product owners are gatekeepers to prevent the development team from being too reactive or spending time on less important tasks.
Business analyst: The business analyst works with the product owner in gathering business requirements, but at a much more granular level. This individual’s focus is on meeting with users, understanding their workflows and specific requests. The business analyst then becomes a liaison/translator between the business and development team. Having business analysts helps reduce the amount of time developers spend in meetings, so they can spend more time writing code and generating insights.
Scrum master: This role exists as the glue that holds the rest of the team together. Scrum Masters coordinate, schedule and run meetings within the development team. They focus the team on the topics at hand, escalate issues and blockers that are preventing work from moving forward.
What you may notice is missing in this team configuration is a formal manager. Management roles are split and shared between all members of the team. Product owners are responsible for setting what work is prioritized, but not the way it is accomplished. Scrum masters run meetings and hold team members accountable for their work, but don’t decide what will be delivered to the business. The development team works collaboratively to decide on the best technical approaches, yet defers to the business analyst’s documentation of when the work is considered complete.
By getting rid of the responsibilities of prioritization, requirements gathering and administrative overhead from developers, the team can focus on the here and now. An agile development team works within the structure of sprints, which are generally two-week segments of time focused on a predefined set of work. The goal for the team is to have a deliverable value or product for the business at the end of each sprint.
This change can be a big shift for teams who previously had months or yearlong development cycles. Additionally, this shift places extra pressure on the team to deliver results frequently, but much less pressure in terms of getting everything perfect on the first try. This new model is appealing to business users who can benefit from project work much sooner and allows for timely feedback from the business that can be incorporated early, instead of when it is too late to do anything about it.
A subtlety of the scrum mindset is that although roles are separated, the results of the team are shared. This needs to be an expectation from the start; no developer can claim that they are not to blame because they got “their” work done. All work is the team’s work. Because of the regular cadence of daily stand-ups and bi-weekly sprint planning and review, the team operates collectively, intimately aware of each other’s tasks. If one developer is struggling, another team member can jump in already knowing the context and goal.
Agile comes with its own set of processes, meetings and vocabulary, many of which are far from traditional development methodologies. It can be overwhelming to jump into this with immediate expectations of a fully groomed backlog, switching to agile estimation tools and formal role divisions. Adopting this all at once can cause the transition to not take hold and fail. Breaking down your tasks into smaller segments can help ease the transition of this new process:
When a scrum team makes incremental improvements from sprint to sprint, both on the project at hand and on your team’s processes, they will gradually become more productive, efficient and effective. Keep an open mind as you progress through your sprints and towards the tools that agile offers. Reassess what is working, what is not and be prepared to implement any changes to improve your processes.
Preparing your business for agility
Remember that with agile, nothing is set in stone. Agile teams are run differently from team to team and project to project. Our Baker Tilly professionals are adept at implementing the agile scrum methodology and organizing teams while keeping your future business goals at the forefront of every decision.