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.
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).
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?
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.
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.
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).