Skip to main content

What have we LEARNED?

Scrum is a stepping stone toward the organization becoming 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.


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  ScrumDevelopment YahooGroup discussion list.
"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.
by Mitt Tarasowski Executive at Libertex. Co-Founder of Clever.do.

Post a Comment

Most Popular on Agile Complexification Inverter

David's notes on "Drive"

- "The Surprising Truth about what Motivates Us" by Dan Pink.

Amazon book order
What I notice first and really like is the subtle implication in the shadow of the "i" in Drive is a person taking one step in a running motion.  This brings to mind the old saying - "there is no I in TEAM".  There is however a ME in TEAM, and there is an I in DRIVE.  And when one talks about motivating a team or an individual - it all starts with - what's in it for me.

Introduction

Pink starts with an early experiment with monkeys on problem solving.  Seems the monkeys were much better problem solver's than the scientist thought they should be.  This 1949 experiment is explained as the early understanding of motivation.  At the time there were two main drivers of motivation:  biological & external influences.  Harry F. Harlow defines the third drive in a novel theory:  "The performance of the task provided intrinsic reward" (p 3).  This is Dan Pink's M…

Elements of an Effective Scrum Task Board

What are the individual elements that make a Scrum task board effective for the team and the leadership of the team?  There are a few basic elements that are quite obvious when you have seen a few good Scrum boards... but there are some other elements that appear to elude even the most servant of leaders of Scrum teams.









In general I'm referring to a physical Scrum board.  Although software applications will replicated may of the elements of a good Scrum board there will be affordances that are not easily replicated.  And software applications offer features not easily implemented in the physical domain also.





Scrum Info Radiator Checklist (PDF) Basic Elements
Board Framework - columns and rows laid out in bold colors (blue tape works well)
Attributes:  space for the total number of stickies that will need to belong in each cell of the matrix;  lines that are not easy eroded, but are also easy to replace;  see Orientation.

Columns (or Rows) - labeled
    Stories
    To Do
    Work In P…

Exercise:: Definition of Ready & Done

Assuming you are on a Scrum/Agile software development team, then one of the first 'working agreements' you have created with your team is a 'Definition of Done' - right?



Oh - you don't have a definition of what aspects a user story that is done will exhibit. Well then, you need to create a list of attributes of a done story. One way to do this would be to Google 'definition of done' ... here let me do that for you: http://tinyurl.com/3br9o6n. Then you could just use someone else's definition - there DONE!

But that would be cheating -- right? It is not the artifact - the list of done criteria, that is important for your team - it is the act of doing it for themselves, it is that shared understanding of having a debate over some of the gray areas that create a true working agreement. If some of the team believes that a story being done means that there can be no bugs found in the code - but some believe that there can be some minor issues - well, …

What belongs on the Task Board?

I wonder about these questions a lot - what types of task belong on the task board?  Does every task have to belong to a Story?  Are some tasks just too small?  Are some tasks too obvious?  Obviously some task are too larger, but when should it be decomposed?  How will we know a task is too large?

I answer these questions with a question.  What about a task board motivates us to get work done?  The answer is: T.A.S.K.S. to DONE!



Inherent in the acronym TASKS is the point of all tasks, to get to done.  That is the measure of if the task is the right size.  Does it motivate us to get the work done?  (see notes on Dan Pink's book: Drive - The surprising Truth about what motivates us) If we are forgetting to do some class of task then putting it on the board will help us remember.  If we think some small task is being done by someone else, then putting it on the board will validate that someone else is actually doing it.  If a task is obvious, then putting it on the board will take vi…

Team Performance Model - by Drexler and Sibbet

Many of you have all heard of the Tuckman model of team dynamics (Forming, Storming, Norming, Performing).  It was created in 1966 and has become the most popular model for describing team behavior.  Is it time to level up in your mental model of team dynamics?  Are you ready for a richer more functional model?



Introducing the Team Performance Model by Drexler and Sibbet



Orientation - Why am I here?
"Orientation is about understanding the purpose of a team and assessing what it will mean to be a member.  you need to understand the reason the team exist, what will be expected of you and how you will benefit from membership.  In a new team, these are individual concerns, because the group is only potentially a team.  that is why these concerns are illustrated as occurring in your imagination at an intuitive level.  As a team leader it is important to provide time and space for people to answer these internal questions themselves."

Keys to when Orientation challenges are resolve…