As a part of the Agile Philly User Group, I'm organizing an user group meeting, where Sanjiv Augustine will present his thoughts on how to Scale Agile Projects?

The meeting is open to all. If you want to attend, please RSVP via email to Naresh Jain ASAP. Please include your name, role and organization.

• Venue: Gestalt, King of Prussia, 680 American Ave, Suite 302, King of Prussia, PA 19406
• Date: Oct 3rd 2006
• Time: 6:30 PM onwards

More details: http://wiki.agilephilly.com/index.php?title=Scaling_Agile_Projects

As a part of the Agile Philly User Group, I‘m organizing an user group meeting, where Bob Schatz will present his thoughts about how to become a change agent in your organization, and thus help move the adoption of agile techniques in your organization.

About the topic:
Organizational Change: The successful adoption of agile techniques in an organization has more to do with organizational transition than a new software development process. The simple values and principles of agile development provide the underlying structure for new organizational behaviors. These changes require leadership at all levels of the organization.

This is for anyone involved at any level in an organization considering or already using agile. The meeting is open to all. If you want to attend, please RSVP via email to Naresh Jain ASAP. Please include your name, role and organization.

• Venue: Fidelity National Information Services (FIS), 2 West Liberty Boulevard, Malvern, PA
• Date: Sep 5th 2006
• Time: 6:30 PM onwards

More details: http://wiki.agilephilly.com/index.php?title=Organizational_Change

In other words, using IRC Chat Rooms as a form of intra-team communication and as a knowledge repository

Context:
I‘m currently working on a product which has 8 development teams. All the teams are located in the same building. Each team has about 8–15 members on the team. It includes a QA, a Scrum Master, a Subject mater expert and the rest are developers. We also have couple of Product owners and Project Managers.

We started of with one team of 8 people about a year ago. We have gradually grown over time by adding 2–3 new team members to the existing teams and talking the same number of older members and forming new teams. We also had a few exchange of team members between the teams.

Forces:
We have tried this predominantly for:

1. Having good collaboration between teams
2. Managing process and technology related knowledge between the teams, so that each team does not reinvent the wheel
3. Consistency between the teams. Both in terms of Architecture and product vision

Problems:
We still seem to be facing issues with the items listed above. We have tried to used a Wiki to capture/document different things that we feel should be shared between the teams. Right from how to get started as a new team member to configuration issues to architectural guidelines, everything seems to be captured on the Wiki. But the real problem is finding things easily on the Wiki. The whole Wiki is such a mess; there is no easy way to refactor it to find information more intuitively.

Work Around: Mostly people walk across team rooms and ask the so-called experts about the issue they are currently facing. While I value face-to-face communication, some times it is not very effective. Esp. when you don‘t know whom to ask or when the so-called expert is not available.

In addition to this, we also use Instant Messengers [IMs]. IMs are little more convenient but they are essentially one-to-one conversations and hence we could see the same issues discussed over and over again.

I also think this is not a very sustainable model for managing knowledge within a team over its lifecycle. We are looking at this system to be in development for 3–4 years and then 20–25 years in production.

Theoretical solution:
To solve the issues listed above, I was thinking of installing an IRC chat server and use chat rooms as an offline discussion forum. When the team members get into office, they can logon to the chat server, just like they logon to IM. When somebody has a question they can shoot it on the chat room. Whoever has the knowledge and is available can respond back. There could be questions flying back and forth in real time.

As these conversations go on, we can have a bot recording [logging] all the conversations. There are a few IRC Loggers [bots] available which can log the conversations. They also provide a web front-end to search the logs.

This can act as the knowledge repository which people can search. The biggest advantage I see with this approach is that it is just a natural process of recording information. We don‘t have to go and separately write [record] it on the Wiki. It‘s also common for people find solutions when they are searching for specific questions. There is a high probability that someone else would have asked a similar question.

Other benefits:
One could use the IRC channel as an effective way to publish information to the team. For Ex. CruiseControl can publish the build results, etc.

Open Questions:
1. Do you think this approach could work?
2. Do people know of a good Windows based IRC server and client?
3. Are there any IRC servers that can group topics together like a mailing list does?

Other comments are welcomed.

Getting the following error message while deploying an application in Websphere?

com.ibm.etools.j2ee.commonarchivecore.exception.
DeploymentDescriptorLoadException: IWAE0022E Exception occurred loading deployment descriptor

Context:
Check your web.xml.
If you are using the following XSD as the DOCTYPE of your web.xml http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd
Then you might want to check your servlet tag to make sure they match the Servlet 2.4 specification.

For example, the following servlet causes the above exception when it tries to deploy the app.

<servlet>
<servlet-name>sampleservlet</servlet-name>
<servlet-class>ABCClass</servlet-class>
<init-param>
<param-name>ABCParamName</param-name>
<param-value>ABCParamValue</param-value>
<description>some desc</description>
</init-param>
</servlet>


Surprising this works perfectly fine if your web.xml is using http://java.sun.com/dtd/web-app_2_3.dtd as the DOCTYPE

Solution:
Removing the

<description>some desc</description>

tag from

<init-param>

tag fixes the problem.

Another problem with DTDs:
If you are using DTD, the order of the tag elements within the web.xml must follow the order reflected in the DTD. Else you will get similar exception message. The order of the tags in web.xml is very important when using DTD. But it should not matter if you are using XSD.

If you open the DTD, it would list the order of the tags in there.
For example, web-app_2_3.dtd specifies the following order that the tags must have in order for the document to be considered a valid XML document:


<!ELEMENT web-app (icon?, display-name?, description?, distributable?, context-param*, filter*, filter-mapping*, listener*, servlet*, servlet-mapping*, session-config?, mime-mapping*, welcome-file-list?, error-page*, taglib*, resource-env-ref*, resource-ref*, security-constraint*, login-config?, security-role*, env-entry*, ejb-ref*, ejb-local-ref*)>


Hence

<ejb-ref>

tag element must be before

<ejb-local-ref>

tag.

Well, I don‘t have any great expertise in TOC. All I know about TOC is what I have heard from people and from Gold Ratt‘s books and articles.

Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results By David Anderson is a good read. He talks about applying TOC to decrease the time to market and hence better business results.

I have used similar thinking process.

The way I used TOC is:

I started considering the whole team‘s activities as a set of workflows. I took each workflow and converted into a graph. This showed how much time and efforts were spent to transition from one state to another. This helped us identify the longest edge in the graph, which is a potential bottleneck in the system. Once you have the bottleneck, the plan is to minimize the amount of time it takes to move from one node [activity] to another by applying an agile practice that suits the best.

Example:
Activity: Fixing a bug
|No..|Node..|Acitvity…………………….|Date and Time…..|Time in Days|
|1…..|A……..|Bug reported……………..|June 10, 2006…..|0……………..|
|2…..|B……..|Reproduce the bug……..|June 18, 2006……|8…………….|
|3…..|C……..|Write a failing test……….|June 20, 2006……|2…………….|
|4…..|D……..|Fix the bug………………..|July 10, 2006…….|20…………..|
|5…..|E……..|Regression testing……….|July 14, 2006…….|4……………..|
|6…..|F……..|Make a release…………..|August 14, 2006..|31……………|
|7…..|G…….|Bug closed by customer..|August 16, 2006..|2…………….|

[Unfortunately I cannot paste the graph. But the table should be self-explanatory]

In this example, it took 31 days for the team to get a release out of door. That is really a bottleneck in the team‘s performance. So it was important to fix this. The practice that came to my mind was Continuous Integration [CI]. In our case, since we were the architecture team, we had to establish CI with our customer‘s build every night. By doing so, we cut short the release time to 1 day.

So now we had:
Activity: Fixing a bug

|No..|Node..|Acitvity…………………….|Date and Time…..|Time in Days|
|1…..|A……..|Bug reported……………..|June 10, 2006…..|0……………..|
|2…..|B……..|Reproduce the bug……..|June 18, 2006……|8…………….|
|3…..|C……..|Write a failing test……….|June 20, 2006……|2…………….|
|4…..|D……..|Fix the bug………………..|July 10, 2006…….|20…………..|
|5…..|E……..|Regression testing……….|July 14, 2006…….|4……………..|
|6…..|F……..|Make a release…………..|July 15, 2006…….|1……………..|
|7…..|G…….|Bug closed by customer..|July 17, 2006……|2…………….|

Once we fixed the release issue, now we had the next bottleneck of fixing the bug which was taking us 20 days.

On asking the team why it was it so difficult to fix a bug, they complained that they had to do 20 things before they could fix a bug. There was obviously duplicate code and complicated design issues.

Next practice that came to my mind was Refactoring and TDD. These are big practices, but after a few days we could see that the amount of time it was talking to fix a bug was reducing. So it was a positive feedback cycle and the team wanted to do more of it.

Context: I just spent the last 3 months helping an architecture team adopt some of the agile practices. When I was brought over to this team, I was supposed to help them build their reputation in the organization. I was given an enormous task of making the team agile.

Forces: So where do I start? I could take the XP white book and slap all the 12 practices on them. But I knew that would certainly not work. Also, I was not sure what were the real issues from the team‘s point of view? I had heard the application teams [their customers] complain. The manager of the team had some issues he wanted to resolve. But what was the real issue?

I was starting on a new team. I had never worked with anyone on this team. Based on my experiences with previous projects, I knew I had to build trust with the team to make anything work.

So the question comes back. Where do I start?

Approach: Well, conducting a team retrospective felt like a decent option. If I could pull off the retrospective, then I could get an initial list of issues [which are really user stories for a coach] for the team. Based on this list, I could ask my customers [the team] to prioritize the issues based on what hurts them the most and fixing which issue will deliver max relief to the team.

So I conducted a team retrospective, I encouraged the team to speak. Some team members were more vocal than the rest. But we had a good discussion. At the end of it, I had my master story list or product backlog [list of issues faced by the team, which I had to help them resolve].

Though this was a good beginning, the issues were very superficial or abstract. I needed a better way to find out the real issues, a tool to do some form of root cause analysis or something like that.

So I started considering the whole team‘s activities as a set of workflows. For Ex. Upgrade to new version of software X. Or. Fix a bug in one of the architectural modules developed by them. And so forth. Thinking of the system as a graph [workflow], gave me some insights into what could be their potential bottlenecks in terms of process and people.

Solution: Soon I found myself applying Theory of Constraints [TOC] to find the process/people bottleneck in the system. Subsequently, I would discuss this with the team and see what they think can fix the problem. I was consciously trying not to push for certain practices. I wanted the team to own the practices. I could help them figuring it out, but I did not want the one screaming my head off about certain process that did not make any sense to any one.

This is what I call “Just-In-Time practice”. Figure out the problem at hand; pick up a practice that can address the problem in the simplest possible way. You have to carefully craft out the version of the practice that would give you the fastest feedback. In other words, set up the practice so that if it fails, it fails fast.

Example: The team had issues getting a stable release out of door at the end of the sprint. There were lots of last minute surprises to be handled.

After considering the integration process of the team, it was apparent that people were not checking in frequently and it resulted in integration nightmare at the end. So clearly the bottleneck was integration. And Continuous integration was the obvious answer.

But for the real “continuous integration” to work, you need an automated build process; you need all those mighty build servers set up running a full suite of automated tests and so forth.

What is the simplest possible thing that could possibly work?
Manual integration on developers machines before checking in. Relatively easier to achieve.

Once you have manual integration working. If you apply TOC to this workflow, you will find that the manual step on developer‘s machine can be a real bottleneck. Developers might forget checking in some files. Or they might forget running all the tests [mostly manual at this stage] or a zillion other reasons.

The next simplest thing that can possibly work is, have an independent build machine, which can just compile all the code and make sure it does not fail at that step. So now you have automated build working.

Repeatedly applying TOC to this process chain can eventually lead you to the real continuous integration in baby steps. Each step owned by the team.

Conclusion: This way you can apply TOC to identify the issue at hand and then use Just-In-Time practice to address the issue.

I would be interested to hear other people‘s experiences with coaching teams.

Have a look at this video and you will understand.

http://youtube.com/watch?v=t9OoitJcNrA

http://sdtconf.com

Took me 3 months to put together this conference. But with the help of West Chester University and folks from Agile Philly User Group, we finally have everything set for the Simple Design and Testing Conference [SDTConf].

Dates: Oct 27th – 29th 2006
Venue: West Chester University, Philadelphia, PA
Target Audience: Developers, Designers, Architects, DBAs and Testers
Conference fee: Free.

SDT Conf is focused on providing agile practitioners a platform to meet face-to-face and discuss/demonstrate simple design & testing principles/approaches. The conference will use Open Spaces to structure conversation, improve understanding, facilitate brainstorming and help innovate.

This conference is not just limited to discussions; we are also planning an exclusive track for hands-on-sessions. This session will give practitioners a platform to work on some of key design and testing issues.

We are hoping participants would come to this conference with design and testing issues that they are facing day-to-day on their projects. Use this conference to exchange notes on other practitioner‘s approach towards solving similar problems. And, may be we come up with new patterns to address some of those reoccurring problems.

You don‘t have to be practicing XP, Scrum or other agile methodologies to attend this conference. This is about design and testing. Agile practices already address some of the common loop holes in this space, but this conference will try to take it to the next level.

Online registrations are open now. If you plan to attend this conference, please register ASAP, as we have only 75 slots in total.

So far, I have Brian Marick confirmed for the conference. We are hoping to have a few other practitioners to enrich the conference experience.

Look forward to see you there.

Recently I co-presented with Alex Ruiz on Agile User Interface Development at the Agile 2006 conference. Alex presented on Abbot and I gave a demo on Selenium.

The objective of my talk was to show:

1. How to write acceptance tests for Web UIs? The focus was on driving UI development from a functional stand-point using acceptance tests.
2. How to quickly build regression/functional tests for an application with existing UI [legacy code] using Selenium?
3. Last but not the least, to introduce Selenium

For the demo, I used VQWiki as my test application. The wiki is a simple yet powerful application to demonstrate some of the core selenium and acceptance testing fundas. Coz of this, the Wiki turned out to be an interesting application for the demo. I had tests in Selenium core and Selenium remote control. This was sufficient to show the power of Selenium. Finally when I recorded a test scenario using Selenium IDE, the audience went gaga over Selenium.

I‘m hoping to upload the tutorial soon. Till then you can have a look at the presentation here.

Recently I presented an experience report at the Agile 2006 conference on offshore maintenance projects using Agile. Following are the details:

Abstract:
Maintaining a business critical application in production having serious performance and scalability issues can be quite a challenging task in itself. Having a new development team sitting on the other side of the globe can easily complicate things further. This experience report describes the challenges faced in this environment, lessons learned, and how we won the client‘s trust and delivered business value as quickly and consistently as possible.

The existing literature states the following as challenges with distributed/offshore team:

1. Decrease in communication bandwidth
2. Lack of visibility into project status
3. Configuration management
4. Command and Control structure
5. Cultural difference
6. Time difference

The points listed above seem like byproducts of something more important. This paper will present the following root causes and how we handled them:

1. Lack of trust
2. Loss of context, both business and technical
3. Delay in feedback cycle due to increase in distance and time difference
4. Duplication of efforts
5. Change is inevitable

You can download the Offshore Agile Maintenance Presentation from here.