The Process is not the Product — The Software Methodology Anti-Manifesto.
TLDR;
The Software Methodology Anti-Manifesto
- The Process is not the Product
- Leading not Managing
- Dialog not Dictation
That’s it, you can work out the rest for youselves, but for those of you who want to, read on.
The Process is not the Product
In a (very) long technical career, I must have been exposed to the majority of software methodologies, and experience has shown that they are, by and large, more of a liability than a help. In fact, I’ll go further and say that I think that too much methodology is much more dangerous that too little. However, the cult of the One True Methodology continues to thrive, and it worth taking a few moments to consider why.
‘If You Meet the Buddha on the Road, Kill Him’
I suppose one reason is the sneaking suspicion that many/most/all of us have is that we are doing it wrong, and there is someone out there doing it right, and if we just followed her advice, we would do it right too, and all the bad estimations, bugs, bad code etc, etc, would all disappear.
You shouldn’t and it won’t.
If you do follow this advice, you will go down the path of Management by Acronym(tm), see TDD, BDD, FDD, XP…
Don’t you dare click that link.
Another reason the Software Methodology economy. It’s akin to the miracle investment advice ads you see. The people selling training courses, books and the rest of the paraphernalia are making a good living. But it’s from selling the courses, books and so forth. If they were any good at making software on time and bug free, they’d be earning a lot more. But just like the investment advisors, they are making money from our technical insecurities.
This is the reason that this article is an anti-manifesto, the real Agile was hijacked long ago. The only way to avoid the gurus moving in is not to have a methodology, a manifesto, or anything else they can latch on to. Think for ourselves.
If you can, do. If you can’t, manage
Yet, another reason is the unstoppable accretion of middle management that happens to companies great and small. As we grow, we become convinced that we need more management. And more. And more. Why? What is the career path for a manager? Hire management underneath you. What’s worse is that companies that succumb to this, tend to develop an immune system. Any attempt to change the management status quo would threaten the very foundations of the managment culture. Not to mention all those management jobs. Innovation? Great. Let’s hire a Head of Innovation. And of course, management has to have something to do, and that is process, tracking sprints, trello boards, anything to fill up the 8 hours of timesheet.
Leading, not Managing
Well, this leads us on to the next point in the manifesto. Leadership. You know, the real stuff. Getting in there and showing way forward. Personally, clearly, one programmer at a time, not just the stuff you think they need to know, the sprints and use cases. Actually, having enough technical clout to be able to teach, coach and encourage. And learn. Informing everyone, right down to the janitors (and all respect to janitors) where we are going and why. Not just once, but all the time. Organisations that do this tend to self-manage. Why? Because people, (even programmers), are smart. Given information and permission, they think, prioritise correctly, don’t bitch about changing goals, and don’t really need managing. If you do it really right, you’ll find yourself following, not leading because the team culture gets bigger than any one person.
Dialog, not Dictation
Finally, we come to the last point, which follows right up on the the previous one. Communcation should never be one way. Information should flow up as well as down. The one cardinal sin is not failure, it’s the failure to communicate, including communicating failure. Treated the right way, people are smart, and very likely have better ideas than management. And everyone should be heard. With respect.
If all this has you shifting uneasily in your chair, good. I meant it to.
PS: No Jira.
