For many development teams, Scrum has proven to be advantageous: direct communication, faster feedback loops and more independence. Some companies have already carried out total agile transformations, meaning that everyone there now works according to agile principles. In this case, what the Scrum Guide outlines for teams of 3 – 9 people has to be adapted for larger organizational units. Agile scaling models such as Scrum of Scrums, LeSS, Disciplined Agile, Spotify and SAFe all offer guidelines to accomplish this.
An incremental and iterative approach is common to all these frameworks. That’s because the only way to tackle today’s brisk technological change is to use short delivery cycles that integrate constant customer feedback. Despite these circumstances, there are still complex products being developed with many compliance requirements that aren’t necessarily innovative or disruptive. An agile approach is also well-suited for these projects, and many teams that work in parallel also require higher-order events, artifacts and rolls in order to create a framework for collaboration.
Frameworks for scaling agile offer solutions for the following situations:
- Collaborative work with a shared product backlog and constant refinement
- Synchronizing sprints and the delivery of product increments
- Carrying out reviews and retrospectives
These issues need to be considered when several teams are working together on a single product or system. Within project management, the term ‘program’ is used to describe this scenario. Teams working together in a program have common goals.
When multi-project management is considered from one level higher, that is, considering all projects and programs within an organization that may compete for resources and priority, one speaks of ‘portfolio management.’
The template for scaled agile programs
For agile programs, our software objectiF RPM offers a new template oriented on the Scaled Agile Framework, SAFe for short.
The template facilitates the following:
- Identifying program stakeholders and their goals, defining and recording the product vision, and building the program backlog
- Organizing and structuring the mass of epics, feature requirements, user stories and enablers, which is typical for large projects
- Ensuring traceability while carrying out program increment planning and team and iteration planning
- Not losing sight of the big picture, including architecture, and maintaining requirements traceability all the way to source code
- Ensuring compliance, especially in regulated industries, as a precondition for high process and product quality
You can easily preview the template in the 30-day free trial version of objectiF RPM. The following video shows you how to use the template to quickly begin a new program and what it comes with out of the box:
From product vision to stakeholders and epics
How is the template used for an actual program?
At the beginning of development, need should always be clarified. Who is interested in the project? What belongs to the system and what needs to be taken into account and complied with?
Teams using a Scrum approach often work out answers to these questions in workshops using creative techniques and then condense their assumptions in a product vision. The product vision can be developed using a worksheet or with the aid of a product vision board. objectiF RPM stores these early results in a central repository, making them available for everyone involved and directly linking them to all changes and refinements made from that point onward.
Visual mapping helps agile teams with early requirements analysis. objectiF RPM offers instruments such as context and goal diagrams with which dependencies, conflicts and processes can be logically thought out and mapped. The results are automatically versioned and are always easily available to all parties.
For validating results with stakeholders, reviews can be started for all elements and element groups (e.g. user stories, test case, use cases and more). Reviewers can access the program in objectiF RPM using a web client and store their feedback at a central location.
Is everyone satisfied so far? If the answer is yes, epics can now be formulated which will then be further broken down during program increment (PI) planning meetings into feature requirements and user stories, and managed across backlogs at the program, increment and team levels.
Where to go from here?
That’s the end of part 1 of our introduction to the new template for scaleable agile programs. In further installments, we’ll show you how to refine epics, facilitate PI planning, and keep results up-to-date and accessible to the whole team. In addition, you’ll learn about dashboards, planning patterns and Kanban boards, and how they can help you keep an overview. Finally, we’ll give an overview of features for solid risk management. You can either wait to read more or download now our free whitepaper about the template for agile program management.