SAFe for a Small Organization

Are you interested in the Scaled Agile Framework (SAFe), but you work at a small organization and aren’t sure it will work for you? SAFe was developed for scaling agile in large companies, but it also can be implemented in smaller organizations. Between 2018 and 2020 I worked at a small, not-for-profit company of about 100 people that was working to improve its software-development workflow. The client chose and successfully implemented Essential SAFe, a lighter-weight version of SAFe intended for smaller organizations. Before starting with SAFe they were mostly Waterfall with some experiments using Agile with Scrum.

They decided to make the transition to Agile to help improve the speed of implementing changes and to get a better handle on priorities. After conducting some research on Agile methodologies and a small-scale implementation of traditional agile on a single team, they decided to go with SAFe. They chose it because it provided the structure that would help them make the transition to Agile more broadly. Also, it had a framework to ensure the success of the transition. If you’re unfamiliar with the details of SAFe click here for a SAFe Overview to start learning more..

Making the Transition
To begin the transition to SAFe, they brought on an Agile coach (SAFe® Program Consultant, SPC) to facilitate the implementation. The organization followed the SAFe implementation roadmap that can be found here.

Implementing this roadmap took months of planning and execution. One key factor in their initial success was obtaining buy-in from leadership. They understood this was not just an IT implementation; the whole organization needed to embrace the new approach. Once the high-level plan was defined, they trained the team. It started with a Leading SAFe class for executive leadership: the business stakeholder group that would become the Product Managers, Product Owners, and Scrum Masters. They also conducted the SAFe for Teams training class for the development staff. Several weeks after completing the training, they conducted their first Program Increment (PI) planning session. Though the first planning event was a bit chaotic, they were able to successfully set the scope of work for the first PI. This PI was ten weeks with four, two-week increments (sprints) followed by a two-week Innovation and Planning increment. There were six feature teams, one Systems team, and one System Architecture group. They followed Essential SAFe with one Agile Release Train (ART).

The organization was committed to following the SAFe framework. This was important because during the first several Program Increments the organization was still learning how to effectively use SAFe. Some had difficulty with the change; the Agile coach played a key role in helping the organization understand how to make the transition successful.

This methodology had a significant test early on because a key corporate objective needed to be implemented within 6 months of the transition. SAFe provided the organization with the structures and controls needed to focus on this major initiative and get to a successful implementation. Using this framework enabled the organization to focus on this goal. Without the structure and planning provided by SAFe it would have been much more difficult to achieve this objective. SAFE organizes developers and QA resources into Feature teams that can work on different applications based on overall priority, as opposed to organizing with a fixed set of teams dedicated to each application. This allowed the organization to shift resources to the most critical initiatives. This aspect of SAFe provided the organization structure which allowed them to prioritize their key objectives and devote resources to what was most important. In addition, it provided the organization with a more predictable understanding of what the development teams could accomplish during the Program Increment.

Changing Priorities
When business priorities changed (as they always do), the organization’s leadership was able to understand that if they added work to the PI then something of equal value would need to be removed. This transparency was critical and allowed the development teams to be successful.

The first real test of this flexibility occurred in one of the early PIs when a major production issue needed immediate attention. This required the formation of a new “tiger” team which was taken from the existing teams to address the issue. Leadership understood that taking resources away from existing teams would impact their ability to complete their PI-committed work. Teams reviewed their decreased capacity and were able to clearly state what could not be accomplished with their reduced staff. Choosing what not to do was based on business value and negotiation with the business. Without this structure, transparency, and the clearly defined scope that SAFe provides it would have been significantly more difficult to make these decisions.

Keys to Success

• Following the SAFe roadmap for making the transition, adhering to the SAFe framework, and not falling back into previous habits.
• Continuous learning – after the initial training, the Release Train Engineer (RTE), POs, and SMs attended follow-on training to add to their knowledge.
• Acting on team feedback – To make Agile successful it’s critical that the teams embrace the methodology and adapt it to meet the organization’s culture. To get this feedback, retrospectives need to be conducted at the team and ART level. Even more important than conducting the retrospective is acting on the group’s feedback. A key example of this was that after working on about 7 PIs, the teams felt they wanted to try lengthening the iteration from 2 to 3 weeks. This suggestion was then reviewed and approved by the organization’s leadership. This is an example of a major change, but even small changes to improve the teams’ experience are important to build confidence in this methodology.
• Using an Agile coach – this person is critical for providing leadership, guidance, and advice. When making this transition, so many new concepts need to be understood and internalized. The coach is needed to provide regular workshops and tips to help the team succeed. Some of the most challenging areas include using relative estimation with story points, writing good user stories with solid acceptance criteria, and knowing when to split stories.
• Creating team working agreements and having a solid definition of done.
• Having features available for teams to review several weeks before PI planning. This requires an organizational commitment to constant feature refinement among the Product Managers and System Architecture team.
• Fostering communication between teams. To help support this communication we developed the concept of “office hours” for the Product Management and System Architecture teams. Each of these groups conducts a weekly meeting where teams could connect with them to review key topics. For the Product Management team, discussions focused on areas like requirements clarification and coordination. The System Architecture office hours provide architectural direction and tactical coordination. We even implemented a technical-only meeting where developers could meet to discuss technical topics. These meetings were not meant to replace quick communications but provided a regular forum for discussions.
• Providing a multiple PI view of upcoming initiatives and targets.
• Displaying a large, permanent, visible information radiator in a public place where everyone in the organization can see the teams progress in completing features.
• Allowing teams to fail fast. Agile moves quickly without detailed requirements or fully developed technical architecture so development teams will need to try different approaches to implement their work. These may not always be successful on the first try. Teams must not be penalized for this type of failure. They need to be allowed to regroup and find a better approach.
• Conducting an Innovation and Planning Increment (IP). Often it is difficult to pause new development to allow time for the team to focus on learning new skills and sharing information. But this is time well spent. The learnings and knowledge-sharing that come from this time can provide a good jumpstart for future work. During this time, the System Architecture team focuses its activities on upcoming iterations. Some examples of valuable work during the IP include sharing information on newly developed applications with other team members, learning new skills, and creating a proof of concept for future work to enable better estimates when this work is prioritized into the ART.

Long-Term
This organization has proven that essential SAFe can be successfully implemented in a small organization. Long term, the key to success is to continue to refine and enhance the process. Anexinet is focused on technology-enabled business transformation strategies and solutions. Clients benefit from our holistic approach—from engaging front-end interactions to dependable back-end solutions, all informed by data-driven insights. So, if you have any questions around all the advantages modern distributed architecture, private/public cloud, Dev/Ops and Agile/SAFE processes have to offer your organization, please don’t hesitate to reach out to us. We’d love to help you get started.