Agile principles and methods have revolutionized the way industries approach management and product development. As large enterprises transition from traditional conglomerates into the 21st-century digital mindset, they start implementing agile innovation methods. And with good reason!
Agile practices improve success rates in software development and improve the quality and speed at which products are delivered. So why is the transition so difficult for large enterprises, and what blockers prevent full implementation of agile practices?
Today we’ll cover why agile fails in large enterprises and how to address the gaps preventing a smoother and more complete transition.
Upskill your developers and close the skill gap
With Educative Teams, you can build learning environments tailor-made for your software developers. Help your team stay on the cutting edge and avoid technical debt.
The Agile Manifesto#
If you’re looking to bring agile practices to your company, the best place to start is learning the principles that agile is grounded in.
In 2001, a group of software engineers came together to compile a list of four values for agile software development:
1. Individuals and interactions over processes and tools
In other words, agile values give an individual ownership and trust in their ability to get the job done. Instead of focusing on titles and bureaucratic processes, focus on fostering more individual ownership and collaboration.
2. Working software over comprehensive documentation
Agile prioritizes a team’s sense of experimentation and innovation. Teams should focus on creating experimental prototypes and receive feedback from the customer in a shorter amount of time and smaller parts, instead of trying to appeal to internal authority to release one large product.
3. Customer collaboration over contract negotiation
Agile prioritizes receiving quick and constant feedback from its customers to drive innovation and helps draw closer to what customers truly value.
4. Responding to change over following a plan
Teams should start developing and creating the project as soon as the basic vision and plan are laid out. Along the way, plans should be subject to change, and teams should value this change to draw closer to understanding their customer.
So what makes it so hard for large enterprises to follow these values, and what is stopping enterprises from adopting agile practices?
Large Enterprises have deep-seated processes#
One thing to consider is that the conception of agile techniques was inspired by the idea of breaking away from traditional bureaucratic procedures. It’s not just about learning and adopting new practices or spending a few minutes in training, but it’s also unlearning deep-seated habits of hierarchical bureaucracy.
How to move away from the waterfall#
Long sequences of testing, documentation, and quality assurance clog the process to bring a working product to market. As a result, agile methodologies to build the project fail to deliver a more efficient timeline. While the waterfall method works for more traditional and stable forms of business, it deteriorates the speed at which a product makes its way into the hands of a customer and thus limits innovation.
So how should large enterprises break away from this waterfall model?
Here are some helpful guidelines to get you started:
- Limit the number of decision-makers.
Run with the principle of “Disagree and Commit”. Agile methodologies promote opportunities to share ideas, but when debating ideas starts to take time, one person should be the boss of making the final decision. Put simply, quick decisions are better than no decision. Disagreements happen, but everyone should own the goal of moving forward.
- Stay on the same page.
During a conversation with Naeem, CTO of Educative, a leadership quality he always looks for when hiring engineering managers is the ability to communicate tasks and goals so that all teams stay on the same page. Maintaining open communication across all teams is vital for aligning individual teams with enterprise priorities.
How to value flexibility over predictability#
In large enterprises, scaling sets the bedrock for creating silos of roles and processes to maintain a more rigid sense of accountability and responsibility. In short, some large enterprises have been built over the years to maintain predictability and consistency and not made for rapid change — and for good reason. For some companies, predictability and consistency are required for their product and maintain scalable growth. The transition away from a matric structure to a more flexible system creates friction with deep-rooted work processes. This begs the question, “what are some initial steps to move the needle towards a network fit for agile methodologies?”.
- Expect to fail; Iterate to adapt.
Large enterprises face a complex challenge. Not only do they have to create a new way of organizing their team, but they also have to unlearn cultural standards built over many years. Like with any new skill, expect to fail and leave room to grow.
- Start small by creating self-organizing teams.
During a LeadDev conference in 2019, Rebecca Hill noted her experience in building a self-organizing team where managing work and executing tasks was a shared responsibility across the team. She believed in building a team where everyone collaborates on what they work on and how they work. Self-organizing teams depart from the traditional structure of one manager ordering the team on task execution. Instead, self-organizing teams allow individuals to be deeply involved and invested in managing and executing their work.
You Can’t “Scale” Agile#
In 2014 during a speech covering how Spotify moved from scrum teams to agile teams, Henry Kniberg, a software engineering manager at Spotify, started by saying, “Don’t scale Agile, Descale your organization.” What does that mean exactly?
It means that large organizations can’t easily switch to agile without learning how to break away from long-lasting work cultures and models built to scale.
Alignment enables Autonomy#
Henry Kniberg, presented a visual diagram to describe the relationship between alignment and autonomy at various companies. Here is the chart below:
Each enterprise falls within the scale of low to high alignment in relation to low to high autonomy. Each enterprise is then categorized by:
- Type of organization
- Type of culture
Which in turn generates four different types of enterprises. Take a minute to evaluate where your company might fall on the graph.
high alignment / low autonomy:
-
Authoritative organization
-
Conformist culture**
Your company vision is well-communicated to your team, and everyone is on the same page. Managerial styles are generally focused on “how” to get something done, as opposed to telling “what” to get done and leaving the “how” up to the team.
high alignment / high autonomy:
-
Innovative organization
-
Collaborative culture
Everyone on the team knows and understands the large-scale visions and goals. Meanwhile, teams are designed to foster creativity and collaboration. Team members split up work, and people have a voice in how to approach a project. In some cases, this model doesn’t work well when companies require more predictable and safe approaches.
Low alignment / low autonomy:
-
Micromanaging organization
-
Indifferent culture
Your company has strict regulations and rules around management that rely strongly on a top-down management system. Individual contributors require approval from their managers, who in turn may need permission from other managers. You may notice a lack of communication between managers or skip managers and their teams.
Low alignment / high autonomy:
- Entrepreneurial organization
- Chaotic culture
This might be more reflective of a smaller organization or a step along the way to an agile organization. You might find yourself in a space where every team member feels they have more ownership over their work, but there’s still a lack of communication between higher company vision/direction and your team. Put simply, your team is not on the same page.
Keep your engineering team on the same page#
Educative Teams empowers you to build learning environments tailor-made for software developers that will help your team stay on the cutting edge. Gain team access to new courses every week as well as completion certificates, mini-courses, and more.
How to transform your team#
Not every approach works the same for every company, and agile isn’t always the best management model. For example, if you were working at an insurance company, would you want your young team of professionals handling secure and sensitive account information through an agile lens? Imagine clients waking up to find mistakes with their accounts but being reassured that the bug will get fixed in the next update.
So, where should you start?
Where to start your transformation#
According to Mike Cottmeyer, CEO and founder of LeadingAgile, Moving your team towards an agile methodology requires:
- Identifying where your organization is at
- Helping it be successful in place
- Making incremental changes towards agility
Identifying where your organization is at
Every organization must start with understanding where their organization fits on the scale between alignment and autonomy. Gather you team together and see where they fit on the scale. You might be surprised by the difference of opinions within your organization.
Helping it be successful in place
Not every organization is technically ready for agile. Some organizations don’t even need to move toward agile methodologies. The next step is understanding the dependencies of your organization and what it needs to be successful. Ask yourself the question, what are the dependencies of my organization? What orders have to remain the same to maintain your current business?
Making incremental changes towards agility
One your organization understand where they lie on the scale and realize that moving towards agility is what they need, then it’s time to make incremental changes towards agility. So where should you start? What are the areas you need to make changes first?
Where to focus on with incremental changes#
Every organization approaches moving the needle towards agile in three different ways::
Culture
Organizations that approach agile through culture believe that by changing the way people “think” about agile, agile practices and structure of the organization will naturally fall in place.
Practice
Organizations that approach agile through practice believe that by changing the way people “work” will naturally change culture and structure over time.
Structure
Organizations that approach agile through structure believe that by changing the “framework” in which people work, culture and practice will change over time.
Among these three, Mike Cottmeyer theorizes that culture and practice builds on top of a structural change. So where should your changes in structure come from? The three areas are backlogs, teams, and working tested software.
- Backlogs
Often times, the list of deliverables at a large enterprise are filled with tasks that span over long periods of time or highlight big vision goals. Instead your backlog should follow INVEST criteria and be filled with small enough tasks to be completed within a day. In doing so, your backlogs will provide your team with more clarity and purpose throughout the sequence of your projects.
INVEST is an acronym for assessing the quality of a user story:
“I” ndependent
“N” egotiable
“V” aluable
“E” stimable
“S” mall
“T” estable
- Teams
Every team member should be necessary and a valuable asset to move forward with your project. Following agile principles of autonomy and ownership, every team member should make local decisions and the whole team should be held responsible for a successful delivery. As a result, your team members will be able to reflect their mastery of technical skills and demonstrate extreme ownership over their deliverables.
- Working tested software:
There’s a fine balance between releasing a perfectly tested software and releasing code that’s good enough for delivery. In order to create a structure that relies on working tested software, set standards to limit technical debt and make sure there are no known defects to the software before releasing to your customers. In addition, determine measurable progress throughout your project to avoid any uncertain work piling up at the end. Put simply, define a measurable and standardized “Done” for your project before delivery.
Creating a strong structure for your team to work in builds the foundation for culture to be coached and for practices to be nurtured over time. As your team becomes more agile, you’ll start to notice roadblocks to your progress along the way. If you believe your company really needs to become more agile, remove any and all impediments that come between your team’s current state and agility.
Wrapping up#
Not every company needs to move towards agile principles, but for companies involved in the tech industry, agile practices are essential for the rapidly changing landscape. Today we covered the reasons why agile fails in large enterprises and reasons for why your company should move toward agile methodologies. We then covered why you should start your company’s transformation towards agility by developing your structure.
Happy learning!
Continue reading about managing your team:#
Free Resources
