Last summer, I changed companies. I had changed jobs before, but this time was different. Not only was I leaving a life of knowing everything (well, almost everything), but I also was leaving a product (LISA) I had invested the past 10 years of my life in supporting (like breaking up with a longtime girlfriend). Little did I realize then that I was about to start my Agile journey all over again. As a product manager, this journey was to take developers who were implementing cowboy methodologies to Agile Scrum. Along the way, we moved from JIRA and Grasshopper to IBM Rational and then to Rally (CA Agile Central) and managed not to lose all the stories and to keep some history of stories to source control for supported versions. The learning and the journey were amazing; there’s nothing like supporting a test product that drives Agile transformation but also helps your own development team adopt and understand Agile transformation.
Back to last summer, when I started my new position at Worksoft, I was coming from the custom app development space, where the focus had been on driving testing at the API layer and leveraging tools like service virtualization. I now had to shift my mindset to testing at the UI layer and orchestrating end-to-end business workflow tests. Coming from the world of DevOps and custom apps, I had never thought about testing at this level. At this macro level defects are viewed differently. As long as the defect doesn’t prevent the business from operating successfully and with reasonable speed, it doesn’t matter. My focus had always been on how to release quality code as fast as possible, not on how a business process is orchestrated across multiple homegrown and packaged ERP applications. It makes sense that you should not write your own accounting and sales order systems; the IRS frowns on that kind of creativity. Purchasing a packaged application to support core ERP processes is a better choice. This allows companies to focus their IT resources on competitive differentiation and building a trusted digital brand. We’re looking at the higher-level business process from the business perspective vs. data negotiation.
The Truth About Agile and Enterprise Applications
Thus, reality set in. I realized Waterfall is still the predominant methodology for managing change and implementing packaged applications. I get it that companies spend millions of dollars buying an ERP system and that these systems are complex and run critical business processes, but still, most companies started dipping their toe into the Agile pond over five years ago. Many of the customers I was speaking with were starting to throw around the term Agile and asking me how to become Agile. You would think these same large corporations that can afford to spend millions of dollars on a new ERP project would surely have started to learn about Agile and the pitfalls of Scrum for large, coordinated deployments. Every case study you read about regarding Scrum has the same basic plot – new idea, need to implement the new idea, cut the idea into themes that are important to the user, and break from themes to stories defined by customer value. This works well for new development, but when you have 10 years of customer requests and small bugs, it is hard to create a backlog that is not a mountain. As you can guess, moving from Waterfall, where you have just lists of defects and requests that can be easily ignored, to Agile, where you must review and rank them, makes the move daunting at best.
“Thus, I got my second big eye-opener on why so many organizations are still grounded in Waterfall when it comes to packaged apps. Not only are they purposefully slow to make changes, but the principles of Scrum and Agile fundamentally don’t support packaged application deployments.”
It should be a natural conversation between Agile and Waterfall managers that, with Agile, you build one small application and test and deploy it. When you install and configure an ERP that has to connect all the mission-critical workflows, you have to have a much larger coordinated effort. An inherited multi-application that needs to support the larger ERP workflows for end-to-end business processes should not be a candidate for Scrum. Scrum is good for a single backlog that services a single product. Trying to put all 20 applications needed for the end-to-end process into one backlog is just not practical.
SAFe – The “Safe” Bet for Enterprise Packaged Applications
SAFe, the Scaled Agile Framework, is the methodology we need to leverage for upgrades and/or deployments of large, connected enterprise-level applications, ERPs, and packaged applications.
SAFe extends Agile Scrum in five key ways:
- Teams create a program, portfolio management, and release planning.
- A tiered approach is used.
- The addition of the architect role.
- Each Sprint is not artificially forced into a production.
SAFe’s up-front acknowledgment that you need a release train that has an architect to coordinate the deliverables of multiple product Sprint teams makes perfect sense. The fact that a release train has a solid focus on the equivalent of user acceptance testing with the final Sprints to ensure the applications work together and are aligned to a business process further justifies why it is the right fit for testing enterprise apps. The portfolio planning in SAFe solves the problem of visibility to incremental completion and for long-running implementations; the progress is real delivered value vs. “not behind schedule.” I find it interesting that I am having these conversations with business people who are responsible for change management of their packaged applications and they are unaware of SAFe. SAFe is not a secret; it is well documented and was created because basic Agile Scrum does not consider all the moving pieces that require coordination and orchestration for a packaged application or ERP deployment.
The image below is taken from a recent presentation given by SAP in conjunction with the release of SAP Solution Manager 7.2. Solution Manager 7.2 SAP has fully embraced the principles of SAFe. The tiered approach does not force too much management overhead; it does a reasonable job of organizing the work. The image below shows the release train on the top, Sprints on the bottom, and waves in the middle. The basic layers and checkpoints of SAFe focus on what functionality can be delivered to the business sooner than using a Waterfall approach. I get it that the ERP doing financial accounting is not the sexiest software out there, but it is necessary to run the business. Those business users are important, but we tend to forget the back-office people.
Sprints have users’ stories that are groomed, and we estimate the amount of work that can be done in about two weeks, which is a stress reliever. With complex, interconnected ERP packages, you can’t create a bit of new functionality in two weeks. I think the next two layers are the most important. The wave allows users to see the features and changes early vs. the day of production, and the project allows the architect to line up features from multiple teams to make sure the end-to-end flow of data goes across multiple applications, the proverbial release train.
Quality gates just make sense to me. If we start to document the test cases early and QA is part of the Agile process, QA can start to automate their tests early, even at the UI. Then, the recognition that tests need to be run unattended from the build server to regress known working functionally can follow. The phases naturally imply that we have a deployed application and it is connected to the larger process. The more we build up our regression library and orchestrate end-to-end validations, the better off we will be when we push into production. This requires cross-application and team collaboration, which helps ensure the end-to-end works vs. my small part works. This is a great benefit of SAFe over Agile.
I love the idea of “waves of functionality.” I have always struggled with how to split a story into small enough pieces that we still have a user deliverable. I have heard coaching, like Sprint 1, adds the field to the database and pushes changes to production, and Sprint 2 builds the API that uses the database field and then enables the feature in the UI that uses it. That is just dumb; there is no real user value in adding a field to a database that no one can use just to keep a two-week Sprint with a deliverable. This is an example of an artificial push into production that does not provide end-user value like a wave should.
After all this, I’m left wondering whether Agile is still an island in an organization or whether SAFe is just the best-kept secret in applying the Agile principle to large, complex deployments with multiple actors. Given that I have moved into this space, I hope the secret will get out soon. Adding a little coordination and orchestration on top of teams sprinting in parallel for a larger release train sure seems like the best way forward in implementing the next major release or innovation in packaged applications and ERP packages.