I spoke at Agile India 2014 on 26 Feb for the Scaling Agile Adoption theme. I also attended the Beyond Agile theme. As cited here, the conference attracted 1236 attendees from 28 different countries across 200+ different companies. It was among the largest Agile conferences in Asia.

Many people connected with me after my talk: From Practitioner to Coach. I gained context on various organizations and their Agile-related initiatives. Met a good number of first-time coaches as well. If you're interested in the topic, you may find my experience report worth a read. I've also blogged on coaching topics.

The feedback about my talk that I will treasure the most came from Lyssa Adkins, author of Coaching Agile Teams and co-founder of Agile Coaching Institute. This is what she tweeted:

Googling for "tips for presentations" will give you a lot of useful links. I want to capture here some basic tips, specifically for technical conferences. Not much about beautiful slides but about readable ones. As an audience, I find it unfair when a talk is really good but the slides are unreadable!

Logistics

• Find out about the resolution supported by the projector at the conference venue. Set your machine's resolution to the same and check your presentation. At times you'll find your text word-wrapped in weird ways or your pictures going outside the screen boundary.
• Do not rely on wifi. Most conference venues arrange for wifi but they are almost always flaky. Avoid running your slides off prezi.com directly. Avoid embedding YouTube streaming videos. Avoid a demo that needs an Internet connection. Keep things local.

Font & Colours

Had the opportunity to attend and speak at the first Bangalore-based Ruby conference, Garden City RubyConf 2014. It was reminiscent of the first RubyConf India in 2010, where I also spoke incidentally.

Among the conferences I've attended recently, this was definitely among the better ones. Great job by the organizers to line up some interesting talks, including keynotes.

I got to meet Chad Fowler after many years. In 2007, he was one of my trainers in an Advanced Ruby on Rails workshop I had attended in Dallas, US. In fact, I showed him a copy of My Job Went to India that he'd signed for me back then. Chad's keynote was quite thought-provoking. He challenged many existing notions about developing and deploying software, and encouraged looking at some refreshingly new approaches out there.

Besides Chad, other speakers were good too. I also noticed something curiously common among the speakers: most were ex-ThoughtWorkers. The conference allowed me to catch up with my ex-colleagues, and hear them share experiences on and off stage. In fact, the conference allowed ample time to network with new and old friends. I later learnt the number of breaks and their durations were consciously planned by the organizers to allow networking. Definitely a good move!

Nearing the end of any Agile Adoption engagement, client stakeholders will start wondering about the benefits received from coaching. This may be for their own curiosity, to justify ROI to their bosses, or simply to show off their initiatives to peers!

Often this translates into a Coaching Benefits Report. But I doubt if a set template would work. Different stakeholders have different objectives, and the report may need to be presented accordingly. Some reports may stress on the subjective aspects, while others may rely on objective ones. Some may be formal in language, while others may have a more lively feel to them. In any case, some aspects you can touch upon are mentioned below.

Metrics

This will be the third time I talk about metrics. We used metrics for baselining; we used it for measuring progress; and we will use it for a Before/After comparison in a Benefits document.

Self-discovery is important for an individual to understand oneself better, and to continuously grow or evolve. While useful for one's personal life, it is also applicable to one's professional life.

In coaching, one of the goals is to aid individuals to gain better awareness of their own potential. While one way to address this is to provide continuous feedback, it additionally helps if individuals are enabled to learn more about themselves on their own.

Some tools that I have personally found useful and have recommended to others:

• Strengths Finder
• MindTimeMaps

A good degree of self-learning is expected out of every individual being coached during Agile Adoption. Without it, individuals cannot move through the various stages of learning as presented by the Dreyfus Model. An Agile Coach should pair on tasks with individuals but this approach is limited by team size: one-on-one attention cannot be given for extended durations of time. After all, an Agile Coach operates differently from a Personal Trainer.

An Agile Coach will usually focus on providing the building blocks, and then set the individual on the path of self-learning. Instead of spoon-feeding answers, the coach will use effective questioning to guide the individual to come up with their own reasonable conclusions. This is an application of what is widely known as Socratic Method.

Additionally what I follow is the Princeton Model of learning:

Facilitation is a very useful skill to have. It helps not only in coaching but in many day-to-day activities. Whether a team discussion or a team activity, a good facilitator can make all the difference.

Retrospective

A common facilitation technique is a Retrospective. It has a clear objective of looking back, as a group, at a recent time period or a particular incident, collect thoughts around different aspects, and then brainstorm on action items related to the topic. Agile teams use this technique for continuous improvement. I like relating it to the 12th Agile Principle:

"At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly."

During the assessment period of an Agile coaching engagement, a lot of information is captured around the team's current processes and practices. Along with these, gathering quantitative data is also important. These will go into the assessment report at the end, portraying some aspects of current state. Collecting such metrics during assessment is called Metrics Baselining.

Recommendations can be made on the basis of numbers and trends observed, especially using complementary metrics. If the assessment is followed by Agile Adoption, these metrics can be used to indicate progress in chosen areas. From a sustenance point of view, a Before/After comparison around these metrics can determine comfort level and for demonstrating coaching effectiveness.

One may think capturing quantitative data will be simpler than gathering qualitative data. In my experience, the former is trickier and even risky. From a tooling perspective, getting to the numbers might be easy enough. But knowing what numbers actually matter is where the complexity lies. Especially since typically during an assessment, the team and the coach themselves are unaware of exactly where the team's challenges lie, and the assessment is supposed to help discover these. Tracking irrelevant metrics may send a team down a useless path, or worse, a harmful path. Metrics selection should be guided by clear meaningful goals. But when unsure, an Agile Coach may choose to capture whatever can be captured, with a clear disclaimer that it's being done so that the information is available if it becomes useful later. So be sure to archive these metrics somewhere safe.

Some typical metrics captured are as follows.

After having collected enough information during the assessment period of an Agile coaching engagement, especially using interviews, an Agile Coach should be in a position to draw a Process Map of whatever has been discovered.

You could go use a tool to build a clean and elaborate process map but I recommend starting with stickies. Take a bunch of stickies and write down the important activities that you know different roles get involved in during the start of an iteration, at the end of an iteration, and in-between. Give a short name for the activity and note the name of the role as well. Keep the granularity at medium level, as you don't want too many stickies at once, at least not initially.

Now on a whiteboard, sequence these stickies, one at a time, in the order they are done. Draw connecting lines between the stickies as you proceed. If some activities are repeated, draw loops accordingly. You will now have a visual timeline of an iteration. If you can spot obvious gaps in the timeline, add more stickies for those missing activities along with role participation.

Now you will want to know more about what feeds into an iteration and how, and what goes out of an iteration and how. The former is usually around requirements and defect management. The latter is typically about releases and deployments. In most organizations, customer feedback and customer support connects the end point to the starting point. However, some of this could be just your assumption. It is unlikely you'd have gotten a complete view of the process as some of these aspects are not apparent mid-release nor are all team members aware of them. It is time to get proper validation.

During the assessment week of an Agile coaching engagement, the goal is to learn about the current state of the team. Special attention is needed towards capturing:

• Day-to-day activities of various roles
• Additional activities such as on planning day, deployment day, etc
• Tools used to support these activities
• Processes around these activities
• Interaction, collaboration, and dependency on other roles or teams during these activities
• Infrastructure environments involved in these activities
• Outcome of these activities in an iteration-level view
• Challenges faced in performing any of these activities or the role in general

In Agile consulting, there can be different types of engagements that you get into with your client. One type of engagement may lead to another type. As an Agile Coach, you will find yourself participating across the board. Your focus areas will change based on what the engagement objectives are.

Here are the typical types of engagements I have encountered.

Assessments

Sometimes a team, a department, or an organization simply is not aware of where they stand with respect to Agile adoption. They need answers to questions like: "Will they benefit from Agile Coaching, or are there too many prerequisites missing? Tentatively for how long will they need coaching before achieving self-sustenance? What areas need the most focus on?" Answering such questions means at least 3-5 days of work, involving interviews, discovery workshops, first-hand observations, metrics collections, etc. This is then followed by summarization and recommendation in the form of an assessment report, which typically contains a proposed coaching plan.

To me, Coaching is about getting the most out of individuals or teams by raising their awareness levels, about their current environment, about the environment outside theirs, and most important of all, about their own potential. This is done mostly by asking them the right questions, and not by providing them ready-made answers.

My definition of an Agile Coach is even less restrictive. As an Agile Coach, coaching is my primary modus operandi. But there are times when I make recommendations based on my practitioner background. I also complement coaching with aspects of mentoring and training. For example, relating personal experiences and sharing useful resources can increase someone's curiosity and give them a clear direction. Conducting a workshop can help kickstart a group on practices like TDD and Refactoring.

Even within the scope of Agile Coaching, I have been exposed to a variety of roles.

Role-based Practices Coaching

The term Coaching is overloaded.

Comparatively, terms like Refactoring and YAGNI are recently invented. But despite having had clear definitions to start with, these words still suffer from semantic diffusion.

Coaching is a plain English word, around since ages. It is not surprising that its definition in the professional world remains open. This is evident from its Wikipedia page.

That said, there have been attempts to describe coaching better, acknowledging the wide spectrum it could cover, and yet putting some boundaries to it.

I have worked on multiple systems written in object-oriented languages. Time and again, I encounter common code smells. What is curious is that these smells are observable not only in legacy^[1] systems but also in well-intentioned greenfield^[2] projects.

One could ascribe these to the developers not knowing any better, or possibly to a more common reason, Technical Debt.

Either way, I have learnt that being conscious of these code smells is important while working with code bases. Simply learning about the code smells is not enough. You need to actively look out for them all the time.

The next step, after identifying the smell, is of course to deal with it. For now, I will only list the code smells. I am planning a separate series of nugget posts to get into more details later. But don't wait for those posts! Read the Refactoring book now for most of the common smells!

For an organization to be successful at Agile transformation, one aspect that needs attention is self-sustenance. Having external coaches is useful as they bring in experience and a third-party perspective. Over time though, it makes sense to groom internal Agile practitioners as Agile champions, who can spread the mindset and practices further.

Transitioning from a practitioner to a coach is non-trivial. The organization should look out for certain characteristics in individuals to identify potential coaches, and follow that up by providing support to prepare them for the role. In a series of articles, we will delve into each of these aspects.

First off, let us establish practitioner-to-coach transition as an effective strategy for Agile transformation.

When do we know we are done?

No, this is not my exit mail. But a post about a reality in any organization: the exit mail that appears in our inbox occasionally.

People have their reasons to quit a company. Even a company like ThoughtWorks. Not always an easy decision. But to each his own. This post is not about the reasons behind the exit mail but about how its readers react.

Thinking about my reactions, I can tie them to the kind of person leaving:

• Unfamiliar: With over 2000 ThoughtWorkers, there are bound to be exit mails from people I do not know. I skim through the first paragraph to get a brief background (how long in ThoughtWorks, which location, reason for leaving). If the writing is witty, I might read till the end. Else delete.

• Respected: These are the exit mails that make me look twice. I would know the person or know about the person. From working with them, or conversing with them, or reading their forum posts, or simply having heard praises about them from others. These people are opinionated, talented, experienced, and natural leaders in the ways we develop software. These mails get archived.

• Team member: These exit mails always get a reply from me. Having worked with someone, you develop a rapport, some mutual respect, and, on occasion, a camaraderie. How I feel about a team member can vary in degree, and a good measure of that is the effect their exit mail has on me.

• Friend: Such an exit mail hurts. Most times I can anticipate its arrival because the person would keep me informed (it still hurts). Sometimes it can be a shock, if the decision was kept personal for whatever reason. But irrespective, it is a mail I dread. It is hardest to say goodbye to a friend. Each of these mails feels like one lost reason to come to office. But we move on. We have to. And we wish our friends well in their journey ahead.

I enjoy blogging: writing about my learnings and experiences, and what others may find useful. For many years, I hosted my blog at WikyBlog.

I blogged regularly during the early parts of my career. After a few years, the posts came in less frequently. This was not accidental. I consciously set off on a personal journey which was more inward-looking.

I now feel the need to blog again. But with a coming-of-age outlook. And a fresh look to go with that.

I am hosting this blog on Github Pages, powered by my fork of ruhoh. It gives me a sense of control as I can create my own theme, and even code my own features.