It was a busy summer Friday in Los Angeles when Ilkyung Karam picked up the phone and continued to chew his lunch. I was really lucky to have answers to my questions, but I was even luckier to discover how an engineering department of the world’s most famous cinema studio embarked on the course of Agile transformation.
The Beginning of the Agile Transformation Journey
Ilkyung managed a dedicated scrum team of around eighteen people across eight different areas of engineering. As you might have guessed from Ilkyung’s job role, management at the engineering department was pushing the Agile project management agenda. Since the new Vice President and Director of Engineering entered the office, the team has begun to use a pure Agile iteration-based methodology.
Ilkyung’s major responsibility was to lead the Agile transformation effort while managing the work intake for the internal network and engineering related infrastructure projects. At Disney, he was more of a general project manager, running projects in Digital Consumer Product Interactive department and using traditional Waterfall methodology. At his new role, Ilkyung was involved in full-scale Agile Scrum — daily scrum meetings, sprint planning, sprint grooming, review, and retrospective sessions.
When Ilkyung started working, he was assigned an uphill task — to migrate from old structureless management processes to Agile Scrum in a very siloed part of the company. Before new management came in, nobody was questioning how and why people were doing things a certain way and all tasks happened in silos with little communication and trust between team members. Ilkyung noted that the prior management system they had was merely a weekly meeting and an Excel spreadsheet. They neither tracked work on a daily basis nor they had a proper ticketing system. Ilkyung helped introduce Jira to the engineering team, simultaneously coaching them and the Product Owner on proper Agile discipline.
Agile Transformation Agenda
One of the first tasks on his agenda was to figure out the best Agile methodology working with the manager of engineering and most favorable sprint length and integrate daily sprint meetings to check on the team progress.
After determining that we would proceed with Agile Scrum, it was difficult in the beginning, because we started with a two-week sprint cycle and it felt very fast for the team. They were used to a much slower-paced environment, so a two-week iteration was too frequent and it did not work well for them. After two sprints, I decided to push for a three-week sprint cycle to introduce more breathing room between meetings that would allow the team to gradually develop optimal velocity. We then introduced “the daily scrum.” We started from meeting once a week and increased the frequency to meeting two to three times a week.
In the beginning during the transition process, you have to start slow, especially when you’re going from no system to Agile. You cannot suddenly go from meeting once a week to meeting every single day. It’s too abrupt. Do you know what’s interesting about this process? Back when I got my Scrum Master Certification when I was first learning Agile, it was only teaching you how to do Agile, it was not necessarily teaching you how to do a smooth implementation. That’s something I had to learn myself, through doing it. Anytime you make a big change, the smoother you are in the transformation process, the smoother the results are going to be.
Another prerequisite to successful Agile transformation is determining how to set up a process of making accurate task estimates. In this regard, Ilkyung has a set of recommendations. If you are working with a dedicated team, it’s a good idea to start using story points in Jira and estimate the volume of work in a measure using a high-level guideline that includes both time and complexity, as an example, a task that takes 1-2 days with medium complexity can be considered 2 story points.
If someone told me that a task is going to take 4 hours and in reality it took 20 hours, they are going to feel like their estimation skills are terrible. This happens all the time. It’s very difficult to estimate something accurately in hours before you actually do it but if you instead estimate in story points with the entire team’s input, then 90% of the time they’ll get it right. It’s a lot easier to hold people accountable with accurate and realistic estimates. The point system worked really well in the engineering department.
Story points, however, can be insufficient to rely on if you have a shared pool of resources. Today, many companies have offshore and outsource resources and a situation of multiple teams working on multiple projects. If all of them are crisscrossed between multiple projects, then, the experts recommend doing capacity planning in man-hours at the beginning of each sprint for each Scrum team. The key difference between capacity planning in Waterfall and Agile is that in Waterfall you generally do capacity planning once during the planning & analysis phase, while in Agile you do capacity planning every sprint cycle, in other words, every two or three weeks.
One of the options to make Agile transformation easier and more structured for large companies is to transform your shared pool of resources into a few dedicated teams. Even though the process can take some time and is challenging, your teams will end up more focused towards their goals. The first step Ilkyung recommends taking is to structure dedicated teams, for example, clearly delineate the work by breaking it down into projects, department areas or applications and assign people to them. That way you can reduce the chances of two resources duplicating efforts. This will also allow for quicker daily stand-ups via smaller teams.
The Challenges of Migrating to a Full-Scale Agile Scrum
Going from no system to a pure Agile was a true challenge for the team. People started to mount stiff resistance — during the first couple of sprints, the team was not happy having to learn a new tool to track their work. They just wanted the manager to let them do their job and trust without any visibility that it would get done. It was the old archaic way of doing things and a very ad hoc approach to management. What really helped Ilkyung to encourage the team was the fact that the other department, such as the software team in the Digital Media Archives group, have already been practicing Agile thanks to the department’s management push on Agile.
The crucial factor was support from upper management. Previous companies’ PMO where Ilkyung has worked at unfortunately did not support the Agile methodology. Ilkyung admits that if you first have support from the top, implementing Agile throughout the company is going to be a lot easier to accomplish. It took around four three-week sprints for the engineering team to start getting used to the new system and the results were immediate.
When I was measuring the team’s output velocity, I was able to determine how many points the team can produce every sprint and the team’s output after a few three-week sprints was equal to 45 points on average, which means that the team is collectively able to deliver an average of 15 points per week including bandwidth for contingencies and issues that happened on a weekly basis. This is a metric that the department never had before. Over the course of the sprints’ retrospective sessions, we noticed that the “what can we do better?” section was gradually getting smaller and smaller.
Migrating to Agile helped the company consolidate engineering resource efforts, see what’s happening at each step of a task’s lifecycle, and drastically increase overall transparency. It stabilized the process of continuous improvement and structured teamwork. However, according to Ilkyung, the biggest challenge in the project environment was not having a clear governance model and not having a clear direction on how to track all the projects from a program or portfolio level.
All I had was Jira and that’s great for managing tasks, but if you want to manage a program, a series of projects, and get a whole portfolio view of the entire timeline for multiple projects, we didn’t have a tool for that. Jira has a portfolio view plugin but we didn’t have that there. What saved us was Trello. Thanks to Trello cards, I have an airplane view of all the projects that are going on simultaneously. Each card represents one project and we can just have a very high-level view of the key resources, project descriptions, estimated timeline if applicable, and overall status (in progress or on hold).
To communicate project progress to management, the team met at the end of each sprint before they started the next sprint and shared all the progress they’ve made in the sprint, using the Trello board.
We were able to show every single project’s progress since the last meeting because we had milestones that we could check off and they could see the overall progress across the milestones.
Ilkyung is convinced that Agile Scrum is exceptionally effective, but the slippery slope of Agile is having a crystal-clear plan for the next iteration yet lacking the view of the big picture.
That’s actually what almost every Scrum Master indicates as the main challenge from my experience, and Ilkyung is probably not the last one on improving the visibility into the future of his projects.
What’s your panacea to seeing into the future in the Agile-driven environments?