It's been more than a (busy) week since I came back from XP Day Benelux 2009 conference which took place the 23th and 24th of November, in Mechelen. I did not present any session this time, so was free to enjoy whatever session would suits my current mood (and needs!).
It took us nearly 3 hours to drive the 120 km separating Lille from Mechelen. Hence, although we had some margin available starting at 7:30, we arrived very late on Monday morning and missed the introductory session where presenters introduce their session to the attendees.
This session was an experience report from a team who transitioned from plain Scrum to Lean/XP practices. The author started with a team which was implementing Scrum on a rewriting project (from MS to WOA) for a sensitive desktop application targeted at pharmacists. The team had troubles: low throughput, bad quality, yet people were working hard, with long overnights and much pressure.
First actions were targeted at the team's working environment and process, to reduce & regulate pressure on the team, which otherwise lead to dysfunctional behavior, by installing a strong, visible and constraining process:
The author then talked about motivation: themes are used to group stories together, which are then planned and worked on together, giving a common goal to achieve. Pairing seems to be used as a way to reduce the bus-factor of the team, but not systematically (?).
The architecture was found to be counterproductive, getting in the path of implementing/adding features: It was needed to touch more than 20 files to implement a single feature, which is a sure sign of troubles. There seems to be a tension between conceptual integrity and flexibility which is not easily solved. The solution was to work on features horizontally (traversing all the layers at each increment), in the spirit of dimensional planning.
Testing was another bottleneck. By reversing the test & code phase (ie. automated test comes before coding, which is followed by smaller manual testing), they managed to make the test fix the cadence of the flow which in the end yielded better through put: Keep feedback very short to ensure knowledge flow through all the phases
Retrospectives were done just-in-time, when deviations from the expected process and figures were found.
Some key retrospective insights:
This a session about a game designed by Gino Marckx on the GTD and Quadrants of Effectiveness time-management method by David Allen. Each player has 5 cards reprensenting actions in hand. Each card can have a urgency level and provides some points (its importance). The urgency is reflected by progress of each player on a track from 1 to 24, players can go back and forth on this track depending on the urgent cards they play. Tasks can be delegated to other players.
The game is designed such that players' strategies are bend towards applying techniques advocated by GTD method and Eisenhower's time management rules:
The game is fun, well-designed and polished, and runs smoothly without too much complexity. All rules can be printed on the board which is quite a small set. I had mixed feelings about its underpinnings however, as it entails players to develop individualistic strategies without taking into account the aim of the group and its context.
This session was lead by Johan Peeters and is an introduction, using some example, to performance engineering of multi-tiered networked applications. Goal is to optimize time or more precisely increase throughput of some system.
The system is modelled as a multi-station closed queueing network and is expected to be in steady state. We start with some simple maths on QN theory to understand relationship with the various metrics we can extract from the system. First model is simple: There is no shared resource between work stations, hence no contention.
If Di is the service time for a station in the system, then the lower bound`````` for processing time when there is one request is \sum_i D_i and the upper bound for throughput is 1 / \sum_i D_i. When the system can process N requests in parallel (can hold N requests). Then the upper bound for throughput is N / \sum_i D_i
````````We then turn to model with contention on resources: Each station competes with other stations for a resource. Then the maximum throughput is simply 1/ max(D_i). In other words, throughput is bounded by the bottleneck in the system. According to Little's law, we have that L = \lambda W with \lambda being the average arrival rate, L the number of simultaneous requests in the system and W the average service time for one request. Substituting for values in the previous equation, we get that response time in system handling N requests with contention is bounded by N max(D_i)
The interesting conclusion of this analysis is: Always optimize the bottleneck before anything else!
After this light mathematical introduction, presentation moved to some practical aspects of performance engineering:
Some example system:
Some questions:
A game about, well, evoluationary design.
Game is fun and highlights the necessity of keeping your design evolutive enough. There is maybe not enough constraint on what team can achieve, and how they can achieve it, so it is hard to optimize, choose between different options. see http://blogistherules.co.uk
Subtitled: Mission Impossible.
A presentation of how architecture and agile can mingle to help reach better software quality, and what may be the role of an architect in agile teams. Not very conclusive, with lot of generalities about what is agile and what is architecture. Might need to be more practical and hands-on session, possibly with some case study or game like feature.
Thought-provoking and lively session by Koen Van Exem. I met Koen for the first time at Agile Open France 2008, in Itterswiller, and we had a passionnate discussion on programming languages and types. I really liked his Dimensional Planning method when I had the chance to get introduced to it and since then I reuse this concept very often to challenge assumptions about perfection and requirements we have developping software.
The question this technique addresses is simple to state: How to mix different domain concepts into shared elements? Canonical sample is the Person object: How to mix the Person object from a Banking POV with the Person object from a Sales POV? This is related to the overall goal of Domain Driven Design: Through Ubiquitous Language development and use, ensure that the system embodies the concepts of the business in a simple, consistent and unambiguous way (in particular, we don't want to maintain two different versions of a Person class...).
Koen goes through OO history to detail previous solutions and why they failed to offer this:
There is a presentation of the Allors framework which embodies theses concepts, plus adds some Naked Objects-like behavior to increase throughput for developing applications with minimal UI.
A presentation of Fitnesse, using some real-world use by expert testers and a sample system to model. Not much new but it was interesting to hear positive stories about putting Fitnesse to use on large and complex systems.