juin 2011Monthly :

I often hear people saying they are coaching others in an agile context. Coaching is often incorrectly used to mean: consulting, teaching, mentoring and a few other unexpected meanings.

Coaching is very useful to help people get from “point A to point B” and it can be used in various contexts, including coaching for Agile adoption or to help people managers modify their leadership style. Either way, to be powerful, coaching requires a few basic skills and a question from my friend Yves prompted me to describe 12 fundamental elements that I believe are required to be an effective coach. You are more than welcome to share your thoughts.

1. Inner silence: To be truly effective at listening to what others are saying and how they are feeling, it is critical to block the voice inside your head – yes that’s right, that voice that rambles all the time saying things such as: I wonder what we’ll eat for dinner tonight?… Damn, I forgot to make reservation for dinner… I hope the kids did well on their math test today… I’m bored… I think I want a coffee right now. I heard the term monkey brain to describe this constant action of jumping around from one thought to the next. To be an effective coach, you will need your monkey brain to calm down so you can find inner peace.
2. Stop all judgment: When you coach people, it is easy and unproductive to become judgmental. Comments such as: Wow, that’s a weird comment… I wonder why he’s saying this… There must be some secret meaning to that sentence… I don’t think I’l be able to help her on this topic… I feel insecure… This won’t help be effective at all. Simply listen to what is being said for what it is being said. Judgments will sidetrack your listening abilities and will make you a very poor coach.
3. Stay focused: Now that you stopped all judgements and are able to keep the inner voice quiet, you need to remain focused for more than 6 seconds. Yes, just like meditation, this sounds like an impossible task at first but with practice, you will develop your focusing-muscle and the task will get easier with time allowing you to be more present to what the other person is expressing.
4. Be present: Be in the moment – right there and then. Listen to what is being said, notice how the person is acting and give her your full attention and make the space secure for the conversation.
5. Don’t aim for personal performance: Aiming for an academy award when you are coaching simply doesn’t work. You are not there to impress anyone. Ironically, the more you will try to impress the other person, the less effective you will be. She will will quickly notice that the focus is on you and not her which will make it pretty much impossible to actually support her development.
6. Ask open ended questions and wait for the answers: Remember, you are not telling a story, you are there to listen. If you need clarification or want to encourage discussion, simply ask a short question. Trust yourself that the other person will understand your questions and if they don’t, they will quickly let you know. Once you have asked your question, wait for the answer.
7. Trust your intuition: If you feel that you need to ask a certain question, then go ahead and ask it. If you believe it is better to wait, then wait. I believe what we call intuition is simply our brain and senses’ abilities to decipher subtle messages from the other person and give us clues as how to interact with them.
8. Keep silent: After asking a question, never speak first. Maintain the silence until the other person breaks it. I am a very strong believer in keeping silent. Silence opens up a secure space for conversations and gives all the space to the other person.
9. Pay attention to the non-verbal: Words are a great way to communicate but non-verbal clues are usually very useful to understand where the person stands – Are they at a rational level? Intuition level? Emotional level? This information will be very useful to adapt your coaching style.
10. Dig deep: It is much easier to stay at the rational level in a discussion. It often leads to contextual information and detailed explanations. To make a real difference, you need to get to the underlying emotions – What are the person’s fears? Intentions? Motivations? Ask feeling-related questions, not logical or rational questions such as: “How do you feel about this event?” instead of “What do you think about this?”.
11. Rephrasing: When rephrasing, use the same key words as the other person. The words are usually very meaningful to the other person and will open up relevant information for you.
12. No context: Do not focus too much on the context. It is usually good to understand what triggered the actions or where the event took place, but the information usually has very little impact on the person you are coaching.

Are there other tips you would like to share?

Mercredi soir, le groupe Alt.Net de Montréal m’a invité à un coding-dojo dans les locaux de Microsoft qui leur ouvre ses locaux.

Cela a encore été une bonne occasion d’apprentissage.

• Nous avons pris le temps d’explorer plusieurs manières d’exprimer nos tests : les  assertions basiques de NUnit, l’écriture d’une contrainte personnalisée.
• Nous avons évoqué le Broken Test Pattern avant la pause. Partir avec un test rouge avant la pause nous aide au retour à savoir où nous en sommes.
• Nous avons utilisé nos moments de refactoring pour introduire au maximum le langage du domaine qui faciliterait une conversation avec un expert du domaine.
• Chemin faisant nous avons créé de la duplication algorithmique et nous avons ressenti le dilemme entre payer cette dette et augmenter les capacités de notre code.

Cela a été une séance très agréable avec beaucoup d’interactions. Cela nous a tous donner envie de refaire une séance de ce type à l’automne.

Le lendemain matin, je me suis lancé dans un refactoring. Puis je me suis dit que j’aimerais connaître vos idées de refactoring. Quelles modifications ferriez-vous ? Bien sûr, il ne suffit pas de dire ce que vous ferriez, il faut le prouver avec du code.

Le code de départ est sur Github : le refactoring-challenge. Faites un ou plusieurs refactoring et partagez-nous vos réflexions et résultats.

Amusez-vous bien .

Je viens juste d’assister a une conférence de Mathieu Villeneuve, de la compagnie Piranha.  Il a montré une video que j’ai trouvée très intéressante.  Le vidéo résume en gros où est rendue l’industrie du mobile en 2010.

http://www.mobilefuture.org/video/archives/mobile_year_in_review_2010/

When an organization starts using Scrum, it runs into tough questions. One question that is particularly challenging is:

Is the Scrum Master the Agile Project Manager?

What if you consider that it is not the right question to ask?

Scrum is about product management, not project management. A more useful consideration is that the Product Owner is the Agile Product Manager. Indeed, the Product owner is responsible for the ultimate direction and success of the product.

The job of the Product Owner is like the typical product manager’s job with an added focus on maximizing value, delivering just-in time, and optimizing the return on investment. The Product Owner maximizes value by collaborating with the Team and customers, by leveraging the entire Scrum Team and also by simplifying product absorption. The faster and more often the release, the faster and more often the creation of value. Where traditional Product Management using the waterfall will typically delay the realization of value, the Product Owner uses Scrum to maximize the flow of value and eliminate waste.

Like the traditional product manager, the Product Owner is responsible for many things, from market analysis and strategic product planning to release planning and sustaining the product. None of this matters though, until the product is actually released. Agile Product Managers, a.k.a Product Owners, help their organization quickly seize market opportunities while controlling risk. That is what agility is about from a business standpoint.

Gartner’s analysts David Norton and Mike Blechar recently published “Enterprise-Class Agile Development Defined“. Although the content is very light and the findings not revolutionary, the research presents a high level differentiation between enterprise wide Agile adoption and enterprise class Agile adoption.

Enterprise wide Agile adoption

Our definition of EAD differentiates enterprise-class from enterprise-wide. Across the organization (enterprise-wide), organizations might be doing many self-contained/independent agile development projects that are totally unrelated and that meet specific tactical needs. Or, the projects may be first iterations of agile development projects intended to help organizations gain understanding and insight into how the application solution could subsequently be grown into a more complete solution, which will subsequently be integrated into the current application solution portfolio. Most of the agile development projects we see start out without real concern for the longer-term impact on the application ecosystem and broader solution architecture. They generally fail to scale to the needed enterprise-class solution characteristics we identify in this research, even though the project may consist of hundreds of developers and be classified as enterprise-wide.

Enterprise class Agile adoption

Enterprise-class AD includes assessing the impact on the current and future enterprise solution architecture for the organization to make the right business decisions.

One of the key finding presented by the authors is that:

Agile development methods are increasingly being used within organizations as business differentiators, which is raising their profile from tactical project level to a more strategic enterprise level.

And as such, one of their recommendation is that:

Enterprise-class agile development cannot be driven only by the CIO and application development (AD) teams. Strong business commitment is essential. Don’t attempt to drive enterprise agile from an IT perspective, as it will fail.

In their research, the authors have identified seven key elements that collectively, positively impact enterprise wide software development processes. Taken together, these key elements help organizations achieve an enterprise class Agile adoption.

• Customer-Centric: Exceeds the notion of the business project sponsor to include the corporate strategies and organizational goals. The product owner and team members need to fully understand and be aware of the impact of the solution and its architecture on the overall corporate goals.
• Collaborative and Cooperative: This is not just cooperation between IT and the business, but also within IT departments across the various sections of the organizations, including teams that are not co located.
• Constant Feedback:  Though lengthy planning is often eliminated from Agile projects, due to organizational constraints it should not (and possibly cannot) be completely removed. This doesn’t mean to overly invest time and efforts but “just good enough” planning should allow projects to get started. As such, constant feedback isn’t limited to the communication between the IT and Business units but similarly with all support departments and various stakeholders.
• Heterogeneous Environment: There is no magic formula for success, and adaptation is required for a successful adoption.
• Throughout the Software Life Cycle: Agile practices, such as refactoring, applied throughout the life cycle, can extend the useful life of the application.
• Continuous Delivery: Speaks to the need of continuous collaboration between IT and the Business units in the development of a product.
• Adaptive Solutions: Discusses a compromise between a complete top-down architecture and an emerging architecture.