Let's start the new year with a rant on SAFe. (Hey, low-hanging fruit 😄). SAFe is a perfectly good process, but it's in no way an Agile process. We could start with "Individuals and interactions over processes and tools." SAFE is clearly very process heavy. 1/6
That comes with too much complexity, which flies in the face of "Simplicity—the art of maximizing the amount of work not done—is essential." Then there's "Responding to change over following a plan". Planning is a big part of SAFe, and the plans are much too long range. 2/6
The whole notion of a PI is a waterfall concept with an up-front plan. I could go on. SAFe violates most of the values and principles of the Agile Manifesto. 3/6
I'm not saying that SAFe isn't an improvement over chaos. People who say "it works" are not wrong because they're comparing it to the things they did before, which definitely did not work. SAFe is hardly the panacea most of the big corps who adopt it think it is, however. 4/6
It's designed to fit the corporate mindset, not to develop software. Adopting it is comfortable, because the orgs don't have to make the significant and uncomfortable changes to the org structure required by Agile. 5/6
Finally, none of the large orgs that consider themselves software orgs (Twitter, Microsoft, Apple, Google, Facebook, Oracle, SalesForce, &c.) use SAFe. There's a reason for that. 6/6
• • •
Missing some Tweet in this thread? You can try to
force a refresh
I've seen two approaches for maintaining architectural integrity in a large system. One is the "architecture committee," which meets periodically and sits in judgment of all architectural changes. You can't make a change unless they approve. 1/4
It's a model built on distrust and the assumption of incompetence. I see no place for that in an agile organization. 2/4
Then there's the "guild" approach. The guild is made up of representatives from all the teams and one or two full-time architects. The entire guild makes architectural decisions. You go to a guild meeting to work collaboratively, not to get permission. 3/4
Sometimes, a skill is specialized enough that it doesn't make sense to fully integrate it into a team. Take Architect. You don’t need one on every team, and in fact, a single Architect for an entire product helps with coherence. The architect has two main jobs. 1/7
(1) Diffuse their knowledge out to the teams, assuring that everybody has architectural skills at whatever level makes sense for them. They teach. They work with individuals. They review the team’s work & make suggestions. 2/7
(2) They work with all the teams for a given product to assure system coherence. They say things like “this is good, but if we do it this way instead, it will work better with what team 2 is doing.” 3/7
IMO, the "Sprint" is one of Scrum's biggest flaws. Just dump it. When you're done with the current thing, metaphorically walk over to your backlog and pick the next-most-valuable thing to work on. There's a lot of waste in Scrum surrounding the packing of Sprints. 1/4
Getting rid of the Sprint gets rid of the waste. 2/4
That doesn't mean, by the way, that cadences aren't useful. Putting everything on the same cadence is not, however. 3/4
I keep hearing about people who want to track the progress of an Agile adoption. What are you going to track? Agile is about "responding to change over following a plan." Tracking towards a goal implies an up-front plan and a definite destination. 1/4
There is no destination to Agile, though. It's a process. You constantly improve. You never arrive. 2/4
The way to keep improving is with a continuous-improvement culture, which is evidenced by things like regular retrospectives that come up with concrete improvements that actually happen. That's not the only way, though. 3/4
I think it's worth distinguishing between a prototype and a mock up. The prototype is the first one. It's a test bed that engineers make changes to until they have the best results. The production versions are exact copies of the prototype. 1/4
I think of all software is a continuously evolving prototype. You never throw away prototypes. 2/4
A mock-up is not a real thing at all. It's something held together with duct tape and cardboard just to see if an Idea can work or not. You throw away mock ups. What people call "paper prototypes" are actually mock ups. 3/4
Often, people think they need documentation to assure continuity of knowledge in the face of rapid turnover. If that's you, then eliminate the need for so much documentation by fixing the rapid-turnover problem. Churn is not a fact of life. 1/4
Keep salaries current with what your competition will pay to hire people away. Provide a solid working environment full of relatedness/collaboration, autonomy/self-organization, mastery/learning, purpose. Create a psychologically safe environment. Trust. 2/4
Provide an ideal workplace where people want to be, and then don't require them to be there if they can't for some reason. Treat people as volunteers, not conscripts. 3/4