Vincent sought continuous improvement

I had the great fortune of seeing the "Becoming Vincent" exhibit at the Denver Art Museum and was truly moved. I've always been drawn to the Impressionists, and Van Gogh has been a favorite. However, I wasn't moved simply because of Van Gogh's incredible use of line, color, and light. It was because Vincent constantly sought to improve upon his work. 

He continually integrated new ideas into his work. From his dark pastoral scenes in Holland, he started adding brighter colors when he went to Paris. After viewing prints from Japan, he explored the lines and shapes similar to visually appealing prints. After being criticized for how poorly he drew the human form, he practiced until it became natural.

Vincent Van Gogh understood the importance of practice in his painting. As he wrote to his brother Theo: "As practice makes perfect, I cannot but make progress; each drawing one makes, each study one paints, is a step forward." Vincent was motivated to continuous improvement, an understood that practice and stretching oneself, through exploring different styles and ideas, was one path.

Feedback on the small

We’re at the end of the year… and given that December 21 is more than half-way done, I’m relatively confident that no apocalypse will keep me from seeing 2013. As with many people, I take some time at the end of the year to evaluate how I’ve done, and what I want to change going into the new year.

But I’ve been thinking about smaller feedback loops recently. I got a bread-maker as an early Christmas gift (I think my husband and sons were anxious to enjoy the results!), and have discovered that I need to evaluate and adjust every recipe that we make – the joys of living at high altitude.

So, I’m taking notes on how much more water or less yeast I need. One loaf worked quite well – almost too well! So I’m starting with the adjustments from there. A tablespoon more water, an eighth of a teaspoon less yeast, less flour, more salt… you get the idea I’m sure. I’m currently tracking all these changes in pencil on the recipes I’m using. I’ll get it right eventually, I’m sure.

In cooking, you can see the results, and get the feedback, almost immediately. How come I have trouble remembering to evaluate my coding work? The sprint’s daily progress? The most recent teachable moment? We don't need to wait for the retrospective, or even the daily stand-up, to assess our work, as a team or an individual.

What are the comments, sensations, and reactions in your daily life that provide the same feedback as that first bite of fresh-baked bread? How do we keep track of the incremental improvements? Some possible reflections:

“That conversation went well. I remembered to listen to the end of the sentence.”

“My unit tests got further when I added an init() method.”

“This sprint seems to be going better than the last one. We decided to start ‘walking the board’ in stand-up and now everyone knows exactly what’s going on.”

“The team is more open in appreciating each other’s contributions. I wonder if that’s a result of the appreciations part of our last two retrospectives.”

Happy New Year! May you find feedback where you need it, as well as the quick, agile adjustments to get the most out of that feedback.

Trust and vulnerability

The snake, Kaa, in The Jungle Book, sings a song to Mowgli: “Trust in me, just in me, Shut your eyes and trust in me, You can sleep safe and sound, Knowing I am around.” Now, we all know that Kaa really isn’t to be trusted. We know it usually takes more than blindly accepting someone else’s statement that they’re trust-worthy. More often than not, if someone says they’re trust-worthy, we double-check their references.

So how do we build trust within a team?

Lyssa Adkins is promoting a hashtag on Twitter - #vulnerabilitytrust - this is my motivator for this column. She wants to see how and when agile teams build trust, and acknowledges that much of it has to do with how and when we show vulnerability.

I must admit, I’ve been feeling vulnerable writing this article (those of you who write regularly may understand). This piece just has not flowed. My colleagues who usually just provide a few minor modifications helped me see what was wrong. I didn’t put myself into the writing. I was going through the motions, noting what one expert says on how to build trust, and listing a few of the results from the Twitter hashtag.  But I didn’t talk about me. I didn’t show my vulnerability. So I’m trying again.

How do we build trust within a team?

My answer? I start with trust.

When I work with you, I start out by trusting you. You don’t have to earn my trust at the start. I will share with you what I know and what I don’t know. I will let you know what I’ve seen that’s worked and what hasn’t worked. I will even talk about how I haven’t been able to figure something out, and perhaps you’ll be able to solve it.

And I will expect you to do the same.

I expect that trust to be reciprocated. I expect honesty and dependability. A little humor never hurts either.

Now, you may lose my trust, depending how you respond to my vulnerability. Because, through this open communication, I have shown you where my faults lie. You may realize that I’m not as strong a developer as you, or that I have some really odd personality quirks.  If trust is lost, we’ll have to figure out how to rebuild the relationship, and how to re-establish that trust, perhaps starting with an element of the trust that didn’t get lost.

Patrick Lencioni notes that trust takes courage. I agree. 

Global values, Agile values

Adaptability. Commitment. Respect.These values sound like agile, eh? Not this time...

My family and I enjoyed a visit to the Denver Art Museum, where we got to play with rock doodling, similar to the artwork of El Anatsui. A Ghanaian sculptor, El Anatsui often used symbols to evoke meaning from his audience. Some of the symbols we doodled included adaptability, respect, change, and commitment. I was initially surprised at the overlap with the values this artist portrayed and the values the agile community identify with. But then it wasn't so surprising.

Every culture, sub-culture, community finds items like commitment and respect important. If I say I will do something - whether it's code the getRecord() method or return your water jug - my word is my commitment. If I don't follow through, how can my neighbor (or fellow developer0 depend on me in the future?

What values do you carry in your every-day life? How do they fit into agile?

Fail Fast, Fail Often, Fail Cheap

I’m working my way through a thought-provoking book – Know What You Don't Know: How Great Leaders Prevent Problems Before They Happen, by Michael Roberto. The main focus is on how business schools do a terrific job at training MBAs how to solve problems, but do little to help them find those problems in the first place. The book identifies ways to find the small problems that may become bigger if left untouched.

One way to find problems is to encourage mistakes. Huh? Really? YES! Maxine Clark, founder and CEO of Build-a-Bear Workshop, even provides “Red Pencil Awards” to people who make mistakes, and find a better way of doing business through that mistake. Clark attributes her mistake-finding attitude to her first-grade teacher, Mrs. Grace. Clark explains how Mrs. Grace would award a red pencil to those who had made the most mistakes, because she wanted her students to be actively involved in class discussion, trying to answer all questions, no matter how challenging. Clark states, “She didn’t want the fear of being wrong to keep us from taking chances. Her only rule was that we couldn’t be rewarded for making the same mistake twice.”

Awards for identifying – even making – mistakes encourage a learning environment, allowing team members to experiment, try new methods, and step out of one’s comfort zone.

Thomas Watson, the founder of IBM, states “If you want to succeed, double your failure rate.” Finding where you fail and adjusting or modifying to no longer fail ensures that you are actively learning, and therefore growing in your knowledge. There are lots of stories about failure in invention and business – the light bulb, the “post-it” note. Sometimes the initial plan for a product can be seen as a failure when actual use is what takes off. Kleenex tissues were initially designed to remove make-up, and it was a source of initial frustration when the company discovered that folks were using them to blow their noses!

One of my favorite quotes is from the fictional teacher, Ms. Frizzle, in the book series “The Magic School Bus” – “Take chances, make mistakes, get messy!” How else will you learn, succeed at something new, and bring more value to your client?

Now, get out there and fail! Then fail again! Your eventual success will be that much sewetre sweeter!

Be Prepared

Agile teams are supposed to be self-managing, but I have yet to see a team that didn’t have a cadre of managers helping them along. Now, that’s not necessarily a bad thing. There certainly are times when a politically-savvy project manager can ease the path to production for a team, or when a development manager can spend the extra time needed to argue the case for a virtual build box or a coffee maker.

But, the team needs to know how to manage itself as well. How do tasks get doled out? What happens when a team member is consistently late to stand-up? How do architectural decisions get made?

Agile teams can take a page from the Boy Scouts – be prepared. Take a little time to explore some “what ifs” and create an agreements document – essentially a working document identifying what to do in specific situations.

An agreements document is an excellent tool for two reasons:

·         Team-building – the best kind of team-building doesn’t happen on a paint-ball range. It happens in the office, where you actually can start to see the results of your work as you… well, work. Creating agreements on tardiness, the presence of phones in meetings, etc. can help the team recognize the behaviors that are each person’s “nails on the blackboard.”

·         Less need to think during a crisis – if process are identified and documented on what to do when production servers die or when an architectural discussion turns nasty, the need to remember isn’t left to our flaky brains, and the tendency to revert to old ways won’t happen. To paraphrase Einstein, “The application will not evolve past its current state of crisis by using the same thinking that created the situation.”

While there will remain time where the team needs to actively respond to a situation (underestimation of the sprint’s tasks, architectural disagreements, a dev environment dying right before a release), the creation of team agreements will help the group be ready for many issues they face on a day-to-day basis.

Turbulence equals challenge

I keep a fortune from several years ago in my wallet. Every once in a while, I actually read it. "Turbulence is a life force. It is opportunity. Let's love turbulence and use it for change."

Where does turbulence exist for you? Is it an indicator that something needs to change? Can you evaluate that area (retrospect) and learn from it?

Agile and Cooking

The strange places my mind wanders to while preparing dinner, such as agile cooking practices. A few points to ponder:

·         Just-in-time cooking and coding. I love going to the grocery store (or even better, the farmer’s market) to get ingredients for that night’s dinner. The trip is quick, the planning is quick, and the ingredients are fresh. I could get additional items, but that just adds to the time in the store, rather than helping me cook. The same concept applies with just-in-time coding practices. That one new feature or bug-fix can be handled so much quicker if all the additional possibilities don’t get layered on top. Of course, refactoring may need to happen, but only when the customer decides that they need the tomatoes and balsamic glaze, not before.

·         Planning for meals and releases. I usually plan a menu for the week. I may not get all the groceries for all the meals at one time – fresh spinach will be gross if I buy it 5 days ahead of time – but the plan is in place. This is similar to iteration or release planning, where you can identify a 3000-foot plan, before you have to get into the details (I know I need a button on this page; I can talk with the product owner the morning I start to code before I decide where it goes).

·         Clean as you go. Unit tests and refactoring are like the kitchen tools I use. I need to make sure that they are clean and ready to go when I need them. It feels like a horrible waste of time to have to clean the kitchen up before I can even start to cook, so, just like in coding, I make sure that everything’s in its place (refactored), and clean (tested), before I say I’m done.

Hmm. I’m hungry!

The trunk is the trunk

Mile High Agile 2012 was last week – a great opportunity to reconnect with fellow agilists, to learn a little something new, and to generally have a good laugh at the Sogeti booth. I got to provide fodder for some of those laughs. After a session where we learned how to coach teams to better understand the values and principles of scrum and agile, I was explaining the different parts of the tree that was created, and said something inane: “…the trunk is the trunk.”  I don’t now remember the context but in retrospect, have an idea.

Throughout the agile conference, there was a lot of presentations about how to practice X or how to explain Y … success stories and guidelines were in abundance. Old colleagues re-connected, new acquaintances made stronger connections. All of this was the trunk of the conference, and the trunk of agile.

Communication.

The scrum values (openness, courage, focus, commitment, respect) dance around it. The Agile principles get a little closer (work together daily, face-to-face conversation, team reflection). But one of the main foundations of agile is simple. Talk to each other. Communicate as well as humanly possible.

Communication is the trunk of our trees. Our roots may be the strong values on which we base our business relationships. Our leaves may be the agile principles and/or the characteristics of high-functioning teams. Our fruits are definitely the outstanding results and achievements.

But that tree is nothing without communication.

Just as real estate agents will all say “Location, location, location,” agile practitioners (experienced and novice) may want to adopt the mantra “Communicate, communicate, communicate.” Or, for those who like more simple language “Talk, talk, talk.”

Change is Hard... Change is Easy

This week, I listened to a talk by Ryan Martens, the CTO of Rally, and Rachel Weston, a certified Scrum Trainer. They were pitching a new element of Rally services. But that’s really beside the point. The discussion that really piqued my interest was when they started talking about change. I’ve been touting that changing to agile processes from traditional waterfall is hard work. There is a paradigm shift that has to happen. Old habits have to be broken. And Ryan and Rachel agreed with me on this point – change is hard.

Then they disagreed with me – change is easy.

Huh. It appears that both statements are true. It just depends on the motivator that’s causing the change.

When the change is something that you aren’t expecting, there can be a period of adjustment (sudden change in job situation, forced move to a new city, change in normal routine). Life seems grayer, duller, more frustrating.

But when you really want the change (improved job situation, better house, ability to add on something that you’ve always wanted to do), the change is like a breath of fresh air. Everything seems lighter, brighter, and more enjoyable.

What’s the reason for the shifting perspective? When you can see the end goal, when you can understand what makes this change good, the transition becomes easy.

Agile processes can bring about empowerment to the team, quicker response to the customer, less overhead, great company responsiveness, more discussion and dialogue, and as a side effect, a more fun-filled work environment. Even though the transition can be tough, keeping these end results in mind can make the process seem less dreary.

My youngest son has been struggling in his freshman year at high school. There’s more homework, the school is bigger, the teachers don’t scaffold quite as much. But there was a subtle shift recently. We started talking about his dreams and plans for college and beyond. Engineering is a tough field, requiring a rigorous college program, which in turn requires good grades in high school. My son made the connection between the change he’s facing now, and his long-term goals and dreams. It’s still a bit of a struggle to remember all the homework, but that focus, that vision, is keeping him on track.

Yup, change is hard, and change is easy. What motivates you to make it easy?

Move

(This is part of my occasional series on what I learned in attending and teaching coaching seminars.)

In the world of IT, we don't tend to move much. I know I will use IM to chat with someone just a few feet away, rather than walking over, or fill both my water bottle and teacup in the kitchen at the same time, rather than walking back half an hour later.  But movement helps in so many different ways.

• Exercise – Even though the “knowledge worker” doesn’t need to be physically active, exercise is important for overall health. One’s immune system improves, sleep comes more regularly (and naturally), and walking from the car to the office (even with a few flights of stairs thrown in) doesn’t seem so bad.
• Change of view – Staring at a computer screen for hours on end can cause strain to our eyes, so moving around, staring out a window, or whiteboarding a process with team members can give our eyes a needed break.
• Clear thinking – The model just isn’t quite jelling with the requirements. Something’s missing. Don’t keep staring at the UML diagram. Take a walk. Go get a cup of coffee, or just listen to the sounds of spring (they’re starting to arrive here in Denver). When you return to the model, the connection or relation may start to make sense.
• Memory – Did you know that you associate new information with your physical location? Not just the where (bland conference room in Anytown, USA), but what you are doing (especially if it’s not a normal action), can help you learn. Our 17-year old son still remembers body movements associated with the seasons that we showed him when he was two.
• Perception based on physical and social state – A warm cup of coffee helps to provide a warmer association with a person. A hill seems less steep when you’re viewing it with a friend, rather than alone.

Movement and your physical location can generate new ideas, help you over stumbling blocks, help you remember new concepts, and build relationships. There’s even evidence that, if you are sitting inside a box shape taped on the floor, you will be less creative than if you are sitting outside that same box tape outline.  What are you waiting for? Get outside the box, and get moving!

Listen

(This is part of my occasional series on what I learned in attending and teaching coaching seminars.)

How much time do you spending during the day listening to others? I mean really listening – not checking your email or doing other tasks while you’re on the phone with a friend (or client), but paying full attention to the speaker.

We listen at different levels in the course of a conversation. Sometimes, we are totally focused on ourselves, thinking about what we’re going to say when it’s our turn to talk, what we’ll have for dinner, why the chair isn’t adjusted properly… We’re spending more time listening to ourselves than to the speaker. The message we send the listener: It’s all about me.

Sometimes, we are completely focused on the speaker, fully processing what they are saying, and following them as they describe an event or problem. In these situations, we are fully attuned to the speaker, and fully present. This message:  It’s all about you.

Sometimes, we are not only focused on the speaker, but we are also aware of how other items within the environment at large are affecting the conversation (“The sun has shifted enough that the speaker is squinting. I’m going to shift to the left a little so that the speaker can shift as well.”) This kind of “environmental listening” can be useful, but may serve to be detrimental if the ability to listen to the speaker gets overridden by the environment. (“Boy, that police car is really racing. It’s loud, but will go away quickly. I wonder where they’re headed….”). The message: I’m paying attention to our interaction. Or possibly: Oh, look at that shiny object…

We are not able to listen fully while we are otherwise occupied. So pay attention to how you’re listening. Sometimes just being aware that we can drift away helps us stay focused. Taking notes, or using other active listening tools can be helpful too. Are you fully attentive, or is your attention elsewhere?

I find that I am just as guilty as the next person of floating off to my own little island and not paying real attention to the conversation at hand. In fact, I kept finding myself slide into the self-focused (non) listening style yesterday, especially while on phone calls. Why? I kept thinking about this piece that I wanted to write about listening!