1. business and industrial
2. business operations
3. management
4. project management

Q&A
AgileLIVE Webinar
Scale Agile Faster, Easier, Smarter with SAFe® and VersionOne
Part 1
April 29, 2015
Q. Some people think that not all skills are required in a team (cross -functional
teams). What is your suggestion in this regard: should all members be available /
part of the team from day one?
Of course, it depends. A cross-functional team should contain the majority of the
skills necessary to define-build-and-test a capability of interest. But specialty
skills, UX, DBA, security, etc. can also be required regularly, or on occasion.
Whether they are dedicated to a team or not depends on depth and need of
specialty. Each team is tuned to its specific circumstance. And of course, the
Agile Release Train provides a home for these specialists, where it’s easy to work
with whatever team needs the help.
Q. Can you elaborate on what you mean by “team of agile teams”?
The Agile Release Train is composed of multiple agile teams, and some additional
skills such as product management and the release train engineer. They work
toward a common mission. That’s a team of agile teams.
Q. Have you come across “fake agile” organizations, which say all the right things, but
do and act differently? What are your top three ideas on how to help them?
Unfortunately, we see it frequently. The “easy button” for some is to adopt the
terminology and labels, not the practices that implement the fundamentally
different way of working. Top three ideas: 1.) train leadership; 2.) train
leadership; and 3.) have them train others.
Q. Should the product owner be co-located with the team?
The product owner should be co-located with the team wherever possible.
When that is not practical, they should be located with the teams during the PI
planning and inspect and adapt events.
Q. What are consequences of not having an architect co-located with the agile team?
Rarely is it the case that an architect is dedicated to a specific team. Teams are
small and can design their own elements of the system. The architect is needed
to provide technical strategy and governance across the system being built by
the ART. Sometimes they will co-locate with the system team, but rarely are they
dedicated to any one team, except in short bursts while attacking specific
problems.
Q. Is it okay that user stories are made by team members rather than product
owners?
Absolutely, every team member can write user stories and acceptance criteria.
Otherwise the product owner becomes a bottleneck. But the product owner has
the responsibility to prioritize the backlog, with input from the teams of course.
Q. Please say more on “decentralize decision making.”
This is well-elaborated in the guidance article “Decentralize Decision Making” on
SAFe LSE.
Q. What is the definition of SCRUM XP?
This what we call the two-day SAFe course that SAFe Program Consultants (SPCs)
use to train agile teams around the world on Scrum, XP, Agile, and Lean. You can
learn more about it here.
Q. Wouldn’t you agree that cultures have changed unintentionally through
outsourcing, MSPs, etc.? It is not my experience that this was part of a
management decision to go agile, but the desire for agile is an after-thought. It
would seem to undermine the value of employees and a commitment to “least
cost.” How do we refocus management on the first pillar? Is management even
aware of the culture they have created? Is there an agile assessment tool for
‘leadership / cultural maturity’?
There is no question that cultural changes occur through outsourcing. Actually,
cultural change occurs with any material change. There is no substitute for
leaders understanding the impact on culture. We have recently provided some
thinking points for this in the new House of Lean and in the Leadership module in
Leading SAFe. There is no lean leadership/assessment tool that I am aware of.
Q. You touched on it earlier, but can you make summary comments on any financial
principles you have to bring to clients to enable SAFe long-term? Thinking in terms
of opex/capex planning and how companies fund work.
Lean-Agile budgeting is a specific topic in 3.0 of SAFe. Capitalization is a guidance
article. These are often significant discussions during SAFe Program Consultant
(SPC) Training.
Q. Can we use this framework for ERP implementation?
There is a case study to that effect: The Royal Melbourne Institute of Technology
applied SAFe to a PeopleSoft implementation.
Q. Do you have a set of best practices for distributed teams? Do you have any failure
cases that persisted to eventual success? I want to anticipate obstacles.
Agile Release Trains are usually distributed, as the flow of value typically crosses
functional and geographic boundaries. Distributed individual teams are a harder
problem. Of course they are sub-optimum, but there are other factors, for
example the simple practicality of having the right skills, so awkward cases are
not uncommon. Be careful that the purity of intended approach doesn’t inhibit
the move to agile to begin with. You just do the best you can and co-locate every
time you can. Most larger enterprises start to evolve quickly to co-located teams,
simply because it’s easier to deliver value that way.
There are no failure cases that I am presently aware of, but of course it will
surely happen, just like with Scrum, Agile, XP, and every other method from the
present and the past. There can be no solution that addresses the challenge of
every enterprise in every way. In cases where there is a slow start, the “largely
required” leadership training via Leading SAFe is the accelerant to success.
Q. I am from IT, and I want to check if we can compare Scrum of Scrums and SAFe in
any way.
Simply, Scrum of Scrums is a single ceremony that helps teams coordinate their
efforts to a larger goal. SAFe is a complete framework of guidance for Team,
Program, Value Stream, and Portfolio-Level concerns. It covers roles and
responsibilities well beyond the team structure, including content authority via
product management and product owner roles.
Q. Are you incorporating elements of SAFe LSE into SAFe 4.0?
Interesting that you ask. Check out the new blog post: Major SAFe LSE Update
with Big Implications.
Q. Is there a program for start-ups who want to get associated with SAFe and be able
to provide training?
A number of interesting new consulting and training firms have entered the
market in support of Implementing SAFe. Check with the SAI partner program at
Scaled Agile Partners.
Q. I used to mix agile practices and TOGAF practices, such as capability and
requirements management. Will the next version of SAFe go in this direction?
The next release of SAFe will provide more guidance around applying set-based
design and model-based systems engineering, and fixed vs. variable system
intent. However, current Principles of Agile Architecture provide the only current
and anticipated architectural guidance. Most of the current architectural
frameworks, including TOGAF, assume a sequential stage-gate model, because
that’s what most of us were doing when they were created.
Q. Does UI/UX design happen during the iteration, or is it one step ahead?
In our experience, velocity is highest when an individual or small UX team
creates the wireframes, style sheets, design guidelines, etc. and iteration or two
ahead. However, the teams themselves need to actually implement the UX;
otherwise things go too slow. (See more on this topic here).
Q. Could you comment on different schools of SAFe – the one that you presented and
SAFe for Scrum Alliance – if there is one?
SAFe is the exclusive property of Scaled Agile Inc. We are discussing collaborating
with the Scrum Alliance to offer the SAFe course under the Added Qualifications
program.
Q. What's your opinion about large programs that are not mostly developing
software but adopting/adapting out of the box systems?
The basic principles of SAFe, cross-functional agile teams, cadence and
synchronization, and the principles as highlighted here apply in a wide variety of
system, product application and solution development settings. Also see the
RMIT case study.
Q. How do we factor those costs/efforts?
Not sure what costs you mean. However the primary cost in a change such as
this is training in the new way of working. SAFe training has a virtually immediate
ROI with SAFe, Lean-Agile, and Team Agile. You can’t expect people to do things
differently if you don’t train them.
Q. It’s very difficult to change the waterfall mind-set in people who are still working
on that model from 20-30 years ago. How do we make them adaptable to agile?
It always starts with leadership. Each SAFe initiative starts with leadership pull
and support for extensive leadership training, via Leading SAFe.
Q. It was mentioned to get “common estimating”... how is that achieved when you
have many “agile teams” doing their own estimations, and those estimates seem
to be valuable at the “team level”?
Many have addressed this problem in different ways. Where teams need to
cooperate on estimating larger work, a common approach must be used. SAFe
starts teams off with a capacity-based first estimate, which evolves to the more
general story point velocity. But since the starting point was the same, the costs
of a story point doesn’t change materially over time. You can read more about
that in Iteration Planning
Q. How do you handle product level when some teams are agile and some waterfall,
including internal and vendor teams?
We don’t have a model for an Agile Release Train that has some agile teams and
some non-agile teams. However, ARTs can interoperate with non-agile
customers and suppliers. Here are two guidance articles to that effect:


Mixing Agile and Waterfall Development
Mixing Agile and Waterfall: Technical Strategies for Interoperability at
Scale
Q. So fundamentally the organization must be mature in Agile/Scrum before moving
towards SAFe, correct?
Not at all. Most of the large rollouts I’ve personally been involved in have little
experience with Scrum or Agile. Of course, there are usually pockets of agility,
which help immensely. Most of the case studies on the site represent significant
enterprise transformations where there was no or little experience with Scrum
and Agile. Scrum and Agile come along for the ride with SAFe.
Q. How do companies deal with PI planning with hundreds of people with multiple
trains?
This happens all the time. That’s the routine case for agile at scale. This is
discussed fairly extensively in PI Planning. The SPC Training and Certification
class spends far more time on these topics, and includes agendas for multi-site,
distributed, concurrent face-to-face PI planning.
Q2: Let us say we have some issues while integrating between ARTs. How do we
resolve those issues? How do we take care of code refactoring, and in case that
takes too much effort or time, impacting and impeding release speed?
If you arrive at that circumstance, then there was insufficient Architectural
Runway available to build on. A combination of Architectural Runway, Vision and
Backlog, two-week system demos etc., should help mitigate the risk of late
integration discoveries.
Q. What (if any) Lean training/experience is needed to push forward with SAFe? My
organization is already Scrum/Agile versed.
We recommend the Leadership Training, and then at least a re-baselining class
to establish what Scrum or Agile means in the context of SAFe. As you know,
there are many forms of Scrum and as taught, terminology differs on concepts
such as backlog items, user stories, definitions of done, etc. Plus software
engineering practices like test-first, continuous integration, pair work etc. vary
widely from team to team. So adopting a common view of what agile means in
the context of SAFe is an important program-level optimization.
Q. The percentage allocation of train team members seems like it should be 100%. Is
that optimal/realistic?
Simplest rule: an individual is on only one team. A team is on only one train.
Then work the edge cases as necessary. Sometimes the ScrumMaster, or product
owner, or perhaps a specialist, supports more than one team. However, the
more multiplexing from team to team, the lower the velocity.
Q. How do you deal with resistant middle managers (or above) in scaling agile?
Indeed, some will resist change, and this is a big one. We reach the tipping point
by training leadership in Leading SAFe. That moves the needle to the point
where most are on board, and they in turn will solicit the support of others who
are not so sure, or don’t want to go. As John Kotter notes, “to change the
culture, you have to change the organization.”
Q. How can a two-week sprint include a full system test? Our test cycle is more than
two weeks.
This is a journey of many steps. Initially, SAFe sets the bar such that a full System
Demo needs to be accomplished in the sprint following the current one. When
that can’t happen, then risk is deferred until too late in the PI. When that can’t
be accomplished initially, the teams evaluate the root causes, and start to
reduce the overhead of the test and integration process with build and test
automation, etc. until it can be accomplished. Of course ideally, the team can
integrate the full assets set in a heartbeat, buy the real world is far from ideal.
You have to be practical about these things, without losing sight of the goal.
Q. By “resource,” do we mean people?
It depends on the context. Many managers and executives refer to the general
case of cap ex, facilities, departments, suppliers, etc. and yes, even people, as
resources. It’s a common and useful term. And of course, most organizations
have a human resource function, so resource is not a pejorative term. I know
some take offence at the term and note “we are people, not resources.” But
seriously, everyone knows that, and any such discussion usually just annoys the
people you need to help make the change.
Q. Several statistics show that culture is the main barrier to agile adoption, but Dean
said the culture comes last. I'm little confused about that. How does one start to
change or influence the current organizational culture? What is the senior
management role here?
Culture is a broad term. John Kotter’s seminal work has taught us that culture
represents the habits of the organization. Habits are hard to change. They don’t
change with a sign or slogan. They do change as new ways of working start to
deliver benefits to those who do the work. That’s why cultural changes trail
significant change management initiatives.
In SAFe, we focus on two areas:
1. Training leadership in the new values, principals and ways of working, which
can certainly start a cultural change, but it won’t persist unless and until
teams and programs are more successful in delivering results.
2. So the next focus is on delivering value, one Agile Release Train at a time.
Q. What kind of targets are set for SAFe Program Consultants (SPCs)? In other words,
how could they take responsibility for the results?
SPCs can’t deliver results by themselves. Only the teams can do that. If I were
going to evaluate a SPCs success, I wouldn’t try to measure the SPC, I would look
at the business results they have been able to help teams and ARTs deliver.
Q. I’m an agile coach that has led one Scrum team to completion. We’re preparing for
the second team. The CIO has bought in, but the culture is thick here. Is
considering SAFe appropriate to look at now, or should we do a couple more agile
projects to let some additional folks experience a different way... hopefully making
them a little more open?
I never recommend waiting for the business benefits to happen “later.” SAFe
works. The results are in the Case Studies. And SAFe is big enough to enable and
require extensive change. Sometimes you need that. Time is of the essence. The
competitors are moving to agile. How long can the business afford to wait for
better results?
Q. Is it possible to implement SAFe in all the teams, or is it better to do form one
team at a time?
A single Agile Release Train is the smallest instantiation of SAFe, and a great
starting point for many. But all teams on the train, and all individual teammates
on the train, must engage in the agile process in order for the team and train to
succeed.
Q. How can you change to an agile organization, when the organization has still to
deliver software? It is like you are rebuilding a fast moving train while it is on the
track.
Creating cross-functional teams, providing agile training, aligning the teams to a
common mission, and eliminating barriers to success is virtually always an
accelerator of productivity. Improved results can happen within the first few
weeks of launching a train.
Q. In adopting SAFE, who are the key leaders for a successful process in a software
development company?
Of course you need executive sponsorship. But we find that first line and middle
management hold the practical keys to success. Start there with Leading SAFe.
Q. How do you flip a company from using a resource management organization
whose job is to assign people to projects to an agile model of dedicated teams
(fixed resources) and managing the work flowing into the team?
Generally, one Agile Release Train at a time. In my experience, it can take years
for an enterprise to evolve to a more value-based organization. But you can’t
force that. It will happen as you pivot to delivering value with one or more virtual
ARTs, and the enterprise starts to see an easier way to meet customer
requirements.
Q. How do you advise a waterfall resource to get up to speed with agile and its
different flavors?
Read the website. Train the leaders in Leading SAFe. Train the teams in SAFe
Scrum XP. They will take it from there.
Q. In a multi-vendor teams including virtual teams, how can SAFe be made
successful?
The Agile Release Train is a virtual organization that can wrap various teams,
virtual or physical, internal or external, into a common working model and
common mission. The rules are the same, no matter the source of the paycheck.
Q. What is your recommendation for teams that use off-shore resources (vast time
zone disparity)?
There needs to be some core hours overlap, which may inconvenience some
people on both sides. Sometimes the roles rotate to make sure the pace is
sustainable. But most people I know would rather have the satisfaction of faster
delivery, and trade off that inconvenience. And of course, you don’t have to
synchronize that way, you only have to do it if you want to go fast.
Q. How do we deal with technical debt in SAFe?
Technical debt is part of every product that is delivering market value. The
question is how much, and how to handle it. SAFe provides the construct of
capacity allocation at the Team and Program Backlog levels.
Q. What about continuous training?
It’s hard to contemplate continuous training (but not continuous learning). SAFe
provides routine Innovation and Planning iterations, and many use that time slot
for ongoing agile training, based on the needs of the specific Agile Release Train.
Q. What is the SAFe burndown?
There is no specific burndown in SAFe, other than a mention of the traditional
Scrum burndown, which of course can be provided at both the Team and
Program Levels.
Q. How often do you recommend hearing about the latest and greatest SAFe
methodology changes?
Every material change is described in a blog post. Visit the SAFe blog here and
subscribe via RSS here and you will be apprised of all changes to SAFe. Every
material change is described in a blog post.
We also recommend watching the webinars that are posted when any new
version of SAFe or courseware released.
Q. Is Dean considering updating his book “Managing Software Requirements” in line
with the latest version of SAFe?
No, Dean’s latest publication is “Leading SAFe LiveLessons.” A new book, “SAFe
Distilled,” by Richard Knaster and Dean Leffingwell, will be published sometime
this fall.
Q. Would you recommend a good free (or really low cost) resource for me to continue
to learning about SAFe?
Of course, the entire Scaled Agile Framework is freely-revealed and publicly
facing. Just click and read. We also have a new video training available, “Leading
SAFe Live Lessons.” And Scaled Agile Partners offer cost effective training
worldwide.