3 Keys to Merging Agile, DevOps & Staff Augmentation

3 Keys to Merging Agile, DevOps & Staff Augmentation

How do you enable an IT organization to support a fast-growing technology company while also building a scalable delivery organization that will last? This was a question asked to me recently and I thought I’d share some of my learnings that I’ve faced for decades now while working with development and management teams at large, fast-paced technologies companies like Salesforce and Splunk. 

First, IT organizations have been at the center of corporate transformation since the beginning of the industry, but it’s important to note that IT organizations have also been transforming themselves as the industry has evolved. Thus, it can feel like an IT organization is changing the tires on a moving car ⎼ entirely possible but challenging.

The following are a few strategies that I’ve used to produce results at scale within a fast-growing company.

  1. Product vs Project: Transforming IT for rapid growth and scale requires a pivot from delivering projects to investing and maturing a product portfolio.
  2. Agile and DevOps: The benefits of Agile delivery for your SLDC have been well documented, so I won’t go into this here, but there are few practices that I’ve found helpful to mature your Agile delivery.
  3. Resource Strategy: Agile requires a fundamental shift from pure outsourcing or managed services to a staff augmentation strategy.

Let’s take a deeper look at these key points: 

Product vs Project 

This isn’t about whether your company provides products or services. It’s about how you view the actual delivery processes within your organization. Projects by nature are temporary endeavors that have a unique set of requirements that need to be delivered within a specific budget with specific skills. Organizations that are purely project-driven tend to have waterfall delivery practices that are constrained by the scope, schedule, and the cost of the project, irrespective of the value being delivered. This means as long as the project is on time, does what was specified in the requirements document, and isn’t over-budget, it’s a success. However, this doesn’t account for whether the right thing was delivered. As a byproduct of these practices, the organization adopts a culture that creates isolated views within their ecosystem that limits the learning opportunities to build competency within the organization for the long term and increases overall delivery time. 

Products, on the other hand, are items or services that serve a customer’s need or want. It’s important to note that I use the term product (tangible) interchangeably with service (intangible) since technically a service can be a product too or at least carry elements of a service. IT organizations that align delivery to products tend to have strategic roadmaps centered around a single product or a group of products that are funded with long-lasting teams that are chartered to drive to the right outcomes for the business. 

Long-lasting teams serve to create deep competencies within the organization which allows the organization to adopt change more rapidly and deliver outcomes faster. Why? All teams need to go through Tuckman’s 5 stages of group development ─ Forming, Storming, Norming, Performing, and Adjourning. However, long-lasting teams centered around one or more products stay in the Performing stage more often than a temporary project team. Think about it, if for every project a new team is formed internally with existing people, consultants, contractors, or any combination of these, it requires people to learn what the objectives are and why, find direction from leaders, build trusted relationships, and understand how to work together effectively. By the time the team has reached the Performing stage the project is over and the project team disbanded. In addition, the knowledge acquired throughout the delivery has moved on to another project or worse, out of the organization all together leaving a competency gap.

Both project and product mindsets have distinct advantages and disadvantages, and to be honest, developing a culture centered around products is easier said than done. However, when your organization adopts a product-first delivery approach, you are telling your stakeholders that you are committed to maturing their business capabilities and investing in your people. At the end of the day, this strategically delivers the right outcomes and strengthens the overall business. 

Agile and DevOps, Not Agile or DevOps

Before we get into the next key point, we need to get clear on Agile and DevOps. These two software development approaches share a similar goal: getting the end-product out as quickly and efficiently as possible without sacrificing quality. 

Agile works toward that goal by using methodologies like Scrum, Kanban and Extreme Programming to deliver short and incremental development cycles. DevOps works toward that goal by combining software development (Dev) with a company’s operations (Ops). It’s less about a process and more about a fundamental change in a company’s culture. The main takeaway here is that Agile and DevOps are complementary.

As discussed above, I like to structure teams around a product or a group of products that support business capabilities. Teams that have a dedicated mission that align to business outcomes will not only drive better results for the business, but tend to take more ownership and accountability than temporary project teams. In terms of Agile, teams should have the flexibility to practice an Agile methodology that works for their product delivery, such as Scrum, Kanban, and/or Extreme Programming. However, I do strongly recommend that teams practicing Scrum align to a 2-week sprint iteration. This elevates many cross-functional planning and dependency management issues and creates a predictable delivery cadence for business stakeholders. In addition, there are a few software engineering practices that support our Agile methodology, such as pair programming, hybrid engineering, and test-driven development. 

However, these agile and engineering practices require a DevOps culture to reap the benefits. This means automating everything to have repeatable delivery processes from code merge to production deployments so that software engineers can focus on what they do best ─ writing code to solve business problems. The DevOps engineers focus on building what’s called the Continuous Integration and Continuous Deployment (CI/CD) pipelines, which includes automating infrastructure, specifically AWS infrastructure. From a functional reporting structure, having a DevOps team operate and function as a shared service for the organization will provide consistency in approach, toolchains, and process, as well as provide a career path for DevOps engineers while being cost efficient for the business.

The biggest challenge isn’t getting Agile and DevOps to work together, but rather changing the organization’s culture to work with DevOps. Since it’s normal for organizations to have silos that are very defined and very comfortable, it’s also normal for those silos to see DevOps as a threat. That’s completely understandable because DevOps can change reporting structures and how teams are defined and operate. Changing a corporate culture is never easy, but the big opportunity in implementing DevOps comes when you get leadership trained, educated, aligned, and committed. The bottom line is that both Agile and DevOps work together in harmony so that teams can fulfill business demands quickly in a cost effective manner to deliver on the right business outcomes.

Resource Strategy

Adopting and implementing Agile and DevOps product teams in your IT organization will get you a long way toward transforming your company so it can grow and scale for the future. However, this is an investment not only in the methodologies and practices your organization uses to deliver work, but more importantly, it’s an investment in your people. When you start out on this transformational journey you may not have the right skills and/or competencies in teams to deliver the business outcomes you’ve committed to delivering. As a result, the quality of the products and services you’re delivering may suffer. Delivering subpar products that don’t meet business objectives, even during a transformation, isn’t an option. Doing so can quickly erode trust with your users and stakeholders. This is where a strategic partnership with a trusted supplier who understands your products and services, your specific Agile practices, and DevOps goals, can help you along the journey. Here are a few things you’ll want to consider prior to forming that strategic partnership with a supplier. 

Staff Augmentation
Staff augmentation is a flexible strategy that enables you to hire contingent talent globally while managing your augmented team directly. Traditional IT organizations running waterfall delivery methodologies tend to employ more managed services from consulting companies. This method outsources the responsibility of development, testing, maintaining, and supporting a range of processes and functions in order to cut expenses. Unfortunately, this removes subject matter expertise from the organization and in my experience, isn’t necessarily as cost effective as it looks on paper. In Agile, rather than outsourcing the work through a managed service you’ll want to pursue a staff augmentation strategy that enhances your in-house team’s skills and abilities. All too often organizations pivoting from waterfall to Agile try to use waterfall practices, such as managed services, to staff teams. Unfortunately, this will not work and your organization will suffer a long slow death march with its Agile initiative. The takeaway here is that a pivot to Agile requires an organizational shift from a traditional managed service model to a staff augmentation model in order to supply the team with the necessary skills and competencies to deliver on the team’s mission.

Learning & Development
Another consideration to take into account when determining your resource strategy is the competency of the supplier’s workforce and their ability to teach and learn. While this seems straightforward, it’s something that is easily overlooked. Thus, you’ll want to ensure that the supplier meets your in-house job level competencies so as not to devalue or disrupt the team you’re augmenting. I advocate sharing your in-house competencies and programming standards with your supplier early in the engagement so they can recruit and hire staff that meets your delivery expectations. In addition, you’ll want to follow the same interview rigor you do for full-time employees, this includes any programming or coding assessments you may have established. While the hard skills are important, you also want to evaluate the soft skills. One competency I look for is the ability to teach and learn. The ability for the contingent staff to teach the in-house team the technology and/or skills they possess is critical for long term team success. However, this is a two-way street, the in-house team needs to be able to also teach the contingent staff about their internal standards and processes (e.g. test-driven development, compliance, etc.) or what I like to call “institutional knowledge.” This two-way teaching and learning is the biggest benefit to the organization as it creates a learning culture that can really give the organization a competitive advantage to meet market opportunities when they arise.

Timezone Proximity
I’ve managed both large global Agile teams, as well as small local Agile teams. The way you structure your practices, tools, and processes will largely depend on what timezone your core business or headquarters is in. The further away your supplier is from your core business, the less agile and more complex your delivery will be. Agile purists will tell you that all Agile team members need to be located in close proximity to one another to be effective. While I don’t disagree with this, it may not always be practical or cost-effective for an organization. In addition, what the COVID-19 pandemic has shown me, is that teams can be just as effective working together remotely as long as they’re in a timezone friendly proximity. 

How far away a timezone team members are will largely be an organizational decision. However, for a frame of reference, I set up my teams to have at least a 3-5 hour overlap with where my core business is located. This will allow in-house team members across the US and my strategic supplier to collaborate effectively in real-time. So if my core business location is San Francisco (GTM -8) I’ll want to be GTM  +/-5 of San Francisco. This will allow teams to practice our Agile methodology without early morning or late night transitions that can create team burnout.

On-call and Incident Response
A core DevOps practice is that teams must have clear, well-documented on-call processes to keep these complex systems running smoothly. Integrating the development and operations into the team helps the team to make better decisions about their products and services they build because they must also support them. Both full-time and contingent team members need to play a role in the on-call rotation and incident response. Thus, it’s important that this expectation is clear from the get go with your strategic supplier and that they are willing to support this level of commitment to your products and services.

Tips for Making Staff Augmentation Excel
Even before the COVID-19 pandemic, staff augmentation required making an extra effort to keep your in-house and contingent team members working together as a cohesive unit so that they continue to mature in Tuckman’s Performing stage. However, in our new reality of social distancing and with internal team members working remotely, it takes even more effort to connect and engage everyone professionally and socially. Here are a few techniques that I’ve found helpful in connecting my organization:

Disclaimer: While the techniques below describe in-person interactions, these are on hold until post-COVID, but the suggestions have been adapted during the pandemic to include virtual get togethers with similar results.
  • Social Hours: Trusted relationships don’t just happen with teams through the osmosis of work. Humans need other outlets to get to know one another. Individual teams are encouraged to self-organize social events weekly, bi-weekly, monthly – whatever makes the most sense for them. In addition, as a broader organization, we come together to socialize once a quarter. We eat, drink, and play games. You’d be surprised how much it helps build relationships with teams and individuals across the organization.
  • Volunteering: I’m a big proponent of giving back to the communities we live and work in. Every quarter we come together as a team to volunteer our time to a non-profit of my organization’s choosing. This can be an online event or a local event where groups of team members can meet and connect for the greater good in person.
  • Quarterly Awards: As part of my employee recognition program, both full-time and contingent team members nominate each other for various awards we’ve defined. Our award committee chooses the winners based on the submitted nominations. Rather than giving out a generic $100 gift card, we’ve come up with awards that align with our cultural values, whether that’s the “R2-D2 Award” that supports our Innovation value or the “Morpheus Award” that supports our Passionate value. Winners receive a cool Zoom background that they can show off during meetings.
  • Periodic Fly-Ins: Nothing brings a team together more than face-to-face conversations. Each quarter we fly in teams to spend a week working together side-by-side pair-programming and white boarding solutions together. We’ll also schedule time during that week to go out for dinner and/or drinks. This not only helps to put a face to the name, but also continues to build trusted relationships.

As you can see there is a lot to consider when building high-performing global teams. Partnering with a strategic supplier that understands your delivery methodology and practices will only help you to reach your business goals sooner. 

Conclusion
So, how do you enable an IT organization to support a fast-growing technology company while also building a scalable delivery organization that will last? By adopting a product mindset, combining Agile and DevOps practices, and partnering with a strategic supplier that can support your staffing needs. Yes, it’s a big challenge to implement and there will be bumps along the way, but I’ve found this to be the best and most effective approach out there.

Connecting The Customer Success Platform

Dreamforce 15: Connecting The Customer Success Platform

This year I had the privilege to present at Dreamforce ’15 on how we’re tackling enterprise data and integrations at Salesforce.com. This is a business operations topic where many companies are struggling to make sense in an ever-shifting and growing landscape of data, technologies and software architectures. Each organization is different in how they try to solve this complex problem. This presentation showcases how we at Salesforce.com approached data integration in a high growth, fast paced technology company.

(more…)

The Programmable Enterprise

The Programmable Enterprise

Salesforce continues to grow at a 30% rate year-over-year. As a result, our data silos continue to increase across the company. This is especially true when companies are acquired and incorporated into the overall Salesforce ecosystem. In order to continue to support a $20B dollar company by the year 2020, our internal data integration infrastructure and architecture will need to be modernized to support the volume of business needs while curbing operating expenses. Our vision is to connect the business to data that they can trust, when and where they need it, so that the enterprise can continue to scale and innovate. This document describe in detail how this will be achieved.

(more…)

Why Point-to-Point Integrations Are Evil

p2p-integrations

Salesforce has been growing at 30% year over year. In order to grow at this rate while supporting the business, IT has had to make compromises. Many of these compromises have been to defer infrastructure and architectural investments to a later date. Unfortunately, over time, IT will become the bottleneck or worse, the blocker for the company to deliver services to our customers. The diagram below depicts a representation of the current state of the P2P integrations within Salesforce. Unfortunately, at the time of the post, this is the internal infrastructure that the company relies on to run a multi-billion dollar a year business.

(more…)

Data Integration Technology Selection Considerations

integration-technology-selection

The purpose of this document is to help guide and inform IT project teams to the correct integration platform for projects. Note that this is only a guide, as there can be multiple options based on the integration activities. Use the matrix in this document in conjunction with input from the Enterprise Architecture Review Board (EARB) to select the appropriate technology.

(more…)

The Self-Service Data Delivery Integration Platform for Next Generation Companies

data-delivery-strategy-banner
Not long ago I presented at the MuleSoft TopMule Meetup ’14 in San Diego, CA, on an initiative I’m running at salesforce.com called Free The Data: Transforming The Way The Business Connects To Data. With approximately 400 MuleSoft employees in attendance, MuleSoft has doubled its size in just one year. It’s a testament to the industry demand for their integration and API solutions. My talk centered around how we are aggregating, exposing and simplifying access to internal enterprise data.

(more…)

Why IT Budgets Promote Point-to-Point Integrations

why-soa-fails
Today many IT departments have a hybrid of legacy on-premise applications and newer, more innovative Software-as-a-Service (SaaS) business applications that they need to manage. Salesforce.com is no different; we have a lot of SaaS and on-premise applications that we use to run our daily operations. Our Enterprise Application Integration program has a number of use cases that we support, but can be consolidated into two main concentration areas: 1) System-to-System Data Exchange, and 2) API Data Access.

(more…)