Thursday, April 30, 2015

Working Agreements

Working Agreements

In a recent post, making a distinction between agreement and alignment, I discussed helping two groups of teams develop a partnership. One valuable discovery was watching how working agreements developed.

Starting with an Intention

We started with an intention not a set of working agreements. The intention was created based on what the group was out to achieve.

The intention was, with names removed, "Team Blue requires Team Green in order to achieve it's desired outcomes. Team Blue will groom the backlog to a level that Team Green can say they are ready to be planned." This was done in the context of developing a partnership.

Discovery of working agreements and rules that support the intention

Working agreements were discovered by doing the work and a common intention.

We discovered how often we needed to meet and for how long. We discovered how best to track where we were and how to make that visible. No one had to be convinced to use the tools or follow the agreements, it would have been silliness not to.

We discovered what topics and discussions lead us away from our goal, and rules were setup regarding those topics.

Acts of Leadership will cause working agreements

"Teams develop norms whether they are paying attention to norms or not." Esther Derby - See more at.

It was acts of leadership that injected the possibility of a future of partnership and participation. From this created possible future came working agreements that supported that possible future. 

A common practice I observe is getting people together to create working agreements. This is done without creating a future, an intention, that resonates with people. The outcome of this is a set of agreements that we use to make excuses for not keeping them.

Leadership injects what is missing that creates space for people to win. In this example, leadership injects partnership and removes anything that is not partnership. 

Leadership removes what exists that will hinder people from winning, by helping them see what is in the way of them winning, in this case blame, disappointment, broken promises, lack of concern for others and more. Much of this was displaced by injecting partnership. 

A leader helps people see their normal way of being and acting that is taking them where they say they do not want to go. 

A leader develops people to have the compassion to develop others such that they see and deal with their inconsistent actions, as the leader sees and deals with their own inconsistent actions. From this real working agreements can develop and evolve.

Effective working agreements are not a team goal they are an outcome of being team.


Monday, April 27, 2015

Alignment vs Agreement


a·gree
əˈɡrē/
verb
verb: agree; 3rd person present: agrees; past tense: agreed; past participle: agreed; gerund or present participle: agreeing
  1. 1
    have the same opinion about something; concur.
    • approve of (something) with regard to its moral correctness.
      "I'm not sure I agree with abortion"
  2. 2
    consent to do something that has been suggested by another person.


a·lign
əˈlīn/
verb
verb: align; 3rd person present: aligns; past tense: aligned; past participle: aligned; gerund or present participle: aligning
  1. 1
    place or arrange (things) in a straight line.
    "gently brush the surface to align the fibers"
    synonyms:line up, put in order, put in rows/columns, straightenplacepositionsituatesetrange
    "the desks are aligned in straight rows"
    • put (things) into correct or appropriate relative positions.
      "the fan blades are carefully aligned"
    • lie in a straight line, or in correct relative positions


Agreement is less helpful than we think

Agreeing and blaming

I have been pairing with another coach, in a high dependency environment, to help create a team phenomenon, a partnership, within a team of teams. A phenomenon we have observed is the how the need for agreement tends to slow conversation and cause partnership to deteriorate.

The initial place the teams operated from was trying to get the other team(s) to agree with them. These conversations were quite painful and not very productive. Trying to get agreement was leading to one group trying to convince the another group that their view was the right view.

Dissonance


dis·so·nance
ˈdisənəns/
noun
MUSIC
noun: dissonance; plural noun: dissonances
  1. lack of harmony among musical notes.
    "an unusual degree of dissonance for such choral styles"
    • a tension or clash resulting from the combination of two disharmonious or unsuitable elements.

Outcomes of agreements tend to be contract like. I will give you X if you give me Y with these caveats. There are plenty of outs if one side did not meet the contract exactly. There is no commitment.

Agreement tends to bring a dissonance, in the conversation, when their are break downs. When break downs occur, i.e. people's intentions are being thwarted, one group is trying to "fix" the other group. The discussion sounds like "it should not be this way" or "it should be this way". As a group they are unable to deal with what is happening. Instead on an inquiry into what is happening, blame and excuse exists.


Alignment is an interesting distinction to agreement

Alignment and committing

As we introduced the idea of partnership and listening for what it takes to meet another teams concerns, agreement started to disappear. Teams would have discussions that started with what do you need to know to be ready to do this. It started with an inquiry into the feature. The inquiry would then go back and forth. Often a team member would take information from one team and start walking through the steps it implied and finally just stop and go, "ahh I get it".


Resonance 

res·o·nance
ˈrezənəns/
noun
noun: resonance; plural noun: resonances
  1. 1
    the quality in a sound of being deep, full, and reverberating.
    "the resonance of his voice"
    • the ability to evoke or suggest images, memories, and emotions.



Alignment looks like resonance, deep, full and reverberating. All concerns are out and everyone is clear the direction we are headed will fully deal with them.  The attitude is, we can make this happen and it leaves space for an authentic commitment, despite any complexities.

Teams in this stage trend away from excuses and blame when things do not go as expected. Teams at this stage understand that breakdowns will happen and they can look at what is happening and where they are intending to go and deal with the break down versus blame someone for it.


Give it a try

Why not try coming to alignment instead of getting agreement the next time you need to work with someone.

Instead of trying to convince them to agree with you, inquire into what their concerns are. Listen and look for possibilities to deal with those concerns. When all parties concerns are on the table and it is clear everyone is committed to meeting those concerns, observe what happens to the conversation.

Notice your own ability to deal with others concerns. Can you be with them and deal with them or do you simply explain why they are wrong?

As with all inquiry, you will learn more about yourself than anything else.



Thursday, April 23, 2015

Agile Process Coach, Really?

Really?

Agile is not a process... Here's an Agile Process Coach to help you understand that. :-)

It shocked me the first time I heard that title.

Of course, when I am honest with myself, I know that I fallback to being a process consultant instead of a coach when I hit certain impediments.


Tools and Techniques are Process Consulting

I am seeing way to much of agile IS:

Doing 1.5 hour retrospectives using the 5 stages as defined in the book by so and so.

Stories are written in the format in that book by that other Scrum dignitary.

The ideal team size is...

The ideal planning cycle is...

The best tool for this practice is...

blah, blah, blah...

There is nothing wrong with these things. These are tools and techniques, often good ones, and they are not agile.

They do not generically combine, without context, into an agile process.


The Easy Way 

The easy and minimally effective way is to use this tool, technique or process.

Do it this way and it will solve all of your problems.

Standup is asking these 3 questions.

Here is the correct tool, technique and/or process.

You must use Scrum or Kanban or XP or or or

I have the answers for you.

Making people bad and wrong.

If you do not use so and so's 5 steps for retrospective you are doing it wrong.

Defining the right process outside of doing the work as if there is a generic context.

Release planning IS all of the stories organized by team and by sprint for the next n Sprints.

There is nothing wrong with these things, they may be helpful at times. These things are process consulting, not coaching and not agile.


The Hard Way

There is a more powerful way based on being compassionate, inquiring, being curios, discovering and being generous. You might call this leadership.

This is hard and it will require uncertainty and fear to be dealt with.

Getting comfortable with what is happening.

Getting comfortable with entering into an inquiry with curiosity and learning.

Developing our ability to discover and uncover better ways of working by doing and helping other do.

Discovering what people are committed to. What are they out create or do?

Helping them see when their level of performance in achieving the things, they say, they are committed to, versus measuring how agile they are, or how well they follow the defined process.

These things are not more right than the easy way. They are more powerful at allowing people to uncover and discover for themselves who they are and what they are out to create.

These things will enable people to become profoundly aware of what they say and what they actually do.

A coach will do this with compassion remembering what they had to discover.

A coach will be someone who remembers how painful it was for them to admit, to themselves, that they say one thing and do another.

A coach will remember how often they judge people on a standard they do not follow.


Where am I

I know I struggle with going back to the easy way.

To often, I encounter a situation where I sell out.

I turn back to being nice outwardly and thinking inwardly how bad and wrong you are.

When I see that in me, I simply acknowledge and get back up and go again... Often with help of my own coaches.


Where are you?

Tuesday, April 21, 2015

Manifesto for Blame Driven Development

Manifesto for Blame Driven Development

Performance Improvement Plans and Firing People over Resources and Interactions

Bug Triaging over Working Software

Personal Agendas over Customer Collaboration

Endless Debates over Responding to Change

That is, while the items on the right will give us a chance to succeed,
we value covering our ass over a possibility to do something meaningful.

------------------------

Principles behind the Blame Manifesto

Our highest priority is to deflect blame for all problems
through early and continuous failure of others.

Welcome changing requirements, even late in
development. Blame processes harness change
for opportunity to delay commitments.

Deliver non-working software infrequently, from a
couple of quarters to a couple of years, with a
preference to the longer timescale or not at all.

Business people and developers must make
vague and incomplete requests of each other 
daily throughout the project.

Build projects around depressed resources.
Give them judgement and punishment,
and watch them squirm.

The most efficient and effective method of
conveying information to and within a development
team is domination and intimidation.

A high bug count is the primary measure of progress.

Blame processes promote sustainable employment.
The sponsors, developers and users should be able
to maintain employment for an indefinite period 
regardless of their inability to honor commitments.

Continuous attention to technical incompetence
and poor design enhances blame-ability.

Simplemindedness — the art of maximizing the amount
of useless conversations—is essential.

The best straw men architectures, incomplete requirements and aimless design
emerge from withholding information.

At regular intervals, the team reflects on who
needs fixing, then tunes and adjusts this person’s
behavior.

------------------------

Here is a blog post with an example of implementing Blame Driven Development.

Saturday, January 10, 2015

Accomplishment and Satisfaction Over Happiness

“Great things are done when men and mountains meet.” 
― William Blake

“You may not control all the events that happen to you, but you can decide not to be reduced by them.”
― Maya Angelou

The Challenge Accepted

Wow! No one had asked me about that tool in over a year. I was sure that no one was using it anymore, I thought to myself as I read the request to review a set of changes and update requests. A bit excited that something I had created was still interesting to others; I decided to take on the work of reviewing changes and updating the tool.

I was satisfied with the tool after I created it. Over time, my skills and the available tools have improved and the code looked very inadequate. That is me trying to be easy on myself. Of course, the inadequate area of the code happened to be the area I needed to update due to a deprecated API.

Continuing despite how I felt

It took me a day to recreate my desire to update the code after looking at it and feeling frustrated about it's state. I was definitely not happy!

Once I started working on the code, I was sure things would get better quickly and I would have it back to a state that made me smile. Nope! After an hour of working, I had completely obfuscated the code. So, I reverted it back to the original state to get the test working again. At this point I was feeling angry with myself and I definitely was not feeling happy!

This unhappy state was not due to an oppressive working environment. It was not due to anyone around me not doing their job and dumping all the hard stuff on me. It wasn't even due to terrible, buggy code, this code only had one defect reported by users and that was for a test case that did not exist when I released it. It was simply the emotions I felt as I went through relearning and dealing with the state of something that was not easy to deal with, mostly due to time.

Accomplishment and Satisfaction

The next day, I set all of those feelings aside and worked on updating the code. The first I noticed was there were things I did not need. The code that needed updating came from someone who required features I did not need so I deleted those parts. That made it much easier to deal with and understand.

The person who asked for the update sent me a link to a document that described updating from the old style to the new style and this turned out to be simple with the unused parts removed. After a couple of hours I was done and all the old tests still passed. I accomplished what I set out to accomplish and it was satisfying. I was happy for a while, as well.

Wes, why do you write this simple story?

It was been relatively popular of late to recommend people measure happiness to see how well teams and people are performing, especially in the agile community.  It generally works by asking question like the following:

  • How happy are you? (on a scale from 1 “very unhappy” to 5 “very happy”)
  • What makes you feel best right now?
  • What makes you feel worst right now?
  • What would increase your happiness?

NOTE: The implementation of the happiness index at Crisp had very specific intentions and a better wording than the generic one about. e.g. How happy are you with Crisp? vs. How happy are you? Though still using the idea of happiness, they also state in the blog post that "The important thing is not really the content of the A3 sheets. The important thing is how they were created, how they are used, and the fact that we now have an explicitly defined identity & strategy, which makes it easier to criticize and iteratively improve over time."

I have strived for happiness, and still do at times and seeking happiness in and of itself is never satisfying. If happiness was what I really wanted, I would not take on many challenges. The example I gave is quite a simple one that involved a few hours over 2 days. In other words, it does not compare to most of the bigger challenges in life I take on.

The intention people seem to have with the happiness index or metric is not my concern. The intent is usually related to creating an environment where people can achieve mastery, autonomy and purpose.

I have the same concern for an environment that allows people to achieve mastery, autonomy and purpose. In my experience happiness does not represent those achievements. This could be a simple definition problem for many using the term. e.g. languages other that english tend to have a broader selection of words that are incorrectly translated to happiness. The first meaning of happiness, from Merriam-Webster is:

hap·py

 adjective \ˈha-pē\
: feeling pleasure and enjoyment because of your life, situation, etc.
: showing or causing feelings of pleasure and enjoyment
: pleased or glad about a particular situation, event, etc.

Maybe others are different than me, but my feelings, i.e. emotional states or reactions, change throughout the day and usually minute by minute. These feeling are always with me and often affect my actions, yet they do not tend to cause actions that lead to outcomes that move me towards mastery, autonomy, purpose, accomplishment or satisfaction.

In my experience, my feelings often lead me in quite the opposite direction of my intentions. They lead me to stop taking on challenges. They lead me to not do things I thoroughly enjoy. I get to the end of the day and I question why I wasted so much time, feeling sorry for myself, watching TV or reading social media, instead of playing the ukulele, writing down what I have learned today or creating something that solves a problem I saw.

I am not trying to call happiness, and my other feelings, good or bad, that is a bit irrelevant as they are always with me and I must deal with them. I am saying these are not the things to measure.

In order to keep happiness high or more likely return it to some 'acceptable' level, I will need to constantly input some type of stimulus.

I propose we replace the happiness goal with goals for:

Accomplishment: to achieve what we set out to achieve.

and

Satisfaction: fulfillment of our intentions

As with those experimenting with the happiness index, I am aware that these in and of themselves are not complete. I can easily see someone with destructive intentions using these incorrectly. The very definition leaves room for people to 'fail' because they do not define what we are out to achieve nor what our intentions are.

In my experience, the possibility of failure is required for me to achieve those deeper intentions beyond my own happiness.

I have shared some of my experiences and I do not ask you to apply this to yourself. What would be much more interesting would be for you to look at your own experiences, which will differ from mine, and answer the questions:

Is happiness what helps you verify that you are heading towards your intentions or purpose?

Do accomplishment and/or satisfaction come closer to allowing you to adjust your path towards your intention and purpose?

Maybe there is something else?