Free eBooks on Agile and Scrum

Here are some links to free eBooks on Agile and Scrum. To download in IE, right click on the link and Select "Save Target As". If you are using Firefox, right click on the link and Select "Save Link As".

Scrum and XP from the Trenches
Scrum Primer
Do It Yourself Agile
Patterns of Agile Practice Adoption eBook Home Page

Tips for students aspiring for a career in Software Development

According to a recent survey, jointly carried out by the Federation of Indian Chambers of Commerce and Industry (FICCI) and the World Bank, 64 percent of surveyed employers are "somewhat", "not very", or "not at all" satisfied with the quality of engineering graduates' skills.
Read More

"Mere 25% of graduates that India produces every year is actually employable." --Jeffrey Fuller, principal advisor of Human Capital, a consulting arm of Mercer
Read More

It is common knowledge that formal college education in India fail to eqip the students with marketable skills necessary to seek employment opportunities after graduation. So we are witnessing a profileration of "Finishing Schools" in India promising to the fill this gap of employable skills (both technical and soft skills) not taught in formal college education. While I do not devalue the role of the finishing schools to fill the skills gap, I doubt if a few months course can make up for a few years of lost learning opportunity in college!

Not getting a decent job after graduation can be very demotivating for the students. So I think the best way out for the students is to take proactive steps to start learning marketable skills necessary for employment while they are in college (as opposed to wasting money in finishing schools after graduation).

Here are a few tips to help the students in IT proactively prepare for a good career:

• Do not wait to acquire industry relevant skills until your final semister or after you graduate! Start as early as you can (preferably from the first year in college).

• Theoritical knowledge is sufficient to pass exams. But hands-on programming experience is essential to develop software. If you aspire for a good career in software development, you should write a few thousand lines of code by the time you graduate from college. Contribute to an open source project if you can. This way you will have something worthy to show/discuss for during your job interview. The interviewer will also ask less theoritical questions if you have something worthy to show off!
  

• You can learn multiple programming languages which are mandated by your university syllabus. But do not stop there. Select a language you like and get in-depth programing experience using it (preferably on an open source project of your liking).

• Find somebody who is already working in the IT industry and is willing to help you acquire industry relevant skills. Consider this person your guru and mentor. This will complement your theoritical knowledge that you have leaenrd from your professors in college.

• Read relevant online journals, blogs and news on IT. There are many free resources on the web to enhance and develop your skills.
  

• Watch Podcasts. You can download them on your iPod or any other MP3 player and listen at your convenience. I strongly recommend the Career Tools Podcast.

• Read good books on programming and design (whether they are part of your college syllabus or not).
  

• Last but not the least, you can contact me if you already know Java and willing to try working on some open source projects. I can be reached at saurabh.banerjee@acclaris.com

Relevant Links:

Engineering Graduate Talent Pool in India, Highlights of Research Report, Nasscom, 2005

The Evolving Global Talent Pool - Lessons from the BRICS Countries, The Levin Institute, State University of New York, 2006

Lean Software Development – Eliminating Waste

There is nothing so useless as doing efficiently that which should not be done at all. --Peter F. Drucker

Lean is a generic process management philosophy derived from the Toyota Production System. The Japanese term for waste is “Muda”. Eliminating waste is the very first step of going Lean. Here are some thoughts on eliminating waste in Agile Software Development for various activities:

Requirements:

• Agile advocates User Stories (as opposed to Use Cases). User Stories capture the high level Goal for a feature/function in one or two sentences in the product backlog. A conscious attempt is made to avoid too much detail. The details are worked out just-in-time during the development. This prevents premature optimization and over engineering of requirements.

• Specify Acceptance Criteria for each user story. Acceptance Criteria is very effective to communicate requirements to developers and discourages gold plating of requirements.

• Slice major user stories (epics) into multiple smaller manageable user stories. Develop the sub features in order of priority. Release something of value to the end user in every sprint. Receive feedback and adapt accordingly in the next sprint.

• Make a conscious attempt to avoid feature bloat (Swiss-Army-Knife approach) as much as possible. Increased complexity increases defect density, compromises usability, makes unhappy customers and drain development team’s resources.

Design:

• Agile teams do not treat design and development as separate silos. Both are integral to each other.

• Avoid elaborate design documents unless when working on very complex features. Live meetings/interactions are more effective for brainstorming design challenges and communicating design decisions.

• Avoid over engineering (use adaptive design as opposed to predictive design). Adopt Refactoring and continuous integration to evolve the design/code over time.

Development:

• Avoid multitasking. Work on one task at a time. Testing must be complete and the task should be ready for release before considering it ‘done” and moving on to the next task. It is important for everybody in the team to agree on a common definition of “Done”.

• Too much work in progress (inventory) in the development branch (code changes which were never released because other work got higher priority) will impede future work. Remove unreleased/incomplete code changes from version control for tasks which were interrupted/de-prioritized midway. Create patch files to preserve (hibernate) the code for future use if necessary.

• Check-in code regularly to version control to avoid last minute integration issues and resulting rework.

• Encourage collaboration (collective code ownership by the team as opposed to individual code ownership).

Testing:

• Do not waste time on elaborate test plans unless the customer mandates them. Keep test plans lean. In my last 14 years in Software development I have seldom seen anybody reading them!

• Keep test cases lean and focused. Avoid too many step by step instructions/details. Otherwise you will get lost in the details and generate useless paperwork. Scripted test cases usually exercise the happy paths.

• Automate regression testing of critical features/functionality which change/evolve frequently.

• Adopt a balanced diet of scripted and exploratory testing.

• Involve the testers from the beginning.

Planning:

• Do not overburden the team. Overworked teams are not effective in producing quality software. Overburden (“Muri” in Japanese) is one of the three types of waste identified in the Toyota production System. We all know how bumper to bumper traffic brings our highways to a standstill! Developers need down time to retrospect, reflect and improve.

• Processes/methodologies are only means to an end (working software). Always keep the end result in mind. Optimizing individual steps (doing things right) may not always lead to the right outcome (doing the right things). So we need to take a holistic look at value creation throughout the entire development process and eliminate non-value added activities as much as possible.

"The most dangerous kind of waste is the waste we do not recognize."
- Shigeo Shingo (Toyota)

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.