My meeting with Jeff Sutherland

Posted by Luc Legardeur mid-afternoon: October 31, 2007

Last week, along with certain other members of the Xebia team, I went on a Scrum Master certification training course given by Jeff Sutherland. Because of the coincidence of its timing, we didn't stop talking about rugby scrums during this session (yes, I know, this one is easy easy but I couldn't resist). For those who don't know him, Jeff is one of the founders of Scrum.

My role within Xebia organization is not to run projects and I was there only to do my job better as President of Xebia France (“What is well expressed is well understood”). So believe me, these two days have to be marked with a cross in my professional diary.
And, no doubt about it, it was a special experience. If I was lyrical, I would qualify this session as a breath of fresh air in terms of common sense, a pragmatic delight or even a well of clear sightedness.
Jeff has definitely influenced my way of approaching situations for ever. If I dared to, I would almost put Jeff on an equal footing with those Anglo-Saxon authors that any manager eager to learn should read, like Jim Collins and Jack Welch.
I'm not going address, even partially, the concepts delivered in the 200 training slides of the training nor even repeat the juicy anecdotes that Jeff was kind enough to share with us on the damaging effects of traditional project management: it would be a but a pale imitation, not to say clumsy, of course. But I do promise to write up a series of notes on “Agile Tips”.

For those reading these few lines and who, like us, are particularly fond of Agile Methods, Xebia is organising a “Scrum Master” certification training course with Jeff on 24 and 25 March 2008 in Paris (in English with the linguistic assistance of a French certified Scrum Master from Xebia).
We'll leave this news with the “Scrum sensitive” readers of this blog for two weeks before announcing the fact to the community on a large scale. If you want to enrol, send an e-mail to info@xebia.fr.

Agile need not deliver business value early

Posted by Anurag Shrivastava mid-morning: October 30, 2007

Agile methodologies are gaining higher acceptance in the software development community day by day. Agile methodologies show their superiority over waterfall methodologies of software development but in the excitement of having found a better way to develop software, Agilists have started emphasizing that the Agile Methodologies can deliver business value early. The promise of early business value delivery, though a very seducing argument in the favor of Agile, needlessly burdens the software development teams to deliver something that they were never trained for. Using early business value delivery argument in the sales process, you can create an expectation so that the software development team's performance will be measured by the business value they deliver with their software. Agile methodologies or any other software development methodology, for that matter would play a marginal or insignificant role in the early delivery of business value. Agile Methodologies should not be advertised as a new faster way to business value delivery with software.
(more...)

Handling bugs with Scrum

Posted by Martin van Vliet in the early evening: October 28, 2007

On my current project, we are using Scrum to build a data processing and publishing application. Our aim is to deliver working, tested software each sprint. Our team includes testers that test the software we make, as we make it. Any bugs they find we try to resolve as soon as they are discovered. Sometimes, though, bugs can not be resolved in the sprint in which they are found. These bugs must be dealt with using the Scrum process.

We use the following process for this. At the end of a sprint, all unresolved bugs classified by the testers as major or higher are entered onto the product backlog as separate items. Issues of minor importance are collected in our bugtracking tool. At the planning meeting for the next sprint, the product owners select the highest priority items (including bugs) from the product backlog for inclusion on the sprint backlog. Items that are not selected remain on the product backlog, possibly for next sprints.

This process provides transparency about the workload left to the product owners, both in terms of user stories to be developed as well as outstanding issues. They can decide on the relative priority of these, giving them full control over the sprint scope. It also creates a bridge between our issue tracking system and the Scrum process, ensuring that these are not two separate worlds.

For this to work it is critical that the testers and the product owners agree on what constitutes a major versus a minor bug. If this is not the case, either unimportant issues show up on the product backlog (and will most likely remain there) or, worse, important issues are left in the minor category, with no visibility to the product owners. A regular review of minor issues with the product owners mitigates this risk and provides further transparency to stakeholders.

Advanced Hibernate, Maps Part 1: Complex Associations

Posted by Maarten Winkels mid-morning: October 22, 2007

When it comes to using Hibernate, most projects only use the very basic features. This is mostly due to naivety or unfamiliarity with the product. Hibernate is a very mature and feature rich product that can be used to solve a lot of basic or advanced problems. I think the point here is to put the complexity at the right level: You can always take a very basic approach to using Hibernate and solve the mismatch between your mapping and your model in your model, but that would put complexity in your model that is basically boilerplate code. It is only there because the persistence layer is not used correctly. If you make the persistence layer (in this case the Hibernate mapping) more complex it will be harder to maintain, but your model code will be more concise and easier to understand.

One of the features of Hibernate that is hardly ever used, but has some very interesting applications is the ability to map java.util.Maps. This blog will show an application of using a Map in your model and mapping that model with Hibernate to a Relational Database Schema.

(more...)

Sharing your task board across the globe

Posted by Serge Beaumont in the wee hours: October 18, 2007

Nowadays the Task Board has become one of the basic agile tools, and it features lots of stickies. As I was looking from my Task Board to my desktop I had an idea: all I needed for an International Task Board was a desktop background and a desktop stickies app!

(more...)

Software development: Should we continue to ignore the evidence?

Posted by Luc Legardeur around lunchtime: October 17, 2007

Editor: Luc is the CEO of Xebia France. This is an english translation of one of Luc's posts on the French Xebia blog.

We have noted it once again, one time too many no doubt. One of our clients (as the people responsible for such a situation work in the same company as the person where our contact operates) has got himself into a lose/lose situation with his integrator in a project developed at a fixed price. What are the facts? We could, without even letting him speak, list all the difficulties he encounters one by one with our eyes closed, reeling them off like a rosary.

A Call for Tender was issued aimed at the principal integrators in the place, because, depending on the Purchasing Department, this is the only way to conduct an IT project (which we told you about in an earlier posting (in french): “Eloge de la qualité”). According to the same specialists, recognised for their IT skills, it's a way of controlling costs and lead times, of sharing the risk with the company selected and of creating leverage (because it goes without saying that some wonderful penalty clauses for late delivery were stipulated in the contract). Integrator X was chosen. In a large part because he made a tempting offer and was able to accept all of the principles of this “contract of confidence” without uttering a word. So the scene was set: a calm atmosphere, mutual trust, the involvement of the best profiles from company X, users' wishes taken into account…

As you might expect, the last phrase is ironic.

(more...)

The joy of big up front design

Posted by Machiel Groeneveld in the late afternoon: October 13, 2007

Big up front design (BUFD) is a term that finds its origin in the standard waterfall model. It is often criticized and seen as something that should be avoided. I believe we should not be so easy to dismiss BUFD. I want to discuss the good things of BUFD, because I believe there are many. For a minute, stop thinking about project effectiveness and all those agile principles and let's zoom in on an imaginary group of people, team red, working on their Big Design. Perhaps you'll agree BUFD has it's merits if you look at it from a personal perspective.

(more...)

Podcast Episode 13 - Terracotta Part 2

Posted by Robert van Loghem mid-morning: October 10, 2007

This week we wrap up the interview with Jonas Bonér from Terracotta that Jeroen Borgers and Peter Veentjer did.

Terracotta is NAM (Network Attached Memory) and it provides JVM level clustering for scratch data.

Head on over to our podcast page here or download or subscribe to our new podcast.xebia.com.

Keep your implementations hidden

Posted by Lars Vonk in the late evening: October 9, 2007

Most Java applications I have worked on the last years embraced the "Program to Interfaces" principle. The name is rather self explanatory so I won't go into detail in the principle. As interfaces by itself are quite useless we need to have at least one implementation. In a typical application this is done by a defining a class such as:

 
public class JbcAddressDao implements AddressDao {
}
 

Nothing wrong here one might say, but I think that this code is in conflict with one of the main aspects of Object Orientation.
(more...)

Mapping MultiMaps with Hibernate

Posted by Maarten Winkels in the early morning: October 5, 2007

Hibernate is a very complete ORM library. One of the few ommisions is the possibility to map collections of collections. In this blog this omission is investigated and a solution is provided for the specific case of a Map of Sets.
(more...)

Next Page »