« June 2014 | Main | March 2017 »
July 15, 2014
Ditch Agile, Go With Common Sense
I am so sick of "Agile" I could puke. Agile "methods" and "processes" are often used as a bludgeon to enforce the great speedup, doing more, faster, with fewer resources. I see estimations forced into the PM or manager's demanded hard deadline, hours getting longer because of wasted time in meetings, and "rapid" deployment of garbage code that needs to be rolled back because no integration testing was done (eliminating QA does that to you.)
Here's a new proposal: Use the Common Sense™ Method. In this method:
1) The user requirements are gathered (user, not marketing) and set down
2) Which requirements to include in that version are decided by a small group of technical professionals
3) Application or changes are designed (roughly) by an architect or senior programmer
4) Requirements get split up along functional lines among the participating teams
5) A common api/interface between the parts is documented by the architect. Operability and scalability issues are addressed first in this phase
6) Teams take a guess on how long it will take to come up with a first pass.
7) The architect applies a Murphy factor and communicates the result to management as the likely alpha release date
8) The coding starts, with progress checks with the architect and teammates, and unit tests for each section. People keep track of their tasks with simple to do lists, like adults.
9) The lower order, foundational stuff is done before the bells and whistles, and is handed off to an independent QA group.
10) Each group addresses the bugs found in its previous commits before coding new stuff. Maintenance and bug fixes (tech debt) is addressed before new features (and bugs) are added.
11) Alpha is tested and released as a beta, along with solicitation of comments from users.
12) The next major iteration is planned with the feedback from the users and stakeholders
This glosses over a lot of the daily iterative development concepts, like "code, compile, test, repeat until it works and is complete." (seriously, this should be a mantra for programmers, completely aside from any methodologies and processes.
Most "Agile" methods these days are used as another method for command and control micromanagement by multiple levels of manager. Seriously, at one place I worked had a Product Manager, a Program Manager, a Scrum Master, a Group Manager and a Team Lead to preside over four (4!) individual contributors. What a steaming pile of horseshit.
If your company has gone whole hog for "Agile", complete with removing your privacy to "encourage collaboration", sell your stock. They will go the way of the dodo within 2 to 5 years, and be a hell hole to work in in the meantime.
Go with pragmatism and common sense. Do iterative development while listening to your users and fixing your tech debt. You will outlast the fad followers who go with Cargo Cult Agile and Management by Guru.
Posted by ljl at 09:40 AM | Comments (0)
How To ***REALLY*** Advocate for the Customer
I occasionally see job ads for "customer advocates" or "customer evangelists". They all turn out to be sales and marketing, that is, advocating or evangelizing stuff to the would-be user.
That is so ass-backwards that it makes me foam at the mouth.
A truly useful and inspiring product is something that people seek out, that before it came along is something people say "I wish there was a way I could..." and when they discover it they often are ecstatic with delight.
Anything else has to be sold, often with lots of expensive propaganda.
So, what then should a user advocate do, especially in an established company with an established product line?
Certainly not marketing. There's a whole department for that already, with slick ads and all.
A true "user advocate" works for the customer. This means that they listen to the users, feel their pain, understand their needs and use cases, and then bring those pains, needs and uses back to the business as requirements!! They are the people who yell on internal mailing lists when your stuff breaks and screws up the customer's day. They are the ones who file bug after bug because your redesign served 95% of your users, but screwed the hell out of the 5% power users who bring the other 95% to the product or use 95% of the product (I'm looking at you, Microsoft "ribbon".)
But no one hires for this. They all look for slavish yes-men who will work within the guru driven flavor of the week to churn out poorly designed, half-assed software on short deadlines (the Agile fallacy) and compete bitterly with each other for a few crumbs in the stack-ranked corporate hunger games.
So, why don't companies want real user advocates? Don't they want to delight their users with products that do things for them? Or is their real customer a schlock advertiser who tries to sell them more useless stuff, crap diets, dubious supplements, or sleazy sex? Even then, most advertisers aren't happy either.
A real user advocate needs to be willing to dig in and become an actual power user of the product. They need to hang out on the user forums and support groups, but not "taking calls" and be measured by issues "resolved" per hour. They need to go to trade shows, job fairs, and other places that users congregate, then ask questions about pain points and wishes and listen to the answers. But only marketing even tries to do this, and they are too busy talking about the product to listen to the users!
So, to paraphrase TRON, who fights for the users? Will your company hire someone to do this, and give them the power and influence to accomplish it? Or will you let a bunch of "evangelists" who have no listening skills tell you what they think the users want? Which product will be better in the long run?
Posted by ljl at 09:32 AM | Comments (0)