The Agile Tour Bangkok 2012 initiated by the Agile66 community could be count as the biggest public agile event (that I know of) ever held in Thailand. It is quite an interesting time of agile movement here. Most of the big companies still stick to the traditional way of building software but the agile practices are certainly in their radar. The conference makes me feel like the agile movement here is gaining more traction and support. The event is well organized and the overall atmosphere looks professional. This blog is not a summarization of the content in the event but rather a list of what I like or have learned from the speakers.

First of all, I am really impressed with the venue (LaunchPad). It is not large but modern and comfortable. The fact that it is not too big plays a part in keeping attendees close together encouraging more interactions.

Here are the random things in the event that I want to talk about.

Individual human dynamic is the key factor

The keynote session is “Enterprise Agile Adoption Stories” by Amr Elssamadisy. Amr told the story of some selective projects he has involved to explain how various characteristics of projects and teams could determine the success of the product. For example, a team adopted just the technical practices of Agile like TDD or code refactoring. They could deliver the working product but it turned out not to be right one for users since the team didn’t have a constant feedback loop with end customers. Another team adopted the iterative approach and regularly communicated with end users but chose to ignore the technical practices. They were building the right software for users but the code base got messy and gradually caused problems since they didn’t pay attention to refactoring.

Amr made a really interesting point that it was not about the methods or practices. I didn’t write down his exact words so I am going to summarize his point here according to my understanding. There are many good products built with practices other than agile and there are many bad products built from agile teams. So, it is not like agile will automatically imply better outcome.

It is the “Individual human dynamic” that matter the most. The personal skills of each team members play a crucial part in driving the success of the team. The teams with the culture of blaming or having problem in taking ownership of obstacles will likely to fail no matter what software practices there are using.

The hero

Amr gave an example of a team full with star developers. These top-notch developers had their own special ways in doing things. Sometimes they just did whatever they thought it was the best thing to do from their perspective and ignored the effect to other parties like QA for example. The end result of the project was not so good, of course.

The interesting is that Amr said the problem of too much hero behavior rarely exist without the leadership support; the management played a part in encouraging this to happen. The attitude of management is one of the crucial factors in shaping the culture of the team.

Working product in every sprint

The second session I attended was “The importance of Agile Analysis techniques and story writing” by Shaun Jayaraj. One of the main points he made was about evolving the system incrementally and producing the working product in every sprint. I like his two examples showing the benefit of this iterative approach.

Gradually add business value – Shaun told a story about a web project of a well known brand. The first iteration produced nothing more than the first page with brand image along with a contact number. The team went ahead and put the page on production. The page didn’t have any functionality but contained business value. Customers saw the page and knew the brand was cooking up something. The contact number was the easiest way for the eager customers to get more information. In the next iteration, the team digitized some existing brochures of the brand and put them on the page to let customers know more about what they were selling. And it went on like this.

Always usable product – In agile, the system should always be in the usable state. A new functionality will be added on top of the already working functionality. This will make it easier to manage the scope of the system. Working product without the complete list of functionalities is still capable of deliver some business value to customers. Shaun gave an example of a banking project he has involved. The project got cancelled after the team has developed the product for a period of time. At the time, the product was already able to do more that the existing system so they decided to go live with the unfinished but usable product. Isn’t that amazing?

Delivering a project is more than just writing software

Micheal Chen talked about how CMMI and Agile actually complement each other in delivering a project. What I like in the talk is not about CMMI with Agile but rather the point he made that software itself was not the whole picture. Completely delivering a project need some other non-coding tasks and involve many parties outside development team.

It took me years of my working life to realize the important of looking at the big picture. The quality of code base is the core of software development but it certainly needs other factors for the project to be success. A great deal of attention also needs to be allocated to other non-coding parts like support process, infrastructure maintenance or operation team. I once heard my colleague said he preferred to call his team a “delivering team” instead of “development team” since his team members also handled many tasks to address problem outside development area. Developers need to be aware that those not-so-fun stuffs like creating script for auto deployment or collecting log files are quite necessary for the project to move forward.

Thanks again for the Agile66 community to let us meet and share all the knowledge and perspectives. I am really looking forward to the next agile event from you guys.