I have brought Agile SCRUM into my development organizations at two companies which fully embraced the concept, process and long term benefits of using this methodology. In both cases over time, the adherence to the agreement eroded and degraded over time to a point where SCRUM was just a label for how we were creating software. In retrospect, the success of the process initially was the cause of its demise.

The first company had created a suite of products prior to my arrival which evolved over time into the big ball of mud pattern. The first order of business was to create a development infrastructure which would manage the code artifacts, reliably build and install the product and a framework which could execute integration level testing. There was no hope initially of anything like unit or interface tests. Once this was accomplished we designated a “day zero” for the transformation from an ad-hoc process organization to an Agile SCRUM organization. We literally stopped the company for an entire day to teach Agile process and the infrastructure we would use going forward in support of developing a cohesive and evolvable product.

The first order of business in that new world was to build tests. We refactored what existing tests we had and created macro level integration testing to ensure the overall product was performing the core competencies correctly. From this point we integrated a number of customer specific code bases along with some rogue development source code repositories into a single and well managed code base. This left a number of client specific capabilities missing from the now unified product. By involving our professional services organization into the process of analyzing the gap in capabilities we were able to alter how customers used the product allowing them to achieve the desired result. It must be said that there were a number of features which had to be added quickly to the core by moving code from the now defunct branches.

Now that work was complete and customers had the new unified code in place, leadership could not stop singing the praises of Agile. We had stories and sprints, standups and retrospectives all around a work spike to get us to a manageable baseline. To me this was not product development in an Agile framework and it set a foundation for expectations that would result in lost confidence in the process.
Previous to “day zero”, client feature requests had been quickly implemented into the fractured code base and testing would only cover the new feature and not the product as a whole. Now, new features had to be engineering into the unified code base and test coverage enhanced to support core areas and the new feature. The work took longer and more existing defects in the code base were uncovered. Leadership saw more work and less output. Story backlog increased at a rapid pace as we looked at promised features and got a handle on the amount of rework required to stabilize the code in support of the new features. The good was overall quality increased, the bad was the delivery dates began to be pushed out.

Sales and professional services had provided customers with their guesses on delivery dates based on the old development process of delivering bolt on, untested product. Their viewpoint was correct, given the same development staff, we were now going much slower. Customers had yet to see the difference in product quality as they had only taken a few minor updates since the unified code base was created. It was easy to talk about the longer term benefits of how development was working and difficult to show the value today. Engineering was happy, leadership and sales were not.

The real test of what we had created came when we partnered with a customer to create a new product which would integrate with our existing product. A blank page on which to prove the power of rapid iterative development driven by testable requirements / stories. We managed the project well, had great stakeholder interaction and quickly brought the product to delivery. Leadership was delighted with the results and asked the question, “Why is this (process) not working on the core product?” Great question.

I have found the most difficult behavior to change when adopting new processes is setting and communicating the impact of the new reality. My zeal for obtaining buy in to this new process by painting a beautiful picture of how things would be overshadowed the work required to put everything in place to be able to create the promised picture. I underestimated the time required to stabilize and refactor the existing code base. I did not provide appropriate guidance to the sales and services teams about costs and timeframes for promised deliveries. I knew what we could achieve and failed to genuinely understand the overall effect on the business in undertaking this quick and radical change. It was the right thing to do and I could have done it differently. I believed at the time the only way to achieve this was through radical change, “day zero”.

I have learned a lot since that time, left that company to pursue other challenges and yes that company is still in business and doing well on a unified code base. Today I would:

I believe this would have achieved a more graceful approach into good development practices and let the company decompress slowly into the new reality. What I did was bring the “diver” to the surface too quickly and the result was the “bends”. I need to remember that change and transformation take time even with the utmost dedication and excitement.