Here is the latest version of my talk that I will give at Agile New England – minor updates and tweaks since the Agile Tour Toronto version last month.

I am really excited about my upcoming methods & tools article on culture and have been getting some great feedback from reviewers. Two comments requested clarification around supporting analysis for my thesis that Agile, Kanban and Software Craftsmanship have a cultural bias.

Here is what I said:

These results (Agile fits better with some cultures) have been validated through group workshops where participants performed the same activity after having an explanation of the culture model.

Workshop Format

1. Handout the  Schneider Model to everyone.
2. Form into groups of 4 to 6 people.
3. Each group selects a handout with either Agile Manifesto, Agile Principles, Kanban Principles, Software Craftsmanship or Declaration of Interdependence.
4. Groups draw Schneider grid on a flipchart.
5. Each principle is written on a sticky note and posted in the most appropriate quadrant.

Results

The following results were from an XPToronto User Group session earlier this year. I also ran this at SoCal LeanKanban and got similar results, but my camera sadly wasn’t working so I have no evidence.

Kanban

 

 

 

 

 

 

 

 

 

 

 

The results here are pretty clear – Kanban is centred around Control culture. So two groups with strong agreement with the proposed model.

Software Craftsmanship

 

 

 

 

 

 

 

 

 

 

 

The group on the left suggests that there is slightly more emphasis on Cultivation culture while the group on the right assigned the most items to Competence culture.

What support is there to the claim that Software Craftsmanship promotes Competence culture (as based on the manifesto)? In this case, I would say it is partially supported by the results.

These results indicate that language is not precised and that the experiment would need to be repeated several times with discussion and reconciliation of results to get a clear outcome. 

Agile Manifesto and Principles

When I ran the workshop in Toronto, no group picked this, so we did a large groups swarm where40 people just wrote out an item and posted it. That’s why there are duplicates. There was a little bit of clustering like items.

The diagram shows Collaboration culture as dominant followed by Cultivation. The term “working software” appears in both competence and control. In my analysis, this terms was ignored because it doesn’t have a strong fit with any of the cultures.

This result supports the claim that Agile is about Collaboration and Cultivation Culture.

Declaration Of Interdependence

The results of this have been written up in an earlier blog post - DOI? Cultural Shotgun

Conclusions

These results provide some support for the hypothesis that each of Agile, Kanban, and Software Craftsmanship have a cultural bias. It is worth noting that this experiment suffers from method bias in that participants were using the same analysis process of assigning attributes from manifesto to the culture model. An alternate workshop/experiment (just invented) would involve having participants brainstorm what are the most important values and then map them to the culture model.

I am very excited to share some learnings over the last 6 months on culture and transformational leadership. Here is the presentation I am giving tomorrow at Agile Tour Toronto and in Boston (@Agile New England) next month. Enjoy.

I have seen a recurring pattern in large organizations – there are large-scale projects that span many separate functional groups, departments and geographic locations. These projects often perform poorly and are difficult to manage effectively. In most cases, Agile is not the most valuable approach to get these projects on track.

At Agile Coach Camp I convened a session to explore this problem and identify some compensations to improve the situation. Many thanks to all the contributors – this is a group work product.

The Problem

Some of the common problems notes by participants were:

• Groups working in silos with missing, slow or broken feedback loops – lot’s of little disconnected pieces
• Incompatible vocabulary between technology and business
• The environments register high for “complexity of self”
• Staff in overload and multi-tasking
• Low visibility, awareness, priority

Please refer to the poster notes for full details.

Compensations

I use the word compensation, to indicate an action that can be taken to mitigate the problem. As there are systemic and widespread challenges in these environments, we did not discuss solutions.

Here are some of the key compensations:

• Draw a project map – who is where, what skills, what % on the project, what component
• Recognize and articulate feedback loops and flow of value
• Create a war-room with kanban boards for all groups
• Measure working software AKA running tested features and “definition of done”
• Conduct a project chartering session including clarification of business value
• Find someone to play the role of project lead (e.g. Toyota Chief Engineer)
• Make sure everyone has tooling for distributed communication

Contributors

• Paul Boos
• Dante Vilardi
• Pascal Pinck

Ooops. I can remember who was there. Please remind me by sending me an email so I can add your name here.

At Agile 2011, I was very fortunate to attend David Chilcott’s session on NonViolent Commuication (NVC) for Agile Coaches. NVC is a very powerful communication toolkit that has already helped me. I wonder how I ever managed without it.

At it’s very simplest form it is about explicitly considering your (and other’s) feelings and needs. The following diagram outlines the key elements of NVC for coaches.

Observing

Observing is an important skill for an Agile Coach. In NVC, the goal is to observe without evaluation, judgement or analysis. The idea here is that when we focus on observable data (I see, hear, etc.), we can operate and reason about what is actually happening rather than the filtered, distorted version that our brains typically serve up to us.  In the workshop we practiced distinguishing observations from evaluations and practiced removing the evaluation to focus on observable properties.

Of course, you can also practice observing with my fun Coaching Skills Dojo.

Feeling

People’s feelings shape the conversation. They can uplift and energize or take you down a rabbit-hole. Here is an inventory of feelings that you can use to understand what’s going on with people.

Needs

Needs are the place where feelings come from. Positive feelings come from needs that are met. Negative feelings come from unfulfilled needs. Here is an inventory of needs that can help you identify what’s going on.

Know thyself!
As a coach, it behooves us know where we are so we can help others.

First, get an understanding of your feelings and needs in a particular situation. This will allow you to more effectively communicate and manage your internal state.

Second, consider what you client is experiencing in terms of feelings and needs. If you pay attention to facial expressions, tonality and words, you will be in position to ask clarifying questions to understand what’s going on for them.

Exercise to find balance

The best part of the workshop for me was the following exercise:

1. Sit in a chair with your eyes closed and think of a situation.
2. What are your feelings in this situation?
3. What are your needs in this situation?
4. Stand up, open your eyes so that you leave the situation in the chair.
5. Look at the chair and imagine seeing yourself in that situation.
6. Now coach the person in the chair. Say an appreciation. What else will you say to them to help them?
7. Sit back down in the chair, close your eyes and integrate.

At Agile 2011, I spent a lot of my time in the OpenJam running sessions on StrategicPlay® with Lego® so that people would have a chance to experience what I see as a strikingly powerful technology.

What follows are some of the models and deep insights that were developed about Agile and how it is experienced at companies. Even though I know a fair bit about adopting Agile, I still find I learn a lot hearing these stories.

Scrum Alliance Leadership

See related post Scrum Alliance Leadership – Models for Success

Jon Stahl had an enlightening talk at Agile 2011 where he walked through his process for incubating transformational leadership to achieve an Agile mindset.

Confused about adoption vs. transformation?  Check out ways to make progress with Culture Gaps.

Agile Mindset – Do you want it?

Jon shows the following short video of IDEO design group to illustrate the Agile mindset and the type of servant leadership needed to support it.

After watching the video with executives who want Agile, he checks in with them:

• “Is this what you really want?”
• “Are you prepared to change your own behaviour to support this?”
• “Are you ready to go first?”

The approach outlined here is to go big or go home. Go big means to help transform an organization or division. Go home, means that rather than help adopt a few Agile practices that may disrupt the organization, to stop work and looks for clients who really want Agile.

Leaders Go First!

The remainder of the presentation is about how leaders can go first by adopting Agile principles as a management team. Jon summarizes this as:

• Live the values
• Lead by example
• Be as transparent as the teams they lead

Here are some example activities for the management team:

• Public display of values
• Visualize projects and plans
• Visual management of key information: people, technology, etc
• Daily stand-up meeting in public place

Thank you Jon, for sharing this at Agile 2011.

Barbara Fredrickson gave a great Keynote at Agile 2011 – Why care about positive emotions?

The essential message is that we can create positive environments and emotions to create an upward spiral of openness, resilience, and better performance.

This is in line with my use of Agile as a way to transform the world of work. And of getting innovation and results through play.

The flow of the diagram below is: Positive emotions –> Expand’s Awareness –> Other thinking –> Mind Meld

Dr. Fredrickson argues that Positivity is a lifestyle change that can result in a upward spiral of positivity with all the associated benefits. Masking the negative does not help, we actually need to focus on the positive – at least three positive events for every negative event.

I really appreciated Barabara’s message, however, the one part I will differ on is that in many environments we need to create trust and safety to reduce the background noise of negativity. This needs to happen in tandem with positivity.

You can learn more through Barabara’s website or book.

Update: Full Video is available on Agile Alliance Website.

This post identifies concrete actions. See also: Acceptance Tests and Models for Success.

The final step was to identify concrete actions that the Scrum Alliance organization and membership can take to move toward the goals associated with specific parts of each model. This is the list we came up with. Each item was given a “thumbs up” or support vote. (There was only one thumbs down, but this was cleared with further discussion/explanation).

1. Create an initial Product Backlog of actions and desired future conditions. This list is a start.
2. Make that backlog visible to all members.
3. Create a mechanism to make it easy for members to volunteer for tasks associated with items on the backlog.
4. Find someone (or several persons) to facilitate the volunteer mechanism.
5. Develop ways to detect new trends and opportunities that may impact the SA and/or be influenced by the SA – eg. the new PMI/Agile certification program.
6. Develop a means for official public response to such trends and opportunities.
7. Start/continue building “bridges” with related communities involved with such trends and opportunities.
8. Apply Scrum/Lean/Agile tools (timeboxes, teams,  iterations, WIP limits) to work on these backlog items and management of the overall SA portfolio.

Participants

Note: Sorry we didn’t get everyone in the picture…

• Bob Allen
• Brad Swanson
• Chris Sims
• James Smith
• Heidi Helfand
• Mark Levison

This post identifies two visions for successful leadership within the Scrum Alliance. See also: Acceptance Tests and Concrete Actions (& Participants).

The group was divided into two teams. Each team independently went through the Strategic Play® visioning process:

1. Every team member built a model representing their ideas to support thought leadership.
2. In turn, each team member shared their ideas through the Lego model.
3. The models and ideas were integrated into a shared model. The results are shown below.

Shared Model from Team 1

Some Notes:

• Low barriers to entry
• Transparent
• A source of ideas (not only source)
• Listening to outside ideas
• Building bridges to other communities (PMI, Kanban, etc)
• Welcome other community members into our community
• Stepping places for learning and different approaches
• Many people working to move SA forward with coordination of effort and needs
• Let go of past
• Have awesome tools and capabilities within our community

Shared Model from Team 2

Some Notes:

• Simple machine with inputs and outputs
• Inputs are multiple communities through individuals and “antennas”
• Collect ideas in central backlog with adequate levels of transparency
• Courageous Leadership to move ideas forward
• Other leaders to spread ideas
• Assisting people with entry to so they can grow
• Building bridges with other communities

Discussion

There were a number of key differences between the models.  A few are discussed below.

What kind of leader? The inclusion of the Crown by one group was particularly challenging due to symbolic association to a king and absolute authority. Upon clarification, it was used to represent strong leadership that was inclusive of other voices and opinions. Something more than a facilitator and less than an authority.

What communities? The first group was much more oriented outwards to other parts of the Agile community and even wider. The second was focused more on the different communities or membership within the Scrum Alliance. So, both internal and external stakeholders are important.