Scrum and scaled agile framework (SAFe)
I wonder if anyone here has any previous experience with SAFe?
There is an ongoing disussion about SAFe at our manging level and I am trying to comprehend all the different parts of SAFe, but I am not there yet where I can say I have a good overview over the SAFe landscape....
In SAFe the innovation and Planning Sprint is the end sprint and where the big realease planning event take place. But what should be included inside the innovation and planning sprint? When you look around online sometimes it is described as a "backup" sprint where things get done you did not have time for in the regular sprints, while other sites say big NO, NO to this, it should instead be used for planning, inovation, education and so on....
And if it only should be used to planning, inovation, education, what about review and retrospective? is this something you should do at the end of a innovation and Planning Sprint (as you would in a normal sprint)?
Is there anyone here who had worked with SAFe for a longer period of times, what was positve/negative with this way of working?
Thanks in advance
What do your company managers think about having an "end sprint" where "the big realease planning event take place"?
Do they have an appetite for a more agile approach to release management, whereby fully integrated and tested increments can be released every Sprint on demand?
SAFe is waterfall/RUP in Agile clothing. Also extremely heavy weight.
See these links instead:
Also, Scrum.org has a scaling class. See more here:
Well the management seems to like the idea of SAFe, I am just trying to understand it and read as much as I can about it and try to get answers to my questions
I will soon take a look at the links posted
Anyone who knows what to do with retrospective and review in a innovation and planning sprint?
Regardless of the name used to label a Sprint, work must be planned and a potentially releasable increment crafted that meets an agreed Goal. The Review should assess work that was completed or not completed, and the Retrospective should consider how the team process can be improved.
If these things cannot be done, or if any of them are considered to be irrelevant, then a Sprint can't be said to have happened at all...and calling it one even with a qualifying label would be a misnomer.
Well I do not feel like I have enough knowledge about SAFe to say that it is a bad or good "thing". I am still processing information ;) Regarding the links...
The things I have read about the innovation and Planning sprint raise more questions and frankly I do not know where to turn to get answers. I have not yet found s SAFe forum where I can ask my questions, the people I know that are interested in SAFe (including management) are also at the beginning at their SAFe journey and does not have the answers either.
Well I would like to have retrospective and review after an Innovation and Planning Sprint, but is this the SAFe way of doing things and if not, why? But is there anyone here that have used SAFe and how did you go about this type of sprint?
Thanks for your replies so far and I want more replies :)
In Scrum terms, a SAFe "innovation & planning sprint" isn't a Sprint at all. It doesn't meet the intent and purpose of a Scrum Sprint which I outlined earlier. It is a confection found in another framework (SAFe) which, confusingly, uses certain terms from Scrum but in ways that are not actually compatible with Scrum itself.
It's therefore pointless to ask what happens to a "review" or "retrospective" in a SAFe pseudo-Sprint such as "innovation & planning", because you are then taking Scrum practices (Sprint Review, Sprint Retrospective) and trying to apply them in a different and incompatible context. If you want to try and reconcile them, you must ask:
- what work is planned into an IP "sprint", and how is a Sprint Goal negotiated
- how does this "sprint" demonstrate value to a Product Owner
- how does it provide an increment that is cumulative and potentially releasable
- how is a Definition of Done applied to the work undertaken
- how is the work reviewed and the team process retrospectively analysed.
I suggest you direct your queries at SAFe consultants, or Dean Leffingwell who is the driving force behind the initiative.
ok thank you for your time, I now know this was not the best place to ask questions about SAFe, but I might be back to only ask about scrum (with no connections to SAFe)
I’m a little late to the thread, but allow me to share some of my thoughts..
A short while ago, our Team was having a group luncheon. The members were talking about a prior implementation, which I was not a part of. The conversation suddenly went into discussing fruits and some of the statements baffled me.
After interjecting, it was explained that when multiple teams were talking about a Server or a System, they were talking about different ones, using the same lingo and verbiage! This led to massive confusion, so they decided to temporarily address the Systems with the name of fruits. E.g. “We have a 2-hr. window with pineapple over the weekend.”
Over the years, it seems that how we address certain terms have seemingly evolved or have a different meaning. E.g. for someone like me, even a “standup” and the “Daily Scrum” has a different connotation – this leads to a momentary pause to ensure I’m understanding the situation.
As a SAFe SPC, as well as a Scrum practitioner. I have worked with single Dev Team(s) as well as multiple ones at the program level. We did not use SAFe or LeSS or SPS (introduced Dec. ’14).
Without going into SAFe, I’d like to bring out some of core Scrum (based on the 2013 Scrum Guide) which may help bridge a gap and continue the dialogue.
A “Sprint” encompasses of Planning, Daily Scrum, Review and Retrospective. The Team refines along the way.
A Sprint always ends with a Review and a Retrospective.
Release Planning and Velocity are no longer formal entities in Scrum.
A Product Owner is empowered and can release the increment ad hoc.
The increment is a potentially releasable product.
There are no “hardening” (not in SAFe) or “innovation” or “planning” sprints in Scrum; Interpretation – The goal of a select Sprint **could be** innovation!
@MG – you’re doing a great service to your peers, management and Organization, exploring the language and subtleties in the world of agility. I haven’t answered your questions directly, but hope some of the thoughts may help, or raise questions for others reading.
> and frankly I do not know where to turn to get answers. I have not yet found s SAFe forum where I can ask my questions,
You've hit on something here. The reason that there is no forum is likely because the SAFe people aren't interested in helping people, they are more interested in making money. That is why they "require" you to come to their training classes in order to get certified and get the inside scoop on SAFe. Leffingwell, the SAFe head guy, comes from an IBM/RUP background where sales and money is way more important than helping people.
Take a look around, how many books on SAFe are there? Who besides Dean Leffingwell profits from them?
Have you noticed how the SAFe web site is completely trademarked and locked down and how you are unable to post info from their web site anywhere else?
It's about sales and money... So, in Agile Manifesto terms... they value making sales and money....over helping people in IT deliver value.
I'm sure they would say the opposite, but I suggest that the proof is in the pudding.
I had my first contact with SAFe about 2 years ago. I had started(!) understanding Scrum for real and had no clue what SAFe was about. I just stumbled over it.
I started scanning through some of their articles. I found they contained a lot of thruth and were well written. I really liked the site for that reason.
While reading on and on, I started getting confused. For all the reasons given above, I discovered that SAFe uses Scrum terminology but at crucial points meaning something very different. I came to dislike the overall package.
I still find things in those articles today that ring true to me and that I appreciate for how they are written. And I keep in mind that the overall package is not for me. That I do not need to attend a SAFe course in order to get to all those little details they kind of skip over in those articles :)
Maybe your experience will be a similar one.
From my experience with SAFe, you shouldn't approach it expecting pure Scrum. In fact, their version of Scrum is officially called ScrumXP, containing 'developers and testers', not just 'developers'. It's apples and oranges. Some of their ideas collated from lots of good practices are useful to bring to Scrum so it's still worth reading up on. I would personally prefer IP sprints to be integrated into regular sprints in smaller pieces - 'now, thou shalt innovate!' SAFe is inspired by Don Reinertsen's product development flow theories and lots of Lean ideas built in - in fact I would call it the Scaled Lean Framework because it is more aligned with Lean values than the Agile Manifesto. Kanban makes sense at portfolio and program levels and explicit Lean roles for management are all good ideas I think. I wish they'd call the ScrumXP something else though. Like I say, apples and oranges.
To help your thought process MG, and going back to the roots of SCRUM, SCRUM is an empirical process i.e. plan / do / review and information is gained by observation rather than prediction.
I’m keen to know how large your organisation is. I have worked in extremely large organisations spanning continents and any scaling framework that brings predictability, transparency and explicit roles to a sometimes “chaotic” world is welcomed. This in turn will begin to increase trust between business and IT which is value in itself building a much needed rhythm. This is just the beginning and the fact that your organisation has identified the need for a framework is a great start. You can then inspect and adapt the framwork to your organisation - SAFe does allow for this.
I also feel that certain processes work better than others at different levels of the organisation and if we have a view of how these will “mesh” together could be of added value depending on how your organisation is structured.
I’m not a certified SAFe consultant, in my opinion the IP sprint resembles to that of a “hardening” sprint as already mentioned in this post. When using any scaling framework make sure it is used as intended as it can be abused and in this scenario you risk the IP sprint allowing for unwanted behaviours such as being the “dumping ground” for any incomplete features or “bug” fixes ignoring the core principles of Agile. For it to be successful you need to have an Agile PMO function in your organisation that allows for effective use of the framework as intended, believes in and supports the core Agile principles, inspect and adapt as the organisation grows.
From my 2 year experience with SAFe, thinking it as Scrum would certainly lead to confusion.
In some way, the framework is more lean towards DSDM where certain degree of planning, predictions and team structure is present unlike Scrum. It is the structure and transparency of this framework that inspires senior management as it resembles traditional company structure with different functions. From experience, it's the portfolio vision of SAFe which creates the temptation in this framework, at least the company I worked for did.
The Scrum part of this framework lies within the Agile Release Train (ART) where it is more a wrapper for multiple Agile/Scrum teams. It is not necessary to adopt ScrumXP as prescribed. The Team Backlog is essentially the Product Backlog in Scrum. So pure Scrum is achievable at Team level within ART.
The Program level is essentially an Agile/Scrum team with main focus on business only with product owners serving as developers.
Now to answer MG question, there are two parts to Innovation and Planning Sprint.
As strange as it might be, it is for the development team to explore whatever they like which might help in future development. It can be research in new technologies or methodologies. These are demonstrated at the end of Sprint to others. Personally I find this useful as it release stress build up during other Sprints and provide further growth in development teams. There can be surprises at times.So you can this of it as "free time" for development team.
This is referring to release, inspect and adapt planning activities for Program increment. It can be viewed as "release to production". As I remember, these activities are not optional for SAFe framework. So whatever Agile development framework is used for software development, this still needs to be factored in. Last minute refinements are done at this stage.
It is easier to understand if you view IP Sprint as a Program focused Sprint for preparation of Program increment instead of Team focus Sprint.
A few years ago, members of the Dev Team wanted to spend a little time each Sprint in innovative activities, trying to streamline existing or find new solutions. After discussion with the PO, this was acceptable and had value.
We took on some of this in the sprints ahead (agreed percentage). Also, the last sprint of the calendar year was light so the Dev Team did more at this stage. Note: There wasn't a scramble to fix known bugs, address technical debt, etc.
There weren't any labels as "innovation and planning sprint" Etc. Instead, we articulated it in the goal, as best as we could and everyone was happy in the weeks ahead.
Has anybody passed in the exam for Scaled Agile Framework certification?
I would like to have an idea on how I could start studying in order to achieve this certification, please.
Thanks a lot!
Hi Vanessa, I don't know if they have a exam for that...the SAFe framework seems not really agile...Almost everyone I come in contact with about the subject tell me the same.
Some very smart people on this forum share the same sentiment when it comes to SAFe.
You are better of doing Scaled Professional Scrum, Nexus
For the SPS, you have all the resources right here at scrum .org. Follow the prescribed study material and you should be fine.
While I truly admire the lightweight Scrum, I won't ignore SAFe just because it comes from RUP gang (aka not the sigantories of Agile Manifesto).
As someone who helps different teams that apply Scrum only and some apply SAFe, I wanted to say something from the ground:
1. What is not good about SAFe:
- Money mindedness is definitely there. SAFe implementation starts with 'Training for All.' Only SPCs / SPCT can train others. For SPC, you need to spend min of $3000. And then you have to pay $800+ / annum (yes, that is correct!) for renewal. 'Training for All' requires each one applying for SA / SP / SSM with their own 'money' and 'annual renewal requirements.
- It scales to a normal portfolio of a company. But If the company is more complex, for example- many company wide cross functional initiatives / not so much product oriented, SAFe gets clumsy. I have seen DAD working well there.
- Variety of roles that can be misused by the hierarchy management. It is not possible in Scrum because Scrum has clearly defined rules around required roles. SAFe DOES NOT MAKE IT CLEAR ANYWHERE what are mandatory rules.Though not intended that way, I have seen existing managers insert customized roles in each layer. Same customization goes for the artifacts too.
2. What is good about SAFe:
- SAFe heavily leverages good principles from Lean (mostly from 'principles of product development flow'). For example, FLOW is a big concept that is not explicit in Scrum.
- SAFe is able to correlate to existing enterprise way of working and help the transformation team to identify the sweet spots to start the SAFe transformation. Along the way, SAFe touches upon typical functions of enterprises such as Finance, HR, Legacl, etc. in an effort to guide them. Scrum is still resonating as a 'from scratch' garage teams. No serious guidelines have evolved in Scrum circles about applying that to existing enterprises.
3. Innovation and Planning iteration:
Contrary to many explanations in this thread, IP iteration is a break away from 'doing the work' to 'finding ways to improve the way of working - a larger 'action-oriented' retrospective.' Though originally intended as 'Hardening' iteration - it was also named that way HIP iteration - IP iteration is welcome window for the team to try hackathons, innovations to bring in automations, tools, improvements that are 'paid'.
One of my teams takes this time to create technical prototypes to communicate about their business ideas (in most cases, they know the problems better), present them to product VP and get them funded for next planning cycle. It addresses two of the problems that I see with Scrum:
- A tangible activity by design to bring up the team's bottom up intelligence
- The possibility of Scrum Teams ending up creating only incremental improvements (IP iteration has better chance of disruptive innovation)
BOTTOM LINE is:
- we can't ignore SAFe. It has some good things. As Scrum community we should be open to explore before shutting it down.
- However, I strongly hate the money making attitude of SAFe group and their consultants. When you talk to some of the SAFe consultants, it sounds like they are in a 'cult.'
Here is a way to learn SAFe without paying for expensive training:
- A super quality short book on SAFe is Get SAFe Now (https://www.amazon.com/dp/B01M1GI80M). This is pretty neat alternative to the training most of which are slides to death.
- After the book, you can explore the content in the scaled agile framework website.
In SAFe - 'Innovation and Planning' sprint; is making room for innovation consciously. This sprint is used for subsequent planning, and innovation hacks. Retrospection to improve ways of working can also happen during this sprint.
In my opinion; making space consciously for innovation is a good practice. This should be utilized for thinking and bringing in new ideas; rather than planning. Backlog refinement should be a continuous activity; all teams should leave some capacity to continuously refine backlog for subsequent release / sprint.
The below article gives quick steps to understand Essential SAFe framework:-
In my opinion; making space consciously for innovation is a good practice.
Making space for innovation continually, each and every Sprint, might be a better one.