The Power of an Agile Mindset

Linda takes us from a negative to a positive affective style, from a posture of seeming or being to one of becoming.  There is just so much to know and understand here.



If you don't already love Linda Rising, you surely will after this.

Notice the tie-in to Seeming v. Being v. Becoming. Mine is derivative, of course.

Empathy and Experience: Coaching

You use an experienced coach instead of the nearest guy with a scrum master certificate because you better chance of success when you're guided by someone who cares, connects, knows the work system, and has been through a few transitions before. Empathy and experience are the stuff that good coaches are made of, yet either of them can become a trap.

Empathy is crucial, but can pickle a coach. When he identifies too strongly with the team and product he'll soon find himself taking on coding assignments and coping with (or adopting) the local pre-agile culture instead of pushing for transformation.  Once the coach's role has been relegated to staff augmentation, the freshness and clarity of his vision is greatly diminished.

Likewise, a consultant can succumb to prior experience and waste his engagements trying to recreate a past glory. A good coach needs to respect the context and personalities and experience base of each team and help them to do their best; doing otherwise leads to frustration.

However great the past may have been and how much you care about the team, your clients need a present-tense, temporary coach.

Seem, Be, Become - Choose a path.

There are many kinds of good, and how we approach them tells a lot about us as people. Take 'Agile' for software developers. 

There are (at least) three different ways to approach this particular kind of good:

One way is to try to adopt the appearance of Agile because "it looks good" or perhaps it would be embarrassing to admit we are not. If we are avoiding the appearance of being non-Agile, then our efforts are likely to fail. Agile development is about engagement, yet maintaining appearance is mostly about compliance (or obligation). "Seeming" without first "becoming" is a kind of misrepresentation, and can strain relationships that would work more smoothly on a basis of trust.

One may want to be recognized as already having the kind of good that Agile represents. This is more legitimate, because most developers have teamed up on tough problems, written unit tests, collaborated with teammates, or worked in short time boxes of a a few days or a few weeks. Most of the XP practices were in existence well before XP became "a thing", let alone before the Agile Manifesto came into being. Being "a little agile-like" isn't harmful, but the "heard it all before" crowd take longer to internalize values and practices. As a result, they frequently lose their position of leadership to more eager, humble, and quick-learning peers.

The third way is the way of humility and hard work. One can become an expert by adopting concepts, developing skills, and building a reputation. It is a fair amount of hard work, and it's going to involve learning as much as you can, as fast as you can, from as many as you can. Along the way you will pick up the appearance and the reputation for the work you are actually doing. You are not distracted by maintaining appearances, not afraid of being exposed, not slipping behind your peers. It's very honest and open-hearted. 

This is not just about Agile development. We are faced with the same three choices for any kind of good that an individual, team, department, or organization is pursuing. When these are the choices, remember that the way of humility is the more rewarding.

Chickens with a Pig Complex?

Famously, scrum has used an old joke to explain two kinds of participants in development work. Pigs and chickens is a reference to having bacon and eggs for breakfast; the chicken is involved (donates an egg), but the pig is committed (gives his all).  In scrum, this translates to stakeholders (chickens) and material participants (pigs).

It always seemed funny that people who are on the hook to pay for the work are chickens and those who are paid whether or not the product succeeds are pigs. Still, I appreciate calling out the idea of advisors and stakeholders v. material participants.

I wonder sometimes about those roles for people who are not primary stakeholders, yet are somewhat involved in the development, but primarily act to give permission or to grant or withhold resources.
Are those chickens with a pig complex? Pigs with chicken complex? Porklucken?

1. Non-coding architects who must approve designs
2. Sysadmin/IT who controls the team's computing resources
3. External UX designers who control the look-and-feel of the application
4. Stakeholders who micromanage or create back-channels to push conflicting goals on development teams

I am the kind of coach who believes in inviting people into the house, not shutting them out.  My strong preference is that people who want to participate materially should be brought into the team (as co-equal "pigs"). I am not one for hierarchy getting in the way of progress. I don't care for people sniping from the sidelines, hamstringing hardworking teams, or participating only in terms of holding a veto. I like to see people engage or make room.

Do you deal with odd semi-participants? Have any stories or tricks you'd like to share? 

Images from Pigs and chickens free coloring page!

Evil? You tell me?

This just in from the put-your-money-where-your-mouth-is department:

Bob M. hung out a blog post describing the evil that is agile coaching. I didn't recognize myself in the mirror he proffered, but because I'm an agilist I value feedback as the first necessary step in the whole problem solving system. Without a closed feeback loop, how can we reach clarity and improvement/acceleration?

So, this is for all the people I've coached, whether as a paid agile coach, coworker, manager, or neighbor.  Take a look at Bob's post for inspiration and pop back here to do me a favor by answering questions:

Am I evil?
In what ways am I evil?
In what ways have I served you, or done you disservice.

I await your feedback.

Affording Agile (Emotionally)

A few ideas rattling around my head need a place to live while I think them through, so I am shoveling them into the ole blog so I can think about prepping materials and exercises for a class I am teaching soon.

I was considering an archetype developer that we've all seen (heck, half of us have been) and how hard it is to reach this particular type when doing any kind of a technology or methodology change.  Here's the stream:

• There is this guy who believes he's an exceptional programmer, but underrated and under-respected by his peers. Why does he think he's good?
• Maybe he doesn't really believe it. maybe he's afraid. (@RonJeffries)
• A guy who never thinks or reads about programming off-hours, never goes to talks, hates pairing, skips reviews. Thinks himself an expert?
• b/c folks like that have a Darwinistic career advantage over peers who /are/ good but think they're mediocre/overpaid/overrated (@LancePurple).
• I suspect Dunning-Kruger Effect. Not good enough to know he's not the best there is. Needs to get out more.
• There's an old chestnut that 80% of licensed drivers believe themselves to be above-average in driving skill.
• Svenson, O. (February 1981). "Are we all less risky and more skillful than our fellow drivers?". Acta Psychologica 47
• McCormick, Walkey, Green ('86). "Comparative perceptions of driver ability— A confirmation and expansion". Accident Analysis & Prevention

The idea bubbling under the surface of all of this is that maybe there are entire groups of people who can't emotionally afford to work in an Agile way.  In addition to those who have various social dysfunctions (like my friends with Asperger's Syndrome or those simply untrained to social forms of work as I was) there are people who suffer from illusory superiority or from imposter syndrome. 

An advantage of working in an agile team is the feedback you have with your team members. You differ in approach and mindset, and you get to enjoy each other's genius and mania. I have learned great tips and techniques from people without a tenth of the experience I have, and have often felt surprised when people feel they've learned from me when I didn't think I was doing anything novel or smart. 

But now I wonder if that synergy isn't seen as measurement as well as an opportunity. Learning about "incremental" and "entity" theory of intelligence has me holding to a new appreciation of how hard it is for people to make this change. 

Where does that leave me? I still don't know how to reach my archetypical developer who isn't interested in finding out that he's not as good as he thinks. His life doesn't center on his development skills, and "it's just a job." He is working heads-down doing the same stuff he's been doing the past n years and has every intention of carrying on the same way until retirement or death. How can I spark an interest in the craft? Can it be done? Can I reduce the personal threat of changing to an agile way of working? 

There, now it's on a blog and I can freely return to it later. All comments, suggestions, feedback, criticisms are welcome in the comments below. Thanks for bearing with me.