Mindset Book Cover

We are quickly closing in on the end of our re-read of Mindset.  I anticipate two more weeks (Chapter 8 and a round up).  The next book in the series will be Holacracy.  After my recent interview with Jeff Dalton on Software Process and Measurement Cast 433, I realized that I had only read extracts from Holacracy by Brian J. Robertson, therefore we will read (first time for me).

Today, we review Chapter 7 in Carol Dweck’s Mindset: The New Psychology of Success (buy your copy and read along).  Chapter 7, titled “Parents, Teachers, Coaches: Where Do Mindsets Come From? explores the impact of some of the most intimate and earliest relationships on our mindsets.Understanding how parents, teachers, and coaches affect mindsets helps us learn to lead change. (more…)

Listen Now

Subscribe on iTunes                   Check out the podcast on Google Play Music

The Software Process and Measurement Cast 399 features our essay titled, Storytelling: Developing The Big Picture for Agile Efforts. Agile reminds us that the focus of any set of requirements needs to be on an outcome rather than a collection of whats and whos.  Storytelling is a powerful tool to elevate even the most diehard requirements analyst from a discussion of individual requirements to a discussion of outcomes. Before we can generate a backlog composed of features, epics, and user stories, we need to understand the big picture.

Our second column is a visit to Gene Hughson’s Form Follows Function Blog.  We discussed an entry titled A Meaningful Manifesto for IT.  Do we need a manifesto to know that how well we are meeting the needs of our customers is a reflection of how fit IT is for purpose? Perhaps the answer is yes, if for no other purpose than to ensure we make sure that what we deliver is not a waste of money.

Anchoring the cast this week is the Software Sensei, Kim Pries.  Kim discusses the role of deliberate practice in increasing the capability and capacity of teams. Kim’s provides practical advice on improving team performance.

Re-Read Saturday News

This week we begin the Re-read Saturday of  Kent Beck’s XP Explained, Second Edition with a discussion of the Preface and Chapter 1.  These sections provide a definition of XP and context for the diving into the principles and techniques. Using the link to XP Explained when you buy your copy to read along will support both the blog and podcast. Visit the Software Process and Measurement Blog (www.tcagley.wordpress.com) to catch up on past installments of Re-Read Saturday.

Next SPaMCAST

The next Software Process and Measurement Cast, #400!, features our interview with Jim Benson. Jim and I talked about personal Kanban, micromanagement, work-in-process limits, pattern matching, pomodoro and more. This was a marvelous interview to commemorate our first 400 shows!

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: “This book will prove that software projects should not be a tedious process, for you or your team.” Support SPaMCAST by buying the book here. Available in English and Chinese.

Listen Now

Subscribe on iTunes                   Check out the podcast on Google Play Music

The Software Process and Measurement Cast 395 features our essay on productivity.  While productivity might not be the coolest subject, understanding the concept is critical to every company’s and every worker’s financial well-being.

Gene Hughson brings another entry from his Form Follows Function blog to the Software Process and Measurement Cast. Gene discusses the idea of accidental innovation.  Gene suggests that innovation is not a happy accident, but is a result of a process, structure, and technology that can enhance innovation. However, it can just as easily get in the way.

In our third column this week, Kim Pries, the Software Sensei, brings us a discussion of how software developers leverage assimilation and accommodation in the acquisition of knowledge.

(more…)

Peabody Library

Peabody Library – So many books, so little time.

We live and work in a dynamic era. In the software development field we are experiencing changes across the board in computing power, management styles, frameworks and techniques. Movements such as Agile and lean are just the tip of the iceberg. In order to build a base of knowledge and grow, IT practitioners need to read, listen, collaborate and experiment. While blogs, podcasts and conferences are great tools to explore the cutting edge, books are an important tool for building or expanding a base of personal knowledge.

I introduced the Re-Read Saturday feature on the Software Process and Measurement blog to help expose both my readers and myself to at least a few of the most important books. We have now re-read Covey’s Seven Habits of Highly Effective People and we finished Kotter’s Leading Change last week. I choose the first two books, and it is your turn to choose the next book. Over the last twelve weeks I asked you to send me the two books that you felt were most influential to your career. A few observations:

  1. The list has 30 entries.
  2. There was NO runaway leader on the list.
  3. The first five on the list each got two mentions.

Since there was no clear winner, I have created a poll. The poll will allow each person to vote for three books. Pick the top three books that have had major impact on your career, OR perhaps the books you always wanted to read. The book that is on the top of the list on February 14 will be the next to be featured on Re-Read Saturday.

Different training tools are sometimes needed!

Different training tools are sometimes needed!

Organizational transformations, like an Agile transformation, require the acquisition of new skills and capabilities. Gaining new skills and capabilities in an effective manner requires a training strategy. The best transformations borrow liberally from all categories of training strategies to best meet the needs of the transformation program and the culture of the organization. The four major training strategies typically used in Agile (and other IT) transformations have their own strengths and weaknesses. Those attributes make the strategies better for some types of knowledge and skill distribution than other strategies.

Training strategies by use.

Training strategies by use.

Lectures and presentations are the ubiquitous feature of the 21st century corporate meeting. These techniques are useful for spreading awareness and, to a lesser extent, to introduce concepts. The reduced efficiency of the lecture to introduce concepts is a due to trainers that are not trained educators, conference/training rooms that are not as well appointed as college lecture halls and learners that tend to pay only partial attention whenever possible. The partial attention problem is a reflection of email and text messages generated from their day job. Difficulties occur when distributed meetings are not supported with proper telecommunications.

Active learning and experiential learning are both excellent strategies for building and supporting skills and capabilities. Each method can include games, activities, discussions and lecture components. The combination of methods for generating and conveying knowledge keeps the learners focused and involved. Involvement helps defeat the common problem of partial attention by keeping the learners busy. The scalability of the two techniques differs, which can lead to a decision to favor one technique over the other. Many transformation programs blend both strategies. For example, I recently observed a program with group learning session (active learning) with assignments to be done outside the class as part of the learner’s day-to-day activities then debriefed in community of practice sessions (experiential learning).

Mentoring is a specialized form of experience-based learning. Because mentoring is generally a one-on-one technique, it is generally not scalable to for large-scale change programs, however it a good tool to transfer knowledge from one person to another and an excellent tool to support and maintain capabilities. Mentoring is most often used for specialized skills rather than general skills that need to broadly distributed.

Transformation programs generally will need to use more than one training strategy. Each strategy makes sense for specific scenarios. The of crafting an overall strategy requires understanding of which skills, capabilities and knowledge need to be fostered or built within the organization, then the distribution of the learners, the tools available and finally the organization’s culture. Once you understand the requirements, the training strategy can be crafted using a mixture of the training techniques.

 

Every team member has a different learning style that has to be synced.

Every team member has a different learning style that has to be synced.

Another learning style model is built on four dimensions of learning styles. The dimensions of the Index of Learning Styles developed by Dr Richard Felder and Barbara Soloman are each described as a continuum.  Each continuum is bounded by opposite attributes of a learning style. An individual could map him or herself on each of the continuum to generate rich understand of their learning style. They are summarized below:

Untitled2

Mature teams generally are comprised of mix of learning styles. A mixture of styles can be complementary. For example, many IT groups I have worked with have at least one big picture person and several more linear learners.  What I generally do not see are individuals that sit at the extremes of any of the dichotomies. Individuals that sit at an extreme tend to be more difficult to draw into the group which impacts the ability to communicate and the ability of team members to trust each other.

One use of this type of model is to map teams.  For example, if we use the example used in Learning Styles and Communication Problems in a mapping exercise, I would judge the three personalities Lawyer (L), Talker (T) and Diagrammer (D) to fall as below:

Untitled1

The mapping exercise can be used to flag extremes that might cause trouble for the team. As noted in the example, the overall team was having issues staying focused when the Lawyer was presenting due to the sequential style being used. Using a mapping approach early in formation of the team can provide the coach with the impetuous for training exercises to sensitize the team to the disparate learning styles.

I suggest doing this exercise as a team when generating the team charter. The process I follow is:

  1. Place each of the descriptors on separate sticky notes and then place them on the wall so that all four continuums are visible.
  2. Review and discuss the meaning of each attribute.
  3. Have each team member mark where they believe they fall on each of the attribute continuums
  4. Discuss how the team can use the information to more effectively communicate.

Opposites might attract in poetry and sitcoms, however rarely do opposite learning styles work together well in teams without empathy and a dash of coaching. Therefore coach and teams need to have an inventory of learning styles on the team. Models and active evaluation against a model are tools to generate knowledge about teams so they can tune how they work to maximize effectiveness.

Include differences (learning styles, that is)

Include differences (learning styles, that is)

The team that completes a project will be different from the one that began the project. Each person on the team will have a range of individual experiences, and presumably, they will learn from these experiences. A mismatch of learning styles can result in communication problems. Communication problems act as a filter for what each individual learns by blocking or altering what the learner perceives.

Learning styles reflect an individual’s preference for how they learn. In many cases individuals mirror their own learning style when they share with others. Most, if not all, teams I have been associated with over my career have been comprised of individuals with different learning styles. This means that to effectively communicate and transmit knowledge, each team member must understand the learning styles of their team members (this is another reason why stable teams generally have higher levels of performance).

An example of the impact when team members do not understand each other’s learning style can be seen in a team I recently observed.  The team is a relatively new team and is distributed, with most interactions occurring via teleconference. Most team members have not had time to adjust to each other’s learning style; therefore members use their own learning patterns as a default when interacting. For example, one team member follows the logical/Lawyer learning style. When presenting information they build a case – fact by fact – in great detail. No one else on the team leverages this as their primary learning style. The great level of detail and the slow (but relentless) build to the conclusion leads to frustration and disengagement. On the same team, another member is verbal learner/Talker.  This person needs learns by hearing, and in many cases, by vocalizing each point.  This person presents information in the same manner as they learn, talking it through (with lots of Keynote slides … with no pictures). In both cases because the members are not aware of the learning styles of other team members communication is inefficient (and my observation is that it can be ineffective).

Teams that are centrally located generally recognize learning style mismatches based on visual and empathetic feedback and can self-correct (assuming that team members actually pay attention when they get together). Distributed teams generally need to take a more active approach to learning each other’s preferences. I recommend the following approach which can be used as a team-building exercise or as a retrospective exercise:

  1. Before the exercise, create a couple of canned scenarios.  For example:
    1. Scenario One:  Pass status information about a trouble task, including a plea for help.
    2. Scenario Two:  Build consensus for a design decision.
  2. Have each team member identify their primary and secondary learning style.
  3. Share these styles with the team.
  4. Once all team members have shared their style, have each team member select a method that is not their primary or secondary style and have them convey the information needed in complete each scenario. (Allow 5 minutes for preparation).

The goal of exposing the team to other types of learning styles is to push each person outside their comfort zone.  This serves multiple purposes. First, the process helps to build empathy. The process also reinforces the awareness that, on a diverse team, all messages need to be shared in a variety of ways so that multiple learning styles can easily absorb the information.  Finally, by learning and becoming sensitive to other learning styles, individual team members will expand their ability to recognize nuances in communications that lay outside their normal learning style. This will ultimately increase the effectiveness and efficiency of the team.