This session, designed for experienced coaches and facilitators, will introduce using “geography” and teach specific exercises that you can use in your coaching work with individuals and teams.

Humans are gifted with a variety of ways of learning and knowing. Our left brain thinking emphasizes rational and verbal knowing. Our right brains connect us with more sensory-based, intuitive and spatial knowing. Agile Coaching with Geography uses both to work at the intersection between our inner and outer landscapes.

Agile Coaching with Geography supports individuals and teams to more deeply access non-verbal and intuitive ways of knowing and perceiving aw well as helping to make these aspects of a system visible to the system itself.

This session will show how NVC can be an important addition to your Agile coaching tool kit.

Last year this session was very well received.

NVC delineates four components of communication:
1) Observations free of evaluations;
2) Feelings straight from the heart;
3) Needs, values and longings;
4) Requests expressed clearly in positive action language.

We briefly introduce each area and then use experiential exercises where participants work in small groups to deepen the learning, followed by debriefing in the whole group to capture and share insights. We’ll also explore examples of how you might use these concepts in YOUR Agile coaching environment,

Process/Mechanics
It’s a fast paced workshop format mixing subject matter presentations, role play and activity-based experiential exercises. We will use real examples from our personal and professional lives to experience the depth and breadth of NVC and how we might use NVC in our day-to-day coaching practices.

—————PROCESS OVERVIEW—————
START-UP /HOUSEKEEPING
— Working Agreements for the Session
— Introductions/Housekeeping/Setup

OBSERVATIONS
— Observations exercise
— Problems identified
— Needs identified

FEELINGS
— Introduce empathy
— Small group role playing exercise
— Report back to whole group

NEEDS
— Introduce Needs-centric perspective as foundation
— Small group role playing exercise
— Report back to whole group

REQUESTS
— Introduce “Well-Formed” Requests - Understanding difference between requests and demands
— Small group role playing exercise
— Report back to whole group

Q & A

Learning Outcomes
— A language and consciousness of compassion that can improve your relationships
— Skills to support dialogue in the face of judgment, criticism, and anger
— Practice in honest expression and empathic listening
— Effective ways to bring more joy, ease, and connection into your life and work
— A nonviolent approach to team and organizational change

It is most important to note that when fetching data and passing it up into the application layers, it should be packaged appropriately based on the need of the calling layer. While you could simply pass full data entities of your Model into the application from repository calls, care should be taken to avoid unnecessarily exposing full Model entity details throughout your application. It is important to minimize the number of locations that will break if the data model changes over time, and rest assured, it will change over time. For this reason, we depend upon the ASL and Repository layer interfaces when using and accessing the Data Model as these methods can be used to create packages of data that represent just the specific information necessary to enact a Use Case or support a View. This collection of information is often referred to as the ViewModel; you can think of this as a Model specifically abstracted for the View, or a specialization of the domain Model.

We use the Data Transfer Object (DTO) pattern to create packages of information to abstract the ViewModel. And as the application layers are designed specifically to represent each Use Case, it makes sense to delegate to them the responsibility of creating such packages which will be contained in the Data Transfer Objects (DTO). The DTO’s are passed to the layers above to be used as needed, and subsequently passed back to the Repository for processing into the underlying data source using whichever data service technology is in force, whether NHibernate, Microsoft’s LINQ to SQL, the Entity Framework or calls to external services, etc.

Any DTO may contain an instantiation of a single entity, a collection of entities, or even just a limited property set representing whatever needs to be managed at the View or Controller level. At some point you may feel the need to reference properties of the Data Model’s entities, but in situations other than when Data Binding to controls, it is a better practice to limit direct property access, and instead use methods that act on the entity types and their Repositories as much as possible.

So, that’s it on layering for now. There will certainly be other classes and utilities in your solution as with any complex application, but utilizing ASL and Repository layers will give you some real bang for the buck. Once in place in your architecture, and once you get the feel for how to abstract the logic across these additional but thin layers, all of a sudden making changes to your system code becomes simpler, and you find yourself breaking and fixing your code less often, even though you may be re factoring faster and more frequently.

Adding layering functionality, even though you may have to spread it out across multiple classes, becomes less error prone because you find yourself writing simpler and less verbose code. Testing becomes easier because you only need to create tests for the smaller methods that you create at each layer. Method names can be more explicit and self-documenting because the methods themselves have a more explicit single purpose. And as your system grows, you become more and more aware of where each discreet piece of functionality lives and why it lives there, as a clean consistency of design slowly emerges and makes itself evident.

How about that…cleaner code, fewer bugs, easier to write, easier to test, easier to understand, easier to maintain. Who would’a thunk you get all this, just from adding a few more layers…but it’s true.