Effective Presentations

"There are always three speeches, for every one you actually gave. The one you practiced, the one you gave, and the one you wish you gave." -- Dale Carnegie

Here is a list of DOs and DON'Ts for effective presentations:

DOs

• Specify the Agenda (scope), total duration and benefits for the audience during the introduction. You can specify what is in scope and what is out of scope for the presentation just to ensure that there is no expectation mismatch. You can avoid irrelevant/premature questions from the audience by specifying a clear agenda at the very outse

• Before you begin, you can request a show of hands from the audience to get a feel of the familiarity of the audience on the presentation subject. I have noticed that experienced speakers always do this.

• Whenever possible share personal experiences & opinions related to the subject. Sharing personal experiences (both good and bad) adds life to any presentation. You can also ask if anybody in the audience has had similar experiences. This will encourage audience participation and make the presentation more engaging for the audience.

• Use Analogies as much as possible. It is very effective to explain the unfamiliar with an analogy/comparison with the familiar.

• Provide real life examples as much as possible.

• Try to defer Q&A till the end. Too many questions from the audience can derail the presentation. Avoid answering questions that needs time consuming answer/explanation. In such cases it is better to request the questioner to see you after the presentation.

• One or two good quotations/jokes during the presentation is always helpful. But do not overdo this. I have witnessed presentations with a quotation on every slide!

• Conclude the talk with a brief summary of what was presented. Specify takeaways for the audience and follow up action if any. Direct the audience to web sites, blogs, etc for further information on the topic.

• Specify your email ID for the audience to reach you for any follow up communication and feedback. Also direct the audience to the link where they can download the presentation.
  

• Plan to finish in the alloted time.

• If the question from the audience is not audible to everybody in the room, repeat the question before you answer.

• Before presenting to a wider audience rehearse with your friends and colleagues.

DON'Ts

• Avoid slides torture (too many slides). Too many slides are bound to make even the most alert audience drowsy!

• Avoid trying to cover too much ground. Keep the presentation focused. When in doubt, choose depth over breadth to make the presentation valuable to the audience. If you try to cover too much, your audience will loose interest on the topic. The goal of any presentation is never to fully educate the audience on the subject. It is rather more important to design the presentation to arouse interest on the subject and motivate the audience to learn more on the topic after they have attended the presentation.

• Never attempt a presentation without adequate preparation. Do not attempt to present anything which you have not earned the right to present by adequate practice and self study.

• Exercise restraint and avoid copy paste from other people's presentations. It is easy to detect copy paste work.

• Don't spend too much time on theory. Theory can be learned from books and the internet and is also easy to forget. Try to cover the practical aspects, best practices, examples, etc.

• Avoid fictitious examples as much as possible. Try to provide examples from real life.

• Try to avoid presenting right after lunch. If you are the unlucky speaker to present something right after lunch, I wish you all the best!

Recommended Reading: The Quick & Easy Way to Effective Speaking

Getting Started with Agile

Do you know a good thing when you see it?

I got introduced to Agile while I worked at Siemens Medical Solutions, Malvern, USA. In fact I was one of the few lucky people to attend the Scrum Master training by Ken Schwaber! I could sense from the very outset that I was heading into an exiting new territory! Since then I never looked back. My perspective on Software development was reset for ever!

Recently I got the opportunity to download and listen to the entire audio book Who Moved My Cheese on my iPod. The book is remarkable for its simplicity. I have already started recommending it to my colleagues at work. I think this book can be very useful to people who are habitually sceptical of new ideas and always tend to hold on to past beliefs.

Here is a great quote from the book which I think holds special significance for new Agile parctitioners:

"Movement in a New Direction Helps You Find New Cheese"

I think that most organizations struggle with Agile adoption due to lack of firm commitment from Senior Management. We all know that the greatest impediment to any change is the "fear of change" itself. As human beings we love to hold on to our familiar self and tend to avoid changes as much as possible. The tendency to hold on to our past belief systems increases with biological age. As a consequence, senior organization leaders often feel a lot of discomfort adopting Agile in its true spirit. So we often witness a mishmash of incompatible practices and techniques which only leads to confusion and demotivation to the team members.

Lesson: "Old Beliefs Do Not Lead You to New Cheese"

Some slides from the book are available at http://www.docstoc.com/docs/10317227/Who-Moved-My-Cheese. I think this is worth a read.

"Move With The Cheese And Enjoy It!"

Agile Code Reviews for Distributed Teams

Code Review is an age old practice in Programming. Nevertheless, code review becomes a bit challenging for distributed teams. If the development team policy does not allow junior developers to commit (check-in) unreviewed code to their development branch in version control, then it becomes a bit difficult for distributed teams to implement an efficient code review process without creating separate branches in the version control repository for every change. A new branch for every task can potentially create hundreds of branches which can soon become confusing and unmanagable for the team. In my experience, only the most expensive version control tools are good in dealing with merging/promoting code across multiple branches.

I think a cost effective approach to solve this issue would be to utilize the "create patch" functionality available in most version control tools (like Subversion). Patches are nothing new in the world of programming. Every open source project utilizes this feature. Developers can create a Patch and commit (check-in) the patch file to a well known location (say a patch folder) and notify the reviewer. The reviewer (located in a different location/time zone) an apply the patch to his local work area, review the changes at his own convenience and get back to the programmer with his feedback (by email, phone, discussion board, etc).

For detailed instructions on how to create and apply a patch in Subversion using Tortoise SVN Client visit http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-patch.html.

I think we can also utilize patch functionality to store code which is useful but not yet ready for release. Often we end up building functionality/proof of concepts which cannot be checked in to the main development branch because it is still not ready for prime time. In these cases we can preserve the changes as a single patch file for future use.

Agile Development Skills

"Your earning ability today is largely dependent upon your knowledge, skill and your ability to combine that knowledge and skill in such a way that you contribute value for which customers are going to pay." --Brian Tracy

I think it would be a mistake to think of Agile only as a new methodology for Software Development. To me Agile is more than just a methodology. It is a paradigm shift not only in the way we develop software, but also in our roles in the development team. In an Agile context we can no longer confine ourselves to a narrow specialty (Analyst, Programmer, Team Lead, Tester, etc.).

Agile Team members must be willing to help out in areas outside their traditional roles/expertise. For example, a Tester might be asked to help out by creating wireframes (screen mockups) to get approval from the customer. The architect might have to help out by writing low level code or fix defects. The project manager might have to help out with Testing. In an agile team, the team members will have to be willing to help out in various areas from time to time to meet the Sprint goals. The new role demands more communication, commitment and versatility from every team member and also makes our job more interesting and fun. In Agile terminology this is commonly referred as Generalizing Specialist.

I think the traditional separation of roles creates a caste system in the team which does more harm than good. In a traditional role centric environment, the team members do not feel empowered to get the job done. So it is very challenging to deliver working software in short Sprints (usually monthly or bi-weekly).

Open Source Development Tools for Small and Medium Enterprises

Here is a listing of best of breed open source tools for Java/J2EE Software Development:

• IDE - Eclipse (Check out the Easy Eclipse distribution)
• Version Control - Subversion
• Unit Test Tool - Junit
• Web Server - Apache HTTP Server
  
• J2EE Application Server - JBoss
• Project Management - Open Workbench
  
• Project Management - Openproj
• Defect Tracker - JTrac
• Web Application Test Tool - Selenium
• Load Testing - Apache JMeter
• Test Case Management - TestLink
• Continuous Builds - CruiseControl
• Web Development -Firefox Web Developer Toolbar Firebug
• Web Development - Internet Explorer Developer Toolbar
• Browser Testing in Various Versions of IE - IE Tester
• Web Accessibility - Web Accessability Toolbar
• Reports - iReport
  

Cross Functional Teams

We need to appreciate the need for cross functional teams for speedy delivery of working software. A cross functional team is perhaps the single most important ingredient for project success. The cross functional team should have competencies ranging from requirements analysis, project management, software architecture, web development, database development, testing, etc. Every team member shares the responsibility for the delivery of working software to the client and operates without team boundaries and organization silos. Senior management needs to empower the team to make strategic and tactical decisions to meet the project goals. To a great extent, the success of cross functional teams depends on organization culture. Care must be taken so that the functional reporting managers do not burden the team members with conflicting assignments (serving vested interests and individual egoes) that dilutes focus away from the project at hand or demotivates the team members by not giving them credit for the project assignments that serves a bigger purpose for the organization. This requires strict vigilance and commitment from senior management. I have encountered several examples where a functional reporting manager indirectly penalized their subordinate for working on high performing cross functional team which did not directly serve the narrow interest of the functional manager.

Agile also advocates close collaboration with customers throught the project development cycle. However, breaking the psychological barrier between vendor and client is a prerequisite for such a collaboration. Honest and open communication is the bedrock of collaboration. Portraying a "happy picture" of the state of affairs by the vendor does not always serve the best interest of the project. Suppressing project challenges and risks to the customer during the project only increases the possibility of last minute surprises causing customer dissatisfaction and business risk (both financial and non-financial) for both the vendor and the customer.

The human factor in Software Project Execution

"If you want to build a ship, don't drum up the people to gather wood, divide the work, and give orders. Instead, teach them to yearn for the vast and endless sea." --Antoine De Saint-Exupery

Traditionally, software project execution had always been a lesser discussed topic than Project planning. While planning is essential for Project Success, the ground realities of software development seldom matches the "ideal" world documented in the Project Plans. Too much of upfront planning and processes often failed to yield the expected ROI in the dynamic world of modern software development. In my experience, most of the high level project planning is performed by Senior Management who either do not have a good understanding of the actual complexities of project execution or lack the will and commitment to do so. Unrealistic expectations set during project inception often doom a project to a death march right from the very begining. It also creates lots of stress and demotivation to the development team that has to fight the battle in the trenches. The net result is that development team has no choice but to "mechanically" follow the "process" on a journey to nowhere.

The Agile Manifesto stresses more on the ground realities of Project Execution vs. Planning. Since, actual results are produced by people, agile stresses more on "people" over "process". While processes and tools are an integral component of team collaboration and success, individuals drive success more than the processes and tools do. Prior to agile, the human factor did not get its due recognition. I think most of the traditional processes failed to address the human factor in software development. In my experience, humans do not work very well when asked to work under too many constraints. Too much processes and beaurocracy dilutes individual accountability and responsiveness. The irony is that the many traditional process that were originally designed to help teams succeed, actually turned out to be impediments to real progress.

However, I would also like to caution that Agile in no way advocates "ad hoc" development. It requires more "process maturity" on the team compared to traditional (process heavy) methodologies where people are expected to work like robots and the process is expected to magically take care of everything! As we all know that with more power comes more responsibility. In Agile, every team member is more empowered to do his/her job but needs to be more responsible and committed for the actual outcome.

Agile Kolkata User's Group

I would like to start Kolkata Agile Software Development User's Group as a meeting ground for architects, project leads, project managers and software engineers practicing Agile Software Development in Kolkata. I also welcome newcomers interested in learning about agile software development to join the group.