The Journey of Agile Transformation at Cengage - Lessons Learned
INTRO
Cengage is an education and technology company built for learners. Around 2013, the company was starting to transition from print to digital and a systems development lifecycle (SDLC) had to be chosen. In the publishing world, a 2 year release cycle was considered normal. Agile was chosen since a two plus years go to market strategy was no longer sufficient. Agile is not the final goal, it is only the means to reach the REAL GOAL, which is to provide students with digital, high quality, affordable solutions.
Although you could go Digital and use any SDLC to get there, as I learned over the last few years,Digital and Agile go hand-in-hand.
Just to show how far Cengage has come, releasing after a 2 week sprint is normal these days and some teams release even more frequently.
The purpose of this blog is to share the LESSONS LEARNED over the last 3.5 year of Cengage’s transformation. It is organized by FUNCTIONAL AREAS as well as SPECIFIC TOPICS and I hope readers can easily find the information that is most relevant to them.
TRAINING
My Cengage interview with Jason Chin, VP of Software Development happened in August of 2015. I was hired as the first Agile Coach (in this particular wave of transformation initiative) and my job was to train folks on “Cengage Way”, which is Cengage’s flavor of Agile adoption. It is based on Agile values and principles, as well as Scrum. In addition, it includes the nuances of content being part of the solution along with a very specific selling cycle at Cengage. It had recently been rolled out by Jason Chin himself, partnering with then Chief Agilist at Eliassen, Damon Poole. Over 150 people from various business units and functions across Cengage, including members of the leadership team, were trained on agile principles in a 2 day intensive offsite that took place over the summer.
This training was developed around Agile and Scrum, with special focus on communication, and included highly respected guest speaker, Dr. Ethan Becker. His very impactful talk was recorded and used in later training sessions. Within the first 6 months, with help from Cengage Champions (see section on Agile Coaches for more details), over 500 people were trained on Agile, Scrum, Importance of Communication and Collaboration, and most importantly the “Cengage Way”,
“The Cengage Way is the foundation for the way we build software and develop content. We take an iterative, collaborative approach to ensure predictability and transparency, keeping our customers at the center of all we do.”
The demand for team specific training sessions got so high that eventually, we kicked off what we called “Agile University”, which included training such as “Intro to Agile”, “Epic Workshop”, “Scrum Master Training”, “The Role of a Manager in Agile”, “All about Refining” and more!
By 2017, our team grew to 12 Agile Coaches! One team member was entirely dedicated to training and 3 others gave a percentage of their time to teaching, building and strengthening Agile University.
There are many different roles at Cengage that are part of the Cengage Solution. To ensure that all involved could collaborate together and understand each other’s world, everyone had to be trained on the Cengage Way.
At this point, any employee could join a Scrum Team and understand the language and the mechanics (scrum ceremonies, Jira backlogs, user stories, acceptance criteria, personas, etc).
AGILE COACHES
When Cengage Way was first rolled out in 2015, there were no dedicated Scrum Masters or Agile Coaches. There were folks with roles such as Business or Systems Analysts, QA Engineers or developers, but when needed, they were wearing hats of Scrum Masters and Product Owners. There were also about 30 Cengage Way Champions across the organization who had full time day jobs, but due to their knowledge, skills and passion for Agile, they were volunteering to spread the awesomeness of the Cengage Way across the org in their spare time. It worked for some teams, but for the most part, the progress was very slow. We had to become transparent and predictable and we needed to do it fast.
A year into my training on Cengage Way, running retrospectives for different teams, facilitating project kick-off sessions and providing occasional 1:1 coaching, another member of the leadership team was hired. Eric Spear joined Cengage in July 2016 and his vision for the transformation has forever altered my career and of course made a turning point for Cengage.
As I mentioned earlier, our team grew to 12 Agile Coaches.
QUALITY
In order to shorten the time frame for product release, several processes had to be improved and streamlined. Quality Assurance was one of them. In my first few months, Jason Chin and I sent out a survey to understand potential gaps to better prioritize the first set of goals. One of the interesting discoveries after a bit of data analysis was that our QA engineers ONLY tested the changes that came to them through Jira; however, not all of the work was actually tracked in Jira by developers. One might argue that it is faster to just fix something than go through the formality of creating a ticket, filling in the details (aka acceptance criteria), and assigning it… When you have large number of people involved, spread across many time zones and locations, it is impossible to ensure high quality code without ensuring proper testing.
There isn’t just software quality at play since the solution Cengage provides to Instructors and Students consists of a Platform (Software), which “serves” Content. Not only does the Software have to do the right thing, be user friendly and display the right content, the content itself has to be high quality. Many people are involved besides the developers and qa engineering. There are authors, subject matter experts (can’t test the content of the Calculus quizzes or Physics problems if you don’t know the subject), media producers, content engineers, and there are folks that actually convert textbooks to different digital formats so it can be read by different platforms. There are folks that (only after software and content are done, and all has been integrated and tested) create the actual courses that can be used by instructors and students. It is a very complex world and the more people are willing to learn, collaborate and communicate across teams, the more successful you can be as an organization.
In October of 2018, survey results showed that most teams track 100% of their work, consistently measure their velocity and in general showed that the mechanics portion of the Cengage Way was in a very good shape. Hurray!
ARCHITECTURE
Architecture was another area that required business process improvement. Six months into the job, Winter of 2016, I sat down with Doug Mealing, the Chief Architect for a quick chat. We talked about some of the challenges. Architecture often being an afterthought was one of the challenges back in 2016. Teams were making decisions without understanding the impact to the overall solution. Requests for architecture decisions often come in at the last moment, Jira user story by Jira user story without having a chance to think big. I mentioned DAD (Disciplined Agile Delivery) framework to him (something that I myself only learned about a few days prior) and he read the book that same night. DAD focuses on becoming Enterprise aware, with delighting customers being the center of it all. A few of us flew to Philadelphia and took the 2 day training form Scott Ambler, who is the co-creator of DAD. After the training, we introduced the roles of Application and Enterprise Architects. They are integral at bridging the gap between the Architecture team and the Product team. Aligning them at the onset of a new idea or product. The team consists of around 20 architects that spend three hours each week making sure everyone understands the big picture, as well as nuances, dependencies and potential solution implications on different platforms/teams. From that point on, during Cengage Way trainings, we always talked about the importance of being Enterprise aware. We also used the concept of the inception phase in DAD to make sure Architecture has enough of the runway.
At the same time, the initiative of embracing the Service Oriented Architecture (SOA) was in full swing. Here is the insight from Doug on that,
“Our SOA implementation allows for the ability to extend the services, not only by updating the core code itself, but also allowing teams to write and deploy their own plugins. This allows for more parallel development and delivering more business value than the traditional approach of one team updating a single service, which often results in bottlenecks. As our systems are content-driven, Cengage’s SOA was built in a way to optimize content delivery, allowing the content to be treated like source code, with it’s own Content Development LifeCycle. The content can support custom extensions, by the same teams building the custom SOA plugins, and it has governance built in, where the content extensions can be reviewed and approved prior to use in Production.”
There was also a decision made to become a React.js shop when it came to the new development and create a roadmap to transition existing applications to React.js from Angular. Doug explains his vision for going React.js,
“React was all about allowing content to drive the UI components that get launched. We were originally using Angular.js which is slow and requires pre-loading all the components in advance, which was inconvenient for content driven dynamic UIs. With React.js, we can load UI components on the fly, so we built a UI registry where the content could indicate the component to launch, and the registry would have the platform specific component launch information. This also allows different platforms to have different component variations, but still reuse the same content.”
PMO
Our delivery schedules are very much dictated to us by our industry. New products/features need to be delivered for “selling season” in the Spring and all revenue generating products have to be delivered and ready by the first day of the Fall semester. We cannot deliver a partial product on the first day of school, thus it is extremely important for us to keep track of what we plan to deliver and communicate with the stakeholder.
The Program Management Office was spun off in parallel with the Agile Organization in September of 2016. We had to define the roles and envision how they would compliment one another. It is not very common to have both, a PMO and an Agile Org, or at least it wasn’t common in my experience. What made it more difficult is that among the Directors of Engineering, the experience of working with Program Managers varied and thus there was some resistance. With time however, it was proven that in a company this big, Program Managers were extremely valuable. We experimented with Agile Coaches working closely with the teams making sure the Cengage Way was followed and scrum ceremonies were run efficiently. Program Managers worked with Product Managers and Architecture to make sure the work was well defined in the pipeline ready for teams to pick up. Program Managers also kept track of large milestones and communicated progress to the executive team and all the stakeholders. They ensured transparency on the organizational level while Agile Coaches focused on teams. It worked and it still works. It is worth mentioning that most Program Managers have many Agile Certifications and some Agile Coaches come with the Program Management background. The real magic happens when everyone has the right mindset, wants to solve problems and willing to fill in whatever the gap might be at the time of need! And we created that exact environment!
CONTENT ENGINEERS
Content Engineering is a role which is not known to many developers and qa engineers who haven’t had the experience working in a publishing company. When you look for engineering talent, you focus on their ability to write code and to work with others. Engineering Managers have to be technical and also be able to lead people. Publishing experience is a huge plus, but it is the last requirement. Thus, the role of a Content Engineer and the impact they have on the solution as a whole is often misunderstood. Cengage Way captures the fact that at Cengage, our solutions are SOFTWARE + CONTENT. Most Scrum Teams at Cengage include a Content Engineer. It is very important for Content representatives to have a seat at the table from the very beginning to understand the requirements and think through potential solutions from the start, just like with Architecture.
PLANNING A RELEASE
When I delivered my very first training on Cengage Way (covering basics of Agile and Scrum) in November 2015 to the Content QA team in Farmington Hills office, I realized how complex this business is from anything I had done before. Imagine all the typical nuances of developers working with QA with quality suffering because they are always at the end running up against a tight deadline.
Now imagine another layer to this madness where just building software doesn’t do much for the user. You can have developers and QA folks working hand-in-hand delivering the highest quality software and it DOES NOTHING for your customers because your customers rely on a SOLUTION, which includes high quality content that actually WORKS WITH SOFTWARE! Now imagine if the content is being created in a complete silo and software is being written without the real content to test it until the very end. If issues are discovered, it is often too late to fix because when you are in the business of education, September 1st comes whether you are ready or not!
Thus, we had to experiment with something that would allow us to bring ALL involved together. We experimented with the concept of “One Team” where members from all the business units came together, sat next to each when possible and had a clear common vision of the Business Value they were bringing to the customer TOGETHER. “We win as a team, we fail as a team” was part of the mindset of the Cengage Way.
As far as mechanics, we experimented with Release Planning Sessions (aka Program Increment (PI)planning from SAFe framework). It was a very successful experiment for where we were in our journey and we ended up running PI Planning for all 24 (at the time) teams in July of 2017.
We are also experimenting with measuring Epic Cycle time now. We are not at the point where we could drop measuring velocity just yet, but measuring Epic Cycle time is a different technique for forecasting or in other words, creating a potential release plan. It also forces us to pay closer attention to how often we actually bring value to the customer.
DEVOPS
Cengage is a matrix organization, which means teams such as Agile Coaches, PMO, QA, Content Engineers, System Analyst and DevOps are shared services. We haven’t reached a point at Cengage yet where any team member could push a button and the code ends up in production (it does sound kind of scary when you say it out loud:); however, the mindset has shifted a lot in the last few years towards Continuous Integration and Continuous Delivery. Like I mentioned in the introduction, releasing after a 2 weeks sprint is normal these days and some teams release even more frequently. Some teams (with others to follow soon) have now moved to Pivotal Cloud Foundry, which makes Release to Production much easier. Continuous Deployment is a good goal to have!
PREDICTABILITY
I already mentioned the importance of stable teams, tracking all the work and measuring velocity. Going back to earlier years, there was an interesting challenge that existed in 2015. Six months into me joining Cengage, our CTO wanted to chat about predictable delivery. “Why is it that our teams don’t feel comfortable estimating Epics and committing to deadlines?” he asked. We could speculate for a long time since there are many reasons for why people don’t feel comfortable estimating their work (i.e.the fear of being wrong). We decided to test out different theories and separate the Product Requirements from estimation techniques in hopes of understanding the true root cause.
He actually worked with me to design a workshop where we took an existing product which was developed in Flash (and potentially had to be rewritten), asked participants to watch the demo, come up with Epics, go through the exercise of estimation and discuss challenges. He listened and shared his experience. He understood that it was mostly the fear of the old code that they were building on top of and dependencies on other teams that made them feel uncomfortable estimating. The evolution of how our teams are organized now, what they work on, the technologies they use is all based on leadership listening to the feedback.
LEADERSHIP
While it is common for engineering teams to be formed, trained on Scrum and left to their own devices, it helps to have leaders show the true passion and results that are needed to impart a change. It is possible to “sell” the benefits of Agile to the higher ups, but to be successful in the transformation, the Executive team has to be on board, align on the values and principles, and truly believe that this way of working is the only way to stay competitive. They need to understand Servant Leadership and need to lead by example.
IN CONCLUSION
There are many tools and frameworks that help achieve the mechanics of an iterative approach and collaboration. There is also a mindset and culture shift that has to happen and I would say that’s where the biggest challenge was during this transformation. People needed to understand why they needed to change and be willing to embrace it.
We were hugely successful! We brought cross-functional teams together and trained them so they could work efficiently together. We achieved predictability, so we could deliver in a more sustainable way. We became a React.js shop and embraced SOA, so we could scale. We used Agile to get to our true goal of delivering high quality affordable solutions. We truly disrupted the industry with releasing Cengage UNLIMITED in 2018 and we were able to do it because of constant collaboration, constant communication, very clear vision, transparency and most importantly TRUST between Product, Engineering, Marketing and Sales organizations.
P.S. As long as this blog is, there is a lot more to share. I haven’t covered the topics of Product Management, the roles of Systems Analysts or Engineering Managers in Agile and many nuances and challenges that TEAMS have faced and worked through. Maybe one day I will write a book, but for now, reach out for any specific questions and I will be happy to chat!