Agile Scaling in Action

Working as part of an agile team is only one element of an enterprise agile dev/test environment. For larger dev/test outfits or larger projects, companies can roll up individual agile teams into one agile environment at enterprise scale.

The biggest reason for adopting agile at scale is that despite the fantasy that a collection of agile teams will somehow organically integrate to deploy a program, that is not the reality. Just as agile promotes effectiveness and optimization at the team level to produce value and results, enterprise-scale agile development promotes the same things at the program level.

Scaled agile allows individual teams working in silos to pool resources and priorities and shift accountability from their specific team or function to the project as a whole. But this is not easy. For some business cultures it feels akin to, say, asking the finance department to willingly take a back seat to the marketing department in support of a top company objective, and not only that, but to lend their time and expertise to the marketing department to advance progress! The balance sheet can wait--the brochures must go out! Hmmmm….

We worked with an ecommerce leader in the online gifting space (annual revenue of $500 million) as they successfully scaled agile, encountering the resistance you might expect and adjusting as they went. This client did not follow a specific prescription for scaled agile but rather looked at the available options and best practices and adopted what worked for them, making changes along the way. Working with them as they undertook the challenge gave us some visibility into what works, what doesn’t, and how to pivot toward success.

Moving to a scaled agile environment

This ecommerce company had 6 agile teams all working independently in support of the same project. The project involved functionality-driven teams (like sign in, checkout, gift options, message, delivery, payment, billing, and review) coordinating efforts among each other to serve several interconnected online brands. Individual teams were agile and comfortable with communication, collaboration, and shifting priorities, but the idea of applying this level of collaboration outside their own territory was foreign. Scaling agile felt like the difference between collaboration among states in the same country vs countries in the same world. There was an altogether different level of higher thinking, inclusion, and patience that was required.

But the costs associated with opting not to attempt to scale agile appeared to outweigh the challenges of scaling. Because these teams weren’t agile among each other, many of the benefits of an agile environment were lost in miscommunication and non-optimized interdependencies. The project was faltering with almost zero tangible features complete and accepted end to end. The hope was that by scaling agile to enterprise level, the project would gain traction.

The company rolled up 6 individual teams of 3-10 into one team. Their general approach was to define short iterations with tangible value to the project as a whole; and to engage flexible team members willing to deploy diverse skills depending upon the sprint, skills gaps, and team interdepencies. They were intentionally not wedded to a particular formula for scaling agile, but rather decided to go at it in a somewhat iterative way, modifying teams, meetings, and approach based upon team feedback and data analysis.

At the same time, each individual team continued to have their own daily standups and their own scrum master and technical leadership. The goal of scaling was not that the individual teams would become obsolete but rather that individual teams would work in concert toward one project.

Practices and tools this ecommerce company deployed from the get-go or added as the project progressed that encouraged successful scaled agile included:

Single backlog: Initially each of the 6 teams had their own backlog. For scaling agile they rolled all team backlogs into one backlog. They needed to define priorities the same way they would on a smaller team, but because multiple sub-teams were involved, they needed a way to allow priorities and interdependencies to be visible. A single backlog achieved this. Now they had to take smart action on a single backlog. This is where the product council forum came in.

Product council forum: The product council forum operated on a strategic level and met every day for an hour. The forum maintained a culture of alignment among all teams by focusing on these areas:

• Top priority items
• Current sprint activities
• Unplanned items
• Decisions to be made at the program level and across teams
• Grooming for the next sprint including two scenarios:
  • The case where one team needs something from another team to complete the next sprint. For instance, Team A needs something from Team B within sprint 14 in order for Team A to complete their task in sprint 15.
  • Reallocation of inter-team resources: Looking to future sprints, one team might need skills not present on their current team. Discussion here surrounded moving individual teams and team members around as necessary to support top priority items.

The most critical role of the product council forum was to introduce and reinforce the somewhat dramatic cultural shift from a department- or team-specific allegiance to a project-specific allegiance. This of course meant that if, say, the most effective way to get the project done right was for department A’s requirements to supercede department B’s requirements, all stakeholders had to see this and support it, including lending time and talent where necessary.

Scrum of scrums: In the same way that the single backlog was strategically managed by the product council forum, individual team scrum masters needed to effectively roll up into one concerted scrum. This is where the “scrum of scrums” came in. This was a group of scrum masters representing all teams within the scaled agile environment. This group worked at a tactical level focused on executing. The group met every two days and discussed expectations, blockers to progress, and any issues among or within individual teams.

When introducing the “product council forum” and the “scrum of scrums,” the company met with some skepticism from team members. What came to mind for many team members was a whole lot of red tape and bureaucracy--”decision by committee” gone wrong. Indeed, if members are not fully engaged and committed to using the sessions as an avenue toward open and egoless sharing surrounding priorities, skill sets, blockers and opportunities, the groups won’t work. Agile at scale works by applying good business practices to the project not just in words but in deeds.

An important addition that the client made to address the skepticism around scrum of scrums and product council forum were actually more meetings, not fewer! These additional, ad hoc style meetings were designed to address concerns at the individual level. The idea was to underscore that for this client, scaled agile was about putting people first, and the project success follows that. So client actions needed to reinforce this priority, not just at the lead level but at all levels of each team member. Two sessions were started: “lean coffee sessions” and “agile coffee sessions.” These were informal opportunities for team members from any team and any position to discuss concerns, issues, and suggestions, both technical and interpersonal. The sessions helped to spread the scaled agile culture organically, not from top down but from bottom up.

The agile coach (discussed further below) played a critical role in shifting existing expectations of what meetings were about, from theoretical debate and opinion sharing to hands-on decision making and immediate action. When the meeting members saw that these meetings resulted in real-time action and open communication, they engaged and movement began.

Active reporting: By the same token, many team members were used to data gathering as a sort of passive reporting tool that didn’t impact their day to day work. But in scaled agile, data gleaned from team and project performance is only as good as the use the project puts it to in real time. This is where active reporting comes in. Again, the role of agile coach helped team members to view data as an active not passive tool.

Scaling agile requires data collection on a macro and micro level, data analysis, and real-time response. In the case of this company, statistics and data were gathered for the project overall and for each team supporting it. Data tracked included:

• Number of story points completed (velocity)
• Aged user stories categorized by reason, e.g., “blocked”
• Dependencies across teams
• Outlook for project completion based on past performance for all previous sprints

This level of reporting required enterprise tools that gather data at the program, team, and individual levels. The company was already using TFS for code and bug tracking, and found it easy to use it for program level reporting as well. The important thing is that the tool has to be used at all levels and for the type of reporting and retrospective you’ll need, you can’t rely on an Excel Workbook or Word doc.

Analysis of the data happened in a retrospective at the program level, the team level, and the sprint level. The resulting actions included merging teams, splitting teams, and changing team members. The ad hoc lean coffee and agile coffee sessions helped in making these transitions smart and smooth.

Agile coach: This role was played by an external person in the case of this company but can be played by either an external or internal person depending upon skill sets. In the case at hand, the agile coach introduced and inspired the enterprise agile culture, encouraged and enabled teams to perform, and guided teams toward alignment including internal and external teams, management, and other stakeholders. The agile coach provided a critical role in moving team members from the old mindset to the new.

What didn’t work in scaling agile

In order for these 6 agile teams to work among each other effectively this ecommerce leader had to correct a few liabilities:

Failure to put people ahead of the project: The cultural shift from project to people is at the heart of this client’s successful move to scaled agile. Without that focus the client could not have engendered the inter-departmental and inter-team trust and respect necessary to gain traction on tasks and sprints. The coffee sessions were initiated to address this element of the shift. Concerns needed to be heard and addressed at all levels in order to everyone to feel they could trust a higher system.

Failure to deal with data: The active reporting and retrospectives involved in agile at scale show where the problems are and often how to address them. When they looked at the data the company found that at times the problems were caused or solutions blocked by the very people who complained about them the most! When analyzed, not just gathered, the data demonstrated this.

Failure to use a tool that would allow them to scale: The company had individual agile teams that wanted to scale agile using an Excel Workbook. In this case the tool became the blocking point. It was necessary to move all teams to a TFS environment.

Failure to invest in alignments and visibility: Some project participants tended to look at the meetings as a waste of time, whether at the coder level, scrum master level, or stakeholder level. They assumed that the meetings wouldn’t result in honest disclosure and immediate action. Commitment to the Council and the Scrum of Scrums process, along with the transparency that makes them work, became a requirement for project involvement.

Failure to set expectations among team members about what being agile means. Scaling agile successfully is a function of the framework and the people; success requires both. This company found they needed to source, select, engage, disengage, and transfer to achieve the right team dynamics. They set the expectation internally and with external stakeholders that if a team member wasn’t able to demonstrate the required skills and attitude, he or she would be a hazard to success and would be deployed on another project immediately. The company actively declined or transferred:

• Single-minded team members who wanted to work with blinders on, performing their tasks within their defined skillsets and nothing more
• Team members who were not genuinely interested in constantly adapting to a changing environment
• Team members who were not committed to constant communication with others to gain information and feedback would hamper the project’s overall effectiveness

Path to Success

Agile at enterprise scale is about delivery and control. This company’s results speak to delivery and control outcomes:

• At the beginning of scaling, the first 2 sprints were an investment in building the teams, the tools, and the product backlog. Sprint 4 was the start of delivery. At Sprint 6 the team started to show consistent delivery. Velocity data meant knowledge and predictability about when each team would deliver the upcoming features assigned to them.
• Prior to implementing scaled agile, almost zero tangible features were complete and accepted end to end. As implementation got underway, aged user stories dropped from 80% to 50%, and finally leveled off at a steady and accepted rate of less than 10%.

The numbers are there and just as importantly, the culture of collaboration, trust, and empowerment that were necessary ingredients for these numbers to be reached has resulted in a larger group that is committed and engaged more than ever. By modifying the platform based upon characteristics of these team members and this project, the employees were able to own the scaled agile process. The client saw both a successful project and a culture that will support more of the same. 

About the Author

Yousef Awad is CEO and has enjoyed a successful and inspiring career in programming, database administration, and project management. With over 130 full-time employees, Integrant provides custom .NET software development and test teams, allowing IT departments to stay in control of their projects and expand their internal teams effortlessly. Beyond Integrant, Yousef’s passion is to bring the power of programming to children and young adults.  Yousef is working towards giving younger children access to coding classes that provide real-world, hands-on mentoring. He welcomes discussion. Please contact him at: info@integrant.com.