Top Twelve Myths Around Agile Adoption In Large-Scale Programs

The advent of Agile methodology was hailed as a game changer by technologists and strategists alike. Wikipedia defines Agile software development as “an approach to software development under which requirements and solutions evolve through the collaborative effort of self-organizing and cross-functional teams and their customer(s)/end user(s). It advocates adaptive planning, evolutionary development, early delivery, and continual improvement, and it encourages rapid and flexible response to change” (link). In other words, Agile methodology promotes rapid implementation through continuous improvement and flexible development for successful business outcomes.

I have had the privilege of planning, executing and delivering projects and programs in the traditional waterfall methodology as well as in the SAFE Agile methodology at Cisco. The Scaled Agile Framework is a set of organization and workflow patterns intended to guide enterprises in scaling lean and agile practices. In this article, I will focus on a review of SAFE Agile adoption for enterprise-scale programs.  

 First and foremost, let’s agree on the basics. By definition, a large scale program is just that – “large and complex”. Any seasoned program manager will tell you that such a program includes hundreds, if not thousands, of interdependent components and system capabilities to manage. At the enterprise level, prudent portfolio managers would therefore break down these components into logically sensible and manageable epics. Typically, each epic is comparable to a traditional large project. Put another way, you can compare the work and effort involved in each epic to a construction project that builds multiple homes in a variety of architectural designs to stand up a community. Goes without saying then - it takes months to implement these program epics at scale with phased deployments every few weeks.

 In my assessment, while Agile Methodology works well for small to medium complexity projects, smart program managers would benefit from keeping the following myths in mind when adopting Agile practices for execution of large, complex programs.

1.    The scrum team size should be small

If you have undergone Agile training, you will know that the recommended size for a typical scrum ranges from a minimum of 5 to a maximum of 11 members. This makes practical sense for small to medium size projects and is a rule that should be followed. However, when it comes to enterprise-scale complex programs such as an Enterprise-wide Oracle upgrade, we need to acknowledge the sheer enormity of scope and the body of work effort required to pull it off. At the end of the day, there is only so much that a team of 5-11 can accomplish in a week or even a quarter. As such, you have two choices – keep the scrum size small but stretch out your timelines to give you more time or increase the scrum size and compress your timelines in the bargain.

2.    A scrum team member should take on the role of other members as the need arises

Since Agile principles are based on “self-organizing teams that adapt to changing requirements dynamically”, it is recommended that a member of a scrum team be knowledgeable enough to adapt to changing needs quickly as a sprint cycle or Program Increment (PI) progresses. As an example, if the Product owner is out on sick leave for a week or has moved on, the scrum master or an engineer should be ready and able to take over their role without impact to the sprint deliverables. That’s the theory. Here’s the truth - people tend to specialize in certain skillsets in the tech industry. As an example, a Java developer may understand ERP implementation as well as client-server architecture; however, expecting them to also understand the intricacies of the end to end business process flows with no direct interaction with customers is foolhardy. Similarly, developers are outstanding at coding but not great at assuring end to end quality of their code. In an agile-at-scale project, therefore, I would recommend that you allocate resources as required – if you need a PO, scrum master, a couple of business analysts, a tech lead, a few developers and a couple of testers, so be it. Allocate resources to roles based on their skillset and expertise. And have no expectation that a developer can be replaced by a testing team member. They cannot. Work with your management to replace people as quickly as possible. You would most certainly reap the benefits of such a decision as you progress through PI after PI.

3.    Incomplete user stories should be pushed to the next sprint or PI

One of the tenets of Agile methodology is to “trust that the scrum team will complete user story execution as fast as possible since they understand the details and hence the requirements best”. Again, while this principle is applicable to small to medium size projects, it takes a critical eye to spot the dangers of blindly following this tenet for large-scale complex programs. As I indicated before, since large, complex programs take time to implement due to the size and complexity of scope, complete reliance on the scrum team will manifest in huge risks and delays to the program overall. Why? – because no matter how authentically committed and dedicated your scrum team members are, they do not see the complete elephant – the big picture. They are ultimately only focused on their assigned scope – the set of user stories they are responsible for executing. It is precisely for this reason that product managers and more importantly, program mangers are critical to the overall success of a large-scale complex program. Every good Program manager worth their money understands this intuitively. They are wired to always look at the big picture, see the churn of interlocking cogs, identify those pieces that don’t quite work well and take corrective actions in good time. What should I do instead, you ask? – in the daily stand up ceremony, explicitly check for progress on user stories. If many are lagging behind, that is a red flag that you have a major obstacle in the path. Ask the tough questions – why?, when? How? And then work with your stakeholders to change strategy to reign in execution or pull together a plan of action to address it.

4.    A scrum team can estimate user story work effort with accuracy

Again, this is true for small and medium size projects. As part of estimation, story points are assigned to each user story prioritized for a PI / sprint cycle. This is the scrum team’s best gauge on how soon the team can complete the features and how many resources it will take to complete the work. The reason it fails in large scale programs is due to the sheer size, complexity, number of people and boundary organizations that you have to deal with.  For one, the single scrum team making the estimates is doing so in a vacuum – with minimal collaboration with other scrums and other impactful cross-functional teams across the organizations. As a result, when such scrums complete their PI planning and provide a DIRO readout, you will find them calling out a disproportionately large number of dependencies, issues, risks along with their objectives. Why? – the project scope is too huge with touchpoints across multiple organizations. The only possible thing a scrum team can do with their limited time (3-5 days per PI planning) is to call out what they see. The result – their estimates are typically far from the mark. The solution? – run a simple regression on your scrum team estimates, discuss the variance together with the extended stakeholders and refine estimates based on the “wisdom of the crowd”. I can assure you it works.

5.    There is no need for change control in Agile projects

If you inspect the Agile literature, it is clear that change control i.e. assessing and making decisions on new changes (creeping scope) is not discussed. That is because the agile, lean development idea is based on the pillar of “self-organizing knowledgeable scrums”. However, in a large-scale program with numerous interdependent cogs (components), knowledge is dispersed widely among many scrums and cross-functional teams. If you wish to make it to the finish line in time or earlier, I would recommend that you think about instating a change control board with associated decision makers and a regular cadence without further ado. This will not only save you and your stakeholders from unnecessary churns and waste of time and money, but also provide much needed visibility to the changes being planned for and implemented in dependent teams across the organization.

6.    Agile does not scale well in geographically distributed teams

Traditional scrum teams are supposed to be co-located - in the same time zone and in the same building and floor preferably. This allows them to participate in all rituals face to face, use the white board and Kanban board live and speed up the assess-build-learn cycle. In large scale programs, as you can probably imagine, there are a number of factors that limit a large team from working out of a single location. Some of these are the dispersion of business and IT SMEs in different geographic locations in a country or across multiple countries, budget constraints and lack of expertise in a specific location. Thus, scrum teams on large programs have no choice but to work across time zones and locations. On its face, this is a huge challenge to the teams with the potential to “bring the sky down”. However, it is also true that this can be worked out. Is it pain-free ?  Absolutely not ! But is it doable? Absolutely yes ! The solution for this one is a combination of structured stewardship, documented progress updates in user stories (after all, if you cannot talk to each other live in a scrum ceremony, you need to keep in sync with each other via updates in user stories, emails, meeting recordings etc), team discipline and execution rigor. This is where program mangers shine. It is critical for program managers to lead discussions on complex issues and and drive them to resolutions with collaboration and partnership up and down the chain of command,

7.    Budget portfolio management of large scale Agile projects is similar to traditional projects

Nothing could be further from the truth. While it is true that there are elements of similarities between traditional budget management and that of an Agile program, when it comes to large scale Agile programs, you would do way better by creating and tracking  budget and spend in alignment with the Agile team structure and resource allocation. What do I mean by that? Typical budget managers track all resources on an excel sheet in a linear format – row after row of resource names and titles. This would expose a long line of developers or analysts with associated costs. It would be very difficult to convince anyone, let alone the funding sponsors, of the need for so many resources. I have found that designing your budget sheets to resemble scrums and epics with clear costs and spends tracked against each is a sure fire way of getting a buyin fron sponsors sooner. No wasting time explaining why you need 65 different developers when they believe hiring 15 should suffice.

8.    Executives do not need to get into the details of Agile execution

It starts at the top. A company would not be able to successfully adopt and implement Agile methodology at Enterprise-scale without the right buy-in and consistent support of their executive sponsors. Before you go down this path, therefore, it is advisable to ensure you have your stakeholders aligned - to your vision, strategy, and even more importantly, to the challenges ahead. Your leaders need to set the right expectations within your Organization for the right mindset and behavioral changes to manifest. This will make your path ahead smoother in many ways, one of which is overcoming unforeseen challenges with confidence and support from your management teams.

9.    It’s impossible to track everything in Agile-at-Scale program epics

While Agile methodology advocates best practices to follow at the Epic and ART levels to assure quality at scale, one would do well to “extend” these to include additional team rituals for better outcomes. For a successful implementation, it is critical for the team to invent a practical mechanism to list and track the thousands of business capabilities / IT components in a comprehensive, easy-to-use method. One could leverage tools such as JIRA, Rally or even a simple powerpoint or excel sheet to implement such a mechanism. You can reap rewards with your stakeholders and peers by adopting and following through on such a mechanism.

10. Adopting Agile methodology at scale means compromising quality

While Agile advocates best practices or rituals for a scrum master, product owner, product manager and Release Train Engineer to follow for quality assurance, it is important for the smart program manager to realize that these are not fool-proof at the end of the day. In large scale projects, for instance, it would be prudent to allocate a sizable chunk of time on your program roadmap to quality testing – integration testing, end to end testing, system performance and load testing, business acceptance testing and user acceptance testing to name a few. The program manager should leverage this window of opportunity to plan ahead, look around the corners and get everyone on the same page consistently and frequently. This is hard to do, and involves drawing from your experiences from prior programs-at-scale or learning on the job.

11. Program management is overhead and unnecessary for Agile programs and projects

This is a na?ve thought in my opinion. Would you say that a contractor is not required for a large scale home community building project? Even if you hired the best-in-class technicians, plumbers, masons and the like, you would need someone to connect the threads, provide general oversight, play “dive-n-catch”, and manage and resolve everyday issues that come up. It takes grit, courage, disciple, flexibility and determination on the program manager’s end to drive their large scale program epic to successful implementation and delivery. They need to be ready to morph their skillsets to provide oversight on multiple fronts -be a coach, a leader, a problem solver, a technical analyst, a business analyst, a quality assurance engineer or a change management lead. Many times, you would find yourselves facing challenges that no one thought about, that become roadblocks to your roadmap and timeline, and you would need to collaborate up and down the chain to come up with mitigation options and resolutions. This is not a role that everyone can fit in therefore. It takes a person who can multitask well , connect the dots intuitively, spot missing pieces or connections, can take calculated risks, is able to communicate to clarify, has the courage to deliver unwelcome news to executive sponsors , has the discipline to keep everyone and track everything, and perseveres through the ups and downs of such a journey.

12. You can map roles in Agile to traditional roles in waterfall methodology

Though traditional waterfall (SDLC) and Agile methodologies have some similarities (they are both leveraged for executing and implementing solutions to achieve business outcomes for instance), that is where the similarities end. Agile methodology adoption calls for a change in mindset that should permeate the entire organization for successful outcomes. You should not assign an agile role to someone based on their limited understanding of the concept and without proper training. If you do so, you run the very heavy risk of defeating the purpose of agile which in turn will take you and your team down the rabbit hole of operating in a “pseudo-agile” world. Can you still expect results? Sure, somewhat, but don’t be surprised by the level of chaos in your organization and the delays in schedules, again and again .