Agile Open France 2013 - Takeaways

Summary

Things I learned, heard, discovered, was amazed of, during Agile Open France 2013:

• Thanks to Willem Van den Ende, I learnt of the existence of Linux Containers, a project to build embedded and isolated servers hosted by a single Linux kernel. I knew and have used VServer but lxc appears to have much wider support and a quite large community.

• I worked with Willem (again!) on a very nice idea of its own: Managing tasks of projects using Graphviz graphs whose nodes are tasks and edges are dependencies. The graphviz file is stored alongside the project in a git repository hence versioned and updated over time while the project is unfolding. Tasks may be added, deleted, changed and grouped under clusters (eg. subgraphs) representing common state: done, inprogress, todo, technical debt…

  Together with Willem we hacked a Haskell solution to extract data from such a graph in order to produce a Cumulative Flow Diagram for clusters, thus giving some statistical information on the projects’ progress, lead time and queues size.

  Although the Graphviz package’s API in Haskell is a bit weird at first, we managed to get somewhere in a relatively small time frame without prior knowledge of this API, which is a tribute to its documentation, above the average.

• While working with Willem, it occured to me that creating tasks/issues/tickets classified as technical debt was actually a pretty good idea. This is not the first time I came across it but I now think I will set it up on my next project, and extract regularly for the team some metrics on the amount of accumulated technical debt.

  The fact that, by reifying the technical debt items in the project tracking system, one gets the opportunity to prioritize it like any other feature, is definitely a plus. Now, technical debt is something that flies in the face of all stakeholders and team members when deciding what to do next and we can ground our decisions on whether or not we are ready now to accumulate or repay part of it.

• I took part in a session on Agile Teaching with an aim towards making courses and teaching to students more amenable to agile methods. Laurent Bossavit told us about its experience at Ecole des Mines de Douai with a 3-days intensive course which gives student the opportunity to practice every aspect of the development lifecycle using agile practices and techniques, something which is more difficult in a sliced lesson taking place over the course of a semester.

  Laurent also wisely remarked that we tend to transpose our experience as trainers for professional developers in a corporate settings to students, which is most of the time wrong.

  Everyone agreed on the importance and benefits of workshops and agile games which, apart from boosting the morale of students who are bored to death by slideware, provides a rich interactive experience to build a more theoretical analysis. I myself tend to start with theory than illustrate with practice which is not so good and this is something I shall change in my next courses.

• Etienne Charignon demonstrated how they have used FitNesse as their only testing tool on a recent project and how successful he thinks this experience was. Their approach was radical: They did not write a single unit test and used only FitNesse to drive their development, something which sounds impossible* to me. Yet they succeeded in delivering a high-quality application (except maybe in the GUI area which, as far as I can tell from what Etienne told us, lacked tests) which pleased the customer.

  They were lucky enough to have onboard an analyst with some dev background who wrote most of the initial tests and maintained the FitNesse. They also had few business logic, the application being mostly a front-end to some database, hence testing with FitNesse tables was really expressive.

  I was impressed by how they used FitNesse as an integrated specification tool, putting all relevant documentation alongside the tests and structuring them using features and functional areas. I always had mixed feelings with FitNesse as most of the time I tried to introduce it, I had a hard time onboarding non-developers, although I am really convinced of the interest of such a tool to provide accurate, structured and precise specification of a piece of software.

• In the train bringing me back home I chatted with Pascal and Luc and our discussion happened to fall on the tests as specification issue. We both agreed that, if only developers are involved in writing tests, it is better to devise the tools and processes to generate specifications from the (JUnit) tests than forcing developers to use a tool that gets them outside of their efficiency zone (eg. outside of the IDE/CI cycle).

• I ran the extreme startup game with Willem (I spent a lot of time with Willem in this conference!) on Friday morning. We gave it a little twist by requiring teams to select a constraint. This time we played the game, in Haskell, with the constraint of not using the REPL which was really alleviated when we managed to make Haskell’s doctest port running.

  Other teams had constraints like: discovering git while developing, not using unit tests, developing on the iPad (kudos to Laurent Bossavit who managed to have a web server in python running on its iPad!).

  This was fun and engaging, as always, and Raphaël gave me an idea to make it more fun: Allow people to participate in the game as investors, fuelling the participants with time to develop their solution according to their business plan and their existing codebase.

• I proposed a session inspired by Dan North’s Patterns of Effective Delivery talk and some blog posts from him and Liz Keogh on this subject: How some teams get past standard agile practices to deliver software more effectively. The wifi was lame in the hotel so we could not watch the talk or even a fraction of it, hence the discussion was a bit biased by my vision of Dan North’s vision.

• In the bus back to Strasbourg’s station we had an informal discussion on Designing for Operability. Pierrick talked about his experience developing a software which is both used in SAAS and hosted mode. The most salient aspect of their approache is that they deploy a software without proper sysadmins (eg. developers are the sysadmins), and the software is autoinstallable and autoupdatable, thus alleviating the need for complex installation and upgrade ceremonies.

  Julien who works as head of an operations department gave us some more insights on how a large organization handles this. One of their strongest requirement is that everything that gets logged by an application they operate should be tracable: A UID should identify the error condition in all layers of the system (eg. client and server) and no log should be produced without it. They also ensure that code deployment is simply done with a checkout from SVN and that tools between developers’ stations and servers are consistent. Binary artifacts are versioned.

What I Will Do

• More Haskell: This is a great language which is easy to develop with in all current environments. I have been loving it for years and still find it amazing… I plan to revive my git-p4 bridge, making it more robusts and usable, and develop a programmable maven shell in order to simplify maven builds and common commands.
• Use FitNesse as documentation hub: Instead of splitting documentation across various repositories, wikis, documents, I will try to ensure all project’s documentation is kept in FitNesse hence versioned alongside the project.
• Improve FitNesse tests quality, and turn them into a real executable specification. Given that I shall start accompanying a new team soon, I will take the time and responsibility to maintain the Fitnesse and write more tests, more easily, in order to provide a good feedback on where the project is as early as possible.
• Run Extreme Startup: This game is both fun and instructive. I will submit a proposal to run it for next Agile France conference and at my current work. I will try to add more questions in order to provide variety and possibly rewrite the graph display part which sucks.
• Review Dan North’s talk again.
• Track Technical Debt