Implementing Office 365 at Cisco – Part 2: SAFe Bought Us Speed, Visibility, and Accountability

As we continue on our journey to the cloud, Cisco IT is rolling out Office 365 to 118,000 employees. You can read about our vision and strategy in this blog.

Our implementation has two unusual angles that might give you ideas for your own move to Office 365. First, rather than using Office 365 as-is, we integrated it with Webex Teams.  (Read more about that here.) Second, we managed the implementation using the industry standard Scaled Agile Framework (SAFe). Though SAFe is more typically used for software development, we found it worked very well for structuring and organizing our complex deployment of Office 365. 

Why SAFe?

Cisco IT has been using Agile development for some time—and had started to invest in Agile at scale using SAFe – the most popular blueprint for scaling Agile teamwork. However, when it comes to a Program like Office 365 which has a mixture of implementation, development, infrastructure elements and a relatively high degree of unpredictability, it is hard to know what approach is most beneficial.

After looking at the options, we decided to use SAFe. The majority of the Program team and Exchange SMEs had very limited experience with Agile, but they agreed—with some skepticism—to give it a try.

Forming the teams

And so, shortly after the initial planning workshop, I (as the appointed Product Manager) drafted a proposed Program Backlog (prioritized features list) and together we formed the team structure that would comprise our Agile Release Train (ART) for Office 365.

We formed three scrum teams:

• Core enablement: email and calendaring, setting up infrastructure and tenant management, getting the core network ready and preparing the processes for Mailbox migration.
• Security: Active Directory security, endpoint security, authorization and authentication, mobile mail, and legal and compliance. We later split this team in two as the Backlog became too large for one team to manage.
• Productivity: desktop productivity applications, mobile productivity applications, document sharing and collaborative editing, integration with Webex Teams, Office 365 groups, and data and insights.

We also formed two scrumban teams, providing them with more structure than Kanban teams but less planning overhead than full Scrum teams:

• Operations, support, governance, and finance
• User experience, communications and organizational change management

We provided basic training on Agile methods. After that, team members continued learning on the job.

Forming the team of teams

All of the teams function together as an Agile Release Train (ART)—a “team of teams” that plans, commits, and executes together. The Product Manager organized the Backlog, set priorities for user stories, and the Release Train Engineer facilitates the process. We come together every 12-weeks and plan our next Program Increment and then each Team functions with a high degree of autonomy in between. To keep information flowing between the team level and the program level, teams enter their Backlogs into a third-party tool (CA Agile Central) so we could see all progress in one place. And our regular ART checkpoints keep the information flowing – bi-weekly System Demos have proved especially effective for making sure that the entire Program is aware of the latest progress and developments.

We scaled up very quickly. Just three weeks after we decided to use SAFe, the teams went to work. We are now about to complete our 5^th Program Increment and would expect to see perhaps another 2 or 3 full PIs before we start to ramp down somewhat.

Winning over the skeptics

Make no mistake: SAFe is a very big cultural change, and some of our team members were apprehensive in the beginning. It helped that we had strong support from our IT leaders and a team receptive to trying new and unfamiliar ways of working.

Overall, whilst not perfect, using the SAFe framework for our Office 365 implementation has worked well for us. Teams like having autonomy and being in control of their own Backlogs. At the same time, the ART gives us structure, cadence-based “just enough” planning, visibility and accountability.

One of the drawbacks we faced was difficulty in achieving predictability i.e. we might plan a certain amount or work for a Program Increment but it is hard to be accurate about what can be done. The unpredictable amount of Operation and Support work in a deployment of this type can make accuracy even harder. It’s also quite hard to get people to adopt new work habits, like updating Rally regularly. When they don’t, the visibility breaks down.

The cultural transition is challenging. Learning to act as a Product Owner and have accountability for all angles of your product takes time. Managers need to respect the Prioritization process and not add ‘extras’ outside of the process. Team members must learn to self-prioritize and know when to share small chunks or progress rather than waiting until the end.

Over time, achieving maturity with SAFe will help ease these challenges and drawbacks though. Our next goal is to help scrum teams get better at predicting what they can achieve (story point estimation, in Agile-speak)—and when (velocity management).

Read more about our security considerations in a blog by my colleagues Jason Freeth and Dave Jones.

Questions? Similar experience? Please share in the comment box.