Cultural norms can hamper successful agile transformation, and organizational culture is the most reported challenge to agile adoption. Many of these habits and customs are started and perpetuated by senior leadership. But that’s often not the only source of resistance to becoming agile.
Team-level skills and experience, training, practices, and collaboration are also prominent barriers to success. Self-managed and self-organized teams often experience elevated levels of accountability that can feel threatening in a less-mature agile culture. Ingrained behaviors and thinking can occur within the team, including business partners, that also can hinder agility.
Five of these barriers are explored here, as well as potential mindset antidotes to help get the team on the road to agile success.
1. Team members may not want to self-organize and self-manage
Team members may prefer to have work assigned to them based on negotiation and interpretation, and without direct accountability in the event of missed milestones, defects, or other technical debt.
Teams may even find collaboration to be fatally flawed and undesirable. How will my contribution be recognized? Why be cross-functional when I enjoy my own specialty? Why be collocated and dependent on others, and what’s the intent of being “committed”?
Changing the mindset: So many of the principles behind the Agile Manifesto reference teams and people for a reason! Collaboration, including incorporating and building on the strengths of fellow team members, is core to agile success.
ScrumMasters executing as servant leaders can provide needed team building. Personal commitment thrives when team members own and organize work; it is the essence of self-organization. Most of today’s product and service development and support workers enjoy and appreciate the need for soft skills and teaming. Teams acquire a sense of ownership and responsibility for their efforts through agile self-management.
2. Software engineering and agile techniques are not yet mature
Over the few decades that software engineering has been practiced, attempts to build software with an engineering mindset have failed because software development is still a maturing profession, sometimes void of standards around what constitutes goodness or quality. Software engineering is a relatively new discipline compared to civil, mechanical, and even nuclear engineering. Agile development is even less mature and defined. All of this makes some believe that using agile could limit team success.
Changing the mindset: For decades, certifications and licensing have received constant attention by professional societies. While licensing of software professionals continues to elude much of the industry, certification programs have mushroomed. And the evidence of agile success continues to mount well beyond the bounds of software development.
Scrum is recognized as an incentive when hiring agile staff. And while there is no industry standard for agile or Scrum, the use and success of agile techniques are reported in numerous surveys, with some of those annual surveys trending practices for over a decade.
3. Frequent delivery of software causes unhealthy business speed
Constantly changing customer needs, competition, compliance updates, and technology further exacerbate the need to take a breath, reflect, and slow the pace.
Changing the mindset: The agile principle of sustainable pace promotes a development team’s ability to maintain a healthy cadence while pursuing value consistent with the pace of business change. More typically, development lags the speed of business change. When is the last time you heard “IT is moving too fast,” or “We don’t want IT to meet the deadline,” or “We can keep the schedule and still add functionality to the release”?
Therefore, while agile teams enable responsiveness to business needs, they rarely outpace them. DevOps has accelerated the pace of delivery for organizations with continuous integration, continuous testing, and continuous delivery. The problem of “the development team moving too fast” is a problem most organizations would covet.
4. Business folks do not want to work with software developers daily
The most cited reason for resistance to agile on behalf of the business is that the business does not have time to meet daily with the team. For Scrum projects, development team members will contend that the product owner has no speaking role in daily stand-ups, so they exclude their business partner.
Changing the mindset: As the financially vested partner, is it really too much for the business to meet for fifteen minutes a day with the development team? Wouldn’t the partner want to know the day-to-day activities of the team and be available to answer questions to sustain progress? Isn’t the business fully engaged in a partnership of collaborative business value prioritization? Does the team patronize business needs prioritizing technical solutions with technical sprints, stories, and excessive refactoring? Has the business lost ownership of the product backlog yielding to the whims of the development team rather than retaining value delivery as its own preeminent determinant?
5. Developers enjoy that late crunch in the project lifecycle
Constant pace does not inspire the excitement we need to thrive and feel important. Some like the rush and the heroic efforts it takes to save a project at the last minute.
Changing the mindset: Unfortunately, the hero-based culture in which some team members thrive persists today. The hero moves on, often without sharing the skills and insights they have collected during their time with the team. Some heroes are arsonists: starting fires and putting them out through more heroics. Hero-based cultures frequently rely on tribal knowledge that is often passed down but seldom written down, as portrayed by early agile evangelists.
Cross-functional development and collaboration are thwarted. Hero-based cultures impair team accountability, further discounting teaming and collaboration. Heroes often act as virtual siloes.
Instead, use retrospectives to identify areas of knowledge growth. Use iteration planning to allocate time for that growth. Smash the siloes. Disseminate the knowledge of the specialists. Encourage teams to grow constantly in capability and ownership.
The road to organizational agility contains potholes, curves, detours, roadblocks, and, frequently, unchartered territory. The organization’s culture establishes bounds that can enable or disrupt agility. Even when the culture aligns with transformation, individual team members can unravel or derail the journey.
Encourage the organization and teams to consider an outside-in (sharing organization gleanings with teams) and inside-out (team practice knowledge transfer to the organization) set of strategies to accelerate an agile mindset. Too often, organizations will attempt to mirror the behaviors of other successful agile transformations without considering the many differences in people and their own culture. Target being agile rather than doing agile.
The road to self-managed capable teams and business partnership both directs and is directed in parallel with cultural changes. Continuous alignment of organizational vision and team norms minimizes the detours.
