The most common question from prospects and clients is: “What can/could we do to lower implementation risk?”.

I suppose this is actually a polite form of the question: “What can software vendors do to make implementations go better?”.

Well, based on the lessons learned from dozens of “post-mortems”, there is a clear answer.

KANA is Agile. By that, we mean KANA relies on the Agile Scrum methodology to drive our development process. But, we also mean that we try to have an agile mind-set, and core to the agile philosophy is a willingness to be self-critical in order to be self-improving. Like all agile organizations, we work in ‘iterations’ – sprints (in agile speak) of work effort each taking 3 weeks. After each iteration, we try to do, as agile prescribes, a ‘Retrospective‘. This is the agile vocabulary for the tried and true notion of a project post-mortem. And, of course, we similarly do post-mortems on our large implementations of KANA software.

Interestingly, lesson #1 learned from post-morteming these internal and external post-mortems is that building and deploying software have a lot in common, and must overcome a single, shared enemy: the inclination to ignore ‘speed & simplicity‘ until far too late in the cycle.

Agile has a principle that you do the hardest, riskiest work first. The core principle of great software design is ‘simplicity and speed‘. Yet, over and over, we re-discover that these related principles are insufficiently baked into project plans. In building solutions to manage the customer experience, the hard and risky work is building a user interface (UI) that is ‘simple and speedy’. So, all Agile learning dictates tackling the twins of performance and usability early on, tackling it in partnership, and not leaving these nasty bits to the tail end.

Why do most Retrospectives in our industry end up re-discovering the importance of focusing on speed/simplicity in the early days? Clearly, there are powerful reasons why performance/usability are often deferred to what then becomes the “bitter end” of a development/deployment cycle. If it was easy to get to speed and simplicity early, failure to test wouldn’t be the root cause of so much distress, failure and need to learn.

Here are the key reasons I hear at the start of projects for not biting into the speed & simplicity challenge from the outset of implementations:

The dumb reason: Why test for performance and usability until we have something near complete?

Consciously choosing not to worry about the hard stuff because the hard stuff won’t be, by definition, fully baked until just before go-live is just plain silly. Early testing is the canary in the coal mine. Testing an incomplete implementation doesn’t prevent performance or usability problems from cropping up later on. Early focus does, however, insure that performance or UI issues at the core of the implementation are uncovered in time to fix them. Last minute issues are usually correctable without enormous pain; architectural difficulties aren’t. Failing to utilize the canary of frequent performance & usability experiments is simply negligent, and usually results in the mine of your project exploding. Early testing delivers early learning, consistent with the Agile goal of ‘failing fast‘. If there is one central difference between a well run project and one flirting with time & cost over-runs, it is a commitment to test for speed/simplicity early and often. Our VP of Professional Services says “If we aren’t thinking about performance on Day One of the project, we’re already late”. Right on!

The waterfall reason: Until we are done with design, we can’t test.

Usability and performance testing are central to the design process and a successful design.

The common reason: We have to get stay on schedule, and if we pause to deal with performance and usability, we’ll be late.

The siren’s song of staying on time is the Number ONE reason cited in post-mortems for delaying the pain of user-centered testing. But, on examination, this reason doesn’t hold much water. What’s actually being said is that the schedule wasn’t built with the idea of early testing. In other words, the project plan is mis-guided, and that mis-guided plan is then used to justify a mis-guided approach. If the plan was constructed around the principle of doing the tough stuff first, then the only reason doing the tough stuff first can cause lateness is the tough stuff was under-estimated. Better to face up to that reality than run the project in dream-mode and take what will be the much bigger (and unexpected) delay at the end.

The logical reason: Getting set up to do usability and performance testing is a bear and takes time.

Even with the best of intentions, there are many barriers to conducting user-centric testing. By the time the environment, scripts, software and artifacts are ready for even “preliminary” testing, the project may be quite far along.  There is no denying the challenge of being ready to do the hard testing soon enough. However, there are well-worn best practices for over-coming this difficulty:

a) Have a pool of performance environments that move from project to project, minimizing setup and provisioning (KANA is now doing this in the Cloud)

b) Make the production of the artifacts necessary to do testing critical path. This often means focusing on getting something ‘thin’ working end to end instead of going deeper, quicker. That trade-off is goodness, however it appears to stake holders, and should be embraced.

c) Accept the canary idea.  The goal of the early testing isn’t to prove the system will perform in production. By acknowledging that early testing is not a substitute for go-live testing, the requirements for getting started become manageable. By lowering the mark, earlier attention to speed/simplicity is possible.

The lesson of all too many post-mortems around software deployments is clear:  either pay the small price for worrying about speed and simplicity early, or pay a huge price late.

(Mark Angel is EVP and CTO, KANA)

No related posts.