#SAFE is Post-Fact Agile and How Could it Be Otherwise
"If you can hear the truth you've spoken twisted by knaves to make a trap for fools"
So I went on a SAFE course. It was two days long and I've yet to log in and do the exam. So I'm not yet "SAFE Certified". Because that's a thing.
But here are my "unsafe" thoughts.
First of all. I've never seen a trainer who was so unhappy to be there.
There's a concept that I used to talk about quite a lot when I was studying for a Masters in Cognitive Science - it's called Cognitive Dissonance. According to Wikipedia:
In psychology, cognitive dissonance is the mental stress (discomfort) experienced by a person who simultaneously holds two or more contradictory beliefs, ideas, or values, when performing an action that contradicts those beliefs, ideas, and values; or when confronted with new information that contradicts existing beliefs, ideas, and values.
Of course George Orwell invented a more succinct term for this: doublethink.
Yup - that's what you could definitely see in the face and body language of this trainer pushing this SAFE stuff. Cognitive dissonance and doublethink. His heart wasn't in it. He was saying and doing one thing when he clearly believed something else.
One of the set pieces of SAFE is something called PI planning - Program (they use the US spelling) Increment Planning. The idea is that across a whole programme of work you get the people involved all together and everybody plans what will be done in the next step of the program.
There was as exercise to demonstrate the idea of PI planning, and the exercise was chaos. But not meaningful chaos. I was in a team that ended up with very little to do because what we started out doing something that was dependent on something else. Then when we went back to the list of things that were still to do, all that was left was something that was low priority. Actually, this is quite interesting, and I'm sure the other groups had some interesting observations, but we didn't examine any of them. Part of the reason was that the trainer would set up activities so that at the end of the activity we would move straight into a break. As a trainer, I know that if you say that - for instance if you say something like "As soon as you think you've finished the exercise, you can go for lunch." Then what the trainees hear is "You can go for lunch now."
A lot of middle managers seem to have been sent on this course. A lot of middle managers who thought it would be OK to do a SAFE course with no knowledge of Agile (naturally the course had no pre-requisites, they would reduce the number who signed up). And that resulted in lots of sideways comments, some of them fair enough, along the lines of "Agile doesn't make any commitment about delivery;" or "Scrum is chaotic."
And, out of nowhere - well, we were talking about estimation - but we were talking about it in relation to estimation using complexity, some guy piped up and explained to all of us that if a developer had estimated that a task was going to take a certain amount of time and then, halfway through, he realised that it was going to take longer, well then that developer should just work harder to make sure that he finished the task on time. Because after more than 10 years of the Agile manifesto that's still what most people know about software development - that most of it's problems could be solved by developers simply giving more accurate estimates and "working harder".
Another guy said that Agile would never fly with senior managers because it didn't commit to delivery.
When I run courses, I start the second or third day asking the delegates if they've got any comments, questions or sarcastic remarks about what we did the previous day. And then I often joke, asking if anyone woke up screaming in the middle of the night worrying about something that we'd talked about the previous day. Well, I kind of did wake up, not screaming exactly, but certainly worrying about what we'd talked about the day before. SAFE wraps itself in a ton of Lean thinking. Small batch sizes, pull rather that push. But SAFE itself seems to suffer from cognitive dissonance and doublethink, and maybe that's what woke me up in the middle of the night. Because what I thought, there in the dark at 4am when everyone is alone, is that the PI Planning event is a MASSIVE batch and the PI PLANNING event is a massive PUSH.
And the other thing - that I just want to get down, is a discussion about what other teams might do in the PI planning meeting. One of the delegates pointed out that some teams could game the system so that other teams ended up doing their work.
And the trainer said something like "well, there's no method that can guard against bad behaviour."
And what I was thinking was - well, a method that can't guard against bad behavour isn't much use at scale. Some commentators (and I'm tempted to agree with them) feel that any large organisation is, by its very nature pathological. So any method that claims to get results out of organisations, rather than small teams is going to have to address this pathology.
Of course, the same people that will question the motives of developers and doubt that the developers will do anything but sit on their thumbs if they aren't kept under close supervision, seem to think that the people giving those teams things to do are entirely altruistic and only ever had the best interests of the company and its employees at heart.
But of course SAFE is cognitive dissonance and SAFE is double think. How could any methodology, framework, whatever you want to call it be anything else? Because SAFE is trying to be all things to all men.
To developers it's trying to be Scrum and continuous integration and all the good engineering practices. To architects, it's trying to be a promise that the big upfront planning that they used to do isn't irrelevant, and that's what the architectural runway might mean.
To senior managers it's trying to look like the command and control waterfall planning that they would love to be the way that the world works, even though it isn't.
One of the ways that SAFE does this is by playing with the large and small print. The large print says "Top-Down Waterfall planning" but the small print says "using the most modern up-to-date Lean Agile Scrum technology."
At least for me, it made me ask some very serious questions about what an organisation is. And organisation is a natural phenomenon that arises to reduce risk. Why do people work for organisations? Simply put because working for organisations is less risky than working for themselves.
Because working inside the organisation is risk reduced, it's much cheaper to do a lot of things inside an organisation than it is outside an organisation.
And then the question because, what do you do in this risk-reduced environment, to get the kind of behaviours that you want to grow and the kind of behaviours that you don't want to shrivel and die.