We valued learned people, but learning and teaching was not part of our culture or our organizational mechanics. We valued ready-made learning when it walked through the door, but our organizational learning didn't go further than the Agile Retrospectives materials and practice that was fashionable at the time. That's no fault of Agile Retrospectives per se. It's a fault of turning it into something fashionable, and inevitably conferring the unconscious orthodoxy onto it that was steadily growing in Agile methodology culture, often obstructing the line of site to the need for a higher order of teaching, learning, and management culture.
Unless team members understand that there is a requirement to be students in an organization, and to study under a teacher, pride and prejudice will likely obstruct the acceptance of a formal student/teacher relationship, and attempts at teaching will very likely devolve into the predictable butting of alpha geek heads over design and process ideas. And this portends obstructions to meaningful and methodical continuous improvement driven by program goals, and a rise of wild, uncontrolled experimentation.
In his book "Managing to Learn: Using the A3 Management Process to Solve Problems, Gain Agreement, Mentor, and Lead"
I used to tell Doc that it is painfully frustrating to teach knowing that our staff understood that they were not required either by culture or by supporting policy to be in the role of learner - especially when program and project expectations were not being met.
It's true that if the learner hasn't learned, then the teacher hasn't taught. It's also true that if the learner doesn't show up, then the teaching doesn't even begin.
Leaders at successful Lean organizations have pointed out that companies who have failed to duplicate Lean successes often do so by trying to adopt Lean as a process improvement effort rather than an effort to create a learning organization. Despite all of the interesting and beneficial mechanical aspects of Lean, Lean is about creating learning organizations. Student/teacher relationships and protocols are a part of learning organizations, with each role having the responsibilities of that role.
There has been a bit of a dust-up in the agile community lately as to whether Kanban work management is necessarily non-agile or anti-agile. The premise being that Kanban can foster environments of directed work, limiting workers' ability to self-organize, and fostering a disrespectful environment for workers as compared to forms of work management and organization common to agile methodologies.
The essential issue here is the issue of respect, but I find that the Agile perspective is willing to take advantage of incomplete and opportunistic definitions of respect. Kanban proponents have rightly pointed out that respect for people is an explicit Lean principle, and that self-organized work is still happening within Kanban workflows.
I see two perspectives talking past each other, and unfortunately, I see Kanban practitioners being backed into a corner, retreating, apologizing for Kanban, and softening the message to make it more palatable by the dominant methodology culture. Ironically, this was the exact position that the Agile was in at the start of the decade when Agile was struggling to make headway against prejudice and misrepresentation by the preceding traditional methodology culture.
Agilists are concerned about returning to the bad old days when disconnected managers directed work from outside the context of doing that work. It's a serious issue that deserves serious concern. It's a serious enough issue that it demands rigor on the part of the mainstream Agile community to engage the effort to understand Lean more deeply than the often cursory glances and biases projected at Lean and Kanban.
I sympathize entirely with the concern of returning to the bad old days of pre-Agile bureaucracy, but I'm equally concerned about the same tendency for Agile bureaucracy to occlude the meaning of Lean and Kanban.
My study of Agile began in 2000 when a mentor from Bell SIGMA turned me on to XP. My day-to-day immersion began in early 2001. I don't want to return to the bad old days either, but I don't want to go forward into a revised, 21st-century kind of bad old days issuing from the same mechanisms of bias and presumption that Agile itself faced, and often continues to face.
I wonder if agilists at large, in the spirit of inspection and adaption, are taking the time to understand Lean and the organizational and cultural context where Kanban thrives. With Agile, we asked organizations and cultures to consider change. I wonder now if Agile is able to respond to the same challenge.
On the surface, the following statement should rile a mainstream agilist. At least, it certainly used to rile me. It riled me enough not to act upon it even when my instincts told me that it might make a world of difference between immanent failure and rescuing a project, its team, and a considerable investment.
It's perfectly acceptable for a manager to direct the team from a position of traditional, hierarchical, directive authority.
I'm taking egregious advantage here in setting this stage. I'm purposefully leaving out the implicit context inherent in Lean. If I looked at the preceding statement through Agile's lens, I might very likely be worried about it. Looking at the statement through Lean's lens, I'm perfectly comfortable with it.
If we don't look at Kanban through Lean's lens, we're committing the anthropological cardinal sin in failing to realize that we're projecting cultural bias on what we're observing. We're even failing to recognize that Lean may have culture and behavior that is based on different assumptions and biases.
Kanban isn't a return to the bad old days of disconnected, directive authority because the position of management in-situ in a Lean organization isn't the same position of management that Agile efforts are commonly called to contend with and the behavior of management that many of Agile's protocols are shaped to deal with.
A manager of a Lean software development team isn't a remote figure who is no longer in the game. The manager is on the team, and he's one of the most competent technologists on the team. The manager in a Lean organization is also a teacher.
A team that includes a manager with directive authority is still self-organizing. The manager is internal to the team. A manager's expectations aren't disconnected from the reality of the work. And when those expectations aren't being met, he can chose to use directive authority to guide the team to counter-measures through teaching. It's also the manager's duty to help people on the team to develop critical thinking skills and instincts that serve problem recognition and resolution in support of the goal.
The expectation for team members to fulfill their duty as students is part of the managers directive authority. Refusal to engage in the protocols of the learning organization is deeply disrespectful to the organization of people as a whole, and to the manager as a person.
Looking at Lean through Agile's lens is perfectly reasonable. It gives a comparative perspective that can help us understand differences and find meaning. But ultimately, Lean should be seen through Lean's lens and should be assessed from the perspective of its native context.
There is a greater issue of respect and disrespect that is inherent in Lean as seen through the Lean lens. Respect is a two-way street. There is the respect for workers and the respect for managers, or teachers
One of the most intractable issues we have in software development cultures is the lack of line management that remains technically-competent. In fact, line managers in software development are often people who choose to escape
We're presently dealing with the effects of several generations of software managers who don't really have much of an idea of what software development work is in detail, which means that these managers can't be effective teachers. Workers don't end up with the teaching that makes them effective and makes the work rewarding. The cycle perpetuates itself.
Agile has been a powerful palliative in dealing with this organizational and cultural snag. By putting a firewall between the deleterious effects of directive authority that is too far from the work and the work itself, agile succeeds in restarting the failing heartbeat of getting software made.
In the software industry, Lean is seen as a kind of specialization of Agile, and that's a unique thing for Lean in industry in general. It's also possibly a detriment and maybe even a disadvantage.
Agile is increasingly encumbered by its own presumptions of organization and culture. Agile's biases are slowly fading into background consciousness, becoming unconscious. As Lean is inevitably and unconsciously seen through the lens of colloquial Agile, many of the organizational assumptions and biases of Agile are projected onto Lean without even realizing that these biases are there.
Lean in its essence is a path to critical thinking, but not a solo path. It's a directed path. A Lean organization is a learning organization
Lean is a means to find the unasked question
This isn't meant to be a condemnation of Agile, but it is meant to point out that if Agile isn't careful, it will become the same kind of problem that it sought to solve.
On my project with Doc, I was valued as a teacher. I was the person who got executive support for the project. I shared product design responsibilities with our product owner. I would go to bat for the team when hard decisions needed to be advocated to the executive. I did the technical screening of candidates and made my recommendations to the team about hiring. And I was responsible for setting program goals and expectations for technical implementation.
In the end, I parted ways with the team when it became clear to me that the team had become intractably self-determining, which is a potential risk in self-organizing teams when technical competence and directive authority are not invested in the same person. Ultimately, the team failed, a non-trivial percentage of our small company revenue invested in the project was written off, and the entire team was dismissed.
This isn't a typical Agile scenario, but it is very much a possibility faced by teams in situations similar to ours. The failure likely points less to an implicit weakness in Agile and more to an explicit strength in Lean: respect is indeed a cornerstone of success, but if respect isn't holistic, it risks introducing the opportunism that can see to the failure of otherwise meaningful software development efforts.
Working with software developers and organizations to help realize the potential of software product development through higher productivity, higher quality, and improved customer experience
Learn more about my work and how I can help you at ampgt.com
