You Asked, We Answered

We’ve compiled answers for questions asked during our Opportunities for Project Managers in the Lean-Agile Enterprise with SAFe® webinar. Please click on each question to view the answer. If you have any additional questions or would like to speak with someone regarding your Lean-Agile transformation, contact us and someone will be in touch shortly.

Stories are short descriptions of a small piece of desired functionality, written in the user’s language. Similar to requirements, but with less detail, as we want to promote active and ongoing conversations about the requirements and not depend on static requirements documents, which are often out of date as soon as they are written. For more detail, please refer to our Stories article.
Absolutely. The RTE is not a technical lead role, and project managers have many of the requisite skills that are important for being a good RTE. This role is about facilitation, coordination, and following sound processes for healthy Agile teams and trains. You can read more about the role in our RTE article.

DevOps is a set of principles and practices that extend Agile beyond the development team and into the parts of the organization that run the operational, infrastructure, and even support activities around the systems that developers build. It focuses on building a more continuous flow of new functionality and value by having those traditionally siloed functions work together, plan together, and improve together.

There is an entire body of knowledge around DevOps, and some great books such as “The Phoenix Project” and “The DevOps Handbook” that you might want to explore. You can also get started by reading our DevOps article.

We look to some of the best thought leaders in change management, from John Kotter, to Chip & Dan Heath and others, to address the significant change factor that occurs in an Agile transformation. A lot of that change management guidance is built into our recommended Implementation Roadmap for SAFe adoption article.

*Note that there are sub-articles for each step in the roadmap, so this is a deeply addressed topic in SAFe.

Similar to the answer to the previous question on change management, our Implementation Roadmap article contains guidance on the best patterns to support individuals and teams as they adopt these new ways of working. Providing sufficient training, coaching, and leadership support are the most important steps to completing and sustaining the change over the long term.
The best way to learn how each of the roles at each level differ, as well as the skills and training required, is to go to our Framework website and read the role-based articles at each level. The are generally found on the left hand side of the Big Picture graphic and have people icons that indicate there is an article about a specific role.
Every organization is different, but we address some of the more common patterns we see in our article on the Lean-Agile Center of Excellence.

Not per se. Each role has a corresponding SAFe role-based course that individuals can attend and complete the certification exam that accompanies it. This sets a baseline of knowledge and understanding related to that course’s learning objectives. In terms of assessing someone’s other abilities to perform specific roles, those judgments are largely subjective, and determined through each organization’s placement process.

We provide guidance on the attributes that we typically find in people successfully performing each role in our role-based articles on the Framework website, which can be useful in evaluating candidates for specific roles.

In the Agile world, there is the concept of “done-done”… meaning that the piece of functionality is fully completed, tested, document, verified against the acceptance criteria written by the PO, and potentially shippable into production. Teams and Agile Release Trains (ARTs) often have written “definitions of done” in the team space as a reminder of the team’s and organization’s agreements on what constitutes “done.”

If your organization has or is considering an Agile initiative, the easiest path is to meet with your supervisor or HR department to explore opportunities to assume a role in that effort where you can gain experience with this new way of working. If such an effort is not yet underway but you see areas where one could begin, perhaps you could be the change agent that proposes a pilot or prototype to see if it would produce better business results for your organization.

If all else fails, you may ultimately need to find a position with another organization that understands the value of your PM experience and your desire to translate that background into a role as an Agile practitioner.

As defined in the Agile Manifesto, Agile was designed as a new way of working for individual software teams. Scaled Agile incorporates those team level practices and adds other patterns and roles for very large organizations with hundreds, sometimes thousands, of practitioners and many teams working together to build very large, very complex solutions. Scaled Agile also addresses not just software development, but cyber-physical systems engineering, product management, and portfolio management. Basic team-level Agile models such as Scrum and Kanban by themselves do not address these concerns.
Fortunately, the patterns are not really that different. In a service industry, the service is the product. We find that service teams tend to lean toward Kanban and flow-based ways of organization work over Scrum, and some of the traditional physical product practices may not apply. That said, the Framework still provides significant value in a services world for healthy Lean-Agile mindsets, values, principles, roles, and many of the practices.
Product Owner is a great entry point into a Product Management role, so you may want to explore the opportunity to start there, gain experience, and move into a Product Management role over time.

It is being phased out in the fast-moving, innovative, disruptive technology programs where there are high degrees of uncertainty about the final solution or the steps required to get to a release-able product. In that context, an empirical model is more appropriate than the defined process model that been historically promoted in PMBOK. It’s essentially the iterative, incremental, scientific model that has been used in R&D for decades. It’s only in the last 20 years that technology professionals have come to the conclusion that the empirical model is a better fit for the inherent nature of their work.By the way, where the work to be done is well defined, well known, highly predictable, etc., the traditional project management practices still work great!

A properly-formed Agile team should only have one Product Owner (PO) at any given time. The PO has a responsibility to ensure the team’s backlog is properly defined and prioritized so the team can pull the next most important piece of work as they have capacity. Multiple POs at the same time is a terrible anti-pattern that never works well!

It is true that over time, as the focus of the work in the backlog for a team shifts from one system or domain to another, a new PO with more experience in that area may be required. The PO may also draw upon Subject Matter Experts (SMEs) to supplement their own knowledge, but ultimately they have the responsibility to decide the backlog items and priority. This is a critical element for decentralized decision making and self-organizing, which is fundamental to all Agile methods, including SAFe.

Contact Us