When I was standing for the Agile Alliance board election in Aug 2007, in my position statement, I claimed that if I get on the board I want to “connect the dots”. I did not get on the board, but later when I got the Pask Award, I claimed again that, I really want to focus on “connecting the dots”. That would be my theme or vision for the next couple of years.

If you know me, you know that I’m really passionate about building a network of highly skilled, talented and passionate professionals. Personally I have experience the magic of working/collaborating with such folks. It is the knowledge and learning from these folks that has made me what I’m today.

In the Agile community, we have a lot of Agile practitioners who are doing great work. But they all seemed to be scattered all over the place like islands in an ocean. Trying to connect these islands [practitioners] can bring a lot of value in terms of knowledge sharing and identifying innovative idea and concepts. I think Agile Alliance is in great position to do this. So with the help of Agile Alliance I want to build a global community of these folks by bringing them closer and facilitating collaboration between them. Networking them is the first step towards this.

Hence recently I created a group for Agile Alliance on LinkedIn.

Purpose of the group: To connect Agile practitioners. If you are a supporter of Agile Alliance and Agile in general, please join this group.

Many professionals I know, have a linked in account today where they maintain their profile, resume, connections with other professionals, recommendations, etc on LinkedIn. IMHO, I am hoping that this existing informal network will provide a simple way for me to connect the dots and build a network of Agile practitioners who support Agile Alliance. Linkedin has another feature called “Recommendations” which is another way for the community to recommend and certify other practitioners to build a trusted network. Recommendations could be an alternative to “over the counter” certificates.

So if you would like to join this group on LinkedIn click the following link: http://www.linkedin.com/e/gis/37631/0FF74232FB92

I hope joining this group will activate the consciousness of belonging to the Agile community as a network.

On Oct 11 and 12th 2007 I was attending the Agile Alliance Functional Testing Tools visioning workshop. During the workshop we had videotaped the lightning talks and tool demos.

Elisabeth Hendrickson with the help of her husband, Kirk, has uploaded those videos to Google videos. Check it out:

http://video.google.com/videosearch?q=AAFTT&sitesearch=

Agile Software Community of India is organizing half a day workshop on Mock Object, by none other than Steve Freeman himself. This is Steve’s first visit to India and I hope he would like interacting with the geeks out here. If you are interested in attending this workshop, you can find more details about it here : http://agileindia.org/stevefreemanonmockobjects

On Nov 17th and 18th I was running an eXtreme Programming Collective at BarCamp Bangalore V which was held at Indian Institute of Management (IIMB). Overall the conference was well attended. There were over 300 participants. The conference organizers did a great job. Everything went smooth. They were also very supportive and helpful.

Big thanks to Sidu from ThoughtWorks who gave me the idea of running a collective during the conference. Sidu and I sat together and planned out the sessions for the collective.

On 17th, we started off the collective by listing all the topics that people were interested in and then prioritizing them. [Customers state the stories and then they prioritize it ]

It turned out that there were lots of people new to eXtreme Programming and Agile. We had people from varied backgrounds and roles, from game designers to bio-informatics researchers, and from PM’s to Dev’s to QA’s, They wanted to get a quick overview about Agile and XP before we went into the hands-on-sessions. Following is the order in which we decided to address the topics:

1. Agile - Roles, Concepts, and Practices - Aman King gave a very interactive presentation. There were lots of discussions. We starting maintaining a Parking lot if any discussion run over 10 mins. At a point, one of the participants got really annoyed saying everything is going on parking lot.
2. After Aman’s talk, I cleared the topics on Parking lot one by one. We had following topics on the Parking lot:
2.a. How is the role of Scrum Master different from Project Manager’s role
2.b. How do we do release planning in Agile. How do we thin slice the stories such that we take care of dependencies
2.c. What are the different estimation techniques in Agile
2.d. How do we handle Non-functional requirements in Agile? Do we treat them as separate stories or are they part of each story?

This took the whole morning.

In the afternoon:
3. I ran a workshop on Test Driven Development. We had some really interesting conversations. I know for sure that 2 people walked out being convinced that they will try it on their projects. Could not talk to the rest to see what they thought.

That was end of day 1. A long day. Filled with lots of activities and discussions.

Day 2: Sunday, started kind of slow. The plan was to do
4. A Refactoring Fest
5. A Design Fest.
6. Few discussion on Is Design Dead? and Is Enterprise Architecture dead?

But due clashes with other collectives. We could not run the refactoring fest. Instead I ran the TDD workshop again for couple of people who missed it the previous day. There were certainly some Ahhh… moments again.

After lunch, we had a design fest. This had a really good turn out. About 20 people came for this exercise. We split into 3 groups and I gave them the Veterinary Medical Systems problem from OOPSLA 2006’s designfest. The teams had 1 hr 30 mins to come up with an application design for the problem. There was a lot of confusion around what design meant. Are we talking about screen design, database schema design or the object model? Basically I was looking for object model, but I was also fine with a DB schema design.

The teams went off and started designing. Each team took a different approach to design the application. One team quickly looked at different objects and their relationships. They decided that the problem was data-centric and hence they decided to come up with a Database scheme for their design. They did a great job of identifying the different tables and basically walked thru all the use cases explaining how their data-model would handle them.

Another team looked at the basic use cases and ignored the exceptional use cases to start with. They came up with a fairly decent object model. Later they were trying to adapt the same object model and ended up missing a few scenarios. But had a fairly decent object model.

The last team actually split into 2 groups and came up with 2 different design. It was basically one person who came up with a design. His approach was to find out all the methods required by the application and then extract classes from those methods. What he ended up was with one class with all the behavior and a bunch of Value-Objects or data-holders.

The other part of the team, used an approach where they took one use case at a time. For each use case, they built a user-system interaction model. From this they started writing skeleton code with method sequences. Once they had all the methods in place for a given use case, then they pulled them off to different classes. They could not cover all the use cases, but did an impressive job for the given use case. Their guiding principle was to come up with working code fairly quickly.

Again like with any art, there are no universal rights or wrongs. Each design had its advantages and trade-offs. But it was great to see 20 people come up with 4 completely different design using 4 different approaches.

Everyone stayed back till 6:30 and were very interested in discussing more.

From today onwards people will refer to me as TQer instead of a TWer. That’s right. Today, Nov 12th 2007, is my last day at ThoughtWorks. It has been a wonderful 4 years for me at TW. I have learnt a great amount of concepts at TW. Fellow TWers have really helped me refine my values and provided me with a vision which will last with me long after I’m gone.

For the next few months I plan to take off and think about what I would like to do next. In the mean time, I would be focusing on Agile India . I also quite a few open source projects that I need to focus on. This would be a great time to do so.

I’m really looking forward to starting the Uncertification Workshops in India.

#1 If we do TDD, we don’t need QA

TDD, also known as Test Driven Design, is more of a design activity and less of a testing actvity. The word test in it can be very confusing for people. In fact, it is so confusing that some people think, we they do TDD they don’t need QAs. Folks like Dan North, identified this as a problem and coined a new term called BDD or Behavior Driven Development. This makes it clear that the focus is not testing, its expressing behavior. Another important fact to note is TDD is not just about unit level tests. People who do Acceptance Test Driven Development or Story Testing, write a failing Acceptance test and then write just enough code to make the test work. Irrespective of what level you write these “tests” [actually lot of people prefer calling it behavioral specifications or intentions], their primary purpose is to drive development, and is not to critique the product. QA who do exploratory testing and other forms of testing can add a lot of value to the development process.

#2 Agile is about Rapid Software Development

Agile is not about Rapid Software Development.

#3 Agile projects don’t have cost or budget estimated

I wish this was true. Life would have been peaceful. Like any other project [software or not], stakeholders want to know either of these

• How much would the project cost them? [Cost]
• When will the project be completed? [Time]
• What exactly will be delivered? [Scope]

In case of Agile we really like to keep these as levers or knobs that can be varied based on the need. We try and explain to the customer why trying to fix all these upfront, at the point when we have the least amount of info or knowledge is a really bad idea and recipe for failure. As far a estimation goes, there are different techniques available out there. Also we do not believe in a silver-bullet. Depending on your needs you will have to choose a technique.

#4 Agile projects don’t plan. It’s very chaotic and direction-less.

At the heart of Agile is the embracing change mentality. We strongly believe in adapting to change over following a plan. We do see value is plans. But planning for us is not a one time activity, its a continuous activity. We do not deliver to a plan, we plan to deliver. Guess what, no longer we have those big Microsoft project plans or Gantt charts that are followed as Bible. We plan, we adapt, we refine as we go. As more information is available uncertainty reduces. We strongly believe in embrace uncertainty. If you have not read Mary Poppendieck’s Lean Development and The Predictability Paradox paper, its a must read.

#5 Agile projects means No Contracts

The Agile Manifesto says “Customer collaboration over contract negotiation”. Which means, we still need contracts in place, but not at the cost of customer collaboration.

Traditionally contracts have been written purely to project the parties from taking advantage of each other. But unfortunately, over the last few decades, contracts have been used by companies as a shield. Each party tries to push as much risk on to the other party in contract. Which introduces a unique tension when it comes to writing contracts. Hence contracts have earned a really bad reputation over the last few decades.

IMHO, Contracts are not bad and contracts are supposed to help us to ensure we’ve come to a shared understanding of the terms upon which two parties will engage. Although one of the consequences of a contract is the ability to sue, which is known as enforcement, this is not its primary purpose. The primary purpose of a contract is to clarify the obligations of both parties. Most people honor their obligations when those obligations are clear. Having a clear understanding of which party is responsible for what furthers good client relations.

#6 On Agile projects We don’t write documents

Documents are another entity that most people in the software world hate. There are valid reasons behind this hatred. I have been in organization where we were document driven. Document was the only form of communication and document meant everything. We all know the issue with document. Agile emphasis on using richer forms of communication and collaboration. Also I have found a lot of places where people think writing the document finishes their job. Agile emphasizes on working software over comprehensive documentation. We tend to focus on lot of short lived documents/artifacts which does one job well. Also over the last few years, there are quite a few sophisticated tools that let you generate quality document from the code, rather than the other way round. We believe in executable specification over comprehensive word document.

http://www.agilemodeling.com/essays/agileDocumentation.htm is a good read.

#7 Agile teams cannot be distributed

Distributed development sucks in general. But Agile can help. Lots of organizations are finding it helpful to use Agile on distributed projects.

#8 Are there minimum processes to be followed to qualify to be Agile team

People usually tend to get into this argument. Trying to qualify a team as Agile or Waterfall. Basically this argument is a waste of time. We do not achieve anything by having this argument. Agile is certainly not about following a set of practices. Agile is a culture or value system. Hence its difficult to define minimum process/practices. The Agile manifesto can be a good guide if you want to ask this question to yourself. Also doing one or two practices does not make you Agile. Evaluating number of practices to Agile maturity levels is the funniest thing you can hear.

#9 User Stories are same as Use Cases 

This is not true.  There are quite a few differences between the two. Have a look at http://www.mountaingoatsoftware.com/article_view/27-advantages-of-user-stories-for-requirements

 #10 In Agile, we start coding day one

This is not true. At least on the projects I have worked, we never starting coding day one. Again Agile is not about churning out more code. It’s about delivering business value. Agile and XP in particular is accused of “missing the forest for a tree” or “missing the big picture”. This is true to some extent, coz when we talk about XP, people talk about starting with iteration zero and then starting actual development. Sometimes we might need a couple of weeks to understand the existing business processes and understand the overall landscape. Usually I guest a 2 week period to do this, before the iteration zero.  I certainly don’t recommend anything in months for this phase.

#11 My team uses a Agile project management tool, hence we are Agile 

Using a tool does not make one Agile. Sometimes tools can help. And some times tools really get in the way. We refer to them as bloatware. Nor does using JUnit make you do TDD. Remember: “People and interaction OVER processes and tools”. Ironically, in my experience, Agile teams tend to use better tools than other teams. Also there is a lot more rigor and discipline when it comes to process on Agile teams.

Time to time, I keep running into people who think Agile is about rapidly developing software. With all good eXtreme programming practices, we should be able to churn code at a rate never before. Some even claim its faster than some of the model driven code generation approaches. Based on my experience and understanding I think this is a big fat lie. IMHO, people in this camp, clearly don’t get it.

To me, Agile is about Rapid Business Value delivery. It is not about delivery more software, its about delivering more business value. In fact, I would go to the extent saying, in Agile, we resist delivering more software. We constantly try to identify and prioritize highest business value delivering features. In this process, we try to eliminate low priority, low business value features. We strive to provide max value for the buck. This is very different from rapid software development mentality. Where the focus is more software. I actually tell people, that when it comes to software development, I’m a lazy person who want to do the least amount of work and get max ROI on it. Prioritizing, focusing on what the business needs first, delivering the same, taking the feedback from its use and adapting our plan accordingly is a great way to achieve this. Even though I say I’m lazy, this is a lot of work and needs a lot more rigor and discipline. Being Agile really helps me strike this fine balance.

Having said that, clearly Agile can help deliver software faster, coz we eliminate a lot of waste [unwanted features, useless process documents, hand-overs, etc]. But that is not the goal. Its a nice benefit of this approach but not the driving factor.

Now that we agree Agile is not about Rapid software development, why do most [if not all] projects track velocity as the measure for progress? Isn’t velocity just a planning tool, that helps us forecast based on yesterday’s weather? How does it matter that we completed 60 story points or we completed 310 hrs out of 320 estimated hrs? Somehow we don’t seem to be measuring business value delivered?

Having said that, I can think of a couple of reasons why we don’t do that:

• Business value is only delivered when business uses the software and benefits from it. Unfortunately a lot projects’ iteration/sprint boundaries are way earlier than the point at which the software is being used. In fact, a lot of teams end their iterations/sprints with a QA/BA/Customer Sign-off. After this, the features sit on a shelf and wait for few more to accumulate. Finally when a hotchpotch of few more such features accumulate, teams do more testing [performance, usability, insatiability, stress, load, blah..blah..blah]. When all this is fine, they show it to more customers and do a user acceptance test. Finally it goes thru all the jazzy Configuration management steps, it gets packaged and deployed. Plus there is a user training and support training phase also involved. Basically, what I’m trying to highlight is for a lot of folks, the world ends at the iteration/sprint boundary. For some people it might extend to the release boundary. But there is so much that needs to happen once the feature is QA/BA signed-off. Hence when we end the iteration/sprint, there is no way to know if we actually delivered any business value or not. I’m not saying there is not value in this approach. It is a good risk-mitigation and to some extend feedback mechanism compared to the tradition approach. But if we really want to focus on business value and measure that, then we need to be deploying every iteration/sprint. Is this feasible? I don’t know. On one of my projects, our time to production was 3 days. It was possible, coz the system was already in production, had a mature code base, had great test coverage and most importantly we had the customer’s buy-in. It really felt great to get concrete feedback in a week’s time. May be this is possible on all projects, we can at least try. Also don’t forget there is a cost associated with each release, but automation is a great way to reduce the cost and time.
• Business value is a vague concept. Unfortunately there is not easy way to know the actual business value. In fact when I say business value, I really mean estimated business value. We may only know the real business value once the business uses the software. None of my customers could tell me feature A is 30,000 USD and feature B is 20,000 USD. The best the customer could tell me was, I think feature A had more value than feature B. This was helpful for prioritization, but not for measurement. We could not really say if the team was giving ROI at the end of the iteration/sprint. Does that mean we should not bother about business value? I can think of one solution. This problem sounds very much like developer estimation problems. For a given story the developers don’t really know how long it’s going to take to complete the story. For years we tried estimating in real hours. That did not work. Then we tried estimating in Ideal developer days or story points. I don’t know if this works or not, I’m do not believe in this approach. But teams seems to be using this approach. The story point approach is interesting. Developers claim that it is difficult to tell exactly how much effort, but based on their experience they can relatively size stories. They can tell if story A feels as big as story B or it feels bigger than story B and smaller than story C. This way we assign points and then track points. Once the iteration is done, we can do a projection based on all the story points and how long it took to complete x number of story points to get a rough estimate of how long all the stories are going to take. Some people refer to this as a pure estimate. Where they separate the effort from the complexity. Efforts can vary depending on the technology, tool, ton of other reasons, but the complexity remains the same. [I don't quite buy this. But I'm para-phrasing what others claim]. Anyway, that’s not the point. The point is can we use a similar approach for estimating business value? Can the business estimate business value in relative points? Let’s say we call it Business Value Points? Making a big assumption that this is possible, now we could have a way of measuring/tracking how much relative business value is being delivered. We might still not be able to give a concrete Dollar amount, but we could see a trend in team’s performance.

Well I think its worth trying these 2 things, it might take us to something new to explore. But I guess you can see where I’m headed. I’m interested in measuring business value also and not just effort alone.

With the help of folks from ThoughtWorks, I’ll be facilitating the eXtreme programming collective at the 5th Bar Camp in Bangalore.

If you are interested to know what is UnCertification Workshops, you can refer to It’s Diwali season, time to light all your Certificates.

If you are interested in attending, please sign up here: http://barcampbangalore.org/wiki/BCB5_Registrations

Intent

Provide the participants with a hands-on-experience of real world refactoring by taking an open source project and refactoring it.

Summary

Refactoring is a very well established practice not just in the Agile Community, but outside as well. Following are some of the books that have been published on this subject:

• Refactoring: Improving the Design of Existing Code: Martin Fowler
• Refactoring to Patterns: Joshua Kerievsky
• Working Effectively with Legacy Code : Michael Feathers

Unfortunately, in-spite of such great knowledge available, there are lots of misconceptions around refactoring. The word “refactoring” is often used in a broad context where “enhancement” or “rewrite” would be a better term, and can cause nightmares to project stakeholders.

This session is an attempt to help the development community understand refactoring a little better. It will provide a hands-on opportunity for developers to explore these concepts in action. This session will try to amplify the participant’s learning process by pairing them with other practitioners and peers.

Slides

http://www.slideshare.net/nashjain/refactoring-fest

Intended Audience

This session is suited for developers and architects who are interested to learn how to refactor real projects.

Benefits

After attending this session, the participants should be able to:

• Build a common vocabulary in the refactoring space
• Identify code smells
• Eliminate code smells by applying the simple refactoring techniques explained in Martin Fowler‘s “Refactoring”
• Write better unit/functional tests for legacy code
• Understand some of the techniques and pitfalls in refactoring legacy code in the absence of unit and functional tests ["Working effectively with legacy code "]
• Take existing code and refactor it to standard design patterns [Refactoring to patterns]
• Learn about the internals of the open source project chosen to refactor
• Know where to look to continue learning the techniques of refactoring

Content Outline

Section 1 – 90 Minutes

Iteration 0 / Overview : 45 mins

1. 20 mins: Quick overview about refactoring with some examples.
2. 10 mins: High level overview of the open source project‘s design
3. 05 mins: The participants form pairs and each pair picks up a module/package of the open source project.
4. 10 mins: The participants spend time understanding the functionality of the module/package picked up by the individual pairs.

Iteration 1 : 45 mins

1. 10 mins: I’ll show 2-3 simple code smells, explain associated refactoring techniques.
2. 15 mins: Each pair identifies one or more classes from the module/package, which has these code smells. They try and understand what it does, in the process they might do some basic refactorings like extract method and rename variables/methods. Eventually the goal is to writes one or more unit tests around it. Once they have sufficient passing unit tests [safety net], they start cleaning up code by applying some advanced refactoring techniques. In some cases, sufficient unit tests might not be required to do simple refactoring like extract method, rename variable, etc. Sometimes internally restructuring the code, can help us understand it better. Hence the participants will have to constantly switch between ‘understanding’, ‘unit testing’ and ‘refactoring’ hat.
3. 20 mins: The pairs stops refactoring. Couple of pairs connect to a central project and demonstrates their accomplishment to the rest of the group. We can break into a discussion about each team‘s refactorings.

Break – 30 Minutes

Section 2 – 90 Minutes

Iteration 2: 40 mins

1. The pairs swap partners so that each team gets a new member and one old member continues on the selected module/package.
2. 10 mins: I’ll show 2-3 little more complicated code smells and explain associated refactoring techniques.
3. Pairs try to apply these refactoring techniques for the next 15 mins.
4. At the end of 15 mins we have another 15 mins demo and refactoring discussion.

Iteration 3: 40 mins

1. The pairs swap partners again.
2. 10 mins: I’ll show 2-3 more complicated code smells and explain associated refactoring techniques.
3. Pairs try to apply these refactoring techniques for the next 15 mins.
4. At the end of 15 mins we have another 15 mins demo and refactoring discussion.

10 Minutes - Retrospective

• What worked? The participants indicate what they learned.
• What did not work?
• What to do differently next time? Suggestions from participants on how to improve the session.

Infrastructure Required

• U shaped table setup with a projector at the center of the table which can connect to all the computers.
• Either the participant get their own laptops with required software setup or we provide the participants with computers. We’ll need 10-15 computers for the participants. Each computer is set up for a pair [2 chairs]. The presenters will set up the computers with the required software a day in advance of their session.
• 10-15 flip charts, one per team.

Pre-requisites for attending the session

1. Object Oriented Programming
2. Java and Servlets knowledge [don't worry too much about this, pairing can save you]
3. You need the following software setup on your machine before you come:

1. Latest Eclipse IDE for Java Developers
2. Latest Sun JDK
3. Latest Apache Tomcat Web Server
4. Latest Very Quick Wiki

Set up instructions:

1. After downloading, JDK, install it
2. Set the JAVA_HOME env variable is not already set
3. Unzip eclipse and try running eclipse executable [eclipse.exe]
4. Unzip tomcat and try running startup.bat or startup.sh from the bin folder
5. Take the vqwiki war and drop it into tomcat/webapps folder. Depending on the version of vqwiki you have downloaded, there will be a folder created under tomcat/webapps called vqwiki-x.x.x Where x.x.x represents the version number. For the purpose of these set up instructions, please replace x.x.x with your correct version number. Example if you have downloaded vqwiki version 2.7.8, then replace x.x.x with 2.7.8
6. Start your favorite browser and go to [http://localhost:8080/vqwiki-x.x.x] Make sure the vqwiki page shows up
7. Go to tomcat/webapps/vqwiki-x.x.x/WEB-INF/classes folder. Copy all the files expect the vqwiki folder to WEB-INF/src folder
8. In Eclipse, create a new project called vqwiki. While creating the new project select the option “create project from existing source” and point it to the tomcat\webapps\vqwili-x.x.x folder
9. Project would have compile time issues, since it needs the servlet.jar which is under the tomcat/common/lib folder. Add it to the libraries under the Java Build Path tab. Make sure that the code compiles without any problems.
10. If you don’t want to start and stop tomcat from command prompt, there is Sysdeo/SQLI Eclipse Tomcat Launcher plugin for eclipse which can simplify some of those issues. Please note that this is optional.
11. If you want changes to your classes being automatically detected by Tomcat, add the following line to tomcat/conf/server.xml

<Context path=”/vqwiki-x.x.x” reloadable=”true” docBase=”vqwiki-x.x.x” />

Note: Some of you might already have lots of these set up. Use your judgment if you want to skip some steps.

PIN REVERSAL

If you should ever be forced by a robber to withdraw money from an ATM machine, you can notify the police by entering your Pin # in reverse.

For example if your pin number is 1234 then you would put in 4321. The ATM recognizes that your pin number is backwards from the ATM card you placed in the machine.

The machine will still give you the money you requested, but unknown to the robber, the police will be immediately dispatched to help you.

This information was recently broad casted on TV and it states that it is seldom used because people don’t know it exists.

Note: I think this information needs to be confirmed, because snopes.com indicates that this is a false story that has been circulating the Internet since last year:

http://www.snopes.com/business/bank/pinalert.asp