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. (Learning how to write short and coherently is a different post.)
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 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 rather 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 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? (Yes, I am thinking/starting to write that book, too.)
We don’t need managers to change first. However, for any agile approach or a transformation to work, we need the management culture to change. For me, that’s the difference between iterations of waterfalls and a real agile culture.
| Published on Java Code Geeks with permission by Johanna Rothman , partner at our JCG program. See the original article here: Agile Approaches Require Management Cultural Change Opinions expressed by Java Code Geeks contributors are their own. |
