Agile Manifesto
The Agile Manifesto says:
“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.”
That means that Agile comprises of continuous improvement, people, collaboration, product delivery, customer collaboration and requirements change. If a framework calls itself “Agile”, it should fulfill those.
SAFe
First of all, I like Dean and the notion of having a solution for big companies that aids them in becoming Agile. If you don’t know SAFe yet, I recommend you visit http://scaledagileframework.com/. That website is very well designed and shows you detailed information on all aspects of SAFe in the so-called “Big Picture”.
In short, SAFe divides product development into three levels: Team, Program and Portfolio. Along with that go a couple of artifacts, roles and responsibilities. The devil is in those details (as of 11th of September 2013).
Team level
The Team level is basically standard Scrum. But wait: Not 100% standard I would say.
- The Product Owner is not necessarily responsible for the return on invest of the product. This is attributed to the “Enterprise Product Manager”. In addition, the PO should “participate” in the “extended product management team” and is usually part of the development organization, not of product management. This means that we are back to the good old days where there was a chasm between product management and development rather than working hand-in-hand as it is intended in Scrum.
- The Scrum Master is described as “management/leadership proxy” as a part-time role (25%) for a developer. He should also focus on spreading technical practices throughout the company. While technical practices are certainly important, this strong focus, the limited time and the complete lack to mention the role of a change agent means to me that SAFe does not want the Scrum Master to help spread Agility throughout the enterprise. So the main benefit of this role is chipped away.
- The Development Team is called “Developers and Testers”. This is good, but lacking other roles such as UX, Architecture, Database, etc. We will encounter those again on the Program level. SAFe does not explicitly say that those roles may not be on the Development Team, but people reading the chart and looking at their own org charts may be tempted to think so.
- SAFe involves a “HIP”-iteration, meant for “Hardening, Innovation and Planning”. It also gives some reasons why HIP-iterations are necessary: 1) Some quality measures might not be economical every Sprint and have to be done once per Release. 2) “care must be taken to provide scheduled time for innovation, exploration and out-of-box thinking”. 3) Release planning must happen somewhere. It is true that some quality measures cannot be taken every Sprint and need specific time allocated for that. On the other hand, innovation and release planning should not just happen once a release, but continuously. Imagine somebody walking up to you, saying “be innovative now, you got 3 weeks!” Doesn’t have the right ring to it. On top of that, the name “hardening” is a concept often already known to enterprises. If they sense that this is a good thing and their “solution” [SAFe] has it as well, they might just stick with what they have and not change a bit. So inspection and adaptation goes out the window.
- There are common Releases for all teams prescribed. While this is not bad or a violation of Agile, I don’t like the fact that it is prescribed. What if a company would be better off having one always working “release branch” and all teams constantly contributing to it at different points in time?
Program level
The program level is designed to manage the team level in SAFe. While this is an existing condition in many companies it is not what Agile aims at. Let’s take a deeper look:
- The roadmap contains the higher-level planning for the Teams' backlogs. The first sentence explaining the roadmap speaks for itself: “The purpose of the program roadmap is to establish alignment across all teams involved in the ART [Agile Release Train] while also providing predictability to the deliverables over an established timeline horizon.” So the teams are not allowed to self-organize their alignment and predictability is the goal rather than maximization of value? Hmm...
- Product management does all the prioritization and value analysis. SAFe accepts the status quo in many enterprises and distinguishes between Product Owner and Product Management. Product Management also does the customer interaction. This does not help collaboration but is a tayloristic division-of-labor approach.
- By the way: There is a team of “Business Owners” who have the last say on ROI etc. So who is responsible now: Product Management, Product Owner, Business Owner – or maybe even somebody at the portfolio level? I lost track.
- There is an additional Release Management Team that is responsible for coordinating the outcomes from the teams in a release. It comprises of senior management of different departments. Again, the teams are not doing this self-organizing but there is a central authority doing this.
- A funny thing exists in SAFe and is called “System Team”. It is described as follows: “The system team is often responsible for initially building some of the initial common development infrastructure and then moves on to other program level activities, including system-level continuous integration and end-to-end testing.” While I do understand the need for somebody providing and maintaining the development infrastructure, this system team can be easily mistaken for a central quality institution. SAFe does say that the responsibilities are shared between the development teams and the system team, so the developers are still responsible. Unfortunately, the structure can easily be mistaken for the System Team ordering the development teams around on what to do. I believe the concept of “System Team” needs some intense rework.
- There is a “Release Train Engineer”, described as “Uber-Scrum Master” or “Agile Program Manager”. While I do like the idea of having a Scrum Master on the level of management, I do not enjoy some of the responsibilities attributed to this garbled role: "Escalates impediments" (so he doesn’t solve them), "Reports status to Release Management Team" (which might lead that role to fulfill the needs of the RMT rather than those of a Scrum Master), "provides input on moving team members to address critical bottlenecks" (here the resource-shuffling game starts and shows the taylorisitc mindset again). SAFe does describe the RTE as being a servant leader, but the responsibilities make it hard for anybody filling that role to comply.
- The UX function is also outsourced to the program level. They are not part of the development teams but rather “provide Agile Teams with the next increment of UI design, UX guidelines, and design elements in a just-in-time [...] fashion.” Where is the team approach? Collaboration? Do we now have to wait a Sprint before we get our UI design? Maybe two? Or three?
- There is a System Architect role as well. He is to “evaluate design alternatives, and perform cost benefit analysis”. He also – amongst other things – responsible for creating Architectural Epics and Features for the development teams to implement. So the teams do not self-organize in that regard and are not responsible for their own architecture. Further down, the Architect is described as not being allowed to dictate anything but rather being a mentor and coach. In my opinion, this description does neither fit the stated responsibilities nor the standard (by traditional managers) understanding of the role and thus is not helping Agility.
Portfolio level
On the portfolio level, “programs are aligned to the enterprise business strategy and investment intent.” I believe this level to be important and won’t criticize much here since most enterprises will be busy with the program level anyway. It’s just important to note that there are again a couple of roles (Enterprise Architect, Epic Owner, Program Portfolio Management) with differing responsibilities.
Conclusion
While I do not approve of the style Ken used to criticize SAFe or the “one is better than the other” comparison of Anderson, I do believe SAFe to be Janus-faced. It most certainly can be interpreted and lived in an Agile way and will work like a charm then. However, the descriptions and corresponding interpretations of most readers/users will lead to nothing but the preservation of the status quo. SAFe does not help to instill a different mindset. On the contrary: people don’t have to change with SAFe – they can just go on as they always did and call themselves Agile now. Two questions arise:
- Why is this a problem? I don’t need/want to be Agile!
Well, then go with traditional models and don’t use one that has “Agile” in it’s name. A tool called “Scaled Agile Framework” should be Agile and you should only implement it if you want to be Agile. - Are there alternatives?
Unfortunately, not many. But you might want to take a look at this little article by Larman and Vodde. They have written a book on the topic as well and it is much closer to Agile in my opinion.
We also looked at the Agile Manifesto at the top of this post.
Agile comprises of continuous improvement, people, collaboration, product delivery, customer collaboration and requirements change. In my opinion, SAFe fulfills product delivery, [arguably] customer collaboration and requirements change. It falls short of fulfilling continuous improvement (Agile Masters are ripped of their balls), collaboration (of different functions) and people (self-organization is hampered). SAFe itself is very much process-focused and not aiming at being optimized itself.
It all can be summed up the following way:
SAFe believes that the world is good as it is and the existing companies, processes and structures created that world. So the status quo has to be accommodated.
Agile believes that the world is not a good place (at least for people working in software development) and should be improved. The status quo – especially the tayloristic thinking - has to be changed.
This doesn’t fit together. SAFe isn’t Agile. It could be a small step on the way to Agility, but it certainly is not the end state (if something like this even exists in Agile).
Most of us worked for huge companies with enormous projects and know how complex, ??irrational and painful their processes, role interactions and structures are, making really hard for them to move away from the traditional ecosystem.
Incorporating SAFe can offer a solution without much hassle but at the cost of loosing part of the Agile *mentality*.
Who is going to make sure that inertia doesn't pull the whole company back to the command and control days? That is a huge risk and unfortunately there is no specific role to look after that area in *SAFe*. Everything relies on the good will of people not crossing that thin red *line*.
But it is not all good or bad in life... SAFe provides many great tools and the book offers some deep analysis into the problematic suffered by enterprise companies at the time of trying Agile.
Most of the ideas found in the book can be cleverly implemented in huge projects and get good results as long as you have in mind that the most important thing is making the shift towards the agile mindset and making sure people do not just accommodates to new Agile reality.
But can't the same argument be leveled at Scrum ? It's perfectly possible to have a team that works according to the Scrum framework (they walk the walk and talk the talk), but that lacks the Agile mindset. I have seen several examples of this. Applying Scrum won't automatically change corporate culture. To me, Scrum is also mostly focused on structure and process. It is often assumed that agility will follow automatically, but I strongly doubt that.
The same applies to SAFe. There certainly is a potential for radical change, away from a tayloristic approach. But it is not implied and not actively promoted. It may be a first step in a larger transition.
Don't you think we are drastically in need of a clearer picture, a stronger vision, of what this 'Agile mindset' actually means? Without a strong vision, it's hard to generate energy for (radical?) change, as Kotter would say. On a more philosophical level, all this talk of 'Agile mindsets' is certainly quite abstract.
you are most certainly correct: Some people out there use Agile terminology without being Agile. I call those "facade Scrum" implementations.
I am heavily working on the clearer picture your are mentioning. If you want to, you can contribute as well. Take a look at the surveys here: http://scrumorakel.de/surveys/ - they will be available until end of September.
Let's improve our world!
Dominik
Your critics is valid in many aspects - but there are buts on my side regarding you critic:
Fact is that thing in real live are more complex if size and number of persons involved are beyond a certain limit.
I see this limit at about 40 individuals working on "PRODUCT" in the same context. under these constraint (constraints matter!) the Scrum idea with its 3 roles does not scale anymore. There are the three levels of portfolio, program and team that Dean identifies. That is in sync with my experience. Then - well - new names for rsponsibilities start appearing ... and that are roles like a program manager or an enterprise architect. Does'nt matter how you call them, you need names to understand a responsibility of a person.
Dean has the standing to give the community a blueprint. I see SAFe as a valid and possible blueprint - but implementing this, you should "inspect and adapt" to the context - as Ken proposes to do.
Final point: Dean at least provided us with positive and guiding thoughts and ideas. Other people offer only critics without adding value to the community (you're not one of those, I know!).
But I think when sending critics, we should add as well ideas to address the critics with value
...and as you say .. not so easy, there is nothing like the silver bullet. An as I know Dean, he does not think that SAFe is "THE" silver bullet.
Best Rainer
Thank you for your comment!
I see your point and agree that SAFe can be used in an agile way. My main critic is that this is not instilled in the framework itself but has to be interpreted that way by the "user" of the framework - which is difficult due to the shortcoming pointed out above.
There are alternative solutions available, the best of which (in my opinion) is that of Larman and Vodde. Unfortunately it's not exactly a "blueprint" and therefore much more difficult to implement.
Too bad the world is complex and there aren't silver bullets
"..discussion in the community whether SAFe is really Agile or not.." and after this you take the "Agile Manifesto" as "THE" reference for "agile".
In your critical view on SAFe I see a lot of your personal interpretations why you think, SAFe is not conform with the four values of the manifesto. But for me no one of your interpretations is the only possible one - and therefore a clear contradiction to that values.
For me SAFe - same as Scrum - can be implemented in a way following this values or in contradiction to them. And - we all know - the majority of implemented practices naming themself "Scrum" are in contradiction to one or more of that agile values (and are not following the Scrum Guide completely - as it should be, see "End Note" on page 16)
BUT: Many of them are working reasonably well.
So: Does it really matter, if something is in line with the Agile Manifesto?
No. The goal of a business is not to be in line with a Manifesto. The goal of a business is to make profit.
And to make profit in our very volatile recent age means, to have "the capability to successfully cope with changes in circumstances“ (which is the definition of "agile" of David S. Alberts in "The agility advantage - a survival guide for complex enterprises and endeavors" DOD-CCRP, Washington 2011. ISBN 978-1-893723-23-8
And he describes this "components of agility":
o Responsiveness
o Versatility
o Flexibility
o Resilience
o Innovativeness
o Adaptability
For me this "definition" of Agility fits much better and is much more adaptive to different kinds of changes in circumstances of bigger enterprises than the definition of the "Agile Manifesto" which is too much restricted to the development of products, especially of software, only.
So:
1.
I doubt, that a discussion how far something is "agile" or not is adding any value to an enterprise
2.
If we have such a discussion anyway we have to create a shared understanding of "agile" in an enterprise context first.
My understanding of this is that this is intentionally done to ensure that the influence of the teams is big. The question whether this is really how SAFe is put into practice, is of course valid, especially now that SAFe seems to get more and more attention from bigger enterprises. It's also sad that SAFe as a framework is intentionally silent on how to introduce SAFe -- I also fear that many enterprises might be tempted to leave many things as they are if there is the superficial impression that the old way is compatible with the SAFe way (e.g. a very hard division of labor and responsibility) when SAFe itself recommends high interaction between teams on all levels.
To me, it's also highly unclear of how much derivation from SAFe would be okay to still say you're basically doing SAFe (similar to the discussion of how close you have to follow the exact words from the Scrum guide). I'm going to take a look at Scott Amblers DAD http://disciplinedagiledelivery.com/ since I think that he takes the approach of providing a set of questions and recommendations on how to solve a given task (e.g. release management), which looks more open and less prescriptive to me.
"how much derivation from SAFe would be okay to still say you're basically doing SAFe (similar to the discussion of how close you have to follow the exact words from the Scrum guide)."
I would say: There is NO value to follow some rules - value is generated, when those "rules" are emerging which are as far as possible appropriate for the specific situation of an enterprise. And I am glad, that - in contrast to Scrum - yo may take (and modify) from the SAFe-documentation what is useful for the specific situation. And you may name the result SAFe or "whole scale agility" ... or whatever you want. See for that - as an illustration - http://www.prettyagile.com/2013/09/a-perspective-on-scaled-agile-framework.html which is recommended by Dean.
Coming to "I understood, Dean recommends to start off on the team level."
Well, this is one possibility. I myself do not prefer this. I - based on the idea of "governance by context", coined by Helmut Willke - prefer to start on the program level as the context for the work of the teams and give the teams the freedom (and responsibility) to organize themself in an appropriate way within this given context.
http://xprogramming.com/articles/safe-good-but-not-good-enough/