Scrum is a stepping stone
toward the organization becoming a learning organization, and much of being
Agile is about the opportunity to learn. In the modern world of knowledge
workers, if the people are not learning on the job, then they are not creating
new knowledge. We create new knowledge by understanding the context of new
problems, deconstructing the problem, understanding the forces acting within
the system, creating solutions to solve them, and then remembering the
decisions that resolved the forces and applying them to new challenges. Experience
comes from numerous encounters with similar problems. When we reflect on new
problems, we generalize and abstract guidelines and rules – this synthesis is
learning. Reflection requires time and distance from the immediate problem.
But if you have never experienced this type of fun on an Agile team, then perhaps you need training wheels for your shiny new Agile vehicle. These training wheels come in the form of the basic framework of Scrum. For example, the product review meeting (demo) is a great place for learning. If the team can create an opportunity for the stakeholders to learn the current state of the product, then they are doing the core of their task. However, the team also needs to present what they have learned during this iteration. Sometimes this is too technical for many of the stakeholders, but this doesn't mean it should be squelched. One of those stakeholders may be a high-level technical architect. If the team learns something about the suggested architecture, isn't this demo a great place for that feedback (positive or negative)?
A great story from Richard Cheng that describes an Agile team in the learning process was covered on the ScrumDevelopment YahooGroup discussion list.
Teams of developers (programmers, testers, business analysis, etc.) typically adapt to change with ease. For these knowledge workers, learning and doing Scrum is relatively easy. In Richard’s story, he’s telling us of a fundamental change that happened within his organization. It is at the company meeting that teams are describing the new knowledge that they have created and describing the impact to their customers.
Leaders are you managing your knowledge workers as if they are industrial workers? Have you upgraded your wetware – your mental model of the way in which you manage and lead people? What are you studying to increase you ability and knowledge? What are you learning? To become the Agile learning organization, the whole body of the organization must learn new things – create knowledge – this is especially true for the leadership.
In her article The Rise of Emergent Organizations, Beth Comstock describes a possible alternative dynamic in the way to organize people to achieve a common purpose. She appears to be experimenting with some of these techniques at GE. I'd like to learn more about what she refers to as "Opening up New Feedback Loops."
See Also:
Why we cannot learn a damn thing from Toyota or Semco by Niels Pflaeging
At what
point in the Scrum framework do we focus on learning? Well, for a truly mature Scrum
team it is constantly, at varying levels. That's what makes working on an Agile
team fun for me. We’re constantly learning something – whether it’s through
planning to do something new or different and it actually working or by failing
to achieve an objective and then realizing a better path to that objective.
Learning to learn is like riding a
bicycle; once you know how, it gives your inner child freedom to explore.
But if you have never experienced this type of fun on an Agile team, then perhaps you need training wheels for your shiny new Agile vehicle. These training wheels come in the form of the basic framework of Scrum. For example, the product review meeting (demo) is a great place for learning. If the team can create an opportunity for the stakeholders to learn the current state of the product, then they are doing the core of their task. However, the team also needs to present what they have learned during this iteration. Sometimes this is too technical for many of the stakeholders, but this doesn't mean it should be squelched. One of those stakeholders may be a high-level technical architect. If the team learns something about the suggested architecture, isn't this demo a great place for that feedback (positive or negative)?
A great story from Richard Cheng that describes an Agile team in the learning process was covered on the
"Let me tell you a true story. I was working with a Scrum team at a financial website. About once a month, there was a company meeting where they presented what they did to the other departments and executives. Their initial presentation contained information such story points completed, hours spent on stories/spikes/firefighting, and what they implemented. As the team really started to understand the goals of the company and the project and their place in achieving these goals, the team presented the following:
1. What have we done this month to help make our company profitable?
2. How have we excited our customers
3. What we have learned
"This is a fundamental shift from thinking about task based, to do list work to actually achieving goals and providing value. Helping your organization shift from getting value from the first set of presentations to the second set of presentations is a big part of what the Agile transformation is about."
-- Richard K Cheng, PMP, CSP
Teams of developers (programmers, testers, business analysis, etc.) typically adapt to change with ease. For these knowledge workers, learning and doing Scrum is relatively easy. In Richard’s story, he’s telling us of a fundamental change that happened within his organization. It is at the company meeting that teams are describing the new knowledge that they have created and describing the impact to their customers.
How would
this fundamental change occur in an organization? My answer is via a shift from management
operating in outdated fashion (i.e., control and reduce risk) to thinking in a
leadership style (i.e., release control and accept risk). It is often the management
– working within the traditional organizational structure – that that have
difficulty embracing the Agile change. Scrum teams may create many more
learning opportunities than management desires, and they may expose many more
impediments than the existing structure can bare. This will cause friction in
the management layers above the teams.
Do not
forget that the management layer has become successful within the old structure,
and they may need to embrace new theories of motivation and practices of
management. These new theories, ones that were not taught in MBA school in the
1980s, are well described in popular leadership literature. The Industrial
revolution lead to a style of management largely based in Fredric Taylor’s work
on Scientific Management also called Taylorism. This theory of management
worked very well for assembly line workers. It does not function well for
knowledge workers. New theories for creating the environment required for
creative knowledge work are described in:
Drive: The Surprising Truth about what Motivates Us by Dan Pink
Switch: How to Change Things When Change is Hard by Chip and Dan Heath
Management 3.0: Leading Agile Developers, Developing Agile Leaders by Jurgen Appelo, author of the popular NOOP.NL site.
Leaders are you managing your knowledge workers as if they are industrial workers? Have you upgraded your wetware – your mental model of the way in which you manage and lead people? What are you studying to increase you ability and knowledge? What are you learning? To become the Agile learning organization, the whole body of the organization must learn new things – create knowledge – this is especially true for the leadership.
In her article The Rise of Emergent Organizations, Beth Comstock describes a possible alternative dynamic in the way to organize people to achieve a common purpose. She appears to be experimenting with some of these techniques at GE. I'd like to learn more about what she refers to as "Opening up New Feedback Loops."
"GE last year did away with annual performance reviews, opting instead for systems that allow individuals to give and receive feedback to anybody they interact with."
See Also:
Why we cannot learn a damn thing from Toyota or Semco by Niels Pflaeging
Esko Kilpi's article on Productivity Revolutions - Medium. An interesting view of Taylor the socialist and troublemaker. And a prediction that "technological augmentation" is going be the next revolution in productivity for the knowledge worker.
How to build the next Trello and sell it for $425 million or more
Atlassian bought Trello for $425 million. Because Trello was on trajectory to kill Jira.
How to build the next Trello and sell it for $425 million or more
Atlassian bought Trello for $425 million. Because Trello was on trajectory to kill Jira.
Comments