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

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, …

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…

Webinar: Collaboration at Scale: Defining Done, Ready, and NO.

I was invited to participate in a Scrum Alliance Webinar.  Maybe you would like to listen to us in a discussion of techniques to collaborate at scale (remotely and with many people).  The topic is one that I've got some experience in discussions - yet I never seem to get to done...
Collaboration at Scale: Defining Done and Ready and NO for Distributed Teams
With Joel Bancroft-Connors, Agile Organizational Coach; David A. Koontz, Agile Transition Guide; and Luke Hohmann, CEO and Founder of Conteneo, Inc.


14 February 2018 11 a.m. ET (USA).




The Scrum Guide is pretty clear on the criticality of the definition of Done: "When a Product Backlog item or an Increment is described as "Done," everyone must understand what "Done" means. However, the Scrum Guide ALSO says that the definition of Done can "vary significantly per Scrum Team." This leads us to examine when and how the definition of Done should vary, how distributed teams should cr…

A T-Shaped 21st Century Knowledge Worker

Knowledge workers in the 21st Century must have many areas of deep knowledge, while also be capable of collaboration across multiple other domains with dissimilar T-shaped individuals.  This description of a person is a metaphor.  Compare it to the shape of the "I" in the classic saying there is no "I" in Team.


I first read about Scott Ambler's term "Generalizing Specialist" - but it's so hard to remember the proper order of the words... get it backwards and it has an inverted meaning... T-Shaped is easier to remember. 
A generalizing specialist is someone who:
Has one or more technical specialties (e.g. Java programming, Project Management, Database Administration, ...). Has at least a general knowledge of software development. Has at least a general knowledge of the business domain in which they work. Actively seeks to gain new skills in both their existing specialties as well as in other areas, including both technical and domain areas.  General…

A FAILURE to Communicate

I was working with a failing team some time ago.  I use "failing" to describe the outcome of the team - not the people on the team.  Are you OK with that description?



An issue arrose in the stand up - a team member that was to verify the quality of a procedure did so and reported that there were a few records that didn't match expectation in the data set.  Upon inquire the number of records not matching was over 2000.  Most people acknowledged immediately the exaggeration - I could tell by the laughter.  After about 10 minutes of discussing the details of the problem - it appeared the team had a handle on the specific situation.

I stopped the discussion and inquired if they could name the impediment.  One team member did a great job of describing the impediment as a _communication gap_.  Wonderful - I could work with that - the problem had a name and it didn't include anyones Proper Name.

"If the problem has a first name; we are going to have a problem."

I&#…