Agile Certifications, part 3, what is right for me

This is a 3 part blog post:

Part 1- What are the common certs available here
Part 2- What are the strengthens and weaknesses of each cert here
Part 3- Which Cert is right for you (below)

The first two parts of this topic are sure to generate some healthy debate (and perhaps some unhealthy debate). This part is probably even more controversial. I look forward to feedback and a healthy debate. I also advise readers to understand this is one Agile community members view, and is not shared by all.

Which cert is right for me?

There is no easy answer to this question, as it depends on what you are looking for. As before I will break this up by certifying body, providing my personal view of who is best suited for each of the certs offered.

Scrum.org

website: www.scrum.org

Who should get their certifications:

Scrum Masters, Developers, Product Owners, team members, and other stakeholders whose goal is to become more effective at delivering.
Those who want to join an active community led by daily practitioners as opposed to trainers.
Anyone interested in learning about Scrum and how to be a part of or engage with a Scrum team.
People who believe certifications should be based on the validated knowledge of an individual (a test), instead of an individuals validated training hours or experience (attending a class or work experience)
Nexus specific:
- Interested in learning scaling techniques from one of the co-creators of Scrum

Who should look elsewhere:

Those looking for resume building. Scrum Alliance and their certifications are more known in the industry
Those looking for a certificate to put on their resume specific to scaling. While Scrum.org offers the SPS, the SAFe certs are more recognized for scaling agile today.

Scrum Alliance

website: https://www.scrumalliance.org/

Who should get their certifications:

Scrum Masters, Developers, Product Owners, team members, and other stakeholders whose goal is to build their resume
Those who have difficulty taking tests, but still retain the material (if you can’t retain the material, I can’t in good conscious recommend any cert).
People who believe classroom training is a critical part of a certification.
People who want to be associated with the largest certifying body in Agile.

Who should look elsewhere:

Those who are concerned a majority of CSMs did not have to validate their learning (with a test).
Those who are interested in scaling

Scaled Agile

website: http://scaledagile.com/

Who should get their certifications:

Scrum Masters, Developers, Product Owners, team members, and other stakeholders who are focused on delivery at scale of more than 50 people
- Also for resume building specific to large scale delivery
People whose organizations will be using a SAFe implementation

Who should look elsewhere:

Those who are focused on team level delivery or smaller scale (less than 50 people). SAFe offers some basics in team level delivery, but their strength and focus is on scaling.
- I personally feel, when possible people should start with Scrum and XP at a team level before scaling. This is not always possible.
Those who feel SAFe is to prescriptive or heavy. Personally I think SAFe WAS, but I feel in the last 5 years it has changed.

Large Scale Scrum (LeSS)

website: https://less.works

As I don’t know the framework well, or any practitioners, I am ill equipped to give advice on this one. Obviously if your org is practicing LeSS this would be a good fit. If you want to learn other defined approaches besides SAFe and Nexus to scaling, I suppose this would be a fair choice. I would personally appreciate some feedback on this one.

Project Management Institute (PMI)

website: https://www.pmi.org

Who should get their certifications:

People whose organizations highly value PMI and its certifications.
People who believe all certs should have training, experience, and a test.

Who should look elsewhere:

Those who want a widely recognized certification
Those looking to build their resume
Those who want to learn about Agile as it was defined by the creators of Agile

In full transparency, I personally have a PMI-ACP certification. I am troubled that many test questions were clearly written by people who had little to no agile experience. And that PMI is still learning what it means to be Agile. PMI defines things based on processes, inputs and outputs. This is one way to approach the world, but now how an Agilist does it.

Conclusion

There are many certs available on the market today. Which one is best for you and your situation depends on what you hope to accomplish. I would caution readers to ask themselves if the right answer is no certification at all. Regardless of what direction you take, I hope this series has answered a few of your questions.

Looking forward to a healthy debate.

Agile Certifications, part 2, what’s the difference

In the first part of this series we talked about what certs are available. This post will be focused on what the strengths and weaknesses of each cert are.

See the first post here

As before, we will review the strengths and weaknesses based on certifying body, as the differences between certs are fairly consistent across certifying bodies.

Scrum.org

website: www.scrum.org

Strengths:

Created and led by one of the co-creators of Scrum
Every certified person has passed a test validating their knowledge
Most trainers continue to be full time practitioners and part time trainers
Scrum.org continues to advance the study of Scrum
Is continuing to grow membership year over year

Weaknesses:

Started 8 years after main competitor Scrum Alliance. Has a smaller membership. While this is true, I think it is less important how big an organization is, and more important to focus on quality.
Nexus Specific and not the rest of Scrum.org’s certs-
- Nexus is new to the market, and still gaining steam. Evidence of success still coming in.
Some argue (though I do not) that since Scrum.org does not require classroom* training or experience hours for their entry level certs that their certs are less rigorous.

*Note- for entry level certifications, Scrum.org offers classroom based training through partnerships. However anyone able to pass the exam with or with out attending the classroom training can become certified for the entry level certifications.

Scrum Alliance

website: https://www.scrumalliance.org/

Strengths:

Largest and most recognized Agile certifying body.
Founded in 2001, has more members than any other Agile certifying body

Weaknesses:

For the first decade, passing a test was NOT required to obtain a CSM. Meaning a majority of CSMs today have not validated their Scrum knowledge
Scrum Alliance is often criticized as being to focused on training and not enough on the values of Scrum and Agile.
Internal challenges. Recently 2 board members of the Scrum Alliance resigned in a very public way citing their belif that the Scrum Alliance was not following their mission. This only a couple of months after 2 other board members resigned. Details here

Scaled Agile

website: http://scaledagile.com/

Strengths:

SAFe is the most common defined approach for scaling Agile.* (According to latest Vesion One Report )
SAFe certifications are the most recognized in the industry for scaling Agile
There are 27 available case studies, more than any other approach (here )
There is an entire framework, community, videos, blogs, books, etc available for free online

*Note: according to the Version One report the most common approach to scaling is “Scrum/Scrum of Scrums”. This is not a defined approach, but simply taking what is defined in Scrum and using the values and practices to scale.

Weaknesses:

Many Agile thought leaders feel SAFe is light on Scrum and team level delivery. I tend to agree, but understand that SAFe has used Scrum and Kanban as building blocks for scaling. SAFe is not focused on certifying team members on team level interactions, instead SAFe leaves that to Scrum and Kanban leaders.
Many Agile thought leaders feel SAFe is to prescriptive. I agree that when I first learned about SAFe 5 years ago it was. However, I think SAFe has come a long way since then.
SAFe is often criticized as being to focused on providing training, and not focused on delivering value.

Large Scale Scrum (LeSS)

website: https://less.works

Strengths:

Second most commonly defined approach to scaling agile according to Vesion One Report

Weaknesses:

Not widely recognized in my experience. I do not personally know anyone using LeSS at this time

Project Management Institute (PMI)

website: https://www.pmi.org

Strengths:

PMI is probably the most recognized certifying body in all of IT. Mostly for their non Agile certs, specifically the PMP

Weaknesses:

The PMI-ACP cert is not well recognized in the community. And doesn’t seem to be gaining much traction
Many of the PMI-ACP questions were written by people who had not worked in an Agile environment, and lacked a fundamental understanding of Agile
Most Agile thought leaders think that PMI is still struggling to understand what it means to be Agile

Again, looking forward to your arguments.

Agile Certifications, part 1, what’s out there

3 Part blog post:

Part 1- What are the common certs available
Part 2- What are the strengthens and weaknesses of each cert
Part 3- Which Cert is right for you

As an active member of the Agile community and an Agile practice lead for a sizable consulting company, I am frequently asked about certs. In this series I will review the most commonly available certs. This list will focus on the most popular, and many won’t make the list as there are simply to many certs out there. As always, excited to hear arguments.

I will divide the list up by certifying bodies, as I think the certifying body of a cert is important. In no particular order:

Scrum.org

website: www.scrum.org

Founded in 2009 by co-creator of Scrum Ken Schwaber. “Scrum.org provides comprehensive training, assessments and certifications to improve the profession of software development” – Scrum.org website.

Scrum.org’s most popular certs are:

Professional Scrum Master (PSM)- Entry level Scrum Master certification
Professional Scrum Developer (PSD)- Entry level for developers on Scrum teams
Professional Scrum Product Owner (PSPO) – Entry level for Product Owners
Scaled Professional Scrum (SPS) – Entry level for those who want to scale Scrum using the Nexus framework
Professional Scrum Trainer (PST) – Top level cert for those wishing to teach the other certifications

Scrum Alliance

website: https://www.scrumalliance.org/

“Founded in 2001, Scrum Alliance® is the largest, most established and influential professional membership and certification organization in the Agile community.” – Scrum Alliance website

Scrum Alliance’s most popular certs are:

Certified Scrum Master (CSM) – Entry level Scrum Master certification
Certified Scrum Developer (CSD) – Entry level for developers on Scrum teams
Certified Scrum Product Owner (CSPO) – Entry level for Product Owners
Certified Scrum Trainer (CST) – Top level cert for those wishing to teach the other certifications

Scaled Agile

website: http://scaledagile.com/

“SAFe is an online, freely revealed knowledge base of proven success patterns for implementing Lean-Agile software and systems development at enterprise scale.” – SAFe website

SAFe’s most popular certs are:

Leading SAFe 4.0 (SA) – Entry level cert for Execs, managers, and change agents who will be leading a SAFe implementation
Safe For Teams (SP) – Entry level cert for all stakeholders on a train
SAFe 4.0 Product Manager/Product Owner (SPMPO) – Entry level cert for Product Owners and Product Managers
SAFe 4.0 Program Consultant (SPC4) – Advanced cert for those leading trains and wishing to teach the entry level certs
SAFe 4.0 Program Consultant Trainer (SPCT4) – Top level cert for those wishing to teach the SPC4 class

Large Scale Scrum (LeSS)

website: https://less.works

“The LeSS Company was setup in 2014 with the purpose of promoting LeSS, offering certified LeSS training and promoting LeSS coaching.” – Less Website

LeSS’s most popular (and only) certs:

Certified LeSS practitioner – Entry level cert for those who will use the LeSS framework
Certified LeSS executive – Entry level cert for those who will be a leader on projects using the LeSS framework.

*In full transparency, I have not used the LeSS framework, nor am I familiar with the organization or the certification. I mention it here, as the framework has a 6% usage rate on scaled projects according to the latest Version One report on the state of Agile. Report here

Project Management Institute (PMI)

While the Project Management Institute (PMI) is not generally an Agile certifying body, they did add an Agile cert around 5 years ago.

PMI has many certs, but their only Agile cert is-

Agile Certified Practitioner (PMI-ACP) – This is an entry level cert for project managers and Scrum masters

Kanban Certs-

While there have been a few Kanban certs offered to date, none seem to be generally accepted or gaining traction.

Extreme Programming Certs (XP)

Currently there are no XP specific certifications that are widely recognized. Generally the Professional Scrum Developer (PSD) and Certified Scrum Developer (CSD) are recommended for developers interested in Agile (see above).

As always, I’m open to feedback from those who disagree.

How to get past “it depends” part 4

*See part one here

The fourth and final question we will tackle in this series is; “What is the best way to handle standups, when not everyone is available at the same time due to time zones?” This question comes up frequently with teams who have team members spread across the world. When there is no convenient time to hold a standup what do you do? First step is to come up with a few possible solutions:

Find a time that works, and make everyone come.
Hold 2 standups every day, such that everyone is able to attend at least one standup
Have everyone update a virtual board daily with their standup report

As we already know the initial answer is, it depends. Now let’s use the model to figure out the answer for your situation.

What are our constraints?.
- In this case, let’s say you have team members in India, Australia, Brazil, and California. You have talked to the team, and there is no time that everyone is willing to commit to for a daily standup. In this case, option one, “find a time that works for everyone is out.”
What are our goals?
- Are we focused on completing our work?
- Are we focused on delivering the project? (Hint, this is better than just completing work)
- Are we concerned with the entire organization’s delivery? (Hint, this is the idea)
- Are we worried about passing an internal IT audit?
- Are we worried about upsetting certain leaders?
- Do we want to be seen as cutting edge in the community?
- (We used the same list here, you will need to figure out what is right for your organization and situation.)
How does each of the options help us reach our goals? In this case, let’s say we settled on project delivery, organizational delivery, and being seen as cutting edge in the community.
- For project delivery we have to understand whether having a daily standup virtual board will help us deliver. Or will having two standups a day be more helpful for the team. Or perhaps it is a “yes and” where you do both? The question is what will help this particular team deliver in this particular circumstance?
- As for organizational delivery, in this instance let’s say we are unlikely to have any impact, so we can skip this goal.
- As for being seen as cutting edge, let’s say having both will best highlight our organizations leadership in the community?
Do any of the options have negative impacts?
- Does having 2 daily sprints interrupt some team members in the middle of their day? Will this interruption delay the teams ability to deliver?
- Does having to update a daily scrum board take to much time and effort?
- Does having both a daily scrum board and a standup mean to much overhead?

Again, once you can answer the above 4 questions, answering the initial question becomes a lot easier. Your decisions and direction should always be dependent on your goals and constraints. One should never blindly follow a model, including this one.

Now if you happen to see me in the community and ask me a question in the following format, I’ll be honored.

Given we have <insert constraints>, and our team is focused on <insert goals here> do you think our organization would benefit more from <option one> or <option 2>?

How to get past “it depends” part 3

*See part one here

The third question we will tackle in this series is; “Does every product backlog item have to be in a user story format?” I frequently get this question from people and organizations who have learned Agile or Scrum define requirements with User Stories. While User Stories are the most common way of defining requirements on an Agile or Scrum project they certainly aren’t the only way. I’ve never felt that technical stories made sense. After all, programs are not people and don’t have wants. Though there are plenty who would disagree with me. So I personally do NOT recommend something like the below (most of the time):

As an: application

I want: to have a connection to the database

So that: I can retrieve account information

However, we already know the initial answer is “it depends”, so let’s use the model to get to an answer for our situation.

What are our constraints?.
- Are there rules that your team must write all requirements in user story format? If you fail to do that what happens?
- Are there rules that force you to write things in non user story format? If you fail to do that what happens?
What are our goals?
- Are we focused on completing our work?
- Are we focused on delivering the project? (Hint, this is better than just completing work)
- Are we concerned with the entire organization’s delivery? (Hint, this is the idea)
- Are we worried about passing an internal IT audit?
- Are we worried about upsetting certain leaders?
- Do we want to be seen as cutting edge in the community?
- (We used the same list here, you will need to figure out what is right for your organization and situation.)
How does each of the options help us reach our goals? This time let us say we chose to focus on delivery of our project and not upsetting certain leaders.
- If not every requirement is in a user story format, will that upset certain leaders? If so is it worth it?
- If every requirement is in user story format will it slow down delivery by requiring people to spend more time fitting technical requirements into user stories?
Do any of the options have negative impacts?
- Will you fail an internal audit if you choose one direction or the other?

About these ads

Occasionally, some of your visitors may see an advertisement here

How to get past “it depends” part 2

*See part one here

The second question we will tackle in this series is; “Is a one-week or two-week sprint better?” As we already know the initial answer is, it depends. Now let’s use the model to figure out the answer for your situation.

While I generally advise against sprints longer than 2 weeks, one could use this same framework to ask whether a three or four-week sprint is the best fit.

What are our constraints?
- Does the organization require a weekly report and expect weekly velocity? If so, a two-week sprint might not be practical.
- Is it practical to get the entire team together every week? If not a two-week sprint may make more sense.
What are our goals?
- Are we focused on completing our work?
- Are we focused on delivering the project? (Hint, this is better than just completing work)
- Are we concerned with the entire organization’s delivery? (Hint, this is the idea)
- Are we worried about passing an internal IT audit?
- Are we worried about upsetting certain leaders?
- Do we want to be seen as cutting edge in the community?
- (We used the same list here, but you will need to figure out what is right for your organization and situation.)
How do each of the options help us reach our goals? In this case let’s say we decided on delivering our project and ensuring entire organization delivery. I suggest 2-4 goals, but your mileage may vary.
- If your expected to make frequent releases of every month or less, will weekly sprints help you quickly shorten the feedback loop, and use the learning from releases to make changes before the next release?
- If your infra team works on two-week sprints, will they be able to support your team every iteration if you change your needs in the middle of their sprint?
Do any of the options have negative impacts? Outside of your major goals discussed above, are there any negative impacts to one option over another?
- Will you receive push back from the enterprise for going with a two week sprint?
- Will your PO object to a weekly planning meeting?

How to get past “it depends” Part 1

As an active member of the agile community I am frequently asked questions about what is the right thing to do in a given circumstance. Such as:

Should we use Scrum or Kanban?
Is a one-week or two-week sprint better?
Does every product backlog item have to be in a user story format?
What is the best way to handle standups, when not everyone is available at the same time due to time zones?

In typical consultant fashion, the answer to these questions is: “it depends”. And what it depends on is the answer to additional questions. As a consultant, I’m more than happy to engage with your organization to ask the right questions. But as an agilist, I’d like to share a simple approach I have with the community, and help as many people be successful as possible. The approach is:

What are our constraints?
- This is the first question as often times you can rule out an option as simply not practical in the current situation.
What are our goals?
- Before deciding which of the remaining options that are available it is important to be clear on what group is attempting to achieve. Agile is a team sport, and answering these goals must be shared by the team or group. If the team can’t align on goals, than there are more important things for the team to focus on than which option is better.
How does each of the options help us reach our goals?
- Of the available options how does each one help team achieve the agreed upon goals? While there will certainly be disagreements here, framing the discussion in terms of meeting defined goals will lead to a more effective and efficient conversation.
Do any of the options have negative impacts?
- Outside of our core goals are there negative impacts that need to be considered?

Let’s apply this model to each of the 4 questions. We’ll cover the first question below, and the other 3 in future posts for brevity sake.

Should we use Scrum or Kan ban?

What are the constraints?
- Do we have stable team members and predictable work? Scrum relies heavily on rhythm, cadence, and predictability. If you are on a service team where new top priority issues can come in at any minute, Scrum would be a difficult fit. Similarly, if your teams availability is unpredictable because they have other obligations that can’t be reasonably predicted over the course of an iteration, Scrum might be a difficult fit.
- Do we have organizational constraints? If the organization requires reporting based on sprints and a retro, then flow based approaches such as Kan ban more difficult. If people in the organization are knowledgeable on Scrum and not Kan ban there will be challenges integrating a new approach including education within the team and across all the groups you need to work with.
What are our goals?
- Are we focused on completing our work?
- Are we focused on delivering the project? (Hint, this is better than just completing work)
- Are we concerned with the entire organization’s delivery? (Hint, this is the idea)
- Are we worried about passing an internal IT audit?
- Are we worried about upsetting certain leaders?
- Do we want to be seen as cutting edge in the community?
How doe each of the options help us reach our goals? In this case let’s say we decided on ensuring entire organization delivery and passing an audit as our highest priority. I suggest 2-4 goals, but your mileage may vary.
- organizational delivery: Would using Scrum or Kan ban affect other projects ability to deliver? Perhaps coordination and collaboration with other teams would be easier with one or the other. How would Infra teams be affected, and could they plan effectively with one Scrum or Kan ban? How would release management be able to plan and support releases with each option.
- Passing an internal audit? If you work for a large IT organization they likely have standards, and will often review your work to see if it meets the organizational standard. If you choose Kan ban or Scrum will you meet those standards? If not, can you collaborate with the audit team in advance to get an exception for your approach. Asking for forgiveness is not always the best approach.
Do any of the options have negative impacts? Outside of your major goals discussed above, are there any negative impacts to one option over another?
- Will using Scrum upset a leader in the organization?
- Will using Kan ban require a purchase of new tools?
- Will introducing a new approach into the organization add confusion and create more problems than it solves?

Once you can answer the above 4 questions, answering the initial question becomes a lot easier. Your decisions and direction should always be dependent on your goals and constraints. One should never blindly follow a model, including this one.

What are our constraints?.
What are our goals?
How does each of the options help us reach our goals?
Do any of the options have negative impacts?

Celebrate Failure

A former US submarine officer and Agile coach was talking with me about how to inspire teams. He told me about a pivotal moment in his career. He had recently joined a new submarine crew that was ranked one of the worst in the fleet. A short while after earning the privileged to command a watch, having only commanded a few watches before, they were doing a routine rise to periscope depth. As they were ascending, a new radar contact was spotted off in the distance. The protocol for finding a new radar contact while ascending is to perform an emergency deep. A scary procedure where a submarine descends as fast as possible, and the experience is similar to an earth quake where everything that isn’t bolted down finds a new location, usually on the floor.

The new radar contact was far off, and didn’t seem to pose a threat. But this officer decided to follow protocol and order an emergency deep. His crew initially questioned his decision, but followed his order. It had been years since the last time this sub did an emergency deep, and this young officer was ordering it with only a few watches under his belt. After a moment the crew followed this officers commands and descended as quickly as possible. Needless to say, everyone was quickly interrupted from whatever non-mission activities they were doing.

The captain sent his executive officer to relive the young watch commander and bring him to the captain’s radio room (office). Not sure what to expect, the young watch commander enters the captain’s radio room and prepares for the worst. The captain simply asked, “why did you perform an emergency deep?” and the young officer replies, “Because that is what the protocol states sir.” The captain says, “good job, I’m glad to have some one I can count on to do the right thing. You are my guy.”

This moment was critical to inspiring the crew. The captain certainly could have yelled at the young officer, but chose to support him. After that, things began to change on the sub. And within a 2 years they won awards for being one of the best subs in the fleet. The crew saw that if they did the right thing, regardless of the outcome, they wouldn’t be punished, and maybe even get rewarded.

Few of us work on projects where wrong decisions can cost the lives of 160 crew and billions of dollars. But the challenges are the same. There is always a temptation to hide failure, and do the wrong thing to avoid consequences. To truly inspect and adapt we need to see the truth, not bend the rules or paint a rosy picture. We can only get there if and when people aren’t afraid to fail.

If you see some one or a whole team for that matter fail, celebrate it. Thank them for their courage. Then ask how you can help them be successful in the future. The mood on the team will improve, collaboration will improve, and most importantly your organization will grow.

As always, I enjoy feedback, and especially relish differing opinions.

Dan

A Reminder of Why we Estimate

Estimates are simply a tool that enable people to make decisions. In a Lean-Agile environment we estimate so that we can predict how much something will cost, when we think it will be done, if we want to explore spending more money to complete it more quickly, and whether or not we should invest our money some where else.

In a Lean-Agile environment we do not use estimates as a goal. We do not use accuracy of estimates as a carrot or stick. We do not use it as a primary measure of job performance. Using estimates in these ways encourages teams to manipulate the system and reduces transparency. It creates push systems, where managers under-promise, and ensure their teams don’t over deliver to prevent having to live up to higher standards in the future. It encourages pushing sub standard work to production to meet objectives. And it ignores the fact that learning always takes place as the project progresses.

To use estimates in a Lean-Agile manner, look at where the estimates varied considerably from the actuals. Encourage and applaud leaders who have the courage to point out where estimates varied, and look at how to improve your estimates in the future. And above all else do NOT use estimates as a tool to hold people accountable, because it may have short term gains in a team who puts in overtime, but those gains will have long lasting impacts on morale and the interest of the team to challenge themselves in the future.

As always, I enjoy a healthy discussion, and look forward to any arguments.

An Argument for SAFe

*Note: Scaled Agile Framework for enterprises (SAFe) is the most commonly used defined framework for scaling Agile**. You can find more at: http://scaledagileframework.com/

Many of the Agilists who have been at it for a decade or more see SAFe as in-congruent with everything Agile is supposed to be. As the manifesto was being written in 2001, Agilists were called lightweight methodologists, as their delivery approaches were lightweight in nature. It was the manifesto that led them to take on the moniker Agile. And it is no surprise that with Leffingwell’s background from IBM he initially created a heavyweight process initially.

When I first had the opportunity to join a SAFe project in 2012, I read up on SAFe and was not impressed. SAFe was to prescriptive, to heavy, to rigid, and frankly the best part about it was that it used Scrum and XP as the building blocks. (At the time Leffingwell didn’t approve of Kanban at the team level, but that is a story for another day). And I’ll never forget, Ken France who was interviewing me said, “well if you don’t like SAFe, tell me what you think we should use to scale?” I didn’t have an answer, so I figured joining Ken’s team would be a great learning experience.

To be sure many of the things I was worried about turned out to be true, but there were also great things in SAFe that were new to me. A larger PDCA or OODA loop with the PI (at the time called PSI), Integrated Demo’s, clear delineation of product leadership, scaled planning meetings, scaled retros. In addition there were basic things most people created when they scaled, but didn’t have guidance for such as the Release Train Engineer, Systems Architect, and a roadmap.

Over the last few years SAFe has come a long way. The most important change is the attitude from Leffingwell and the SAFe leaders that all of the practices are customizable (the principles are immutable). Much to many people’s dismay, mine included, Leffingwell well chooses the word framework to illustrate the point that you can take from SAFe what makes sense for your particular situation. Whereas Ken Schwaber uses the word framework to say Scrum and now Nexus*** provide you an exoskeleton, necessary but not sufficient building blocks to deliver solutions. Regardless of the word selection, the approach is the right one.

Scrum and Nexus take the approach of providing some basics with which you add on to to create a methodology. With a heavy suggestion that none of the basics are altered. SAFe takes the approach of providing you an entire methodology, or everything you will likely need, then saying change or remove what doesn’t fit for your situation.

My suggestion is all Lean and Agile coaches should have a basic understanding of SAFe as it is the most commonly used defined approach to scaling Agile and Lean currently. From there, if you have a functioning scaled agile organization take individual practices and concepts from SAFe a la carte and incrementally if and when it makes sense to help your organization deliver. If you are starting a new program, or have decided to make a major transformation, consider SAFe against all the other approaches, and choose the what makes most sense given the current situation

Looking forward to the hate mail…

Thanks,

Dan

**Taken from the Version 1 State of Agile report. I do not consider “Scrum of Scrums” a defined framework. http://info.versionone.com/state-of-agile-report-thank-you.html
***Nexus is Scrum.org’s approach to scaling Scrum. https://www.scrum.org/Resources/The-Nexus-Guide