Partnership & Possibilities

As part of my commitment to my own professional development, a few months ago I attended a certification training program on effective practices in organizational change and leadership development. Although it required more time commitment than usual on my part, I found the experience well worth it. I would make the same decision again if I had it to do over. So when I heard that the Human Systems Dynamics Institute  was bringing its HSDP Certification Training Program to Portland in January 2012, I wanted to share my experiences and how the HSD methodology has positively impacted my practice and my work with my clients.

Human Systems Dynamics brings together theory and practice to effectively respond to today’s unpredictable, complex and emergent environments.  Rooted in complexity science, HSD incorporates a system of simple strategies that help to make sense of the patterns that emerge from chaos when people work and play together in groups, families, organizations, and communities.

Human Systems Dynamics is based on the premise that we interact in complex adaptive systems on a daily basis, in our personal and professional life.  Glenda Eoyang, founder of the HSD Institute, and Thomas Berkas, Ph.D, define complex adaptive systems as consisting of

interdependent agents, [where] the behavior of each agent conforms to a short list of simple rules, and the group of agents exhibits emergent, system-wide patterns of behaviors.

Recognizing these patterns of behaviors and how they influence the actions of groups and/or organizations helps us to understand the dynamics at play. From that recognition and understanding, we can apply simple rules to guide the behaviors of each person or team member in the organization, and in turn, lead to better and more effective working relationships.

In my practice, HSD has made an indelible impact on my approach with organizational systems and individuals.  Sharing the concepts and methods of HSD with my clients has had considerable influence on how my clients think about and work in organizational systems and, in turn, has brought about effective change in their organizations.

I recently facilitated a meeting with a group of managers who needed to create closer working relationships in order to effectively support their Agile teams and continue their enterprise IT Agile adoption efforts. To help them think about the culture and system they wanted to evolve, I introduced a short series of models and methods from complexity science and HSD that helped them to visualize their current system, describe their desired system, and choose next steps to move into an emerging future. By applying HSD processes, the group was able to move forward successfully.

I will be attending the HSDP Certification Training Program in Portland on January 18-20, 2012, as a volunteer Teaching Assistant (TA). The training consists of 10 full-days broken in three sessions (Jan, Feb, and Mar). Don’t let the time commitment dissuade you; it is well-worth it.

If you think this is something that would benefit you and your organization, consider registering for the training.  Or send me an email: dlarsen@futureworksconsulting.com.  I’ll be happy to answer any questions you may have or share information about my experiences with HSD.*

For additional Information on HSD, please check the following resources:

- Human Systems Dynamics Institute

- Options for Action: Power point presentation by Glenda Eoyang which describes paradoxes found in human systems dynamics.

- Simple Rules: Organizational DNA: This article by Royce Holladay describes the power of Simple Rules to establish patterns in organizations.

- Free webinars on HSD can be accessed here.

- Additional articles on HSD can be found here.

*Note: As FYI - I have no financial stake in this workshop or the institute, nor will I gain any additional benefit from it’s presence in Portland other than participating in it again while avoiding the travel. The “WIIFM” is the opportunity to create a local cohort of people who know and understand the methods and models. I look forward to the opportunity to create an ongoing learning group in which we can find more ways to help our clients and our organizations as they navigate complex times.

Some months ago I read a fascinating article from the British newspaper, The Guardian, forwarded to me by a colleague who knows my interest in the area of what is commonly called “gender intelligence”, or the relationship between brain chemistry and structure and male/female behaviors. Written by Madeleine Bunting, the article claims that virtually all of the scientific studies purporting to show that there are indeed, biological differences between men and women, are either misleading or so badly bungled that their results have no merit. She claims that the so-called breakthroughs in neuroscience, genetics, and evolutionary psychology suggesting the feminist consensus of the last 30 or so years that gender is entirely a social construct may be inaccurate, simply wrong or bad science.

Citing results from a number of well-respected researchers in the US and the UK, Bunting raises an interesting question, namely why the question of sex differences exerts such a powerful hold on us? Regardless of whether you believe sex differences are real or not, what makes raising the question occur with such frequency and such passion?

Elizabeth Spelke, Ph.D., a widely respected professor at Harvard, has studied the field of cognitive development for many years. Her research demonstrates that children as early as 10 months old categorize the world by gender. It is interesting that infants in her studies apparently do not show the same categorizations by race. Spelke notes that humans are “…predisposed to see the social landscape in terms of gender” and that we keep on looking for differences because that is one of the basic ways we order our experience of the world.

So does it add or detract from our experience of the world, our relationships, our ability to lead and manage others to think in terms of sex differences? When we do, are we simply perpetuating stereotypes or are we honoring diversity? What is your view on this topic?

“Our experience thus far has been that while self-organizing teams may enable the organization to operate from day to day without active management, a more integrated organization and more productive teams make the value-add of managers highly transparent and place a premium on specific leadership skills.” from Adam Light, Chris Vike and Diana Larsen. “Teamwork Required: Managing Agile Application Delivery in a Matrix Organization”, Cutter Agile Product & Project Management Executive Update, Vol. 12, No. 19. October 2011.

For a free download of the article pdf, register at the Cutter site. You can also order reprints from Cutter to use as a discussion case study for your own management teams as they navigate the transition to Agile.

December 12 & 13
8:30 am – 5:30 pm
Hotel Vintage Plaza
422 SW Broadway, Portland, OR 97205

Price:  $1750 per participant*
Group Rate:  Register 3 or more participants at $1550 per person

REGISTER

The workshop is limited to 18 participants, so make sure to reserve your spot soon!

Course Overview 
Managers have a unique role to fulfill in an Agile world. Whether leading a shift to Agile methods or guiding a newly Agile organization, effective managers join their current skills with strategic tools learned in this course to keep people and teams on track.
 
This course gives you the hands-on experience and builds the skill set you will require to thoroughly understand and utilize the real-world fundamentals of managing in an agile environment. The instructors bring their expertise in agile management, planning and development to help managers utilize their knowledge and skills to harness the power of an Agile organization.

Course Description

Workshop Leaders
Diana Larsen
Sharon Buckmaster

*The price includes participation in the 2-day workshop AND two (2) hours of individual one-on-one coaching with one of the instructors.

Over at her “Insights You Can Use” blog Esther Derby has posted two pieces on how teams can benefit from the lens of Double Loop Learning in their retrospectives. Chris Argyris first wrote about the concept of single and double loop learning in the 1970’s. Esther offers a specific application for Agile teams with:

A short essay, “Promoting Double Loop Learning in Retrospectives”
and
A slideshow, “Double Loop Learning in Retrospectives II”

To learn more about Chris Argyris and his theories of action, including double loop learning, see:
Smith, M. K. (2001) ‘Chris Argyris: theories of action, double-loop learning and organizational learning’, the encyclopedia of informal education, www.infed.org/thinkers/argyris.htm. Last update: September 07, 2009
and
Wikipedia. “”Chris Argyris”

Team member: How will we know when we’ve found an impediment? What do they look like?
Sponsor: How can I know what impediments block our teams’ productivity?
Scrum Master: How can I get the team to mention impediments in our daily meeting and retrospectives?
Product Owner: Why is everyone whining about impediments? Why don’t we just get the work done?

It’s all fine and well to say identify and remove impediments but often we bump up against a stumbling block, find a way around, and make things work anyway without further thought. It’s second nature. Moving forward is what’s important. And, besides, those stumbling blocks? That’s just how it is around here.

Recognizing and shining a spotlight on impediments isn’t as easy as it sounds. At the Agile Roots 2009 conference Tom Perry led a session to do just that.

In his session, the participants (including me) focused on this question. We came up with a list teams could use to amplify their ability to recognize and manage impediments. Typical impediments fall into categories, including:

Incomplete work
Missing information
Repeated work
Waiting
Missing dependencies
Interruptions
Defects
Bureaucracy
Missed/Unclear communication
Unmade decisions
Faulty assumptions
Insufficient time
Missing parts
Unknown new technology (contributed by @mxmoss)

…to name a few.

What kinds of impediments do you find?

In a article at the Six Sigma IQPC site, Christian Loyer offers a new twist on the old fishbone diagram root cause analysis approach.

He describes the usual application of a fishbone diagram for digging in to solve a problem. In addition to Ishikawa’s Ms for manufacturing fishbones that Christian mentions, I’ve also used Ps or Ss. You don’t have to stick with these. Try to think of all the factors present in your organizational system that can affect your current project, and come up with your own fishbone alphabet.

During a retrospective, the traditional fishbone works as a team activity for Generating Insights to help the group reflect on the data the they’ve gathered and dig into the root causes of issues.

However, Mr. Loyer offers a new way of applying this technique. He calls it the reverse fishbone and uses it to help a group anticipate what’s to come and make plans for helping their project succeed. As a project manager, he notes that using this technique collaboratively helped him to perceive the project in a different way and understand needs he might otherwise have overlooked.

Consider using this reverse fishbone activity in your next retrospective to Decide What to Do by envisioning actions that could move the team closer to their goals.

A Flexible Framework for Agile Retrospectives:

Set the Stage
Gather Data
Generate Insights
Decide What to Do
Close the Retrospective

For more retrospective activities, check out the “retrospectives” category on this site.

Martin Jul writes about a retrospective activity in the post “Retrospectives - Adapting to Reality.” He describes an interesting process for highlighting issues in the Generating Insights part of a retrospective session.

In this activity we mark out three sections on a whiteboard:

“DO” is where we put the things we should do or keep doing. This is all the things that makes us more efficient. We don’t list all the good practises, just the ones we are currently learning and need to do consciously until they become habits. An example could be “Talk to the customer about the requirements before we start implementing them.”

“DON’T” is the section with all things that we do that lead us to step on the usual landmines. These are the fires we are currently fighting and the things we want to stop doing. Tom Peters calls this a “To Don’t List”. Example: “Don’t over-architect the application to support speculative future requirements”.

The third section, “TRY”, is the section for new things we want to try out and evaluate. Example, “Try adding automated acceptance tests with FIT”.

Everybody contributes. As the team names items we cluster them so similar items are grouped in one. Then, the next step is selecting the most important ones as focus for the next iteration.

We normally recommend a simple process called “dot voting” where each team member puts a dot in each area to mark what they rate as the most important item. This is usually enough to make it clear what the most important issues are. We post these on a big visible “Do / Don’t / Try” chart in the team working area. They give focus to the things we should do consciously for the next iteration. Then, as part of the next iteration retrospective, we look back and evaluate the results.

We keep the things that help us for as long as they keep helping us.

The simplicity of the activity appeals to me, and that it focuses on three ways of continuously improving the team’s effectiveness.

I’d make one change. Instead of asking team members to vote on the most important issues, I’d ask which would provide the most benefit or most positive impact. For many teams, “most important” means many different things to different people. Most important along what dimension? I like to take a step closer to clarity with asking about impact.

In the next step, Deciding What to Do, the team could identify an actions to match each of the three items, gain commitment for the next steps, and take those next steps into the planning meeting as tasks. I like it!

Plus, as the retrospective leader, it gives an opportunity to use your Yoda voice!

Michael Tardiff (@mjt) tweeted:

Forget pleased & surprised: I’m astonished at the energy & number of seat-switches in “Park Bench” when tackling “creating insights.” Wow.

I’ve used “Park Bench” at the end of workshops as a way of reflecting on the day or as a debriefing technique after a training exercise to uncover group discoveries. You may be surprised that I hadn’t thought of it for retrospectives. I was. Luckily, Michael thought of it.

“Park Bench” a great technique to engage a team in the “Generating Insights” segment of the Agile Retrospectives framework. It injects fun into the session with a bit of “role-playing” on everyone’s part, though no real acting talent is required.

Set Up the “Park Bench” Activity
Start with a set of data gathered from all the team members - a timeline, team radar, FRIM, charts with effort or velocity data, or other substantial sets of events, attempts, accomplishments, tasks, that happened during the iteration or release.

Line up 4-5 chairs in the middle of the seating circle or across the open end of the seating “U”.

Envision an imaginary “park” and visualize the line of chairs as a “park bench.”

Describe the Park Rules:

There must always be at least one open seat on the bench. Anyone may join the bench (and talk) whenever there is an empty seat. If the last seat fills, someone else must leave the bench. People who are not on the bench may not comment, only people on the bench can talk. People who are not on the park bench listen closely to the conversation, take notes, and join the bench when they have something to contribute to the discussion.

In the Park
The retrospective leader (RL) sits in one of the chairs and begins to talk about a few observations of the (imaginary) park, the day, and the data, while wondering out loud what meaning other people might have made of it. The RL hopes that someone will sit on the bench too, to share and discuss their insights, thoughts about implications, and other interpretations of the data.

In the imaginary park world, people walk by, then join the RL for a while on the park bench (i.e., in one of the chairs). They share their insights, discuss, and go on their way. There may be several people on the bench at the same time. The RL may leave the bench to make room for someone new. The rotation of keeping an empty seat gives more people the opportunity to share their thoughts.

Eventually dusk falls in the park (the flow of comments slows) and everyone leaves the park bench, including the RL.

Moving into Action
Choose the next activity to help the team synthesize their insights and ideas from the Park Bench into proposals for improvement or impediment removal actions if ones have not already emerged.

Michael offers a great reminder! And not only about this activity. It’s a reminder of how many activities can serve multiple purposes in supporting groups of people learning and thinking together if retrospective leaders think creatively about applying them in new situations.

Today I invented a phrase (at least I think I invented it because I haven’t heard anyone else say it): “Avoidable Heroism.”

I invented it in response to a question, “Should my team work on the weekend to meet a commitment made under their control?”

Now, I don’t know the background behind this question. Maybe it’s perfectly reasonable for them to work on the weekend. Maybe they have no agreement about sustainable pace. And, it raises a few questions in my mind. How often does this happen? How far from the commitment are they? When was the first, best opportunity to re-negotiate the commitment? How did it slip by? What else is happening that affects their ability to commit and deliver?

Avoidable heroism happens on teams when the system pressures the team into committing to “stretch” iteration goals (rather than evidence-based goals) and someone (or more than one someone) has to work nights and weekends to meet the commitment.

Avoidable heroism occurs when unit test coverage goes down, team members focus on cranking out quantity of code rather than quality code and “forget” TDD, so that at a certain point a team member throws themselves on the technical debt grenade and begins to clear away the debris.

Avoidable heroism ensues when team members hand the new code to the testers on the last day of the iteration, rather than including them as part of the cross-functional teamwork from the first day.

And so on.

In the 1980’s (yes, I know that was before many of you were born), Tina Turner sang an anthem, “We don’t need another hero!”. Make it your own, your team anthem.

N.B.: I hope someone out there who’s into writing anti-patterns will collaborate with me on documenting this one.