Over a million developers have joined DZone.

Agile Approaches Require Management Cultural Change

DZone's Guide to

Agile Approaches Require Management Cultural Change

An Agile expert discusses how Agile approaches challenge the management mindset and therefore the corporate culture, and how to turn this into a positive.

· Agile Zone
Free Resource

See how three solutions work together to help your teams have the tools they need to deliver quality software quickly. Brought to you in partnership with CA Technologies

Ron Jeffries, Matt Barcomb, and several other people wrote an interesting thread about prescriptive and non-prescriptive approaches to team-based Agile. The issues are nuanced and for me, don't lend themselves to a Twitter discussion.

If you don't want to read the entire thread, here is a summary: people often need help with their Agile approach. Some people start with Scrum in its entirety. Some people use a combination and build up.

In some ways, Scrum is a prescriptive approach: it defines roles, it defines a timebox of work, and the minimum times to plan and reflect. It's a framework, not a fully defined process. And that's part of the problem. To use Scrum effectively - or any other Agile approach - team members need to think for themselves about what Agile approaches mean to them personally, and as a team.

That's why we have the Agile values and principles. Too often, I meet people who haven't internalized the values and haven't read the principles (and, if they're supposedly using Scrum, they haven't read the Scrum Guide. Argh!!).

Gil Broza has a terrific video about why people don't realize the mindset is a critical part of an Agile transformation. See Practice Does not Make Perfect: Why Agile Transformations Fail (50-min video).

Andy Hunt (along with the late Jared Richardson) started the Grows Method. The idea is you start with small experiments, and proceed to more complex ideas as you master the necessary project "hygiene": work on one thing at a time, use continuous integration, work in rank order, etc.

I wrote about the history of Agile approaches in the first chapter of Create Your Successful Agile Project and what people might need to consider for their Agile project.

I am sure that Ron (and Chet) teach understanding, not just "do this practice" because they are terrific teachers and explainers.

There are many potential problems with an Agile transformation. The biggest one I see is the difference between Theory X and Theory Y management: the idea that people are resources who need to be pushed to work, or the idea that people want to do a great job for the company.

Agile approaches challenge the management mindset and therefore the corporate culture.

Culture expresses what managers value. Culture (according to Edgar Schein) is what people can discuss, how people treat each other, and what we reward. If we reward hero work, multitasking people, and (excessive) planning instead of throughput, and no or insufficient feedback about everything, our Agile transformation cannot succeed. It doesn't matter what approach we use, we can't succeed.

Prescriptive frameworks, such as Scrum, can help everyone see the culture is closer to Theory Y than Theory X. In addition, Scrum makes the culture clash visible.

However, using skills or prescriptions as a way to transform the organization fails in these ways:

  • We don't see how to change the culture of management, which drives the culture of the entire organization.
  • A prescriptive approach doesn't help the team members, teams, and managers see the culture and know what to do to change it. There is a difference between team-based work where people are interdependent and workgroup work where people work independently. Iterations don't work for management and other workgroups. Standups don't work for workgroups because standups are about micro-commitments between people, not status reporting (I wrote about this in Create Your Successful Agile Project).
  • And, not every framework is useful for your project. You might need a more frequent cadence of planning and reflection than your approach suggests.

I don't buy the Shu-Ha-Ri approach to Agile transformation because it assumes that by changing behavior, we can change the culture. That might be true for a project. I have yet to see it be true for management. Even though I prefer the Dreyfus model of skill acquisition (because it's more nuanced), it's often not quite enough.

We need to address the culture changes for Agile with small experiments (this is why I like Cynefin so much and used it to explain many of the issues in Agile and Lean Program Management).

For me, the question is how can we help managers move from a plan-driven, resource-efficiency mindset to an adaptive, flow-efficiency, feedback-driven mindset?

We don't need managers to change first. However, for any Agile approach or transformation of work, we need the management culture to change. For me, that's the difference between iterations of Waterfall and a real Agile culture.

Discover how TDM Is Essential To Achieving Quality At Speed For Agile, DevOps, And Continuous Delivery. Brought to you in partnership with CA Technologies

agile ,project management ,company culture ,scrum

Published at DZone with permission of Johanna Rothman, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}