If you are interested in attending a refactoring fest and if you are around philly area, I‘m conducting a session for the agile philly group.

For more details click here…

It is important to understand what a retrospective is and why we need one before we jump into antipatterns.

Based on my experience, I can think of the following antipatterns with regard to retrospectives:

• Reoccurring problems:
  If you see the same problems repeated over and over again in each retrospective, you might have missed the most important, learning aspect of a retrospective.
  Maintaining a history of previous retrospective can help as the first step. Retrospectives must be seen as a chain rather than a bunch of independent nodes. Capturing the discussion and letting the whole team follow up on the action items can be really help. Avoid one person taking the ownership of the whole retrospective.
• Retrospectives as a way of reporting to senior management:
  Trying to capture information in retrospectives purely to report to senior management is a big smell. Retrospectives are, by the people, for the people and of the people. The focus is people and the process around them, not the senior management. Certainly, notes from the retrospective can help senior management. But retrospective is not meant for purely that purpose.
• Dull Retrospectives [Not enough humor and openness]:
  Retrospectives with low energy levels, where the participants sit like rocks, expression less, scare me. Though retrospectives are a serious affair, they must be fun filled, enjoyable learning experience. The team should feel comfortable expressing their opinions. Monotonous format of a retrospective can make retrospectives an event instead of a regular practice.
• Retrospectives turning into bitch session:
  If all one does during a retrospective is complain, complain and complain, it does not feel right. The team has to brainstorming and coming up with potential solutions to their problems rather than just bitching. One must utilize the retrospectives to do some root cause analysis and come up with action points.
• Time boxed retrospectives:
  You should let the retrospective run as long as the team wants or have more frequent retrospectives. Retrospectives are important, intense discussions which involve a lot of brainstorming and creative thinking. When I enter a time boxed retrospective, I don‘t feel free to discuss a lot of issues, coz I think they can be very time consuming. So I‘m forced to wait for the volcano of frustration erupts in a wrong place at a wrong time.
• No action items/resolutions:
  At the end of each retrospective the team must come up with a list of action items. In the coming iteration/sprint, the team makes sure those action items are resolved or discussed further. But not coming up with unanimous action items defeats the purpose of a retrospective.
• Lack of respect for ground rules:
  Retrospectives have very simple ground rules. If one does not care about these rules, it means to me that they do not care or respect the team members.
• Retrospectives optional to team members
  Team members skipping retrospectives is a big project smell. Even if someone is not interested/willing to speak, they can still listen to other team member‘s perspectives. The only reason I might not attend a retrospective is, when I have lost hope. And that‘s a big problem.
• Formal structure for retrospectives
  If the teams are asked to fill out a form at the end of a retrospective, you might just a missed the forest for a tree. Any kind of formalization around self organized events is a big smell. The event losses its essence with formalization.

What is a retrospective?
Retrospective (from Latin retrospectare, “look back”) generally means to take a look back at events that already have taken place.

In the software world, a retrospective is a meeting held with a project team at the end of a project or process to discuss what was successful about the project, what could be improved, and how to incorporate the successes and improvements in future projects.

In the agile software world, a retrospective is a meeting held by the project team at the end of every iteration/sprint to discuss what we learnt as a team, what we can improve as a team and plan the future iteration/sprint based on this learning.

Why do we need retrospectives?

1. Improve learning: Reflection is a key step in learning from experience. Retrospectives can help you capture the continuous learning process of a team and take it one step further.
2. Communication and Feedback mechanism for any agile team.
3. Helps the team to adapt their process based on their learning of what works and what does not work. In other words, it gives a team a way to adapt process to their context.
4. Helps the team to consciously work towards improving work quality, satisfaction and work culture.
5. Helps the team self organize by empowering the team members.

What should be the scope/focus of a retrospective? Technical/Process/People?
Retrospectives should be focused at improving customer and team satisfaction. Which means, we have to focus heavily on people and the process around them, their interactions/communication patterns, workspace and work culture. Everything else is secondary.

How long should a retrospective be for?
They can be 15 mins to 2 days. As long as the group have or feel something important to discuss. If retrospectives are always lengthy, it might mean you need to increase their frequency. Even after increasing the frequency does not solve the problem, it means something important on the project is broken and it needs to be fixed.

How do you decide the frequency of retrospectives?
Lots of factors contribute towards this. Team size, experience working together, nature of the work, etc. Ideally you need frequent retrospectives to begin with, but as you go on, it should become less frequent and shorter. Most of the agile projects end of the iteration/sprint is a good time to have a retrospective.

When should one schedule/time a retrospective?
The schedule of a retrospective is very important. Trying to mix them up with lots of other meetings on the same day can make it very ineffective. Participants should not feel like it‘s just another meeting. I would ideally conduct a retrospective at the end of the iteration/sprint and before the planning meeting. Outcome of the retrospective can greatly affect the next iteration/sprint planning.

What is the best location to hold a retrospective?
Same location as the team room can be a mind block. [Too much of the same thing.] I prefer a conference room with a lot of white boards, open walls [visible surface] to stick cards/posters and food. It should be away from people‘s workstations and phones. Some people prefer going to a bar/pub for these meetings.

Who should facilitate the retrospective?
It is difficult to say who would be a good facilitator. But it‘s easy to say who should not play the role of the facilitator. Team leads, Iteration Managers, Scrum Masters, Managers, etc are a big NO NO. You want an unbiased person who has sufficient knowledge about the project and process. Having someone from the team facilitate has the risk of turning the discussion towards personal goals. Getting someone from outside can reduce personal conflicts. But at the risk of not having a focused discussion targeted towards the real pain points. The discussion can turn out to be very superficial.

Who should take the responsibility of following up on the action items?
Ideally the team and not just the manager. We want to build self organized teams who can constantly learn and fix problems.

Should retrospectives just try to identify issues or should they try to come up with resolutions?
Retrospectives are brainstorming session which should try to identify issues, find the root cause and try to come up with an unanimous resolution. If we just identify issues and leave them, what next? Who would resolve it? This would make the retrospectives a bitch session. Trying to come up with a unanimous resolution drives home the team ownership aspect.

Should the team vote for top x [say 3] issues?
Mixed feelings. While we need to start somewhere, the way to identify top 3 issues can be very difficult. If you have different number of people playing different roles [Dev, QA, Analyst, etc] on the team, the voting would be heavily biased towards the majority of people in a role. Developers might get their issues prioritized while QA issues might be neglected. Often different people rate issues differently. Letting team members own the issues and resolve them based on their priority can help the team overall.

Are retrospectives optional?
Team members skipping retrospectives is a big project smell. Even if someone is not interested/willing to speak, they can still listen to other team member‘s perspectives. The team should focus on creating a work environment where all the team members have the sense of ownership. Once this happens, even if you try to stop people from attending retrospectives, they won‘t miss it.

Who all should participate in a retrospective? Who should be a part of the retrospectives?
The whole team including the customers. Some times it is helpful to have chickens, other team members as silent spectators. It is important to have honest and open communication with in the whole team. Retrospectives have really helped my team build trust with the customer by improving communication and increasing visibility thru retrospectives.

Can retrospectives be distributed?
Mixed feelings. Retrospective is a way to resolve communication problems and give feedback. By having distributed people participate in retrospectives we might introduce the same issues with low quality of communication. Flip side is, if you do not involve distributed teams, each team might drift away into separate islands. A middle round can be worked out, where each team conducts their local retrospectives and then representatives from each location have a cross location retrospective. Preferably face to face.

Does it not get annoying to be forced to work with different wikis and each wiki having different syntaxes?

Currently I have to work with:
1. fitnesse: for our acceptance testing. Since fitnesse is meant for acceptance testing and has a horrible search functionality it stays in its own space
2. MediaWiki: The current client that I‘m working for uses MediaWiki for the project and cross team wikis. So all the important project stuff goes here. But these have horrible navigation. It also does not support RSS on all the pages.
3. Confluence: At my current company we use Confluence for internal use. It is pretty powerful. But my biggest complain is, it‘s licensed, not open sourced. It is difficult to convince my client to buy confluence.
4. VQWiki: Currently I‘m playing with VQWiki. It uses Lucene as its search engine. I was looking to integrate lucene with Fitnesse and that‘s how I got introduced to vqwiki. Now we use it for our refactoring fest at the Agile Philly User Group.

You will be surprised to see how many different wikis are available out there. List of wiki software

I see a big problem having so many wikis with lack of open standards across these wikis. None of the wikis seem to understand each other‘s format. Right now the only way to avoid information lock down is to write some crazy scripts to port data from one wiki to another. This is certainly not a sustainable model as more and more companies switch to wikis for team collaboration.

Over the last couple of days I was wondering how to hot deploy webapps in Tomcat? After trying all possible search queries in Google I gave up. But I knew for sure that it was possible to hot deploy webapps in Tomcat, as I had done it before.

I started playing with Sysdeo Eclipse Tomcat Launcher plugin. This plugin had an option to make the context reloadable. It actually updates the server.xml under the tomcat/conf dir. This is how I figured out how to make this work for any webapp.

Just add the following line to the server.xml

<Context path=”/yourContext” reloadable=”true” docBase=”rootFolderOfYourApp” />


Now I don‘t have to stop and start tomcat for a small change in a class file to reflect.

What is the purpose of Continuous Integration?
1. To avoid last minute integration surprises. Big bang integration leads to integration nightmare. Continuous Integration tries to break that by doing it in small steps.
2. Helps in improving quality of the software and reducing the risk by giving quicker feedback.
3. Brings the team together. Helps in building collaborative teams.
4. Continuous Integration gives a level of confidence to checkin code more frequently that was once not there. So if people are afraid to check in, your Continuous Integration process is not working. Continuous Integration process goes hand in hand with Collective code ownership and one team attitude.

Is Continuous Integration the same as Continuous build?
No. Continuous build only checks if the code compiles. But Continuous Integration goes beyond just compiling. It executes a bunch of unit and functional tests to verify that the software built is functioning the way it should.

How do you differentiate between Frequent Versus Continuous Integration?
As soon as there is something new to build, its built automatically. But it has to be using a clean environment. This gives the feedback as quickly as possible to respond fast.
When it stops becoming an event and becomes behavior.
Merge a little at a time to avoid the big cost at full integration at the end of a project
The bottom line is quicker feedback.

Can Continuous Integration be manual?
Manual Continuous Integration is the practice of frequently integrating with other team members manually.
I feel it should be an automated process so that you are compiling, testing, inspecting, responding to feedback. Because people are not good at being consistent and cannot do repetitive tasks (i.e. its a machine‘s job)

Requisites for Continuous Integration?
There are lots of grey areas. But a quick list is:

• Common source code repository
• SCM tool
• Automated tests
• Build scripts of some type
• Feedback mechanism
• Commit code frequently
• Change of developer mentality, desire to do it. Reinforce thinking about Integration.

What is in a Continuous Integration build?

• pulling the source from the SCM
• compiling source
• executing unit tests
• deployment
• packaging
• labeling the repository
• generating and compiling source
• documentation (javadocs)
• source code metrics – static analysis, pmd, dependency analysis (jdepends), mccabe/cyclomatic complexity
• code coverage
• database – create the schema
• restoring the environment (pre/post build)
• reporting / publish status of the build
• historical record of the build
• functional test
• integration tests
• performance tests
• regression tests
• smoke test
• build metrics – timings
• artifact publishing (.ear, .jar, .zip)
• auditing information (i.e. why, who)
• creating installer

Who all are the stakeholders in the Continuous Integration build?

• developers
• testers [QA]
• analysts
• managers
• system operations
• architects
• DBAs

What is the scope of QA?
They help the team with automating the functional tests. They pick up the product from the nightly build and do other types of testing. For Ex: Exploratory testing, Mutation testing, System tests which are hard to automated [pulling out the network cord].

What are the different types of builds that make Continuous Integration and what are they based on?
Builds are usually based on their feedback cycle and target audience.

1. Local Developer build :
1.a. Job: Retains the environment and only compiles and tests changed code.
1.b. Feedback: less than 5 mins.
1.c. Stakeholders: Developer pair who runs the build
1.d. Frequency: Before checking in code
1.e. Where: On developer workstation/laptop

2. Smoke build :
2.a. Job: Compiles , Unit test , Automated acceptance and Smoke tests on a clean environment[including database].
2.b. Feedback: less than 10 to 15 mins.
2.c. Stakeholders: All the developers within a single team.
2.d. Frequency: With every checkin
2.e. Where: On a team‘s dedicated continuous integration server. [Multiple modules can share the server, if they have parallel builds]

3. Functional build :
3.a. Job: Compiles , Unit test , Automated acceptance and All Functional\Regression tests on a clean environment. Stubs out or mocks out other modules or systems.
3.b. Feedback: less than 1 hour.
3.c. Stakeholders: Developers , QA , Analysts in a given team
3.d. Frequency: Every 2 to 3 hours
3.e. Where: On a team‘s dedicated continuous integration server.

4. Cross module build :
4.a. Job: If your project has multiple teams, each working on a separate module, this build integrates on those modules and runs the functional build across all those modules.
4.b. Feedback: in less than 4 hr.
4.c. Stakeholders: Developers , QA , Architects , Manager , Analyst across the module team
4.d. Frequency: 2 to 3 times a day
4.e. Where: On a continuous integration server owned by all the modules. [Different from above]

5. Product build :
5.a. Job: Integrates all the code that is required to create a single product. Nothing is mocked or stubbed. [Except things that are not yet built]. Creates all the artifacts and publishes a deployable product.
5.b. Feedback: less than 10 hrs.
5.c. Stakeholders: Every one including the Project Management.
5.d. Frequency: Every night.
5.e. Where: On a continuous integration server owned by all the modules. [Same as above]

Adapt your own process/practice.
General Rule of Thumb: No silver bullet