Problem solve Get help with specific problems with your technologies, process and projects.

Making enterprise agility work with cross-functional teams

Enterprise agility works when cross-functional teams are able to self-organize, resolve problems and form Communities of Practice.

How is Agile different in an enterprise than in a smaller organization?

Mike Cottmeyer explains that enterprise agility is about "being able to inspect and adapt in the large." We can apply Agile values and principles to every part of a business. It's not only software teams who can self-organize, respect and value everyone equally, regardless of position, and empower individuals and teams to continually improve how they work.

Most people use the word "enterprise" to refer to a large company. One pitfall larger organizations must face is the tendency for teams to become silos. I've seen large development organizations go from having functional silos -- such as development, quality assurance (QA) and business analysis -- to having multiple cross-functional Scrum teams that don't talk to each other or share ideas. One way to prevent this is to establish Communities of Practice (CoP). For example, I established a testing CoP in a development organization with many Scrum teams. I invited everyone interested in testing to participate. Testers, coders, business analysts and product owners regularly met to share ideas and demonstrate tools or practices that helped their teams.

Technology problems are magnified in larger organizations. Core Agile practices such as continuous integration that include an automated build process and adequate coverage from automated regression tests aren’t too difficult for a small team to establish. It takes extra coordination and discipline to get CI successfully building and testing the combined code of many teams.

Enterprise agility may require extra roles or positions not needed in small companies. For example, if development teams as well as their customers are spread around the world, people who have both technical knowledge about the software and subject matter expertise may be needed to travel among the different locations and act as customer proxies.

Since larger problems can develop in larger organizations, they must allow extra "slack" time to experiment with ways to keep technical debt to a manageable level. For example, if an application lacks adequate automated regression tests, teams need time to learn good automation techniques, and experiment with different approaches and test frameworks to discover what will work best for their situation. In my experience, a cross-functional, self-organizing team has the diversity of skills and experience that allows it to solve or find ways around obstacles to delivering high-quality software.

Dig Deeper on Topics Archive

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.