Iteration 1, 2, 3: Lego Animal 2

Posted by Conrad Benham on November 27, 2008

Jenny Requesting StoriesOn 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.

Lego Parade

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.

Pinpoint Asia: new sponsor

Posted by Conrad Benham on November 23, 2008

Pinpoint Asia

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.

Agile Lego Game 3

Posted by Conrad Benham on November 19, 2008

Lego Jenny  Lego Conrad

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
Contact

Open Everything Hong Kong

Posted by Conrad Benham on November 18, 2008

Open Everything Hong Kong 2008Let’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.

Competition Jam 2

Posted by Conrad Benham on November 14, 2008

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:

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 contact.jpg. 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: contact.jpg

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!!!

Steve Freeman on People and Teams

Posted by Conrad Benham on November 09, 2008

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 Freeman

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.