Agile in the Enterprise – How to Act Locally and Develop Globally

Image_Blog Defining Service Transformation

As the Enterprise Agile coach for PTC, I’ve spent the last 10 years training and mentoring Agile teams in large enterprise environments. Along the way, I’ve learned some hard-won lessons about the intersection – what some call the paradox – of Agile and enterprise environments.

The Agile movement has revolutionized software development, in large part by its focus on getting teams of software developers to work together more effectively. The basic idea of Agile development is that software should be delivered incrementally, in easily digestible chunks. This in turn encourages early feedback so that requirements can continue to evolve as development proceeds, maximizing value to the customer.

The Agile approach was originally designed for very small, self-sufficient teams working in close proximity to each other. Not surprisingly, implementing an Agile transformation in an enterprise environment is much more challenging. Large and geographically distributed teams are often needed to produce the complex solutions required by enterprises. The team gets even more complicated when contractors, partners, customers or suppliers are involved in the project.

Enterprise development teams are often subject to additional scaling factors, such as regulatory compliance, domain complexity and technical complexity. When we go about implementing Agile processes in larger organizations, we need to assess where the company stands with regards to these scaling factors, and implement processes and tools to address them.

Large teams utilizing Agile processes need to share information as easily as if they were working in adjacent workspaces. Communications tools such as videoconferencing, white boards and instant messaging can make it easier for large and dispersed teams to communicate. It’s also important to provide a tool to manage access to artifacts such as requirements documents or user stories. Tip: It often helps to organize teams so that members are in similar time zones, and to alternate meeting times so that the pain of having meetings outside normal working hours is equitably shared.

Agile is modelled around self-organization, which makes it particularly important to address the cultural differences that arise among enterprise “teams of teams.” When multiple organizations are involved in a project, each of the organizations tends to have its own, sometimes conflicting, objectives, culture, and organizational structure. In my experience, the best way to break down these silos is by creating opportunities for cross-group integration and transparency. Establishing cross-organizational groups at the senior level as well as in key functional specialties helps foster a clear understanding of team roles and a greater appreciation of each team’s distinct strengths and capabilities.

For most of our customers, regulatory compliance plays a critical role in enterprise software development. For example, FDA Title 21 CFR Part 11 requires drug makers and other FDA-regulated industries to implement controls for software and systems that are involved in processing data that is required by FDA rules or used to demonstrate compliance to FDA rules.

I can’t stress enough: Compliance needs to be baked into the process in the leanest way possible. Most development organizations tackle a wide range of projects, and not all of these projects require the same degree of rigor. In one enterprise Agile transformation, we created decision matrices to determine what level of rigor was required for each project. For example, on a high risk project the team might be required to create a detailed design for management approval while on a low risk project it could make design decisions on its own. This is an area where our own ALM tool, PTC Integrity, really shines, as it allows you to quickly customize any team process and easily transform it into an executable Agile workflow.

Two additional challenges that are often present in enterprise software development are domain complexity – complexity of the field in which the solution operates – and technical complexity – complexity in the way the solution works. Let’s look at each in turn.

Domain complexity is addressed by engaging experts in the same discipline as the end users of the software – such as engineers, doctors or bankers – into the development process. For example, PTC Creo is tested by mechanical engineers who know how to design complex products that exercise the software to its fullest extent. Learning mechanisms such as Communities of Practice can be created to make better use of the subject matter experts within the organization.

Technical complexity, requires frequent integration and early testing which are, interestingly, the core tenets of Agile transformation. I once worked on the Agile transformation of a team responsible for delivering a project that involved Java, C#, and a proprietary development language. We kept the project on track by creating a new build every day that ensured integration of each of the technologies.

Disciplined Agile Delivery (DAD) is a recent Agile software development approach that can aid in the transformation of enterprise development teams. DAD extends the construction-focused methodology of Agile development to address the complete end-to-end delivery cycle from the initiation of the project to the delivery of the completed solution to the customer. DAD goes beyond producing potentially shippable software to producing consumable solutions that solve business needs.

In the end, Agile development requires changes in culture and attitude as well as changes in tooling and process automation. For Agile development to succeed in the enterprise environment, developers need to stay true to their self-governing ethic as they work closely with enterprise professionals. They should also leverage enterprise assets. Achieving success means focusing on the right behavior and learning environment as well as the best process and toolset to enable Agile teams to act locally and develop globally.

This entry was posted in Agile Development, Integrity and tagged . Bookmark the permalink.

2 thoughts on “Agile in the Enterprise – How to Act Locally and Develop Globally”

  1. Jim Winder says:

    Wonderful article Dave. I’d like to talk w you about Agile and the demise of the Requirement. I work with some companies that have abandoned Requirements almost altogether for User stories. I see some real danger there.

    1. Dave Dame says:

      I agree, it is dangerous. It’s all about context & risk. User stories work for certain types of development where it is all about the user interaction. Requirements are still needed to reduce the risk of mission critical processing, backend systems or embedded software development.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s