Scaling Agile Programs with SAFe
Make the highest value things first to make money faster.
Q: We have multiple teams working on the same feature or project. I know that a Scrum of Scrums meeting can help them stay in sync. But what about when all of those teams are also working on multiple other features? At some point, it becomes impossible.
A: SoS should include just one person from each team. More importantly, you should be drawing value streams that concentrate feature development in fewer teams. It is exactly because this coordination is so important that we reconfigure the organization. If we flow work through teams, and seek to concentrate like work together, we won't have 100 teams needing to coordinate to deliver value.
Q: What suggestions do you have for Agile teams interfacing with a waterfall organization—where portions of the project must be delivered by the waterfall teams?
A: Have Agile PSI end points align with delivery milestones the waterfall team is tracking against. You most likely will have multiple PSIs before a major waterfall delivery date. Try to decouple your Agile teams' dependency on waterfall teams' deliveries as much as you can to minimize bottlenecks. Where you can't decouple, you should be able to show objective evidence that your Agile teams are being blocked by waterfall teams which will hopefully encourage a discussion with management of why that is.
Q: Product backlog: How do you ensure the design of long pole features and functionality are considered up front, rather than deferred as too complicated to consider in the beginning?
A: Program managers who own the program backlog of features should strive to bring the higher risk, more complex features to the top of the backlog (if they are considered important), yet still maintain a balance of lower risk, less complex features in the mix. This allows the teams have a higher probability of delivering something within a PSI. Skipping a feature in the backlog because it is deemed to complex or risky and only scheduling the easy work is not considered good Agile practice.
Q: Should defects have points assigned like feature user stories?
A: Yes. That way you have a clear measure of your teams throughput (velocity) which includes all work (stories and defects).
Q: What sort of developer or QA environments do you maintain if the released code does not match the QA environment? How and where do you test, verify, and duplicate bugs?
A: The Agile teams should have a developer deployment environment that mirrors your production environment for the reasons mentioned in the question. The Agile team that developed the functionality should also maintain it.
Q: How can a team estimate 10 weeks ahead?
A: It is a critical Agile maturity step that teams be able to do mid-range planning, in which they can forecast delivery of stories over the next three to six sprints. The key is that they are not planning detailed tasks, but rather plotting stories into sprints, usually with more confidence in the near-term and less confidence in the long-term. To be able to do this well requires a team to achieve some level of steady velocity. That is, the number of points delivered each sprint. This tends to focus team improvement activities on achieving consistency rather than merely faster. To conduct mid-range, or PSI, planning also requires the entire team to be present.
Q: Culture is a big issue for many people. How do you manage the communication between siloed teams when different teams are not used to communicating with each other?
A: This is a cultural shift and why strong objective coaching and facilitation is so critical to a successful Agile implementation.
Q: How does continuous, last-minute critical business requirements affect portfolio level backlog and future release planning?
A: If these last-minute changes are not managed through the regular program backlog grooming cadence, then it will have a big impact on your existing plans. If changes to release plans are allowed after your Agile teams have made commitments to those plans, then you have effectively invalidated the planning process and the teams' ability to establish a predictable cadence. This is where a strong release train engineer (RTE) is important to assist in ensuring working agreements are honored.
Q: How do you account for work for non-functional or compliance items? Are they considered overhead so you deduct them from individuals' or teams' capacity?
A: That is correct if the NFR or compliance items are levied on all new features. Consider them part of the definition of done for the feature.
Q: All enterprise companies span multiple time zones and are distributed. How do you conduct program-level meetings?
A: Dean Leffingwell's Agile Release Train asks that you bring the entire train (of up to 150 people) together for two days of planning for a 10 week release. This requires a commitment from executives. If you cannot send everyone, then you may just send team leads, but it is best to identify potential risks and obstacles immediately to have everyone together for planning.
Q: When you have 5–10 teams, how do you avoid that the individual team members join all other daily scrum meetings to just stay up-to-speed?
A: Good scrum masters remind team members of their commitment to their current team. The release train engineer in conjunction with the systems team and product management team should assure that information is properly flowing down to the execution teams, as well as manage any inter-team dependencies such that individual team members don't feel like they need to attend other teams' daily scrum meetings. This could also be an indication that there is too much coupling between teams.
Q: In this model, how does performance testing get accomplished across all the components?
A: This is the responsibility of systems engineering team at the program level of SAFe.
Q: How can we get a demonstration of these ideas in CA Agile Central? Are there any videos available?
A: Your technical account manager can demonstrate this for you.
Q: How do you feel about continuous delivery versus the 10-week delivery?
A: CA Agile Central, as a platform and coaching organization, supports both SAFe and continuous delivery, as well as a hybrid between the two. However, if you plan to pursue a hybrid approach, our recommendation is to have experience in scaling both within your organization (to allow you to pick and choose what works best for you) and your organization based on your experience of what aspects are effective. While SAFe is very prescriptive, it has proven to scale programs up to 150.
Q: Does the velocity normalization logic mean you are normalizing 1 point = 1 day effort more or less, is that right?
A: You are correct. This is a guide provided by Dean Leffingwell order to roll-up points across an organization.
Q: We have 12 individual teams, but I could see them in 3–4 programs instead. Do you haven any proven benefits of doing this? I could see more efficiency, more awareness of dependencies, and so on.
A: Yes. Aligning individual scrum teams around a single value stream allows you to ensure team level efforts are aligned around integrated features that deliver real value to customers (taking into account dependencies, integration needs, and so on). It also ensures that the execution and strategy arms of your product development organization are aligned so you are not only building things right, but building the right things.
Q: Can you describe objectives?
A: Establishing an objective for each PSI is critical to ensure execution is aligned with strategy.
Q: You talked about the role of the project manager. What is the role of the business analyst?
A: The business analyst is represented as the epic owner role in SAFe. Typically, an epic owner works with one or two epics at a time, which fall within their area of expertise and current business mission. See this site for more information.
Q: What about gaining management support, by a commitment to understanding what Agile really is, versus "good idea."
A: SAFe concepts are built on both Agile and Lean concepts and management's understanding and support are crucial to its success. Dean Leffingwell begins his executive training by explaining the house of Lean. The key here is that management is educated in Lean thinking, product development flow and Agile development.
Q: How do you normalize the velocity across multiple teams? Velocity is generally a team-centric metric.
A: In the context of SAFe, this is what Dean Leffingwell recommends for normalized team velocities which provide the economic basis for estimating work.
- For every full-time developer and tester on the team, give the team eight points (adjust for part-time people).
- Subtract one point for every team member vacation day and holiday.
- Find a small story that would take about a half day to code and a half day to test and validate. Call it a 1.
- Estimate every other story relative to that one.
- Never look back (don’t worry about recalibrating).
This topic can be controversial (even among our coaches here at CA Agile Central) and is outlined in detail in our Leading SAFe course.
Q: How are you able to overcome non-dedicated teams, or are you?
A: In the context of SAFe, it is a foundation that the DBT (Define, Build, Test) teams are dedicated to the Release Train that they are delivering features for. See more information here. At the program level, SAFe explains roles like architecture, UX, system team, and shared services that are shared at the program level.
Q: I would like to hear ideas about how to estimate how much of your program backlog will make a release without resorting to traditional project management. Velocity works well at team level, but at the program level there are more dependencies.
A: In SAFe, it is recommended that a program's feature backlog is also estimated in story points and velocity is used to assist with the release planning process. See here for more information.
Q: My company has a large defect backlog. What is the best way to have multiple teams pull from the same backlog during a sprint planning session?
A: In SAFe, a release planning session is recommended that would include all work to be delivered by the teams delivering to a common value stream (called a release train in SAFe). See this description of a release planning meeting in SAFe for more details.
Q: Would you structure your program in one project in CA Agile Central, or would you have a project per team?
A: We recommend a structure where the program is a project in CA Agile Central that then has child projects for each team that is working on the features in that program backlog. Think of the project structures as backlog containers where each team should have their own unique backlog that rolls up into the overall program backlog. For more information, see how to set up your hierarchy.
Q: Isn't the team-level product owner artificial then or just a delegate of the program manager then, if the program manager is so well defined?
A: In the context of SAFe, the product owner maintains ownership of the team backlog and prioritization. Since the product owner will be part of a larger product owner-product manager team, they will be getting input from the program backlog that will impact their backlog.
Q: What does UX stand for?
A: UX stands for User Experience. User experience highlights the experiential, affective, meaningful, and valuable aspects of human-computer interaction and product ownership.
Q: What if different teams are using different sprint lengths due to the types of work they are doing? Isn't it being too prescriptive to say that all sprints have the same start and stop dates?
A: If teams are coming together as part of a single Agile Release Train, it is critical that they be on the same sprint and release cadence. However, while this means that all sprints have the same start and stop dates, if you have a data warehouse team that needs a longer sprint, we would recommend you make it four weeks (rather than three) so they still align with the overall Agile Release Train's sprint boundary and cadence.
Q: With multiple teams, are all teams on the same two week sprint cycle? Or can the sprints be staggered?
A: It is critical that teams that are part of the same Agile Release Train be synchronized and on the same sprint cadence. The most common cadence is two week sprints. In addition, all teams within an Agile Release Train synchronize on a PSI (potentially shippable increment or release) schedule which most commonly is 10-12 weeks in length.
Q: How do you handle a cadence or release of a new system that has six months' development and several teams?
A: Start the 10 week cadence cycle. You have your value stream and teams identified already. Spend a lot of time getting your leadership educated on SAFe, and then launch with a first 10 week PSI cycle.
Q: Will ScrumAlliance introduce a new role besides SCM and CSPO?
A: No, ScrumAlliance does not have plans to introduce a new certified role at the scaled Agile level. However, there is a SAFe Agilist certification and CA Agile Central offers that certification course.
Q: What does PSI stand for?
A: PSI stands for Potentially Shippable Increment (release). This refers to the result at the end of the longer timebox. Even though you still have potentially shippable increments at the end of each sprint. In this case, it's the cadence on which all teams' work can be integrated.
Q: How do the product manager (program) and the product owner (team) work together?
A: The product manager is chief product owner with all the product owners from the team. Similar to how the release train engineer (RTE) is uber-scrum master.
Q: What are some of the key factors to keep in mind as an organization moves from waterfall to Agile?
A: Some key success factors to consider include having active executive support and leadership for your scaled Agile initiative, a focused and incremental adoption approach, expert guidance from someone who has expertise in scaled Agile rollouts and organizational change, dedicated coaching support at the team and program levels, and a scaled Agile rollout plan that addresses not only process but organizational structure, people and roles, metrics, and reward systems.
Q: Should there be one scrum master per group? Would multiple scrum masters handle different aspects (communications versus analysis)?
A: At the team level, generally one scrum master per scrum team. As teams become more mature, a single scrum master may be able to support several teams. Scrum masters would not be layered in to handle communications versus analysis. A single scrum master is responsible for supporting Agile practices within a scrum team, and helping to protect the scrum team from outside influences during a sprint. They are also tasked with ensuring obstacles preventing scrum team progress are addressed.
Q: Are all of these roles in addition to the scrum roles? It seems like it is adding a lot of overhead.
A: Think of the program-level roles as being a re-purposing of existing roles in the organization. An example might be a member of the PMO who is responsible for chasing down status on program deliverables. Within a SAFe Agile Release Train, this person may instead fill the role of the release train engineer.
Q: Is there something magical to the five sprint cycle?
A: While 12 weeks may seem like a more logical increment, 10 weeks gets you to just under quarterly, giving you time to take in the results of the PSI and take that as input into broader quarterly steering at a strategic level. In general, 3–6 sprints is about how far ahead teams are able to plan with any meaning.
Q: Are PSI demos the same cadence as sprint demos?
A: PSI demos are on a regular cadence. While a sprint demo happens at the end of each sprint increment, PSI demos happen at the end of each PSI increment. PSI demos tend to be far more meaningful and valuable for business stakeholders because entire features are demonstrated in this forum. This is a great event to ensure stakeholders invest time in attending.
Q: Does SAFe extend well to outsourced and off-shore development teams, when they are delivering part of the work that needs to be coordinated with on-site teams?
A: Yes, it is typical that organizations implementing scaled Agile have globally distributed teams. As CA Agile Central coaches support the launch of Agile Release Trains, they employ strategies for effectively collaborating and planning in a distributed manner.
Q: Can you elaborate on the system-team? What types of people are on these? What's their knowledge and skill special or different compared to others? Also, how to motivate them?
A: You can get an excellent overview of the System Team here.
Q: What are some ways to make sure the organization stays in sync without having numerous meetings, or without having to invite 100 people to a single meeting?
A: The Scrum of Scrums structure works well here. Remember that the SoS should include just one person from each team. Secondly, you should be drawing value streams that concentrate feature development in fewer teams (within a single Agile Release Train). It is exactly because this coordination is so important that we reconfigure the organization. If we flow work through teams, and seek to concentrate similar work together, we won't have to coordinate as many people and teams to deliver value.
Q: How does the program manager role fit within this framework?
A: Program managers who own the program backlog of features should strive to bring the higher risk, more complex features to the top of the backlog (if they are considered important), yet still maintain a balance of lower risk, less complex features. This allows the teams have a higher probability of delivering something within a PSI. Skipping a feature in the backlog because it is deemed too complex or risky and only scheduling the easy work is not considered good Agile practice.
Q: Is the project manager still the technical product owner?
A: The role of project manager would change depending on the skillset of the individual, so they may be well suited to being a technical PO if they have the skillset to fulfill that successfully. But the individual may be better suited to a number of other roles within the Agile context such as scrum master or product manager.
Q: Sometimes we must start to implement architecture items (basic blocks) non-demonstrable, this can last for a couple of weeks. How do we deal with this (no business value to demonstrate)?
A: The value is in the discovery work being done at the architectural level to help define if the work that needs to be done is feasible. The demonstrable component is defining what work needs to be done and how to perform this in the upcoming value stream within the context of the architectural runway.
Q: Do we have a glossary for all these acronyms?
A: You can get a glossary of terms from www.scaledagileframework.com.
Q: How do we know the epics and features have had enough thought behind them to know they are ready for the next level of breakdown?
A: You could create a discovery process from a portfolio Kanban with exit policies in each column to determine if an epic or user story is ready to be developed. See here and here for more information.
Q: Can we make release planning shorter?
A: Two days is a general rule and really depends on the number of people that are participating in the release planning. We've seen it done in as little as 1.5 days. This may still seem long, but it is an important investment in making sure your teams are working on the correct things for the upcoming release. This planning meeting is key to making sure your teams and release trains are aligned.
Q: The program level team consists of a lot of roles. How do they operate together? What type of interactions and meetings are needed?
A: The short answer is there are a number of prescribed checkpoints and interactions that allow SAFe to work. The Leading SAFe two-day workshop goes into great detail on this question. Contact your account team for a more in-depth conversation on this topic.
Q: What does the architectural runway graph describe? Varying levels of effort on architectural items?
A: Architectural runway is an ongoing effort. The graph is showing the steady delivery of architecture features over time.
Q: What are some strategies for managing design iterations that flow into development iterations and where requirements elaboration fits in? How would you manage prioritization between architectural versus business features?
A: Dean Leffingwell calls this maintaining an architectural runway. The rules for doing so are simple and Agile:
- These teams iterate like every other Agile team on the program.
- Credit goes to working code, not models and designs.
- Time is of the essence—it should take no more than a few iterations to prove the new architecture.
Q: How often should Scrum of Scrum meetings be done?
A: Dean Leffingwell say that SoS meetings are done as needed, but typically the release train manager sets the frequency based on need.
Q: How do we get visibility for features that have user stories in several different high-level projects (same hierarchy level) in CA Agile Central?
A: If you apply CA Agile Central Portfolio Manager with portfolio hierarchy above the story hierarchy, you'll be able to see features at that level. Talk to your sales representative to find out how to take advantage of CA Agile Central Portfolio Manager.
Q: Do you think it is not a good practice to have a product manager as a product owner? Why would you recommend or not recommend a PM sitting in the product owner role?
A: It is nice to have separate people doing these roles, but in practice we know this isn't always possible. We've found that some organizations will give the role of PM and PO to a team of a few people and let them naturally move to the role that best fits them. It works well to start your SAFe transformation, but you will find over time that you will want to have different people in these roles.
Q: Do you have any best practice references in industries that have used scaled agile to improve lifecycles of hardware or software projects?
A: Most frequently, our experience has shown that hardware typically requires longer cadences, so you would coordinate deliverables between hardware and software teams at PSI boundaries.
Q: Do program managers need to deal with the taxonomy of the software developers and testers versus leads?
A: Not on a day-to-day basis. The program managers will be dealing at the SAFe program level and will be helping to fill the backlogs of the teams. But it will be good for the program managers to not act in a vacuum and should know the teams are doing. This is where a tool like CA Agile Central will help. It will allow you to get the visibility into how your teams are doing.
Q: What level of estimation or sizing is done at the release planning?
A: Sizing of features is based on Donald Reinertson's Weighted Shortest Job First. When you break down features into stories scheduled in the sprints, the stories are estimated in points (like normal scrum).
Q: What are the differences between the business features that go into a PSI and the features that go into a team sprint? What are some examples?
A: The business features are scheduled along with the architectural features into the PSI. Then in the agile release train, you decompose the features down into lower-level stories to get assigned to a team in a sprint.
Q: What is the relationship of product manager to the release team? In scrum, POs decide what features are most important—which also relate to what needs to be released first. What if the PM and release team clash?
A: The Agile release management team typically includes senior representatives from product management in order to alleviate conflict.
Q: How much time should product owners spend with their scrum teams?
A: The product owner is a member of the team, so availability to the scrum team is critical.
Q: Is the program backlog estimated in story points? If so, by who?
Q: Is the system team a QA-like team or a team of developers?
A: The system team is more like the team focused on providing assistance in building and using the development environment infrastructure: continuous integration, build environments, testing platforms.
Q: Are there any cheat sheets for the CA Agile Central reporting?
A: You can find sheets on CA Agile Central Reporting here.
Q: How can we implement Agile principles in a large platform, technology migration project where business requirements are not that much different from business as usual.
A: Agile practices and principles initially come from a "build the thing right" viewpoint. Decreasing the cost of individual changes and improving the quality through incremental work habits generally creates improved relationships between the implementation group and the various stakeholders. This in turn sets up the relationship to handle future needs more effectively.
Q: What about an Agile application to a new product line launch, when the very first delivery requires high-level architecture solutions and 3–6 month of work for about 30–40 engineers. Time to market is the key.
A: Scaling Agile in that environment is critical to success. The focus created on features and epics allows much faster feedback and learning by the organization, increasing the likelihood of successful launch. Agile is very compatible with the enterprise Lean startup approaches, and are actually a prerequisite for success in most aspects. Create a laser focus on delivering the most important features and epics, even at the expense of less optimal team or feature mapping.
Q: How do you convince a program manager to scale Agile in an environment that only has one scrum team, with other teams that are one-person teams?
A: Look at this from a risk mitigation perspective. What are the risks to the organization's capabilities if you lose one of the people on the one-person projects? Team responsibility creates an opportunity for cross-training and risk mitigation. More importantly, teams allow an organization-wide reduction of work-in-process (WIP), leading to faster delivery of capabilities and improved focus and quality of the results.
Q: Is SAFe a CA Agile Central term?
A: No. SAFe stands for Scaled Agile Framework® (SAFe). It is rapidly emerging as the industry standard approach of scaling Agile in the enterprise.
Q: Can you have some Kanban teams (1–2 people) and scrum teams, all under the scope of a program?
A: That's how we tend to work in practice, although it's not an official component in SAFe. We generally look to teams with work who have a business-justified lead time less than 10 business days as potential teams for adopting Kanban or other continuous flow-based approaches.
Q: Can you apply Agile principles to maintenance projects?
A: We have seen some of the most dramatic improvements by applying Agile on a maintenance project. It is just as important to focus the team on the highest value work, maybe more so because there tend to be so many requests. It is just as important to use good design, quality and flexibility to allow changing priorities.
Q: Are there any case studies for SAFe being used in a data warehousing environment?
A: Telstra, an Australian telecom and CA Agile Central customer, has a public presentation here.
Q: I work in a non-software development team and have been trying to adopt Agile methodology for projects which run between 5–7 months long. Do you think this will work?
A: We see a lot of success applying Agile in a non-IT environment. A great example is CA Agile Central Software itself. We use elements of Agile in every department: accounting, marketing, sales, and the executive team. For many groups, scrum with its iteration timeboxes works well. When work is very uneven (big and small), or has a lot of specialization, Kanban works better. The key is to get focused on value, work in smaller batches, make work visible, build quality in, and enable self-organizing teams. SAFe provides a way to coordinate the work of many teams, so they can collaborate on a delivery.
Q: How does one absorb late-breaking change into the routine planning?
A: Late change is exactly what Agile is designed to handle. Teams at every level—team, program, and portfolio—must be empowered to make those decisions, and must develop the capability to make smart decisions about when to accept changes. Because in every sprint the team can handle new information, fewer changes are viewed as emergencies. That is, what used to be an emergency can now wait until the next sprint.
Q: With synchronized sprints, how do you get the right audience at each of the meetings?
A: The best approach is to have a combined demo. At CA Agile Central, in one hour all our teams can demo. Most of the company attends, at least virtually. Another company had a science fair model for demos, with stakeholders moving around the room to see the work that mattered to them. For planning at the sprint level, that may be too detailed for that audience; so it is better to have them at PSI or release train planning.
Q: Where do administrative teams fit into this model? These are smaller, focused on maintenance rather than new development?
A: If a team is too small—fewer than five full-time people—then scrum is too much process. That said, most true maintenance/administration teams don't use scrum but rather get more value out of Kanban. Kanban has the same focus on value, prioritization, collaboration, transparency and quality, but it does not use timeboxes.
Q: Please clarify the 10-week framework.
A: SAFe recommends that PSIs (potentially shippable increments) be 8–12 weeks, with 10 preferred. The logic is that you want it to be just a little less than a quarter, so that the results of PSIs can then feed into quarterly strategic planning at the portfolio and enterprise level.
Q: How do you manage releases where you have a mixture of Agile and waterfall, with one common release date, where integrated testing as a whole needs to occur?
A: Here is where the HIP iteration is key. Hardening is the time for integrated testing, which is usually done by a collaboration between the delivery teams and the system team. The key to success here is that the waterfall teams complete their work, including functional testing, when the scrum teams complete their last sprint. Then all work is integrated and tested during HIP.
Q: Is feature is a synonym for capability?
A: It may be. One of our customers defined capability with several defined features. A capability could also be a MMF (minimal marketable feature) or MVF (minimal viable feature).
Q: Explain how normalizing velocity is done and how it affects individual teams.
A: SAFe does talk about the approach of one developer or QA person = 1 story point per day over an iteration minus scrum overhead. There are many conversations and some controversy around normalized velocity.
Q: Is the system team a sprint team? What type of backlog items might this team have?
A: This is applied as both a sprint team as part of a single ART (Agile release train) or a team supporting multiple ARTs and own stories and tasks in each ART. Often the backlog items they manage include the infrastructure, continuous integrations, and end-to-end testing.
Q: Where are the requirements being defined? There doesn't appear to be a business analyst (BA) on the team. Also, what about shifting resources between teams depending upon stories assigned to the multiple teams?
A: Requirements are being defined and created at the feature and details of the user stories. The traditional role of business analyst is not defined in SAFe; however, we often see them take on the product owner (PO) role or align with the PO. We like to keep teams persistent, so we like to flow work through the teams.
Q: How would you apply SAFe with mixed Agile and waterfall based teams to the release train concept?
A: We have worked with some customers that started out with teams still using waterfall and aligning stage gates or features that they are delivering and aligning with the Agile portfolio and Agile teams. Many of these companies start to feel the pain of trying the mixed methodologies and ultimately look at ways to move them to scrum.
Q: Is there a reason that the release timeframe is 10 weeks and not shorter or longer timeframes?
A: The 10 weeks is roughly a quarterly release cadence. In SAFe, a tenet is to develop on cadence and release on demand. Therefore, they are using the PSI (potentially shippable increment) for the cadence and may release at any point if they are doing continuous build and deployment where a HIP iteration is not needed.
Q: How do you represent an architectural backlog in CA Agile Central?
A: In CA Agile Central, this architectural backlog is included in portfolio items, such as architectural epics, features, and stories.
Q: How do you deal with PSI releases versus actual product releases in CA Agile Central, since only one can be a CA Agile Central release?
A: We suggest using the CA Agile Central release as a timebox, aligning to the Agile Release Train. Then use tags or a custom field to track actual releases like v2.1, v2.2, and so on.