-
About
Notes and views on CRM, open business models, and what the Web means for customer relationships. [more]
-
Speaking at:
Telecoms CRM, CEM and User Experience 2008
Travel
Linkblog
Photos
Agile analysis, waterfall delivery
ITERATIONS, SCHMITERATIONS… Many a developer shop claim they are using an agile (as in RUP, not XP) approach, yet when time comes for them to put money where their mouth is, they are doing the ol’ good Waterfall.
Part of the problem is - the Customer. The Customer wants to know, up-front, what the application will look like.
But - although there is some truth to the old saying that all software would work perfectly if it weren’t for the users - blaming the customer is rarely a sound business tactics.
Why would the customer need to know exactly if he could trust the vendor implicitly?
Yes, trust. So many failed projects on their books, few companies have faith in vendors’ competence. They put provisions and clauses in the contracts so that they can sense an impending catastrophe before it strikes. One of these clauses: the Analysis shall deliver a complete specification of the final product.
Poor analysts.
They become designers, software architects, and documentation makers. Rarely do they have time to spend on their favorite subject, Requirements. Meaning the requirements rarely make it into the design, which leads to a product not matching the client’s needs, which leads to … poor satisfaction and a little less faith, again.
Here’s a solution: think agile, and the Waterfall can work.
Some deception is needed. The analyst will create beautiful visual representations of the final product - be it UML diagrams, a GUI prototype, or web page demos. And he has to work the client to make him think this is, indeed, the product. It has to be logical and detailed and, yes, sexy. The analyst has to seduce the client so that he sees the final product even though he’s actually looking at an abstraction. One that is decidedly incomplete and open to changes.
Indeed, visual modeling is a great way to capture, verify, and test requirements.
I understand the Agile camp looks at diagrams with certain disdain. Truth is, diagrams have no value in themselves - the client needs the code (or function thereof) - BUT they have a tremendous power in that they suck the customer in. He has something to look at, to dream about. And in that process he can express his wishes better than through written word.
Of course, the visuals don’t tell the whole truth; they do, however, define a boundary for any requirements that can and will come later. Which can allow for some agile approach even though the process goes from Analysis to Design to Development etc. and doesn’t allow for requirements to be formally introduced once Analysis has finished.
The product will never look exactly the same as the specs produced by analysts. It might, however, be closer to the customer’s needs, and even if the customer notices the differences, I doubt he’ll complain.
Sphere: Related ContentOver-zealous salesmen, beware!
ERIC SINK is not just complaining about over-zealous store employees at Best Buy who would bombard him with unwanted offers whenever he shops there. He’s got an idea:
What I want is a Best Buy “Quiet Zone” card. Instead of blue like the Reward Zone card, this one would be red. I have no idea how my Reward Zone card works, but my Quiet Zone card would work like this: Whenever a Best Buy employee sees it, they immediately shut up. That’s it. All I have to do is wave my red card and suddenly every blue shirt in my vicinity will put a cork in it. Don’t even finish your sentence. I am buying exactly what I came here to buy, and nothing else.
Brilliant. Sometimes, oftentimes, I don’t want any kind of relationship from my vendor: I know exactly what I want, and I also know that I do not want anything else at the moment. A simple transaction, please, let’s get this over with. Here’s my money.
I think one of the tragedies of CRM - and one of the reasons it’s failing to deliver - is that it makes selling an automated process that can be launched at unsuspecting customers anytime. I call for service - change of a telephone number on my contract - and the rep would instantly try to cross-sell/up-sell me if I don’t hang-up immediately. Did I say change of a phone number?
The ubiquity of fully-automated channels have created the environment in which I don’t have to interact with anyone if I don’t want to. Shopping on the internet has reduced my contact with human beings on the other side to a bearable minimum. Now, looking at it from the standpoint of a business owner, that’s a serious trouble.
Instead of wastefully keeping their “push” models, companies like Best Buy should do everything to create honey-pots, pull their customers instead of launching grenades at them, create experiences that online stores cannot, by definition, replicate.
Let’s see - a hardware store could create a play-area for geeks to try-out stuff before purchasing, to assemble their new dream Quad-core X-Fi double-8800GTX computer in a controlled environment and with help available, so that the experience of shopping there vastly exceeds anything available online.
And sure enough, customers pleased with the experience will buy more - ‘nuf said.
Sphere: Related ContentAgainst division of labor
SOFTWARE CONSULTANCIES that are running on RUP have it all figured out: analysts analyze, programmers program, testers test, and project managers… well, who knows what they are doing anyway.
I am starting to perceive this division of labor as inappropriate.
Obviously, it has its benefits. The craft of software development requires so much ongoing learning that nobody could keep up with new languages, frameworks, and methodologies while working on projects and be a specialist in all disciplines of software. Hence we say, let analysts work with requirements, architects to turn them into design, coders to translate that in the appropriate language/platform, and testers make sure it all works reasonably well. Seems like a logical choice, doesn’t it?
Here is the drawback: by drawing thick lines between the disciplines, we emphasize their differences and make them separate while the opposite is desirable. The customer doesn’t need a requirements matrix, UML diagram, nor test scripts; and sure as hell he doesn’t care about source code. He wants to see his processes automated, his customers’ data kept clean and safe, etc. That won’t happen unless all roles involved in the delivery process know about each other.
True, most testers know that what they test is a program code, and likewise, analysts tend to have an idea about the program architecture they are implying when drawing complex class diagrams. I am not saying they don’t know anything; I submit that they know far less than they should.
A couple of years spent charting UML abstractions can make one think writing code is easy: just lay down the bricks as prescribed in the analysis document, and everything will be fine. Or, looking at it from a different angle, writing J2EE code for enterprise applications, year after year, can make one conclude the business proprietors are a bunch of clueless, desperate egomaniacs willing to throw millions of dollars at the latest buzzword (think SOA, think CRM, think BPM) hoping it will automagically generate satisfied customers, increase in sales, etc. When people don’t know the whole story, they can come up with some real strange ideas.
Writing good software is hard. Making it serve business needs is even harder. It takes a well-defined and reality-checked process, fearless execution, and lots and lots of guts to deliver. Here, I submit that all the people involved in software delivery need to be intimately familiar with the whole process in order to produce something useful. Sounds trivial, sure, but isn’t as obviously accepted as it should.
To anyone wanting to start a career in software, I’d recommend this: try to get your hands dirty. Try coding, analyzing, testing, and if they let you, managing, too, though I am a big believer in servant leadership when I think of software projects, so you may want facilitating (instead of managing) projects. Be a generalist: whatever you may want to specialize in will one day be obsolete anyway.
And when you find what suits you best, stick with it; if it’s Java or Rails, great, if it’s making sure the app does what it should, that’s cool, too. Just remember what comes before you and what follows when you think you are done.
Sphere: Related ContentDowntime
[Filed under Service Announcements] Apologies for the unexpected downtime, apparently my hosting company, A2hosting.com, accidentally suspended my account during a scheduled migration this weekend.
Usually, I would be considering an immediate switch to another provider, just becauses I am angry and because I can, but this time, I won’t. I submitted a ticket with them 2 hours ago, and just got a reply with an apology and explanation - all systems running now. Good to see working customer service.
Actually, I should even be grateful for the blackout since it reminded me that my domain needs a yearly renewal. Shame to you, ev1servers.net (my domain provider), for not notifying me in advance - I shouldn’t have to remember this kind of stuff!
Sphere: Related Content-
Recently featured
-
Stay in touch
-
Blogroll
Promotion
