The 8th edition XP Days will also be held in Kapellerput in Heeze, near Eindhoven.

Call for Sessions is now open (until July 15)

Guiding Your Personal Life: Plan-driven or Agile (Linda Rising)
Around 1800 the industrial age began in England. Suddenly people moved from the farm to the factory. This change was inspired by many elements. First of all the clock was becoming widespread in it’s use, which gave people an accurate way to tell time, allowing people to make punctual agreements. Second, caffeineated beverages were discovered, replacing beer as the main beverage. As water had to be boiled for making tea and coffee, it became largely safe to drink. This coupled to the rise of factories led to the lifestyle we still have today. This lifestyle, however, isn’t very natural. Until the industrial age the time for sleeping was dictated by the sun, allowing people more sleep in winter when it was neede more. Furthermore, caffeine isn’t very healthy either as it blocks the natural hormone that tells us we are sleepy, meaning we sleep even less. More and more, sleep is seen as something that is a waste of time. While it has been proven that without adequate sleep, we are not at our best, physically, mentally or emotionally. Even worse, without adequate sleep our brains show visible signs of premature aging. Caffeine will make us feel better and have us believe that we perform better, but the effects are no better than what a break would allow. Even more, caffeine only improves vigilance tasks. Tasks that require prolonged attention and little physical activity, like tightening bolts on a production line. And worse yet, for complex tasks only extroverts’ performance improved, while introverts tended to get worse.
Extensive experiments have been conducted that prove that sleep improves our learning capacities. Even just a short nap helps a lot. Sleep is divided up into cycles that consist of several phases. So maybe we should make sure that we use similar cycles for our activities. At the very least we should experiment with these ideas to see what works and what doesn’t.

Organizational Patterns and Scrum: Fine-tuning your Agile Implementation (Gertrud Bjørnvig & Jim O. Coplien)
The presentation started off with a little roleplaying where several people from the audience got a hat with a role attached to it and had to act out what they thought were the distances between them and the other people on the team. Through this play several of the patterns from the book Organizational Design Patterns were shown. After this a short history of patterns was discussed, along with the definition of a pattern and what Scrum is. The statement was that Scrum is very complex and that it should contain a whole slew of patterns, and that if Scrum isn’t working properly for you, you might want to investigate these patterns to find out how they can help you get to where you want to be. The conclusion was that Scrum is a pattern language, where the patterns provide insight and encouragement to fix broken Scrums. The patterns can also be used as an incremental path to Scrum adoption. So if you haven’t read it yet, go read Organizational Design Patterns by Coplien and Harrison, as it contains essential knowledge everybody who wants to change their organization should have.

Deliberate Practice in Software Development (Mary Poppendieck)
In sports and music it is well known that you only get to be an expert if you practice a lot. And not just any practice, but deliberate practice. The four pillars of deliberate practice are having a mentor, being challenged, getting immediate feedback and being dedicated. Mentors in IT should hire and grow people, review and guide work, set technical standards and ensure technical excellence. Unfortunately, most companies don’t have mentors. They usualy assume that product champions are enough. But a product champion is more like a conductor than like a music teacher, necessary, but not enough to ensure quality. In order to be challenged, you should get to do hard things and be able to do them frequently. Only too often you don’t get challenging work assignments as assignments are handed out to the people who are already good at that type of work. And when it comes to feedback the programmers are often kept at arms lenght of the customers, so the feedback is usually indirect. A good example of direct feedback is the feedback you get when you work on an Open Source Project, it is immediate, constant and detailed. And finally, skill development takes time. Time spent in the same place, as rapid job movement doesn’t develop skill. Time to learn without interruptions. Time to invent, practice requires the time to make mistakes.

The IT Division Refactored (Richard Durnall)
After quite a few years as an industry we’re still seeing over 60% of all projects in IT fail. This might be in part due to the way our IT divisions are structured. We are still working in a structure that was pioneered to manage a lot uneducated people. Despite the fact that we’re no longer uneducated and that we’ve known for quite some years that this model is quite inefficient for our current needs. All of this because managers believe that it is better to fail conventionally, than to succeed unconventionally. The current model is to start at the top, appoint managers by specialisation, allocate people to divisions/teams, communicate a strategy, determine performance targets, define the delivery process and then to engage the customer. A better model would be to start with the customer, develop a strategy, design initial processes, define process metrics, structure the organisation to support these processes, appoint process managers, and to end at the top and then to adapt and improve. Things to keep in mind are to improve the process first and only then to automate. Otherwise you will automate things that weren’t working in the first place. You should also allow for change. IT systems are corporate concrete that will freeze the processes. Systems Management Theory resolves the challenge of how to do Agile at scale.

Value Management (Evo) with Scrum development (Kai Gilb)
One of the reasons why selling Agile development to managers is so hard, is that the agile manifesto is all about the developer and not about delivering value to the stakeholders. The value management process contains eight steps: identifying the stakeholders, finding and specifying quantitatively the stakeholder values, prioritizing the possible solutions, breaking the winning solutions into smaller entities and packaging them, developing the packages, delivering to stakeholders, measuring the changes, and finally learning and changing the behavior. Scrum is only about the four steps from solutions to delivery. The value management cycle and the development cycle are both equaly long -1 to 3 weeks- and should take place at the same time. To implement value management you need to determine the business values, refine those in stakeholder values, refining those in product values and turn those in a prioritized scrum list. This doens’t have to be a top-down approach, as long as the end result is that the lists are defined. So if the problem is that a certain service is too slow, the developers are asked to come up with as many solutions as possible to solve this problem and then to present these to management in a value decision table, containing information on how much better the situation will become, how much resources it will cost etcetera. The greatest challenge to get this working is to get the business owners and steering committees to stop thinking in technical solutions. Business owners should instead focus on what their real needs are and the steering committee should sign off on value improvements, so the developers can come up with the best technical solutions that will give maximum product value improvements. Some case studies of where value management has been used show astonishing results.

Agile modeling and documentation best practices (Scott Ambler)
Agile modeling is a collection of practices based on several values and proven software engineering principles. The models this produces are as simple as possible so they are still understandable and can fulfill their purpose, but also so that they are just barely enough. When trying to scale agile delivery suddenly a lot of factors come into play like team size, compliance requirements, geographical distribution, enterprise discipline, technical complexity and organizational complexity. Agile Model Driven Development tries to address these issues. AMDD starts each project with iteration zero where the intial requirements and the initial architecture are envisioned. This should take a few days at most. Then every iteration starts with iteration modeling, which should take a few hours at most. This modeling is necessary to plan the iteration. When the resulting model isn’t specific enough for certain issues, this is followed up with just in time model storming, which should take a few minutes at most. And this in turn is followed by Test Driven Development. All of this modeling takes place under the assumptions that it is only just barely good enough and that it happens as late as possible so you can document stable things and not speculations that will prove false. You should prefer executable specifications over static documentation, as static documentation has a tendency not to be maintained. As for the quantity, you need a bit more than the extremists may care to admit, but a lot less than the bureaucrats realize. A big problem with documentation in most organizations is that it isn’t very effective, as the chance that it is correct, read, understood, followed and trusted are ever decreasing respectively. So in conclusion it should be realized that a model isn’t necessarily a document, that modeling is a key scaling strategy for agile development projects, and also an important part of every software process (including agile ones), and it’s an important communication technique. You’re likely doing a lot more modeling than you realize, but as you don’t realize you’re doing it, you could be a lot better at it.

Adventures of an Agile Architect (Dan North)
Once upon a time there was an agile architect named Dan. He was asked to coach a non-agile team into being agile. When he arrived he found that technically the software was SOA gone bad. All sorts of clients were coupled to all sorts of services through a WSDL. There was a whole lot of duplication too, as lots of the services did basically the same thing, but using different parameters. Operationally it was a complex, flaky infrastructure, with lots of EJB’s running in a non-standard old version of JBoss. And finally organisationally, the developers lived in silos, arguing vehemently for their prefered solutions, without listening to each other. The story has a happy ending however, as he was able to guide them into implementing a SOA as it was meant to be with clear context boundaries. Operationally they ended up with deterministic deployments and a product that was stable in production. And organisationally they had a happy team that staid happy even after he left. But before he got there, he set out to listen to all the developers. And was blown away by the realization that they all wanted the same thing. This made it a lost easier to determine and set a strategy. He warned the management that he was about to change things to remedy the situation and that it would make a lot of noise. They agreed on the condition that he really would fix things. He then set off to change the culture. It turned out that daily standups had already been tried, but that they had failed to be effective. Instead he set out to have a daily discussion about what the best possible today could be. With this and similar measures he was able to get the whole team on board to set off to become agile. To fix the technical mess the software was in, he introduced the command pattern. And when they chose a wrong direction in the implementation of said pattern he found out after taking the blame for that mistake that the team was now more willing to start experimenting, as nothing had happened to Dan after admitting the mistake. After the command pattern was in place they got rid of the EJB’s as they really didn’t need them. When the EJB’s were finally gone they introduced bounded contexts to separate the different areas in the software. This resulted in the fact that every piece of the code now had a logical place where it could be found. And when all this had been done they opened up their code to other teams and spread their way of working throughout the company. The lessons Dan learned from this project, are the ones he told me and the same as I’m going to tell you now. First of all, there is always a reason why the organisation and the software are in the state they are in. A lot of choices have preceded the endresult, choices that were most likely the best possible choices that could have been taken at the moment. Second, in order to make everyone aware of those reasons, every team should have a shaman that can tell the stories with that history. If a team doesn’t have a shaman, you should either find one, or learn how to be a shaman yourself. The third lesson was to strip away everything you can, right until the moment that it breaks (at which time you have to put the last bit back). Superfluous code obfuscates the story of the code and makes it much harder to understand. The fourth lesson was that you can’t buy architecture. You can buy tools if necessary, but architecture has to be made to fit the situtation. Trying to hammer your situation into an existing architecture results in bad code and an unhappy team. The fifth lesson was to use transitional architectures. Sometimes a piece of code is too complex to be changed all at once. Transitional architectures are architectures that are far from perfect, but that are a step in the right direction. You should take care to communicate to the rest of the team that this is only a single step, and where you intend to go. And the final, and perhaps the hardest, lesson was that life moves on. When you leave a team they’ll probably make decisions you wouldn’t have made and that you might not agree with, but that are the best they could make.

Kanban vs and Scrum – Making the most of both (Henrik Kniberg)
Scrum in a nutshell is to split the product, the organiztion and the time to go from a large group spending a long time building a huge thing to a small team spending a little time building a small thing but integrating regularly to see the whole. A typical evolution from waterfall to Scrum goes through the ScrumButt phase. Kanban in a nutshell is to visualize the workflow, limit the work in progress and to measure and optimize said flow. A typical Scrum to Kanban evolution is caused by the fact that for most Operations & Support teams, Scrum doesn’t fit properly and so they evolve to Kanban. Scrum and Kanban are both tools, and like a knife and a fork, it’s hard to say which is best, they are simply intended for different purposes. A comparison should therefor be made to understand them better, not to judge which is best. Scrum prescribes 3 roles, whereas Kanban knows no roles. Scrum prescribes timeboxed iterations, whereas Kanban does not. Both limit work in progress (WIP), but in different ways. Scrum limits the WIP per unit of time (iteration), whereas Kanban limits the WIP per workflow state. Both are empirical, but Kanban is more configurable. Scrum discourages change in mid-iteration, making users wait until the next sprint, whereas with Kanban the user only has to wait until a slot in a certain workflow state becomes available. A Scrum board is reset between iterations, whereas a Kanban board never gets reset.

Turning on a Sixpence – No excuses: Concept to cash every week (Kris Lander & Gus Power)
(Summary taken from the handouts that could be downloaded on above blog)
KEEP IT MOVING: We pursue profit for our clients by continuously delivering features in response to market and user feedback.
KEEP IT WORKING: We take a balanced approach, getting feedback all the time, building quality in and managing technical debt carefully, to move at speed and keep the cost of change low.
KEEP IT TOGETHER: We keep software fully integrated and in a deployable state by checking in every hour or so and getting quick confirmation that everything is working from our builds.
KEEP IT REAL: We keep software grounded in the real world by looking after our own environments, configuring them and optimizing them as part of the whole product.
KEEP IT COMING: We deliver software at a sustainable pace and work towards a visible destination, planning just enough just in time and keeping options open for as long as possible, so we can maximize return for our clients.

Typical Java Problems in the Wild (Eberhard Wolff)
Some common problems keep cropping up in Java code. Ten of these were presented by Eberhard Wolff. They were not necessarily the most common, but certainly with severe effects.
#1 Weak transaction handling.
The transaction is committed, but the exceptions that might occur are never caught, and no rollback is performed. This kind of problem is hard to detect as it only has effects if an exception is thrown. But when it does occur, it can lead to weird behavior and data loss and many other strange effects. Possible solutions are declarative transactions and transaction templates.
#2 Exception design
The three rules “Get all the details from a system exception!”, “Each layer must only use its own exceptions!” and “Exceptions have to be checked – then they must be handled and the code is more secure.” sound reasonable but lead to lots of useless exception handling code and lots of exception types without specific handling of that type. Possible solutions for this are to use more unchecked exceptions (RuntimeExceptions) and to handle only cases you really want to handle. This should be augmented with generic exception handling in the web layer that handles all runtime exceptions that were not handled elsewhere.
#3 Exception handling
Many exceptions are not logged or even swallowed entirely. This is related to #2, if you have excessive checked exceptions, this will occur more often as developers are forced to handle exceptions they can’t really handle. The solution is to at least log exceptions, and to think twice on whether it really is okay to continue in the specific situation. This should be combined with generic handling and improving the exception design.
#4 Architecture mess
Architecture is the decomposition of systems into parts. You should take care not to have overly large or complex parts and you certainly don’t want cyclic dependencies. Because if you do, maintenance will be hard as will concurrent development. Changes will in such a case often have unforeseeable results. Solving this is very hard if you are already in such a mess. So make sure to manage dependencies from the start. Otherwise you are looking at a major restructuring of your application.
#5 Adaptor layer
When performing a service you often encounter cross-cutting concerns such as security, tracing, checking for null arguments, logging, conversions from DTO to internal representations. This kind of code adds lots of boilerplate to each service. Changes to any of these items is very hard, because there are a lot of methods to change. The solution is to use aspects to take care of these cross-cutting concerns.
#6 No DAO
Quite a few people think that as the JPA is a standard, it doesn’t need abstracting away from. But this means that the service will be dependant on JDBC and will throw SQLException, meaning that the persistance will be visible i nthe service layer and beyond. This results in code that is impossible to test without a database, so no real unit tests are possible. The solution is to use a DAO or a repository.
#7 No tests or bad tests
Having no test at all or bad tests means that the code is not properly tested and most likely of low quality. This leads to the code being hard to change. The solution, of course, is to write proper unit tests. But reality has shown that writing proper tests is hard. Therefor you need to educate people on how to do it. Tests should also be integrated into automatic builds. And integration tests and functionality tests should be added as well.
#8 Creating SQL statements
Creating SQL statements by simply concatenating string with parameters is bad for performance, as the statement is parsed every time. Even worse is that this leaves your software open to SQL injection. The solution is to use preparedstatements.
#9 Not designing for performance
If performance is left for the final stages of development, then you can hardly do anything to fix it. As changes might introduce functional errors and it’s too late for the bigger that are necessary. Even worse, the results might be wrong if the performance test is run on different hardware than production. The solution is to get information about the performance requirements before starting on development.
#10 Multiple threads, memory leaks
If multi-threading isn’t done properly, then the system will work in small tests, but production will fail. The problems will probably be hard to analyze and/or fix and they can only be found by code reviews or extensive debugging using thread dumps. The solution is to use WeakHashMap to avoid memory leaks, to synchronize, and to prefer local variables. ConcurrentHashMap should also be considered.

Good keynote by Sherali Karimov that not only told how Atlassian employs agility, but also gave some pointers on how to implement it in your own company. (Unfortunately I can’t find any slides, but their website seems to offer some of the same content.)

Het modelleren van een canoniek datamodel mbv XML Schema (Modelling a canonical data model using XML Schema)

Dutch presentation by Linda Terlouw about what a canonical data model is and how to implement it with XML Schema. In short a canonical data model is a shared data format for exchanging data between services. It is meant to prevent the rise of lots of translations between all the individual data formats, allowing you to only need to translate your own data to the canonical format. We were also warned that a canonical data model, which models only what is necessary to share information, isn’t the same as a corporate data model, which models all information in the company. A distinction was made between hierarchical and relational models, and it was explained how XML Schema supported both of these options, along with all the pros and cons.

Geef je code wat liefde (Give your code some love)

Dutch presentation by Rob Westgeest and Willem van den Ende from QWAN about how code becomes more maintainable if you give it some love by refactoring. The bottom line is that with small refactorings in the order of ten minutes work, can save you the five minutes you need to read a method. (Which you would need to do again and again.) Presentations by QWAN are always highly entertaining and informative.

Keynote – Mod4j: Open Source Modelling for Java Developers

Another good keynote that introduced Mod4j, presented by Jos Warmer. I was almost surprised to hear that a partner at Ordina still got his hands dirty on code. So it was the right kind of sales pitch, and for an open source product too! Mod4j stands for Modeling for Java, and it is an open source DSL-based environment for developing administrative enterprise applications. (Again there were unfortunately no slides, so I had to take that quote off their website.) At the time of speaking the product wasn’t finished yet, as they weren’t offering all the functionality they wanted, but they had a working version and it looked cool.

Software Quality Automatically Measured

Nice presentation by Gert-Jan Schouten about a cool Maven2 plugin to measure quality and express it with a number. Too bad about the small font of the slides. And the code that was shown was completely illegible due to the small font. But the worst letdown was that the code that was shown wasn’t open source or even for sale. Fortunately somebody from the audience mentioned Sonar, which does more or less the same.

Pragmatic model driven development in Java with smart use cases and domain driven design

This presentation by Sander Hoogendoorn and Rody Middelkoop was slightly too slick for my taste. But as I say, it’s a matter of taste, I bet lots of other people loved it for the exact same reason. In fact, the presentation went so fast, that even with the slides, I can’t quite figure out all that was said.

–

I skipped the last session, as I was pretty tired and didn’t see anything that I thought could hold my attention during this last track. Instead I sat on the lounge chairs on the first floor and talked with some people until they opened the bar. (And kept right on talking afterwards as well of course.)

Dinner

It’s become quite a tradition already that the ladies of Duchess have dinner afterwards, and so seven Duchesses, Diane Etman from VXCompany and two men (since we now allow each woman to bring one male guest) headed off towards ‘de 3 Vrienden’ in the city center. There we met up with the third man, since he had misrembered the time and was already there enjoying the sunshine. VXCompany was very gracious to sponsor the food, so we only had to pay for our drinks. After our first dish we all scooted over three seats so we could talk to more people than just those who were sitting close in the first place. All in all a very successful ending to a great day.

Scrum is een framework voor het managen van softwareontwikkeling. Multidisciplinaire teams leveren in korte ‘sprints’ werkende software op. De nadruk ligt daarbij op:
• Mensen en interacties boven processen en tools
• Werkende software boven stapels documentatie
• Klantbetrokkenheid boven formele contracten
• Omgaan met verandering boven starre planning

Is Scrum hèt antwoord op de ontwikkelingen in de markt? Nee, maar de Agile softwareontwikkel- aanpak biedt wel belangrijke voordelen: de opdrachtgever heeft tijdens de ontwikkeling zelf het stuur in handen. Gewenste wijzigingen door veranderende omstandigheden of inzichten worden gewoon meegenomen en alleen de écht effectieve functionaliteit wordt ontwikkeld. Dat scheelt veel doorlooptijd en kosten.

Wilt u ook weten wat het werken met Scrum voor uw organisatie kan betekenen? Laat u dan in één avond bijpraten over Scrum door de man die de aanpak bedacht heeft en door een tevreden klant. Deze avond mag u niet missen!

Deelname is gratis. Inschrijven kan op www.basopleidingen.nl of mail naar ron.van.rijswijk@capgemini.com.

Programma
18.00 ontvangst met buffet
19.00 welkom
19.10 presentatie Jeff Sutherland
20.00 pauze
20.20 een succesvolle toepassing van Scrum bij Alcredis
20.40 presentatie en beantwoording van vragen door Jeff Sutherland
21.15 borrel

Locatie
Avifauna, Hoorn 65, Alphen aan den Rijn

Orlando Scrum Gathering 2009
Monday, March 16, 2009 – Wednesday, March 18, 2009

Gaylord Palms Resort & Convention Center
6000 W. Osceola Parkway
Orlando, Florida 34746
USA

Don’t miss this one: Top Headliners in Agile to participate in the Orlando Scrum Gathering

Confirmed speakers:
Ken Schwaber – co-founder of Scrum
Jeff Sutherland – co-founder of Scrum
Mike Cohn
Ron Jeffries
Jim Coplien
Alistair Cockburn

Join with Scrum community members from around the world as they gather together in the sunshine of Orlando Florida to share in a mix of experience, information, values and expert insight that provides a framework for evaluating and incorporating the Scrum process. Learn from experienced practitioners, Scrum founders and leaders in the agile community.

New this year a Scrum PMI track

Participating in a Scrum Gathering is an important step in expanding Scrum knowledge for Scrum users of all skill levels, as well as a great introductory opportunity for those who are investigating the possibility of using the Scrum process. A day of Open Space will afford participants the opportunity to set agendas, discuss timely topics and interact with industry experts and peers in casual group settings.

Payment: Scrum Alliance Members $1,500
Non-member $1,800
Limited space; the last two Scrum Gatherings sold out weeks in advance!

www.scrumgathering.org

Additional questions? e-mail scrumgathering@scrumalliance.org

Op donderdagavond 5 maart organiseert Agile Holland weer een bijeenkomst, deze keer bij de Hogeschool van Arnhem en Nijmegen (HAN) in Arnhem.

Er staan twee onderwerpen op de agenda:

• Emiliano Heyns (Scrum master bij de HAN) zal een tryout doen van de presentatie die hij midden maart bij de Agile Processes 2009 conferentie in Stockholm zal geven:Gaining Management Buy-In By Proving The Business Value Of Agile Software DevelopmentDeze presentatie gaat over de niet-technische aspecten van de Scrum implementatie bij de HAN; een aantal projecten hebben een aanzienlijke organisatiecomponent, en ook daar heeft Scrum zijn diensten bewezen.
• Ervaringen uitwisselen van de Agile Open Belgium conferentie, die op 20 en 21 februari plaatsvindt in Gent.

Het programma start om 19:00 en duurt tot ca. 21:00; daarna is er gelegenheid om nog even na te praten onder het genot van fris of bier.

Locatie: Ruitenberglaan 31, 6826 CC Arnhem, zaal A3.01. De lokatie bevindt zich op loopafstand van station Arnhem Presikhaaf (met dank aan de HAN voor het beschikbaar stellen van ruimte).

Wij zoeken momenteel nog een partij die broodjes of pizza wil sponsoren voor deze avond. Interesse? Laat het ons even weten.

Schrijf je snel in via het formulier hieronder (alleen zichtbaar als je ingelogd bent). Er is plaats voor ongeveer 20 deelnemers.

Tot ziens op 5 maart!

After diner we had to get started on the workshop for fear of running out of time. By then everybody had arrived. Michael Franken started off with a presentation about why we need Agile software development. Comparing software development to preparing food. Saying that there are two types of project. One was following a recipe from a cookbook, and the other creating a new recipe. It was rather obvious that software development falls into the second category. (Seeing how the cookbook style is rather like following a tutorial, nice to figure out how certain tools work, but useless to create actual software.)

After this presentation the actual workshop started where we got to try out planning poker. Our tasks weren’t software related, as such tasks would take too much time to complete three iterations in one evening. Instead we had to do sums, fold boats and inflate balloons. The tasks may have been trivial, but planning poker is not. After only three iterations all three teams could accurately estimate how much work they could do in one iteration.

All in all it was a successful workshop and a great evening.

Of course not everything went according to plan, so here are some plans to improve our workshops. Please feel free to chip in with more ideas in the comments.

- Make a planning and communicate it up front.
- Related to the above, mention whether there will be dinner or not.
- Make a list of people who attend and make sure who is actually present (nice way of also making sure to talk to everybody).
- Mention the attendance fee and communicate the bank account number.
- Prepare a proper thank-you speech.
- When planning a raffle, make sure you have time for it. (As I now had to take all the goodies home again.)

According to Ivar, here are a list of things that we don’t learn in school:

See Smart = Agile++ by Ivar Jacobson on Clara’s blog.