Posts Tagged ‘methodology’

Rethinking IVR development

Previously I’d written about the lack of software development methodology in creating contact center applications such as self-service IVRs and routing logic. Since a lot of IVR developers are self-taught, without formal software engineering background, or forced by circumstance to take on the task, I believe a good way to approach this is to start from the very basics of software development. Set aside methodology for a moment and just simply contemplate on what an application is.

Like a Story

Who doesn’t love a good story? An introduction that hooks your attention, progresses to a climax that prevents you from setting down the book, and finally a conclusion that satisfies your curious appetite.

An application also has a beginning, middle, and ending. The beginning is taking some sort of data as input, the middle is to process that input, and the ending is the result of the execution. So in your mind just think of the app you’re creating as a simple outline for a story, with a beginning, middle, and ending. From that you will add a variety of elements to the outline, expand plots, and finish a complete story.

MVC

No, I’m not referring to “most valuable customer.” MVC is the famous Model-View-Controller design pattern, first conceived way back in 1979 by the brainiacs of Xerox PARC. You may already know that Xerox PARC was credited with the invention of the mouse, GUI (graphical user interface), and Ethernet. But equally important was its contributions to software development, like object-oriented programming (OOP), the Smalltalk programming language, and of course, MVC (from Wikipedia):

The model is the domain-specific representation of the data upon which the application operates. Domain logic adds meaning to raw data (for example, calculating whether today is the user’s birthday, or the totals, taxes, and shipping charges for shopping cart items). When a model changes its state, it notifies its associated views so they can refresh.

Many applications use a persistent storage mechanism such as a database to store data. MVC does not specifically mention the data access layer because it is understood to be underneath or encapsulated by the model. Models are not data access objects; however, in very simple apps that have little domain logic there is no real distinction to be made. Also, the ActiveRecord is an accepted design pattern which merges domain logic and data access code – a model which knows how to persist itself.

The view renders the model into a form suitable for interaction, typically a user interface element. Multiple views can exist for a single model for different purposes.

The controller receives input and initiates a response by making calls on model objects.

This is a very popular pattern when it comes to web app development. Next time you’re doing some online shopping think about all the facets of the experience and what has to come together to make it all work.

Now close your eyes and imagine how it would work without visual elements and only using your ears. In other words, think of your IVR app as a web app, but without the browser and only caters to blind users.

Keep It Simple, Stupid!

Be conscious of the KISS principle, in designing the presentation (i.e. IVR menus and voice prompts) and in coding the business logic. Remember, your users are blind and their browser is a numeric keypad.

Learn to love abstraction. Break up big problems into smaller chunks, perfecting a chunk at a time. Refactor your code in order to simplify it, not only to you the developer, but also to others who may need to read it one day. That means grouping similar logic into functions or subroutines. Always comment your code and update documentation.

Write your app as if writing a story. Carefully craft the main characters, build upon subplots, be concise and clear, etc.

I used to write IVR apps with a sequential mindset, meaning that I’ll string up menu after menu. It made for hairy looking apps and difficult to navigate through the code when needing to make changes.

Then I learned from someone to code it like a state machine (or a wheel). Analyze the call flow to find logical abstractions. Create a label for each abstraction (e.g. Greeting, AskForCustNum, ProcessCustNum, etc.). In the code keep a variable to update the labels as you develop the whole call flow in the IVR as a gigantic loop. Here’s what I mean in pseudo-code:

// Initialize the state machine

SET state_label = ‘Greeting’

WHILE state_label NOT-EQUAL-TO ‘End’

IF state_label IS ‘Greeting’ THEN      // Greeting menu

{ play greeting prompt }

SET state_label = ‘AskForCustNum’

IF state_label IS ‘AskForCustNum’ THEN       // Get customer number menu and input

{ ask for customer number; get customer input }

SET state_label IS ‘ProcessCustNum’

.

.

.

IF state_label = ‘End’ THEN       // End of call flow

{ play thank you prompt }

EXIT WHILE

Obviously IVRs aren’t programmed like this anymore, so this would require some translation to whatever IVR development tool you’re using. But notice that this will flatten out the menu tree to make the app more readable, plus changes to the call flow can be made easily by just modifying the variable state_label accordingly. For example, in order to bypass the greeting all you have to do is initialize state_label to ‘AskForCustNum’ or whatever new entry point you want — there’s no need to move blocks around or reconnect any lines.

Conclusion

In any IVR development project it makes sense to step back a bit and soak in the broader picture before diving head first into the programming aspects. Write code as if writing prose, and always keep simplicity and abstraction in mind to ensure that not only you will enjoy the development process, but also others in the future.

Software development methodology often lacking in contact center projects

This post is solely based on my past experiences in the field as a developer (IVR, screen-pop, and call routing applications) and as a consultant (business analysis, design, architecture, etc.)… I have not conducted any sort of scientific polling or studies to confirm this, so it’s purely a personal observation…

Perception

More often than not, contact center projects are run without regard to any sort of methodology, especially software development methodology, when programming tasks are involved. It is unfortunate and I believe a contributing factor to a high failure rate of contact center projects.

One of the hurdles to overcome is perception. It seems that there’s a perception gap between the understanding of traditional software development versus, say, IVR app development. Traditional software development utilizes common tools and IDEs to enable the developer become more effective in writing code, be it C++, Java, or whatever. These tools normally come with comprehensive debugging and simulation features to facilitate the development life cycle. The developer can quickly find out and demonstrate whether or not his (or her) code works per customer requirements.

Contact center app development, on the other hand, is regarded as some sort of magical stew with telecom, IT systems, and developer know-how all mixed in. But it really is similar to traditional software development except with more constraints: the tools are likely to be proprietary, debugging and stimulation features are lacking, and testing usually requires a coordinated effort between telecom, IT systems, data networking, and more. So the catch is to effectively manage the development life cycle with acknowledgment of these constraints and to work within them.

Design

Most importantly, don’t skip the app design phase — no matter how tight the project time line is. The requirements document (yes, it’s recommended to have that too) should be the Old Testament, and the design document is the New Testament. Together they are the project’s Bible. Seriously, I have seen my share of project management ignore a good, documented design, and what happens? The project may be off to a decent start with the developer coding away, perhaps proudly demonstrating some rapid prototyped app to everyone’s delight. Then sometime in the middle or tail end of the project a major flaw is uncovered or updated customer requirements warrant a new design — and all hell breaks lose. At this point the project team will take either one of these routes: 1) Go back to the drawing board and really spend time to finally document and update the design; or 2) Go into panic mode, apply band-aids to gaping wounds and use fingers to plug holes in the dam.

More often than not, it’s option 2 that gets chosen because it has the illusion to be the path of least resistance. To a panicked and undisciplined developer, option 2 will result in spaghetti code. Lots of duplication, hard-to-understand functions, hard-coded values — the works. That IVR or routing app, once affectionately called a cute little furry critter, all of a sudden grows into a hairy monster who hasn’t showered in years. Instead of correcting the critical mistake when there was still enough time and resources, now it becomes a software development lifeless cycle in a death spiral. Get the picture?

Development

I’d also recommend a development phase with a more collaborative and peer-friendly methodology (a la Extreme Programming). Instead of a solo developer, engage two of them. Not only is this good practice in times of unpredictable situations (illness, family emergency, etc.) where a second developer resource is readily available to take over, but also having peer reviews or peer programming significantly reduces defects and shortens testing times.

I can attest to the effectiveness of a peer programming methodology even in a contact center project. A coworker and I were developing an IVR app together, and after coming up with the design we split the work into functional chunks, and sometimes even sat in each other’s cubicle watching over the other person code. We were able to quickly implement algorithms, point out each other’s mistakes, bounce off ideas, and even take over when the other person had to step away. As a developer it was a great collaborative and satisfying experience. We delivered the IVR app ahead of the deadline and with minimum defects.

Okay, I can see you PM types frowning, But there’s no budget to acquire two developers! In that case, instead of just a pure business analyst resource, acquire one who’s also an experienced developer (most developers can handle BA tasks well). Or let’s hope that you (the PM) can also wear a developer hat. Yes, that’s how much I believe in this aspect of software development, even in contact center applications. Two developer brains are definitely better than one. And if you really must have only one developer, you will appreciate the time spent in the design phase to produce a quality design document. (God forbid the lone developer leaves the project, right?)

Testing

When it comes testing time, make sure all documents are in order. Test against the documented requirements first, then turn testers lose to detect any exception conditions. The best testers will be those who fat-finger a lot but are detail oriented. If it’s a DTMF IVR app, make sure to go through all the menus and key combination. If it’s a speech app, make sure testing is performed with landlines, cell phones, loud voices, quiet voices — you get the idea. If it’s testing routing and agent screen-pop, make sure to simulate what a rookie (or absent-minded) agent might do. I’ve had heard horror stories of systems going live — after a successful system test and user acceptance test — only to fail miserably in the real world for various reasons. Reasons which could’ve been predicted and implemented during testing.

Your thoughts?

Do you think there’s a place for software development methodology in a contact center project? And what are your own experiences?