Product Development Leveraging SAP Agile Kanban
With the delivery of DataXstream’s OMS+ 3.0 we have had to completely rethink our approach to software development and delivery to match the speed at which we can solution. Our traditional tried and true waterfall methodology was an anchor to our software delivery team. As we researched our options we found that Agile Kanban delivery methodology was the closest match to how we worked as an organization. I was also very familiar with the concepts of Kanban having worked as an engineer at a tier one automotive supplier that leveraged Kanban in its manufacturing processes.
DataXstream’s OMS+ enables complex order management processes and point of sale in SAP. Unlike other OMS/POS solutions on the market, OMS+ resides directly in SAP and saves its transactional data in STANDARD SAP tables. Our team’s ability to solution new functionality is significantly accelerated because of this. We leverage existing SAP capabilities for our user interface backend and therefore do not need to spend time developing complex backend functional components and integration points to other external ERP solutions.
Picking a software delivery approach was really the first step for us because we still had to figure out how to make it work within the context of SAP software delivery. For all our products we leverage SAP’s add-on assembly kit (SAP AAK) to package and deliver products to our SAP customers. SAP recommends a 4 box landscape to properly, code, test, package, and validate for customer installation. This software landscape configuration lends itself very nicely to a waterfall delivery methodology. So the challenge was how do we leverage this best practice configuration in an Agile delivery format.
Our first challenge was deciding how to document and manage our delivery process. We settled in on a number of products offered by Atlassian to accomplish this. We implemented Atlassian’s Jira software using their Agile Kanban templates for requirements management. We also implemented Atlassian’s Bitbucket solution for source control of our UI content and integrated requirements tracking with Jira. To manage our release strategy and automated test execution we implemented Atlassian’s Bamboo product. We also got lucky when we looked at how we would integrate4 this with our existing customer support tool Kayako. Our support portal supported direct integration with Jira so that bugs reported via our production support team could be pushed to Jira and linked to the support ticket in Kayako. We actually considered switching our production support tool to Jira Service Desk but Kayako actually had better integration than Jira supported between its own tools and Kayako supported a multiple customer configuration better. Maybe just say “We considered switching our production support tool to Jira Service Desk but Kayako had better integration between its own tools and offered better support for multiple customer configuration.”
Our next challenge was how could we run an Agile Kanban delivery process within a traditional SAP landscape and traditional SAP AAK packaging process without slowing down our delivery. The answer was to implement automated testing for both product testing and customer delivery and validation processes. Automated testing allows us to release incremental new functionality from development to our test system and then regression test the entire product from top to bottom in a matter of minutes. The new functionality is manually tested to validate its function and then added to our automated test teams queue for development of new automation scripts that will be leveraged in future regression tests.
Today the process of releasing SAP transports and recompiling the UI components is still manual. However the next phase of development includes status based triggers that will automatically release transports into our test environment, recompile the UI, and kick off automated testing. This approach allows us to release new functionality and retest our entire OMS+ solution multiple times a day if required. Once new functionality has been validated in our test environment we release the changes to our consolidation environment for packaging leveraging the AAK. We don’t create packages for every new change that is released to our consolidations environment. We package under 2 conditions. We have hit our quarterly release window and it is time to package a new release or we have a customer that requires new specific functionality prior to an official release window. This approach allows us to delivery new software continuously to our SAP customers and still maintain high quality levels of our solution.
This approach has resulted in our development team pulling our 2 year OMS+ software delivery plan into about a 9-month window. This has had a number of other unintended consequences; keeping our development backlog organized and current requires significant effort to keep up with the the rate at which our delivery team solutions. Our marketing team is also struggling to keep up with the rate we are delivering new functionality. In fact as I write this our current marketing is at least 3 months behind our current product.
All of this was made possible and made to work by the amazing team that supports this development process at DataXstream. Our speed is driven by the team’s ability to solution functionality with a future proof mentality and unmatched design and development skills. The software development process we have implemented was designed to provided the controls we need to deliver high quality software and not become an anchor on the development teams ability to deliver new software quickly. We have implemented a continuous delivery process within a traditional SAP software development framework.
We hope you will stop by our booth this week at SAP TechEd 2016 and check out OMS+, learn more about SAP agile kanban, and learn about our SAP consulting delivery practice.
