Agile Hong Kong

In the next session we’ll go through the Wine Bar solutions developed by competitors signed up to the Competition Jam. We’ll take a look at what worked well and identify areas that could perhaps be improved. The floor will be open for discussion to allow people to offer suggestions and insights in what they do on their projects.

Without giving too much away, this session will give participants insight into structuring a project so it is easy to maintain, extend and ensure code quality. I will also introduce some technologies and paradigms we haven’t yet explored , in my own solution to the problem with a view to covering them more fully in future sessions. While the focus of this session will be on the code we’ll also have a look at some of the process aspects involved with Agile.

After going through all of this I’ll announce the competition winners.

Prizes for the night will be sponsored by JetBrains.
Pizza will be sponsored by Pinpoint Asia.

When: 7:30pm, Thursday 11h of December 2008
Where: ThoughtWorks Hong Kong Office
Address: Room 1304, 13/F, Tai Tung Building, 8 Fleming Road, Wanchai
Map: ThoughtWorks Hong Kong

On Wednesday evening Jenny Wong did a fantastic job of leading a practical session demonstrating how to build things in an iterative, Agile fashion using Lego. The aim for the evening was to introduce participants to building a Lego product in small, incremental stages using a number of Agile concepts including stories, poker chip planning, iterations and on-site customer with show cases at the end of each iteration.

The group of twenty participants were divided into five groups each with four team members. Each team member was assigned a role: Business Analyst, Developer (two, to allow for pairing) and Quality Assurance (QA). Jenny and I acted as business proxies, deciding on which stories should be developed within an iteration.

The evening was divided into a single release with three iterations of 20 minutes duration each of which was further broken down into the following stages:

• Estimation (3 minutes)
  • Teams estimated how much effort would be needed to develop a particular story. This stage involved the entire team.
• Sign-up (3 minutes)
  • As business proxies, Jenny and I worked with the teams to determine what should be developed within the iteration. This included defects and stories not scoped for development during previous iterations. We also gave teams the opportunity to ask us questions about what should be developed when contradictory requirements were encountered. This stage mainly involved the Business Analysts but was open to developers and QA to listen in and ask clarifying questions. As business proxies Jenny and I used poker chip planning to ensure the functionality requested did not exceed what could be built during the iteration.
• Development (4 minutes)
  • During this stage, the developers set to work, building the Lego animal. The responsibility of the BA at this stage was to ask the business proxies questions when development became difficult due to ambiguity.
• Testing (5 minutes)
  • At this point the QAs tested the finished product to identify any defects giving the developers a chance to fix them.
• Showcase (5 minutes)
  • The final stage of the iteration was the showcase in which the QA and BA worked together with the business proxies to show the product as it had been developed in the iteration. This gave the business proxies a chance to provide direction on the product, to ensure it met expectations.

At the end of the three iterations, five unique Lego animals had been built which were put on display for all to admire.

To finish the evening, we held a retrospective. Ordinarily a retrospective is held at the end of each iteration. Due to time constraints we held a single iteration at the end of the release.  The aim of the retrospective is to gather information from people so they can share their thoughts. In this iteration we asked participants to talk about the following three areas:

• What we have done well
• What we should have done differently
• Puzzles, questions, ideas

The following came out of the retrospective.

What we have done well

• Prefers to be a developer, enjoyed playing with Lego.
• Business value was useful for development team, because usually do not see this. We can focus on most important stories.
• Knowing previous velocity helps plan for next iteration.
• Asking leading questions that help answer questions for the team.
• Push back on customer.
• Mileage out of prebuilt components.
• Throwing out low-value stories.
• Velocity went up during the second and third iterations.

What we should have done differently

• Customer feedback sucked: on-site business.
• Ask business questions before the end of iteration.
• View all stories at the start of iteration one.
• Not enough time spent with the business.
• More estimation points, not just 1, 2, 3 extend to include 5 and 8
• Testing: acceptance criteria unknown
• Non functional requirements not known until testing/showcase
• Should have revisited estimations
• Additional story points implemented was not appreciated; rather it was expected
• QA to test during development
• We didn’t do pair development
• Stories were out of order
• Not all teams had Lego wheels
• Over-engineering once an idea had been considered
• Assumptions were made about stories

Puzzles, questions, ideas

• Is it better to have a lower velocity?
• What was the project name?
• Does a BA provide insight to developers during development?
• Can one team act as a business representative for another team?

I’d like to thank everyone that came along and made the evening a fun and energetic event. Thanks also go to Jenny for running the event and to Pinpoint Asia for their sponsorship of the pizza. Thanks go to Vince Natteri for making a formal introduction of Pinpoint Asia to Agile Hong Kong.

It is with great pleasure that I introduce Pinpoint Asia as a new sponsor of Agile Hong Kong. A specialist IT recruitment firm, Pinpoint Asia recruits talented, experienced technologists for permanent and contract roles across the Financial Services, Technology, Legal, Logistics, Commerce and Government business sectors. Pinpoint Asia’s reach covers the Asia Pacific region including Hong Kong, Tokyo, Singapore, Shanghai, Beijing and Seoul.

I would like to thank Pinpoint Asia, in particular Andrew Lee the founding Managing Director for sponsoring Agile Hong Kong. It is because of the generous support of our sponsor offer that we are able to enjoy prizes and refreshments at each meeting.

When was the last time you played with Lego? How about Lego and Agile together? This could be your chance… In our next Agile session Jenny Wong and I will lead a session whose goal is to give a hands on introduction to iterative Agile development with…Lego! This will give participants hands on experience to Estimation, Signup, Development, Showcasing and Retrospectives.

Delivering business value, welcoming requirements change, frequently delivering working software and continual self-assesment are some of the Agile Principles as described in the Agile Manifesto. Jenny and I will demonstrate how these guiding principles can be achieved using Lego as a metaphor for programming languages to build a simple project Agile style. Lego, which has a low associated learning cost, is an ideal tool for us to use to give a hands on demonstration that focuses on learning the above listed concepts.

It doesn’t matter if you are a Developer, BA, IM or PM you will be able to participate. The aim is to give participants exposure to each of the stages listed above, something people don’t ordinarily gain day-to-day in their projects. In Agile projects it is important that team members understand what others do and how they, as an individual interact, with other individuals to achieve the common Agile Manifesto Principles.

The mini-Jenny and mini-Conrad were created using Chris Doyle’s super awesome Lego character creator: Mini-Mizer

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

Let’s get together and share at the first Open Everything Hong Kong 2008!

Open Everything is a gathering of people interested in sharing their ideas on topics they are passionate about. Unlike other events, Open Everything does not focus solely on technology. Indeed technology may comprise part of the event, however the aim of Open Everything is for people to share ideas on things that matter to them - whatever that may be. Openness is the goal, collaboration is the approach. As it’s name suggests, Open Everything is open to all - the more diverse the group of attendees the greater opportunity for people to open up and share their ideas.

Registration for Open Everything Hong Kong is between 9am and 10am on Saturday the 6th of December. The event itself commences at 10am sharp. The first presentation will be given by a guest speaker after which the floor is open for participants to get in and contribute.

Open Everything Hong Kong 2008 is the first of three Open Everything sister events for the day. Upon close, Open Everything Hong Kong will hand over via video link to sister event Open Everything Berlin which, in turn, will hand over to the third and final sister event, Open Everything Madison, Wisconsin in the US.

For more information including timetable, venue and other logistical information please refer to the Open Everything Hong Kong 2008 website. Please ensure you register so the organiser has an idea of numbers and so they can contact you in case something changes.

It’s going to be fun, collaborative, educational and competitively friendly…

I’m inviting all Agile Hong Kong developers to enter in what is designed to be a friendly competition whose aim is to give people the chance to show off their Agile Software development and Extreme Programming skills. You’ll be given around a month to complete the sample programming exercise. At the end of the competition time, the winners will be announced and we’ll look at some of the solutions to see how the problem was solved.

So, what’s the problem?

Your client owns a wine bar and is looking to replace her existing cash register with a point of sales system. Her vision for the system is that it will keep track of inventory, money collected throughout trading hours and generate reports. Her motivation is driven by demand as she is about to expand her business. She is looking to prepare the business in time for its expansion.

Your client wants an initial software release in one months time, followed by a second release a month after that, to coincide with the expansion. At the end of the first release there will only be a single sales system. With the expansion, however the bar will have a total of three bar areas, each bar having two point of sales systems.

In scope for the first release will be the inventory tracking and order taking components of the system.

• Before the initial order is taken, the bar staff open an account for the customer, identified by table number.
• When entering a drinks order, the staff select the table, choose the drink and the quantity. The quantity of drinks for that item, within the system, is deducted accordingly.
• When a staff member orders a drink that will deplete stock, they will be informed, including the current level of stocks remaining.
• When a staff member places an order that will reduce stock levels below zero, the order is immediately rejected. The staff member is informed with a message saying how much stock is remaining.
• A customer may make as many orders as they wish.
• When the customer wants the bill, a staff member will enter the table number and print it out for them.
• When the customer pays, a staff member will enter the amount of money received and deduct that from the account. The account for that table will then be closed. The amount of change owed to the customer will be displayed. No receipt is issued.
• If the amount entered is insufficient, the staff member will be notified and the account will remain open.
• In order to make way for other functionality, your client is happy to initialise the system with current stock levels when it starts up. She is looking for guidance from the developers as to the best way of doing this but expects to be able to specify the name of a drink, the number of units in stock, and its price.
• When a staff member enters an order for a table that does not currently have an open account, the staff member should be notified with an error message telling them so.

What’s the prize?

Thanks to our sponsor JetBrains, there are two prizes up for grabs. The two winners will receive one license to one of the following JetBrains products:

• IntelliJ IDEA Personal
• ReSharper Personal
• TeamCity Build Agent
• dotTrace Personal

Timelines

• The competition opens…now…
• The final submission date will be Tuesday 9th of December 2008
• The prize night will be Thursday the 11th of December 2008

How to enter?

• Entry is open to all interested people, though I would prefer entries from those that can attend the competition prize night. If you can’t make it or are unsure if you can, please enter anyway, this is a friendly competition, you can still win.
• Register your interest to enter by emailing me directly at . This will give me the opportunity to get in touch with you to inform you of updates.
• If something is unclear please let me know so I can clarify for you.
• Make sure you submit your solution by the due date.

What should you submit?

Submissions will be via email. Once you have completed your solution please email a ZIP file to me on the address:

I can’t tell you exactly what I’m after in the solution…I don’t want to hinder your creative thoughts, so the following list is to be considered as a set of hints and guidelines and is definitely incomplete:

• Neat, well factored code.
• Evidence of eXtreme Programming.
• Code and any supporting artifacts. I don’t need compiled binaries.
• An automated build will be desirable.
• Any stories you came up with.
• Anything that shows how you applied Agile techniques, e.g. Stories.

The rules!

As much as I don’t like to impose them they are necessary. Sorry! I’ll keep them clean and clear.

1. Have fun!
2. I’ll be judging the submissions and won’t have time to argue about the solution once it’s submitted. If you think there is a flaw in the problem or something doesn’t make sense please contact me and I’ll distribute any updates to all entrants (so please be sure you email me to register your intent to compete).
3. You may submit a solution to the problem in the language of your choice, just remember, though that different languages have different levels of support for Agile and XP. You may use any technologies you see appropriate to solve the problem. Sometimes though, less is more.
4. You may work in pairs and collaborate with others, however, if you win you will still only receive a single prize for the submission.
5. You may make multiple submissions but only stand to win once.
6. Ideally you will attend the prize night (11th of December 2008) if you enter the competition. You can still win if you don’t attend, but I’d prefer it if you could be there so we can discuss your solution with you.
7. The solution remains yours. I may however, ask for your permission to post your solution on the Agile Hong Kong website - but you’ll be under no obligation to do so.
8.  You must submit your solution by the due date.
9. I want to encourage as many people as are interested in participating. Solutions that are publicly demonstrated will only be constructively critiqued.
10. I don’t want to see copied or duplicated solutions. So please, don’t do this.
11. The judge (that’s me) is not eligible to compete. However, I will solve the problem to offer my own insights into the solution.

Good luck and have fun!!!

On recent travels through Asia, Steve Freeman stopped by and shared his thoughts and experiences with self organising teams and people. In his presentation Steve introduced a number of concepts, drawing on the Agile Manifesto and also had the group engage in some practical exercises related to teamwork.

Steve introduced a number of people in his discussion, quoting from Deming, Cockburn and Snowden. When making decisions that affect a team it is important to be inclusive. Deming was quoted as saying that the people closest to the work should make the decision. In doing so you will have a team that is more likely to adopt the new direction. Cockburn adds that a project needs just enough process and detail, too much of these and the project will suffer. According to Snowden then, it’s important to pay attention to the feedback loop to understand whether the corrective measures taken by a team are working and where they can be further refined. Steve spoke of the concept of Forming, Storming, Norming and Performing first introduced in a short article in 1965 by Bruce Tuckman entitled Developmental sequence in small groups’ (PDF).

Steve introduced Ralph Stacey’s Agreement & Certainty Matrix. This is a model used to help determine the actions that should be taken in a complex environment using two criteria: degree of certainty against level of agreement. This matrix has a number of applications. It can be used to determine the balance between leadership and management, helping make decisions by aiding in their understanding and to communicate and justify a certain direction. Related is the Cynefin framework developed by Snowden and colleagues while working at IBM’s Institute of Knowledge Management. Like Stacey’s model, this framework is also used to help people make decisions based on complex data. In this context, Steve asked attendees to talk in pairs about a recent project they’ve worked on where there were difficulties, paying particular attention to the politics and religion that was at play on that project. He then asked each pair to identify where they fit within the two models mentioned.

For those interested, a summary of Steve’s presentation has been compiled by Steven Mak on InfoQ China. This summary is in simplified Chinese.

One of the principles in the Agile Manifesto is “People over Process”, because a culture where teams can take initiatives to succeed is more productive than one which is mainly concerned with protected teams from failure. The promise of self-Organising Teams is that they’re effective because because the people who are closest to the work know best what to do and are most motivated to do a good job. No-one, however, promised that this is easy. Just telling an inexperienced team to Self-Organise is no guarantee of success.

In this talk, Steve will discuss his experiences with Self-Organising teams, and present some of the leading-edge results from Social Complexity science that will help you understand the dynamics of your team and how it can work together.

Steve Freeman is a pioneer of Agile software development in the UK, where he writes software and coaches teams in a variety of industries. Steve has trained and consulted for teams in Europe, America, and Asia, and co-authored the JMock library. Previously, he has worked in software houses, consultancies, and research labs, earned a PhD from the University of Cambridge, and written shrink-wrap software. Steve has also taught at University College London. He is a presenter and organiser at the major international industry conferences, and was  conference chair for the first London XpDay. Steve was also winner of the Agile Alliance Gordon Pask award 2006.

http://www.m3p.co.uk/blog

(Thank you to Steve for preparing the above abstract).

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

I’m very excited to announce JetBrains as a new sponsor of Agile Hong Kong. JetBrains are best known for their excellent commercial IDE products IntelliJ IDEA for Java and ReSharper for C#. They are also known for TeamCity, their Continuous Integration server and for dotTrace, a memory and performance profiler for .NET.

Both IntelliJ IDEA and ReSharper have built in support for some XP practices such as automated refactorings, test driven development and automated build scripts. They are also responsible for building other quality products which you can read about here.

JetBrains have generously offered support by including Agile Hong Kong in the JetBrains User Group Giveaway program. Included in this giveaway program are licenses for the following products:

• IntelliJ IDEA Personal
• ReSharper Personal
• TeamCity Build Agent
• dotTrace Personal

I would like to thank JetBrains for supporting Agile Hong Kong. Expect to see giveaways of licenses for these products at code jams and as a thank you to speakers.

On Thursday we took a further look at automated testing. A couple of months ago we had a Code Jam focused on Continuous Integration, in that session we looked at automating the build as a whole, including running tests. In our last Code Jam, we paid greater attention to testing and automating those parts of a system that rely on external or difficult to configure components.

In the session we looked at the differences between state based testing and interaction based testing including the pro’s and con’s of the two approaches. We identified why mock based testing makes unit testing easier and discussed the layering that tends to occur when using mock based approaches. Shen Tham drew an excellent comparison between stubs and mocks, briefly discussing the concept of Inversion of Control (IOC) and how it applies to mocking (this is something we’ll look at more closely in a future Code Jam). Aaron Farr also showed us how he uses mocks when testing the Model View Presenter pattern.

A reasonably simple example was used to demonstrate the use of Mockito. The example is a simple but incomplete graphing application that shows how data retrieved from a feed can be provided to something that can render it. The intent is to show how the various components can be split from each other in such a way that they an be unit tested separately from any live system that needs to be configured. If you take a look at the code you will see that the data used in the graph can be sourced from any appropriate system such as databases, file systems, FTP and HTTP. Likewise, it should be easy to see that the data can easily be displayed in a variety of ways. It can be written to a stream (as per the example code), written to file, sent to a browser via HTTP, published to an FTP server as a file, the options are open. It should be obvious that the feed and display are independent provided the common application interfaces are adhered to. While the mocking and stubbing techniques don’t enforce this, they certainly make help make it easier.

We looked specifically at the following Open Source Java mocking frameworks:

• Mockito (used in the sample example code)
• EasyMock
• JMock 

For other languages you might want to have a look at the following tools:

• .NET: Rhino Mock, moq
• C: CMock - (ruby based) mock tools for C and Test Driven Development in Embedded Software
  
• Python: Mock, PyMock, pMock, pymox, Python Mocker
  
• PHP: SimpleTest

For further reading on Mocking I suggest the following:

• Mock Objects
• Mocks Aren’t Stubs
• State-based vs. Interaction-based Unit Testing

In closing it is important to understand that an emphasis has been placed on testing at the unit level using mocks and stubs. There are many reasons for doing this. One must remember that unit testing alone is not sufficient to ensure complete and reliable integration with 3rd party systems. For this we must still write automated integration tests.  However, these tests can be isolated in such a way that they are only executed by the continuous integration environment if they take too long to execute on a developer machine. Unit tests written with mocks and stubs are therefore not a replacement for integration or functional tests.

Many thank to Kalun Wong for his summary of the evening’s activities.