Category: General

In their article, What is agile?, Jen Krieger, Daniel Oh, and Matt Takane discuss what we at Red Hat consider the most important sentence of the Agile Manifesto:

“We are uncovering better ways of developing software by doing it and helping others do it.”

I like this sentence because it helps to understand why we could apply “agile” outside of software development. We could replace “developing software” in that sentence with something like “cooking,” and it would still give us a good idea of the mindset of people who engage in “agile cooking”.

Of course, we often associate “agile” with specific practices. Let’s take the example of two agile practices that were used together during a Coding Dojo event. A Coding Dojo is a great way of uncovering better ways of developing… I’ll stop there; you know the rest of the sentence by now. A Coding Dojo is a great way to get better at something by practicing with others in a safe and controlled environment. The practices I uncovered that day were test-driven development and pair programming:

• Test-driven development, or TDD, is a process in which a developer starts by writing an automated test for a function, then writes the code that will make the test pass.
• Pair programming is when two coders work together using one computer.

The Coding Dojo experience

Imagine yourself in a room with 20 coders, one laptop, and one big screen. Two seats are near the computer for the first pair of programmers, and there are enough seats for the other programmer pairs who will observe before taking their turn at the keyboard.

The kata we used that day was the Bowling Game. The goal of the Bowling Game, as explained on the Coding Dojo website, is to “create a program, which, given a valid sequence of rolls for one line of American Ten-Pin Bowling, produces the total score for the game.”

Each pair of programmers has a five-minute timebox to advance in the resolution of the challenge, using TDD and taking steps that are as small as possible. At the end of the timebox, another pair will follow.These interactions help them express their best in the code they produce.The first coder starts by writing the first test. The test fails to red as there is no code yet (test tools associate green with a passing test and red with a failing test). The second coder writes the smallest possible amount of code to make the test pass green, and he or she then improve the tests. The test goes back to red, and we switch back to the first programmer, who then writes the smallest possible amount of code to make the test pass. And so on. Refactoring is done along the way.

The interaction between the two coders is the kind of magic we all love to see. That’s because contributors are not submitting a patch hoping for a fast review; they have the review in real time. And because they are progressing in small steps, explaining what they are doing, it is easy for everyone to stay connected, whether you are in the audience or the second coder in the pair.

Writing the test first forces an early understanding of what is required. Focusing on the smallest amount of code possible to make the test pass also helps to keep the design as simple as possible. Refactoring along the way ensures that we keep only the code we need.

Here are the key differences between the Coding Dojo experience and the typical development process:

• Developers work in pairs instead of alone to code features and fix bugs
• Testing is done before development instead of after code is developed
• Code review is done in real time, with the pair, instead of waiting for another developer to review and merge

Looking at a larger amount of code makes it more difficult to understand. The process is not only slower but leads to less beneficial interactions between the coder and the reviewer.

Why do we consider pair programming and TDD agile practices? Because they are designed to foster strong interactions between the individual members of the team. These interactions help them express their best in the code they produce.

This brings us to the second sentence of the Agile Manifesto:

“Through this work, we have come to value: Individuals and interactions over processes and tools.”

You can, of course, have processes and tools. But those processes and tools should foster the expression of individuals and their interactions. The latter has more value than the former.

So the next time you are engaged in a conversation about tools or processes, ask yourself (and others): Are we bringing a tool or a process that will grow individuals and interactions?

Answering yes to that question shows you the agile way.

The article was first published by opensource.com.

The Chief of Staff role is multi-faceted and highly dependant on the company, the principal, and the context in which people operate. I collected a few thoughts and links about the role in the Tech Industry a while back.

Maxine Litre wrote an article for the Chief of Staff Network on How to Find the Right Fit in the Interview Process. The article made me think of the questions I would ask if I had to replace myself in my current role.

Interview questions reveal the essential characteristics of a role. So I wondered what I could learn about the Chief of Staff role from the questions others would ask.

This is what motivates me to ask you: What are the three questions you would ask a potential candidate who would replace you in your current role? (Use the form linked, drop me a message on LinkedIn, or an email).

I will compile the answers in an article (and of course credit each of you).

When? Why wait? The sooner, the better!

In a previous post, I described a great approach to get people to get to know each other a little bit more thanks to a fantastic one-on-one format. Try it, you will see yourself, it is really fantastic!

Another approach to get people to know each other is to use Appreciative Inquiry.

I used nearly the same three questions in different contexts: during the Wednesday breakfast for new employees in a fast-growing company, and also as an ice-breaker for meetings where people don’t know
each other.

The mechanics are simple and highly effective. You ask people
to form pairs. Their goal is to interview each other, asking three
questions:

• Tell a story that you consider being a success,
• Without being humble, describe the talents and skills you used to make it a success,
• Describe your three concrete wishes for the future of the company.

You give them a limited time, like 15 minutes, to do the two interviews. You probably need to remind them that the time is ticking and be flexible with the timing. As you walk around in the room, people ask you clarification questions, such as “Is it limited to professional life?” (The answer is: “No, of course, you can share non-professional experiences.“)

People usually enjoy that session and ask for more time to interview others in the room. You don’t need to give them that time. Just mention that they will have breaks, lunch, and dinner or, in short, other opportunities when they can interview each other.

If you are ready to invest a little bit more time, you can add value to the exercise by asking each pair to present briefly the talents and wishes of each other. It is really powerful when each writes talents and wishes on sticky notes (one per sticky note) so at the end of the presentation, you have one sheet of flip-chart representing the talents of the group and another with all the wishes of the group.

By starting the conversation there the room is full of energy, confidence, and optimism, and you are ready to have a productive meeting.

After one meeting I facilitated, I received a thank you note from one of the participants explaining that he enjoyed the meeting and the activities because “it created the kind of positive energy that gets things done.”

We are back to the mindset conversation I cover in the first chapter of Changing Your Team From The Inside. Shifting our mindset is essential to be able to interact effectively with others. Helping them to shift their mindset is key to effective collaboration.

Try it and let me know how it goes! I will use it again next week, in a distributed setting this time as we cannot be face to face.

Photo by Christina Morillo from Pexels

The Culture Map is an excellent book by Erin Meyer. As my current team evolves in an international context, I had the idea to use the culture map as an icebreaker to start one of our quarterly meetings.

The team is composed of people from France, Germany, Spain, Sweden, and The Netherlands. The team has to interact daily with a lot of people from the US, and nearly all countries in the EMEA area.

We used a Miro board and one of the culture map provided in Erin’s book (reproduced below).

I gave a short explanation of the first scale: Communicating. Either you are in a Low-Context culture where the communication is precise, simple, and clear, or you are in a High-Context culture where the communication is sophisticated, nuanced, and layered (you are expected to read between the lines).

Then, I asked one question: Where the US would be?

All the team members connected to the Miro board can see the cursors of the others, and so I asked them to move their cursors to the position they thought the right answer would be.

After some discussion, people started to position the US in comparison with other countries. Of course, we covered the fact that a country cannot be a point on a scale but more a range on the scale. We also covered that all people are different and that the more you know a country, the more you can appreciate the subtle differences of the different regions.

We continued to iterate with the next scales:

• Evaluating: How people give direct or indirect negative feedback.
• Persuading: How people are trained to begin with the theory or to begin with facts or statements.
• Leading: How people are used to an Egalitarian or a Hierarchical model.
• Deciding: How people are used to decisions made in a Consensual way or Top-down.
• Trusting: How trust could be built either though business related activities or through sharing meals and drinks.
• Disagreeing: How people are used to see debates and confrontation as positive for the team, or as negative for the team and inappropriate.
• Scheduling: How people see the time as linear (everything is scheduled and you stick to it) or flexible (everything can be approached in a flexible manner.

It was a very good opportunity for the team members to express their preferences, and a good reminder that wherever you are on the scale, you have to accept that others could be at another position because they value that position more. They are no “good” position or “bad” position.

A very good starting point to appreciate the diversity of the strengths of the team.

What Got You Here Won’t Get You There: How Successful People Become Even More Successful is a book by Marshall Goldsmith and Mark Reiter published in 2007.

The trouble with successful people is that they tend to believe that their “bad” habits are not so “bad.” They have proof of that. They are successful. So, what could they do, or more precisely, what could they stop doing to be more successful?

The book presents The Twenty Habits That Hold You Back From The Top:

1. Winning too much: The need to win at all costs and in all situations – when it matters, when it doesn’t, and when it’s totally beside the point.
2. Adding too much value: The overwhelming desire to add our two cents to every discussion.
3. Passing judgment: The need to rate others and impose our standards on them
4. Making destructive comments: The needless sarcasm and cutting remarks that we think make us sound sharp and witty.
5. Starting with “No,” “But,” or “However”: The overuse of these negative qualifiers which secretly say to everyone, “I’m right. You’re wrong.”
6. Telling the world how smart we are: The need to show people we’re smarter than they think we are.
7. Speaking when angry: Using emotional volatility as a management tool.
8. Negativity, or “Let me explain why that won’t work”: The need to share our negative thoughts even when we weren’t asked.
9. Withholding information: The refusal to share information in order to maintain an advantage over others.
10. Failing to give proper recognition: The inability to praise and reward.
11. Claiming credit that we don’t deserve: The most annoying way to overestimate our contribution to any success.
12. Making excuses: The need to reposition our annoying behavior as a permanent fixture so people excuse us for it.
13. Clinging to the past: The need to deflect blame away from ourselves and onto events and people from our past; a subset of blaming everyone else.
14. Playing favorites: Failing to see that we are treating someone unfairly.
15. Refusing to express regret: The inability to take responsibility for our actions, admit when we’re wrong, or recognize how our actions affect others.
16. Not listening: The most passive-aggressive form of disrespect for colleagues.
17. Failing to express gratitude: The most basic form of bad manners.
18. Punishing the messenger: The misguided need to attack the innocent who are usually trying to help us.
19. Passing the buck: The need to blame everyone but ourselves.
20. An excessive need to be “me”: Exalting our faults as virtues simply because they’re who we are.

The “twenty-first” habit is goal obsession.

The idea that being obsessed with a high-level goal makes you forget the here and now. The present in which you are, indeed, destroying all your chances of reaching your goals.

I love to use books with people I work with. I used The Five Dysfunctions of A Team or The Advantage by Patrick Lencioni. I also used Radical Candor by Kim Scott.

I decided to use the twenty habits with a leadership team I just met.

The first part of the session was reviewing and discussing the habits. Listening to the questions and discussions can teach a lot about the people in the room.

The second part was for the team members to identify for each other, through an anonymous survey, what habit they thought the others in the team should focus on removing.

The third part was for the team members to discover the results, and pick the habit they will want to work on during the next quarter.

The last part was to select their accountability partner to work with to achieve the goal.

I am happy with the results so far. If you try the practice, let me know through the usual means: email or Linkedin.