Distributed Stand-up meetings essentially becomes a lot of ceremony and the true value of communication, feedback, team bonding, working towards a common goal starts falling apart.

If you have done distributed stand up meetings you would have noticed that its not easy to communicate to a bunch of people on the other side of the phone. (Telephonic conversations are good when there is just one person on the other side. As the number of people on the other end of the phone starts increasing the quality of communication starts dropping).

Also if you have noticed, when a person does not know who is listening on the other side of the phone, they usually speak very little. May be they just talk about 2 out of the 3 things (What they worked on and what they plan to work on. They skip the learning/roadblocks part). I would argue that you can understand who is working on what by looking at the story wall (you don’t really need a stand-up for that). More on this @ Standup Meetings: Missing the Forest for a Tree.

People have tried using Video Conferencing and other techniques, but it usually falls short of encouraging and fostering true communication. It also leads to a lot of time wastage and ceremony (prep-time, getting to the video conferencing room or setting up the video conference tool on your machine). IMHO, its easy to get distracted when the person speaking is not in front of you. So your attention span starts reducing and if you have a team of 8-10 people, it would be difficult to comprehend and remember who said what.

So if Distributed Stand-up meetings as they stand are not the best options, what else can we do?

I have 2 suggestions:

1) Really light weight option: User a chat (conference) room. Everyone from the team shares their bits simultaneously and then people have a small chat to decide the game plan for the day. This has a nice side effect. These notes get naturally persisted in the chat history. So if someone misses the standup or if someone wants to go back and refer to some day’s standup notes, they have it accessible. Also creates a felling of async, non-blocking io (Remember the good old open source days, this is how we used to work).

2) Slightly more process centric: One-on-One Standing Meeting: Each location has their own stand-up meeting at beginning of their day (or what ever time is suitable for the local team). And then, when both teams are online, one member from each team will update the other team(s) about their progress and anything else which is important that might affect the other team(s).

Usually people think of this as a Scrum-of-Scrums where ScrumMasters from each team present their status. We don’t use ScrumMaster. Instead we make this a rotating responsibility of each team member.  Which means, one team member from each team will represent their team in the standing meeting in a round-robin fashion per day. Next day, the person who represented the team in the standing meeting, not only shares their progress with others, but also shares other team’s progress with the rest of the team. The next person in the queue then attends the next standing meeting. These meetings are usually very light weight and are done in 5-10 mins.

P.S: One pant does not fit everyone, find out what works for you and evolve from there.

Recently I read Esther Derby’s blog post on Five Reasons to Hire a Coach for Agile Teams. While I agree with all her points, following are the questions or concerns running through my mind.

• What are the risks involved when hiring a coach?
  • What is success ratio? How many teams you know (not heard of in some cooked up report by a consulting company or a tool vendor) who are successful adopting Agile with a coach’s help? And how many teams do you know who have failed trying to adopt agile without using a coach? Let me clarify, when I say adopt Agile, its not about a bunch of practices. Its about continuously evolving the process to make it lean and more efficient and more enjoyable.
  • Can any coach do or do we need a special type of coach? Point I’m getting at is, your chances to succeed is based on the quality of the coach and her experience.
  • In my opinion your chances of failure is much more if you hire an average coach from outside who does not understand the business, organization and team context & culture.
  • The big problem we face today is we don’t have a good way to know if someone is a good coach or not. What are the chances you’ll end up hiring the right coach? Its not sufficient if someone is a certified professional. In some cases, its not even sufficient if someone has written a couple of books.
  • Also in my experience, ability to connect and influence the team members is very important. A good team member is in a much better position to achieve this than any average coach from outside.
• How sustainable is the model of hiring a coach?
  • What happens when the coach leaves? Is the team evolving their process or still using what the coach put together?
  • Hiring a coach from outside might speed up things. But I’m not sure if people will be able to understand the rationale behind doing certain things. In my experience failure is a great learning tool. Taking more time to achieve something (and in the process failing a few times) is not bad, it make something more sustainable and scalable.
• Can you teach/coach someone to be agile? Agile has been around at least for the last 10 years, what are the chances one or more coaches can change that? (I’m not saying its not possible, I’m trying to highlight that its not simple. It involves organizational transformation and change in individual’s mindset).

My advice is before looking for a training or coaching, do sufficient homework?

Recently I’ve been getting a lot of request for Agile Training and Consulting. Unfortunately the expectations from the training are not clear for me. Most people approach me saying, “we want a TDD training” or “we want a Project Management training“. Once I start talking to them & their team (or even worse sometime during the training), I realize the topic we’re discussing is not their biggest issue. I get a feeling that most organizations have not done their homework to figure out what they really need and how they should go about it. They might have heard somewhere that ‘blah’ will help them and they want to jump on it.

Few months ago I started doing readiness assessments before my trainings. (I’ve also started doing assessments after my training so see if the training was effective.) But I have realized the assessment is not enough. So I’ve started asking the following questions even before the assessments:

• What kind of issues your organization is facing currently and do you think Agile will help you? If yes, why so?
• What is the current strength of your development team? How experienced is the team with software development? Does your team understand all aspects of software development?
• What is the current process you follow? In other words, from the inception of an idea to the delivery of the same, what are the various steps and people involved?
• What is a day in life of a team member (one per role please)?
• How do your stakeholders (including customers) perceive your team/organization? Currently how do you gather feedback from them?
• How would you rate the technical know-how of your team? Are they able to quickly resolve technical challenges and respond to changing priority of the business?
• Is your team/organization open to trying out things that might seem non-intuitive/illogical? For Ex: Letting the requirements evolve during the project, not freezing them? Letting tests drive your design?
• And so on …

Luckily a lot of organizations don’t get back to me with answers for these questions. This is really good for me, because this acts as a filtering criteria. I feel I would have wasted my time training/coaching this team. There are others who are in much more need and are more receptive to what I’ve to contribute.

What do we, as agile Coaches, value? What is our value system?

I value:

• Respect and Trust
• Transparency and Open communication
  • This works both ways. As a coach you want to show them that its OK not to know something. You certainly don’t know everything. But you are willing to learn.
• Safe-fail experiments
• Being hands-on and in the groove 
  • Second-hand information and knowledge can only take you so far
• Down-to-earth, humble attitude
  • Being one amongst them.
• Joy of improving things one baby-step at a time
• Motivation and self driven
  • Lead by Example
• Continuous learning and putting ourselves out of our comfort zone
  • I care, I’m here to help make things better and learn in the process. I’m not here only for the money.
• And so on…

As a coach, my goal is to help people evolve their thinking to be more “agile/adaptive”. Building great software is only a part of it. Agile/Lean thinking applies and shows in lots of ways even outside software. And in lots of cases I’ve seen that when people start applying these values in other parts of their daily lives, they get a much broader and deeper understanding of this thinking process.

Few years ago, when I was a consultant at ThoughtWorks, people used to ask me, what was my job like. I would respond saying, “My job is to set up small ‘safe-fail‘ experiments for my team.” Learning from one’s mistake in a controlled, safe environment is the best form of learning according to me till date. It has a much long lasting impact. Almost always, this really helped me evolve my understanding of how agility can manifest itself.

When it comes to Coaching, there are different styles. What style you can use depends on:

• Your strengths and weaknesses. By your personality. 
• The team & individuals you are coaching.
• Whether you are going in as a coach or they (the team) is coming to you for coaching.
• The short-term and long-term needs of the team
• And so on….

Over and above all, to be effective at coaching, one needs to win the trust of the team. Trust is very important. If the team does not feel safe in your presence, then you can’t be effective at coaching. I strongly emphasize on building trust and gaining respect quickly. This in-fact would be my first goal as a coach.

Someone, really high up the hierarchy (one of the CxOs), after reading a bunch of case studies and reports, decides Agile is the way to go. She builds a business case and announces

We’re going Agile. This will solve all our problems. Our software products will be delivered faster than light.

Hand picked set of managers are sent to the near-by, favorite Scrum Certification course. And from that day onwards, the army of software slaves wear their Agile uniforms and start marching. Starting with those pre-pre-pre-pre-poker; sorry planning meetings to the re-re-re-review meetings to the daily (ouch my legs hurt) scrums. And of course the wet-row-spectives.

After doing all this, your company don’t even see the light, forget delivering products at lightening speed. Then of course you hire a X-Stream black-belt consultant to explain you why you need another Engineering process to succeed. So you start doing TDD, no BDD, no TDD, no RDD with automagic retractoring and revolutionary markitecture. Knowledge of resign patterns is mandated. You also instill the promiscuous rare-programming with sustainable mace and so on.

You continue down this path cursing yourself that you are not good enough. Only if you had the right set of people perfectly following the process, you could see fluffy bunnies jumping all over the place.

On the Agile Alliance LinkedIn group, Eugene Yamnitsky posted the following question:

One of the key Agile transformation success factors is Executive Commitment. Every book and article I’ve read mention this, but there are no good explanation on what it really means.

Great questions!

In my experience, Executive Commitment is very deep and crucial. It’s certainly not as easy as flipping a switch and expecting magic to happen.

What  does this really means?

• First and foremost they need to understand that, for any change program or transformation, its the people and the environment they operate in which makes the difference. Not the new process itself. What Agile tries to do is change people’s behavior and the environment they work in.
• They need to take time to actually understand what is Agile and what it is not. Essentially so that they have the right expectations set. So that they understand the impact of what they are getting into. This should involve talking to practitioners about their experience. Reading at least few experience reports and so on.
• Involving their teams to understand their issues and aspirations. The worst thing the executives can do is decide “Agile is THE way to go” in a closed room meeting and force it down people’s throat.
• Once there is a general awareness about Agile in the organization, ask any one team to volunteer to be the pilot project. Work closely with that team to set realistic plans.
• Once the pilot project is kicked off and folks on that team & supporting teams are sold on the concept, they need to step back & stand behind their teams (support them) and trust them to do their best.
  Send a clear message across the organization that this is important and we really care about this stuff. (There is a big difference between pushing in down people’s throat and doing it collaboratively with their buy-in)
• The Executives need to be open to failures and also need to communicate that clearly to teams saying its OK to fail. We are trying something new, which is a huge paradigm shift and there is certainly risk involved in it. So its OK to fail.
• Also sometimes I find that since the expectation setting is not right, teams are always trying to change their way of working in a hurry, under a high pressure. Its very unlikely that I would do my best under such situations. Give your teams the space and time they need. Like anything new, there will always be a learning curve.
• It usually very helpful to have someone in the organization play an evangelist role. Someone with real first hand experience with Agile. The executives need to invest in the right things.
• The other very important thing that the executives can influence is the organization culture. Encouraging honest and open communication. Not by just doing lip service, but by actually leading by example.
• Like with any change program, everyone (esp. the executives) are always interested to know as soon as possible if the new process is working on not. Is it helping on not? Sometimes people try to put in tracking/measuring mechanisms which are inherently broken. As we all know, you’ll get what you measure. So the metrics you use will influence to a large extend how people will behave. This one single things can screw up the whole adoption process.

I can go on, but I guess this gives you the gist and seriousness of the kind of commitment required.

To conclude, I think it all revolves around

• communication,
• expectation setting,
• collaboration,
• leading by example,
• showing that they care and providing the required support (time, money, effort)
• being open to take the risk of potential failures.

Recently, during a project rescue effort, I introduced Checkstyle as part of the automated build. This morning I saw the build failing because of the following Checkstyle violation:

When I checked the source code of the 2 files, this is what I found:

1
2

public class SuccessEvent extends EngineEvent {
    private final Document document;

1
2
3

    public SuccessEvent(final Document document) {
        this.document = document;
    }

1
2
3
4

    @Override
    Document getDocument() {
        return document;
    }

1
2
3
4
5

    @Override
    String getMessage() {
        return "";
    }
}

1
2

public class AcceptEvent extends EngineEvent {
    private final Document document;

1
2
3

    public AcceptEvent(final Document document) {
        this.document = document;
    }

1
2
3
4

    @Override
    Document getDocument() {
        return document;
    }

1
2
3
4
5

    @Override
    String getMessage() {
        return "";
    }
}

As you can see, except the name of the class, the 2 files are identical. On one hand I’m thrilled that Checkstyle does a great job at catching such errors, on other hand I’m sad that there are developers who write such sloppy code.

Some time back, I spent 1 Week helping a project (Server written in Java) clear its Technical Debt. The code base is tiny because it leverages lot of existing server framework to do its job. This server handles extremely high volumes of data & request and is a very important part of our server infrastructure. Here are some results:

Topic	Before	After
Project Size	Production Code Package =1 Classes =4 Methods = 15 (average 3.75/class) LOC = 172 (average 11.47/method and 43/class) Average Cyclomatic Complexity/Method = 3.27 Test Code Package =0 Classes = 0 Methods = 0 LOC = 0	Production Code Package = 4 Classes =13 Methods = 68 (average 5.23/class) LOC = 394 (average 5.79/method and 30.31/class) Average Cyclomatic Complexity/Method = 1.58 Test Code Package = 6 Classes = 11 Methods = 90 LOC =458
Code Coverage	Line Coverage: 0% Block Coverage: 0%	Line Coverage: 96% Block Coverage: 97%
Cyclomatic Complexity
Obvious Dead Code	Following public methods: class DatabaseLayer: releasePool() Total: 1 method in 1 class	Following public methods: class DFService: overloaded constructor Total: 1 method in 1 class Note: This method is required by the tests.
Automation		Ant for Automated build Hudson for Continuous Integration Migrator for automating Database migration process FitNesse to write End to End Acceptance Tests JUnit and Mockito for unit testing Panopticode for visualizing software metrics Emma for Code Coverage Checkstyle and JavaNCSS for Static Code analysis JDepends for calculating design related metric StatSVN for generating SVN Usage Reports Dead Code Detector for analyzing Dead Code
Version Control Usage	Average Commits Per Day = 0 Average # of Files Changed Per Commit = 12	Average Commits Per Day = 7 Average # of Files Changed Per Commit = 4
Coding Convention Violation	96	0

Another similar report.

Recently I spent 2 Weeks helping a project clear its Technical Debt. Here are some results:

Topic	Before	After
Project Size	Production Code Package = 7 Classes = 23 Methods = 104 (average 4.52/class) LOC = 912 (average 8.77/method and 39.65/class) Average Cyclomatic Complexity/Method = 2.04 Test Code Package = 1 Classes = 10 Methods = 92 LOC = 410	Production Code Package = 4 Classes = 20 Methods = 89 (average 4.45/class) LOC = 627 (average 7.04/method and 31.35/class) Average Cyclomatic Complexity/Method = 1.79 Test Code Package = 4 Classes = 18 Methods = 120 LOC = 771
Code Coverage	Line Coverage: 46% Block Coverage: 43%	Line Coverage: 94% Block Coverage: 96%
Cyclomatic Complexity
Obvious Dead Code	Following public methods: class CryptoUtils: String getSHA1HashOfString(String), String encryptString(String), String decryptString(String) class DbLogger: writeToTable(String, String) class DebugUtils: String convertListToString(java.util.List), String convertStrArrayToString(String) class FileSystem: int getNumLinesInFile(String) Total: 7 methods in 4 classes	Following public methods: class BackgroundDBWriter: stop() Total: 1 method in 1 class Note: This method is required by the tests.
Automation	Maven for Automated Build Cobertura for Code Coverage	Ant for Automated build Hudson for Continuous Integration Migrator for automating Database migration process JUnit to write End to End functional Tests JUnit and Mockito for unit testing Panopticode for visualizing software metrics Emma for Code Coverage Checkstyle and JavaNCSS for Static Code analysis JDepends for calculating design related metric StatSVN for generating SVN Usage Reports Dead Code Detector for analyzing Dead Code
Version Control Usage	Average Commits Per Day = 1 Average # of Files Changed Per Commit = 2	Average Commits Per Day = 4 Average # of Files Changed Per Commit = 9 Note: Since we are heavily refactoring, lots of files are touched for each commit. But the frequency of commit is fairly high to ensure we are not taking big leaps.
Coding Convention Violation	976	0

Something interesting to watch out is how the production code becomes more crisp (fewer packages, classes and LOC) and how the amount of test code becomes greater than the production code.

Another similar report.