via Geek and Poke
Agile is Bloated
I realised this the other day when, on a mailing list, someone asked about what the “Sprint Goal” was supposed to be. A reply came from someone else that they didn’t have a goal, but since “scrum mandates a goal”, they decided that their goal was “to implement stories”. Of course, this is a rather meaningless way to have a sprint goal.
So that got me thinking: Have agile processes become so complicated that they confuse the hell out of most people?
Take something simple, like user stories. Originally they were just little pieces of features to build.
Nowdays you’ll be told how user stories have to be from the user’s perspective. And they have to follow this “As.. I want.. So that” template. And that they have to be INVESTable. And oh, the stories have to be small. Like really small. Really, really tiny small. There is a whole industry around just making your story so small that it cant be cut any smaller. (PS: dont forget, vertical slicing only! Like a sashimi).
And you have to estimate them. There is a whole another industry around how to estimate these really, really, tiny small INVESTable stories. Using these things called ‘story points’. Y’know relative estimation and all that (psst.. relative complexity, not relative effort). But only with fibonacci numbers (they’re cool!). And overlapping probability distributions (also cool!). But be careful young padawan, because when it comes to tasks (which are SMART by the way), then you don’t use story points.
I could go on and on, but you get the picture. What a mess. And this is supposed to be a lightweight process? COCOMO is easier than this stuff (just kidding). I’m not surprised that most people fall into the pit of despair before they can get their Hello, World user story ready (see cartoon above).
How did we get here?
Just as we get anywhere: One step at a time. You see, people mess up. So we add a couple of rules. But they still mess up, so we add a few more. But they still mess up, so we add a few more. But they still mess up. And this time its because they cant comprehend all those rules that were put in.
Why do we have all these rules?
A fragile process requires a perfect environment and perfect execution. Without that, it will fail. Worse, it fails much more spectacularly than whatever was done before it.
A forgiving process process works in a variety of different environments and execution skills, perhaps with a range of results, from mild improvement to much more radical improvement.
Unfortunately, most of the attention has focused on fixing the environment and execution instead of making the process more forgiving. So, an agile transition goes
- Fix the organization
- Follow all the steps of the process
There are a whole bunch of people who will validate whether the organization is ‘ready’ for agile. It is the spherical cow syndrome again.
Today you need a PhD to understand agile. Woe betide you should you fail to understand the difference between a complicated system and a complex system. What?? You don’t know the difference? No wonder your agile team failed!
Agile really IS simple
When you really think about it, agile is pretty straightforward. There are only two concepts to it.
- Release a few features, get feedback, adjust accordingly
- Improve your collaboration and communication
All those things like iterations and user stories and fibonacci story point estimates are nice, but you can be perfectly agile without them too.
Start where you are
So your first release is three months long. You’re release cycles are not of the same duration. You don’t use user stories. Your features take three weeks to deliver. You don’t do TDD. The team isn’t colocated.
That’s okay. The main thing is to delivering once a quarter or less, and incorporate the feedback. Then, see what you can do to improve collaboration.
Some of the agile folks are going to laugh at you and your ‘agility’. Just ignore them.
Yes, some of these things do help, but you don’t need everything at once right from the start. All these things are just practices. You can implement them if you want to, or skip them if you don’t, or implement them later if thats better. For what it’s worth, I’m no longer a fan of user stories.
Start where you are.
You collect requirements a certain way? Just do the same thing. Estimate a certain way? Continue that. Then add or replace pieces one by one as you hit roadblocks.
It’s not the most efficient way of doing things, but it is the most forgiving.
Somewhere along the way, the whole agile movement got derailed.
One set of folks went into researching how the organization could be fixed.
Another set went off into adding more and more rules so that people wouldn’t shoot themselves in the foot.
All this has just made things much more complex (or is that complicated ). And the more complex something is, the harder it is to get right. It’s a positive feedback cycle.
Back to Basics
All the jargon is unnecessary.
You dont need a PhD to understand this agile stuff.
Feedback. Collaboration. Thats it.
It’s time to cut the agile crap and go back to the basics.