The latest fads and trends seem to blast onto the scene with a focus on the upside but often there are delayed downsides lurking. In the world of software development there always seems to be a creative way to mess up or miss-interpret a great new practice. There are many articles about Agile Development’s positives and negatives from a development perspective. Google is all about Agile and it seems that every development organization will at least tinker around with Agile trying to emulate Google’s success. But let’s face it, replicating Google’s culture, bank account and stranglehold on a cash cow service (search) is nigh impossible. SaaS (Software as a Service), vendors are especially into Agile. This makes sense! In the world of SaaS (e.g., Google), Agile is especially effective since software distribution is not an issue (there are challenges with this in SaaS but they reside largely within the walls of the hosting group, more on that in another article).
Vendor service and support organizations often find themselves in the middle when it comes to Agile trying to balance the need of the vendor to get product to market quickly and the needs of the customer base to actually understand and gain value from the new features.
Figure 1 Customer Support helps balance the Speed versus Value Trade Off
There are particular challenges with Agile when the support and services organizations attempt to swallow the hyper output of the latest bunch of Michael Phelps warp-speed coding sprints. The issues reside in a number of areas that impact service, support and customers directly. These issues/questions include:
Were customers really involved – or is this sprint for an R&D interpretation of need? While the Agile manifesto proselytizes the direct involvement of customers, vendors often decide that they know what the customers want and act on their behalf.
What does “done” really mean? Often, new builds are rolled out with new functionality but documentation, implementation guides and training, i.e. “support and service readiness”, is not there when the new code is released to customers.
Does Agile only really work for SaaS? Is it good for packaged software vendors who distribute code as well? SaaS vendors tend to roll out code regularly as a result of regular code sprints and it is relatively easy to switch on/off beta test versions. Packaged vendors can do this as well but the code will likely be beta tested and batched into a few update releases. While there is certainly strong value in regular builds and smaller sprints, the packaging and distribution issues still loom large.
What if customers (SaaS and packaged), don’t want to use the new improved version because of the risk it carries (bugs, retraining, new processes)? Having multiple revisions running around negates much of the value of SaaS and creates nightmares for packaged software vendors. This can end up being mitigated by configuration switches that turn on or off new functionality but this has its downsides too if it gets out of hand.
Is there a swim lane/Sprint for fixing bugs in the current functionality? Understandably, developers generally prefer building new functionality over fixing the old stuff…who wouldn’t? But this may not be what the customers actually need! If customers are still trying to get “Feature A” to work, why would they want you to foist “Feature B” on them.
Is there a lane for supportability, e.g. for addressing and reducing the primary reasons customers contact support? While initiatives around the “Customer Experience” get a lot of interest, they often don’t get funded. Development is often still incented on getting the latest and greatest “quarter saving” feature out rather than making the experience with the current products better. While it is tempting to focus on the new stuff, if a vendor is serious about Customer Experience, they need to make the investments in making their current products easier to use and support. If customers call the most trying to use “Feature X” then there must be a team dedicated to knocking that out. This is not an all or none item but vendors should ensure that they regularly “chip away” at reducing or getting rid of the reasons that customers need “help”.
Should Services be in the Scrum? In many ways customers are going to be equally impacted by both the new product feature and supports ability to support that new feature….YES, support HAS to be in the Scrums. That being said, their role has to be clear to the other Scrum members and especially to support and services themselves. They can’t be passive observers…they have to be in the game. The solution the customer needs is a “whole solution” that includes all the things they need to make it work…this is much more than just the code and service and support is the best organization to understand that.
Summary
The creators of the original “Agile Manifesto” (Ken Schwaber et al.) cited two specific points that are of interest in this context. They are:
- “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”
- “Working software is the primary measure of progress.”
It is important that these statements work together in concert. In some situations they can be at odds with each other. I would argue that “working software” is only part of the way there…this goes back to defining what “Done” is. While we shouldn’t try to “Boil the Ocean” or develop only in the “Big Bang Waterfall” model, vendors should see the deliverable as a bit larger than “working software”. …Think “Whole Product” that includes things like reasonable end user documentation, training and the like. Bringing in the pragmatic view of customers and the services and support organizations is critical to bringing quality solutions versus just code to the market; we must be closer to the customers actually trying to gain business benefit from the solution!
The responsibility is not on development alone, services must develop service and support readiness processes that augment and become a part of the Agile Development process! The combination and collaboration between development, services and customers is what will win the gold medal here! Remember the old saw – if it seems too good to be true it probably is.
Leave a Comment