People Are the Heart of Any Practice

There’s an endless number of boxes for different Agile practices that organizations are eager to tick off, including various ceremonies, roles, and activities. Frustration with Agile maturity models is related to how they sometimes grade Agile maturity as a volume measurement of doing “more Agile,” regardless of outcomes being created.

While Agile practices can be helpful, it’s dangerous to focus too much on just the action of doing the different practices. Success with any Agile practice depends on having the right attitude and embracing the Agile way of doing things.

Don’t Do Checkbox Agile

When you only focus on implementing Agile practices without also embracing the purpose and spirit of the practices, you open the door to perverted goals. For example:

• Kanban boards can be set up for management to track and micro-manage team members, rather than as a tool for the team to coordinate and self-organize.
• Story mapping can be done by an expert to speak at a team rather than as an activity for collaborative discovery and planning.
• Teams can be forced to track Agile metrics for management reporting, instead of using them as a source of feedback for continuous improvement.

Unfortunately, because Agile has become so popular, this is the only experience many people have. For many people, this is what it means to work in an Agile team: the same management command and control, just with more meetings and some funny job titles.

Signals of Broken Agile

Over the years, I’ve seen that certain violations are problematic enough to indicate a core failure in embracing Agile:

• The goal is to “get it right” instead of embracing learning and feedback.
• The culture prioritizes pleasing managers over doing the right thing for customers or teams.
• Management pushes Agile teams to deliver fixed-scope and fixed-time projects.

These problems are hazardous because their impact ripples through teams and departments, promoting behaviours that go against Agile. They negatively affect teams and limit the potential benefits that Agile or any other practice can create.

Agile Manifesto Litmus Test

No matter how many Agile practices your company implements, a quick test to gauge if you’re doing real Agile is to flip around the value statements from the Manifesto for Agile Software Development:

• Processes and tools are valued over individuals and interactions.
• Comprehensive documentation is favoured over working software.
• Detailed Contracts take precedence over customer collaboration.
• Following a plan is more important than responding to change.

If any of those statements are true, you’re not doing Agile as it was originally imagined.

Since each violation of the Agile Manifesto’s values is a sign of broken agile, we can reason that succeeding with agile at least requires embracing those values.

In the absence of the values, Agile practices are hardly Agile at all.

Mike Burrows, Kanban from the Inside

Your Attitude Impacts Outcomes

Agile is broader than just a set of activities; it’s a cultural way of working because your attitude affects how you do things and the outcomes you get from them. This idea presents itself in different ways at different levels in an organization.

• How you are as an individual:
  • Do you want to improve at what you do?
  • Do you care about helping customers?
  • Are you open to learning from your mistakes?
• How you are as a team:
  • Does the team proactively share, ask questions, or offer help? Or do people do the bare minimum, or only do what they’re told?
  • Does the team consider reflection and improvement as an optional nice-to-have when there’s no “real” work to do?
  • Is the team open to showing ugly and incomplete work to customers to get feedback? Or do they only want to show polished, finished work?
  • Is the team interested in interacting with customers and stakeholders? Or do they see that as someone else’s job and prefer to focus on the code?
• How you are as an organization:
  • Are teams empowered to self-organize, or do teams have multiple managers and layers of management making all the decisions?
  • Are sources of friction identified and removed? Or are teams expected to crunch to meet their dates?

Culture and behavioural barriers to Agile can emerge at any level. Sometimes, new practices can make a positive change by creating new interactions, but practices are not a panacea.

When trying to introduce new ways of working, the goals of practices and the people involved should both align with the values of the Agile Manifesto:

• Solve customers’ needs through iterative and incremental development.
• Foster relationships between developers and customers.
• Use early feedback to inform planning.
• Rely on self-organized teams of multi-skilled peers.

Agile practices are only effective when they’re a natural extension of the team’s values. Without people who embody Agile’s values and principles, the practices are just empty rituals that can actually hinder you.

Conclusion

Agile should improve the experience of both developers and customers. Teams should want to do Agile. If your version of Agile isn’t creating a better experience for customers and developers and improving outcomes, then something’s wrong.

Focus on the way of doing things rather than just on the action of doing them. Trying to do Agile by installing practices and expecting people to carry them out like machines might create a lot of activity, but will fail to deliver meaningful results.