Agile (specifically Scrum) gives business analysts, Scrum Masters, and project managers a framework to prioritize work within a project or domain which has already been identified, scoped (somewhat), and approved. However, Agile does not help determine which initiatives to work on nor how to prioritize conflicting initiatives with limited resources. Additionally, Agile doesn’t prescribe methodology on how to deal with cross team dependencies and cross team coordination. Finally, Agile does not define how to deal with release planning nor release dependence.
Some extensions to Agile such as the Scaled Agile Framework (SAFe) attempt to provide an infrastructure for being Agile while identifying, scoping, and approving initiatives within an organization. Full SAFe is a complex process which is focused on program management. SAFe has released some different flavors that include Portfolio SAFe, Large Solution SAFe and Essential SAFe. Nevertheless; even Essential SAFe comes with a relatively large overhead for small organizations.
In working for a small software company (approximately 30 employees) I have found that Agile of any type was not enough as my company needed to coordinate cross team dependencies and align initiatives with business objectives. When looking into SAFe, it was quickly realized that the layers of management/decision making needed to do even the Essential version of SAFe did not exist. But, the need to have methods which could align business strategies with Agile team implementations still remained.
My Organization’s Solution
How did my company handle this dilemma? Ultimately, we took the principles of Agile and applied them to our planning processes. The leadership group within our organization eventually looked at ourselves as an Agile team and identified the product manager to serve as the Scrum master for itself. While the product manager was involved with making the decisions and prioritizations, the senior leadership group was ultimately responsible for such decisions (self-organizing team). As such, the product manager treated the leadership team as an Agile team and facilitated team meetings to help the team collaborate and select priorities just like a Scrum Master would do for an Agile development or engineering team.
Further, the leadership team looked to Agile (Scrum specifically) to determine what types of meetings might help us coordinate our prioritization efforts. A Kanban tracking approach was utilized to encourage adapting to change while still tracking all items actively in flight. These items would serve as a singular representation of all engineering and analysis priorities.
Results of Our Approach
Applying the Agile/Scrum approaches to leadership became a logical approach towards remaining Agile, while still having more mature prioritization and strategy sessions. However; this approach required less overhead than implementing a full-blown Project Management Organization (PMO) or implementing the Scaled Agile Framework (SAFe). Rather than worry about processes and approvals, we viewed the leadership as an Agile team, met regularly and applied the Scrum ceremonies to the leadership group. The team used longer iterations than the development teams (using months or quarters rather than two-week iterations) and worked to determine priorities which could then be assigned to the Agile teams for development or analysis.
This transition came with some growing pains, however. The organization has ultimately experienced better alignment of priorities and improved the throughput of work. Just like no team is “fully Agile”, this management Scrum team continues to evaluate our processes and continues to seek for internal process improvements to adhere to the Agile principles. Rather than continually questioning the priority of work, we created a method which could adapt to change, yet still clearly report on progress of initiatives. The approach also helped align business objectives with development work and adapt to change as needed.
The specifics of our implementation may not make sense for all organizations, but ultimately, we treated the leadership group as an on varying cycles based on agreed upon organizational needs. These included standups, biweekly release planning, monthly and quarterly work prioritization.
To further the approach, the leadership group implemented a Kanban board using Jira. This Kanban board includes major initiatives, general software improvements, and urgent / immediate code changes needed in production. Further, the Jira Kanban board then linked to the team boards to allow each individual team to create child stories which linked to each item on the leadership/planning Kanban board. This approach added some additional tracking overhead but provides complete traceability and reporting from ideation to deployment. Further, the Kanban approach created a backlog which serves as a dynamic product roadmap.
If your organization is struggling to be Agile while also adhering to strategic prioritizations, consider using an Agile approach to product management and view your leadership stakeholders as an Agile team. Assign one person to be the Scrum Master for the leadership team and evaluate what Scrum ceremonies might make sense to apply to the leadership group. Once the leadership group adapts the cadence of the meetings, the same benefits that the engineering teams get from Agile can be applied to program management. This may work well if your organization doesn’t have a fully structured PMO and have not been able to implement the Scaled Agile Framework (SAFe).