Announcing: BarCamp Hong Kong 2008

Posted by Conrad Benham on August 28, 2008

Agile, Ajax, Apple, Artificial Intelligence, Aspect Oriented Programming, Big Visible Charts, Blogging, Business Analysis, C, C#, C++, CSS, Continuous Integration, Databases, Design Patterns, Domain Driven Design, Entrepreneurialism, Expert Systems, HTML, Haskell, Innovation, Iterative Development, Java, Leadership, Linux, Mashups, Mobile Development, Open Source, Pair Programming, Project Management, Retrospectives, Ruby, Scala, Social Software, Stand Ups, Start Ups, Web 2.0, Web Design, Web Services, Windows, XP…

These are just some of the things you might consider presenting at BarCamp Hong Kong 2008 on September 6 2008. With the hordes that are expected this year, the “unconference” promises to be a very lively and fun-filled day in which you will get to share your ideas and hear the ideas of others’ and make new friends. Like last year, the BarCamp will focus on IT related topics. Participation doesn’t mean you have to present as anyone can attend any event, though if you have something you’d like to share, you should certainly consider presenting.

Still not sure? Check out what some people said about last years event:

Want to know more about BarCamp in general?

Don’t forget your laptop and charger, Wifi will be provided and some of the presentation rooms even have projectors for live demonstrations.

For more information check the BarCamp Hong Kong 2008 website.

See you there!

BarCamp Hong Kong 2008 was not organised by Agile Hong Kong.

Control Chaos with Scrum 9

Posted by Conrad Benham on August 17, 2008

On Tuesday, Aaron Farr of JadeTower gave a very entertaining and informative overview of Scrum. Drawing on experience gained from working in Scrum teams at Siemens, Aaron was able to provide a thorough insight into the process.

Aaron opened by discussing how Scrum is a lightweight process that manages the chaos associated with building software. This chaos is controlled by providing guidelines designed to limit the impact. Various roles are necessary to enable this including a Product Owner, Scrum Master and Scrum Team.

Scrum is an iterative style of development where certain pieces of functionality are delivered in a fixed period of time known as Sprints. Aaron introduced the notion of a Product Backlog which is held in user stories and can be estimated and prioritised. The product backlog is defined during the planning meeting that occurs prior to the commencement of a sprint. The sprint runway was also discussed which clearly defines work that is to be complete.

Some interesting questions were raised as to how stories should be estimated. The two concepts are intuitive hours and the somewhat abstract idea of story points. Either way story estimates help determine velocity which can be used to create burndown charts.

Aaron ended the evening with a highly interactive session in which he demonstrated the creation of stories that were subsequently estimated. In this entertaining session he asked for input from people to determine the relative size of each story. That is, the size of each story in comparison to other stories that were estimated. The first story chosen was used as a baseline to estimate the size of subsequent stories.

Aaron has kindly put his slides on Slideshare. He also suggested people refer to the Scrum Checklists on InfoQ for more information in the way of mini-books about Scrum. Aaron also made reference during his presentation to the page You Aren’t Gonna Need It hosted on C2.

Scrum: Agile for Everyone

Posted by Conrad Benham on August 04, 2008

Need an agile, iterative process that still gives you the flexibility to code software in a way that works for you and your team? Scrum may be the answer. Focusing on larger issues of workflow and project management, Scrum provides a framework to tame the chaos of software development. Many other agile (and non-agile) methods can work hand-in-hand with Scrum, making it an excellent first step to transitioning to a more agile workplace.

J Aaron Farr is an experienced scrum practitioner and previously helped assist and train an enterprise development team at Siemens Medical Systems in the ways of agile software development. In this session, Aaron will introduce Scrum and share some practical lessons learned.

When: 7:30pm, Tuesday 12th of August 2008
Where: ThoughtWorks Hong Kong Office
Address: Room 1304, 13/F, Tai Tung Building, 8 Fleming Road, Wanchai
Map: ThoughtWorks Hong Kong
Contact

Practical Builds using Hudson 1

Posted by Conrad Benham on August 04, 2008

Our last Jam was both theoretical and practical. In the theoretical part we looked at what makes a quality build system. The practical part took some of the theoretical concepts and applied them, focusing specifically on continuous integration using Hudson. We also played around with some of the tools typically used in Java projects to aid in the project quality.

In the current context a build system is something that automates the static checking, compilation and running of automated tests (unit, integration and functional) against production code. If the build system has been carefully designed it may also include a process to manage the upgrade of a database and also create deployable artifacts (of course a build system may do more or less of the activities described). A facility to deploy these artifacts to various environments may also be included, though this is increasingly being handled by the continuous integration environments as they mature.

While the choice of tool used to automate the tasks mentioned above does not really matter, there are choices that will make the job easier. Some in the industry argue that the XML approach offered by tools such as Ant is cumbersome and not as powerful as new approaches that are offered by tools such as Rake or the Groovy Ant Task the script is actually written in code. Certainly the thing that must be avoided is starting a project using plugins that are offered by IDE’s to build certain parts of a system. Doing this tends to lock the building of a project into the IDE which makes the task automation impossible (unless of course if the IDE plugin has a scriptable equivalent). Over time it can become increasingly difficult to release the dependency on the IDE plugins. The aim is to create an automated build system that can be invoked by an external agent (a continuous integration tool or a developer) and not require any further intervention.

Simplicity is key! An easy to use build system will not require the definition of properties before it can be executed on a developer machine. For efficiency it should be possible for a developer to check a code base out of a repository and be able to invoke the build system on it (provided the requisite build tool has been installed correctly).

One goal of a build system is to make it fast, so it is painless and easy for a developer to run a  full build prior to checking code changes into the code repository. The pain comes when the build is slow to complete. In such a scenario it is worth optimising the system (code or build system itself) so it executes faster. Sometimes the pain can be transferred to the continuous integration tool. This implies that a different build task or target may actually be invoked by the continuous integration tool. It is common to have a default build that is executed by developers (remember our goal of making it easy for developers to get up and running) which runs a good portion of the build omitting that which is slow. The slow parts can be transferred to the continuous integration version of the build.

We also looked at failing fast. It is important to ensure that those things that run quickly do so early so they can also fail early. For example, static code analysis tools that check for duplicate code should be run first as they are generally quicker to execute than a compiler or automated tests and therefore save time by failing early and fast.

In the practical component of the evening we used Hudson to integrate a solution to the Anagrams problem that we solved in the first Code Jam. That solution was hosted on GoogleCode and can be found here. It is also the same as the solution posted in the first Code Jam. The aim of the practical component was to install and configure Hudson, understanding the capabilities of what it and tools like it can do. We then modified the build file that came with the project to add checks to it. We also looked at a number of tools that are commonly used in Java build systems. All of the tools we looked at are open source:

So how does a build system affect the agility of a project? A quality build system will help verify the quality of a system. Beyond that it aids in the concept of frequent releases (one goal of Agile) by making the artifacts required for deployment easy to create and obtain. Even deploying them in some cases.

Build Jamming

Posted by Conrad Benham on July 23, 2008

Builds are a fundamental part of any project. They are the bedrock of a project. Done well they make development and maintenance of a project easier. Done poorly and they can increase the time it takes to develop and maintain a project and even make development difficult. A well structured build will even help reduce defects by making continuous integration easier and by ensuring tests are run during each integration cycle. A good build will also aid in the deployment of a system.

In our next Jam we’ll look at build systems. Identify what makes a good build system, looking at how they might be structured for best practice. We’ll also look at various tools that support builds. Specifically we’ll look at tools that support continuous integration, prevent code duplication, bug detection and style checking amongst other tools. This Jam will include both a theoretical and a practical part. Some of the practices introduced in this session will form the basis to some future code jams.

So, dust your laptops off and come along. If you don’t have a laptop (or it doesn’t work) then come along anyway, we’ll work in pairs so there should be every opportunity for you to team up with someone. Don’t forget your laptop charger!

Drinks will be provided.

When: 7:30pm, Tuesday 29th of July 2008
Where: ThoughtWorks Hong Kong Office
Address: Room 1304, 13/F, Tai Tung Building, 8 Fleming Road, Wanchai
Map: ThoughtWorks Hong Kong
Contact

CI is a Software Development Practice 2

Posted by Conrad Benham on July 21, 2008

A big thank you to Chris Stevenson for giving an “Introduction to Continuous Integration with a brief introduction to Cruise Control”. Chris works for ThoughtWorks. He has worked in many of the offices, most recently in Beijing and is en route to San Francisco where he will be lead developer of Cruise Control Enterprise.

Chris presented a solid introduction to continuous integration (CI) citing Martin Fowler’s work on CI. According to Chris, CI is about ensuring we have working, compiling code that passes unit tests. While many consider CI to be a tool, Chris made it clear that CI is actually a software development practice that is often supported by a tool, but does not have to be. As a result CI is a practice that is used by the team. Automated CI tools are important on projects that have larger teams. CI is the practice of continually integrating code changes made by members of a team with the code base, ensuring these changes don’t break the build in any way. This is verified by running an automated build (as distinguished from a CI tool) that compiles, tests and creates deployable artifacts.

Automated builds must include automated tests: both unit and behavioural tests. Chris introduced the practice of behaviour driven development (BDD), with specific reference to the tools RSpec (for Ruby) and JBehave (for Java). Chris also introduced a number of tools used for user interface testing: Selenium, WebTest, Sahi, Frankenstein, White, Abbot.

Chris spoke of the importance of small continuous commits to the code base. Small changes limit the amount of merge conflicts that occur when checking code into source code control systems and therefore minimising the pain that is associated with conflicts. It is therefore common for people to check code in many times a day. Chris highlighted the importance of a short build, discussing the implications of a build that takes a long time to complete.

Chris ended his presentation with a sneak preview of Cruise Control Enterprise which is to be released in the next week or so.

Interestingly, Eric Minick recently wrote a blog entitled “Continuous Integration: Was Fowler Wrong?“. Eric’s premise is that CI is about tests, not builds. Given the controversial nature of this, a discussion has commenced on The ServerSide.

A Code Jam will be announced in the next day or so which will provide a practical introduction to Continuous Integration tools and how to use them. So, stay tuned…

Continuous Integration with Chris Stevenson 3

Posted by Conrad Benham on July 09, 2008

Core to any serious software project is the build environment and source code repository. When developers write code they must check that code into a source code repository that allows developers to share their code changes with other developers on the project. But how can one be sure that changes checked in by one developer will work with changes introduced by another developer? The key development practice used to support this is Continuous Integration (CI). Integrating small changes often leads to a system that is always in a working state. Tools have been developed over the years to support this practice.

To talk about CI, we have Chris Stevenson. Chris is a senior Agile dude at ThoughtWorks who has worked on many different projects employing CI successfully. He will discuss what the practice of CI is and why an organisation serious about software quality should adopt it. Specifically, Chris will talk about the team dynamic required to adopt CI covering how it should be used and what to do when things go wrong. Topics will include the cost benefit of introducing a CI environment to an existing build process. He will also give a demonstration of tools supporting CI the practice of using Cruise Control.

When: 7:30pm, Tuesday 15th of July 2008
Where: ThoughtWorks Hong Kong Office
Address: Room 1304, 13/F, Tai Tung Building, 8 Fleming Road, Wanchai
Map: ThoughtWorks Hong Kong
Contact

Lean Thinking with Richard Durnall 1

Posted by Conrad Benham on July 06, 2008

At our last gathering, guest speaker Richard Durnall gave a very interesting presentation on Lean Thinking in IT. In his presentation, Richard covered a large spectrum of the Lean Thinking space. From a solid background of applying Lean in the Automotive industry (where Lean grew from) Richard spoke with authority on the history of Lean and its application. He then drew from that experience to explain how Lean thinking can be applied in IT.

Lean Manufacturing has had a major influence from Japan where Toyota used it to great effect. This influence means that many Japanese words can be found in Lean to describe various components of it. One of those words, muda, for example is used to describe waste. Another word, jidoka, as Richard explained it, is about autonomation or automation with a human touch. It focuses on introducing technology to people in a structured and considered manner such that those people will adopt the technology being built for them. A system that is built that dismisses jidoka could be considered muda, particularly if the users it is built for do not adopt it.

Amongst the topics presented, he spoke briefly on the differences between Agile and Lean. In a recent blog post, Richard compares Agile and Lean. Martin Fowler has also weighed into the conversation with his own ideas.

Richard also made reference to a couple of books during his presentation:
•    Learning to See by John Shook
•    The Toyota Way by Jeffrey Liker

I’d like to thank Richard for presenting at our last meeting and for making his presentation available, which can be found in PDF form. I want to wish him well on the rest of his world tour in which he will continue to present on Lean Thinking.

Lean Thinking

Posted by Conrad Benham on June 10, 2008

For our next meeting we have guest speaker Richard Durnall who will talk about Lean Thinking and how it is applied in the IT industry. Richard is considered an expert in the field of Lean Thinking in IT, having worked closely with other Lean experts. He began his Lean experience in the Car Manufacturing industry (where Lean originated) working for Ford. Presently, Richard works as a Principal Consultant for ThoughtWorks, applying and coaching Lean at the clients to which he consults.

Richard, a very energetic and entertaining speaker is presently on tour, talking about Lean at a number of places around the world. Don’t miss out on what will be a very insightful and educational evening.

Rather than reinventing the wheel I refer you to the following information on Lean Thinking:

For more information on Richard, please visit his website.

When: 7:30pm, Tuesday 17th of June 2008
Where: ThoughtWorks Hong Kong Office
Address: Room 1304, 13/F, Tai Tung Building, 8 Fleming Road, Wanchai
Map: ThoughtWorks Hong Kong
Contact

Does Agile work for you?

Posted by Conrad Benham on May 14, 2008

Thank you to all who came along to the presentation held this evening entitled “Will Agile work for you?”. While the question was never directly answered I hope I was able to provide some insight into what an Agile environment should be like.

I covered a number of aspects on Agile environments including, Team Composition, Team Empowerment, Technical Passion vs Domain Experts, Continuous Improvement, Agile Leadership, Bonuses and Management. Some very interesting questions were raised during and after the presentation. One of the questions was about introducing fresh graduates into an Agile environment. A challenging question was raised around the approach to introducing Agile into an environment that does not readily accept new approaches. This led into a vibrant and interesting group discussion on the topic that explored some fascinating areas. All in all it was an energetic and enjoyable evening.

Our next presentation evening, which needs confirmation, will be announced soon. You can expect the next meeting to be in late June. The next Code Jam is on Monday the 19th of May.