Agile

2014 Conferences

I know it is a bit early to sum up the year in November, but since I have not planned any more conference talks this year I think I will do it anyway. As the picture shows I have been pretty active this year.

 

2014-11-08 12.15.31

I have been presenting at conferences in Norway (Software 2014), Sweden (Javaforum, Øredev), Germany (Javaland), Poland (JDD), Ukraine (JEEConf, JavaDayKiev) and Morocco (JMaghreb). In addition to my speaker appearances, I was also able to attend JavaOne in San Francisco where I got to meet a lot of people in the JCP and ended up being selected to the Expert Group for JSR 371 – MVC 1.0.

I hope to continue speaking at a lot of conferences next year as well. Talks have already been accepted by jDays and Javaland, so it looks promising.

Upcoming Talks

I think time is due for a small update post. Right now I am preparing code samples and slides for the upcoming talks this winter:

  • Javaforum, Gothenburg – Spring 4, Java EE 7 or Both?
  • Software 2014, Oslo – Organizing for Continuous Delivery
  • JavaLand 2014, Brühl – Spring 4, Java EE 7 or Both? and Implementing Batch Processing in Java EE 7

My profile at Lanyrd is also kept up-to-date.

Continuous Delivery at Javaforum Malmö

It was an excellent Javaforum meeting in Malmö at FooCafé Yesterday with three brilliant presentations….or at least two brilliant! I will leave the verdict for the last up to you since I am kind of biased…
Well, anyway, here are the slides from my presentation. Below, you will find some comments and thoughts from the discussions under and following the presentation.

Branching Strategy

This is always a hot topic when brought up. I still believe that excessive branching is evil, especially in the context of Continuous Delivery. The longer period of time a piece of code is kept away from the main part of the code, it is more likely to fail. Thus pulling and pushing (or the equivalent of your preferred VCS or DVCS) is the key to make sure that all developers are actually working on the same code base. Frequent pull/push combined with the right techniques, such as Branch by Abstraction, makes the use of the evil feature branches unnecessary even when performing so called major refactorings.

The use of Gerrit was also discussed in this context. Even though it involves a manual step (the approval) and use branching as underlying technique, I think that as long as you see it as a part of the Commit Stage and do not let the unapproved code branches batch up it is an excellent tool for securing the quality of the code base. The caveat is if the approvals starts lacking and you end up with a lot of small parts of code in their own gerrit generated branch awaiting approval that nobody is aware of.

Deployment Scrips

Should you run deployment scrips even on your local development environment? Well, it depends. Normally, you will get much faster feedback by running the application by using the application server support in your IDE. Most IDEs supports hot deploying on save nowadays. But if you make changes to the code that is likely to affect the deployment scrips, or if you are developing the deployment scripts, you should of course test them locally to be sure that they run as expected. Remember that the deployment scripts are also a part of your code base.

Another example is if the target environment is Linux and the developers are running Windows. If the target environment is not likely to change, I see no reason why you should clutter the deployment scripts with OS-specific code or, God forbid, have two versions of the scripts.

A Pragmatic Approach to Continuous Delivery

Summer time means less people at work and more time to think ahead what to do the remaining part of the year. In my case it means that I have signed up for a talk called A Pragmatic Approach to Continuous Delivery at jDays, a Swedish Java Developer Conference located in Gothenburg. Read the abstract here, and vote for it here if you think it sounds interesting.

While I was at it, I also proposed a lightening talk on the same subject to Smidig 2012, a Norwegian Agile Developer Conference in Oslo.

Agile Architect Pattern

Intent

Guide the team to reduce technical debt before it becomes a problem.

Motivation

The nature of agile development is to deliver working software continuously. This means that the focus for all actors (Product Owner, Scrum Master and Team) is on the functionality delivered in each iteration. As a consequence, technical debt is considered okay and is likely to increase for each iteration completed. Often, this is allowed to go on until the debt has reached a level where the velocity of the team is starting to decline. After a while something has to be done, and the term Refactoring Sprint is introduced. A refactoring sprint is in this context an iteration totally devoted to paying off technical debt, thus no functionality is delivered for an entire iteration.

How it works

The Agile Architect Pattern prevents the scenario from the motivating example from happening by introducing an Agile Architect role. The Agile Architect can be seen both as a member of the team and as well as a stakeholder. This makes him/her able to both work with the team members, guiding them while trying to identify architectural issues as well as discussing requirements for future iterations with the technical resources from the client. While the team has a iteration-by-iteration time frame, the agile architect can see a few iterations ahead making sure the architectures evolves in a way that (hopefully) will not cause major problems ahead.

When to use it

The Agile Architect Pattern should be used in any project spanning over enough iterations likely to cause the technical debt large enough to slow the team down. It is important that the Agile Architect is comfortable both in the code domain acting as a guide for the team as well as on a higher level of abstraction to be able to interact with the client technical resources.

Upcoming Talk at Agila Sverige

I will be giving a lightning talk on the subject “The Architect role is needed, even in agile projects!” at the Agila Sverige conference which is arranged in Stockholm the 23rd and 24th of April this year. I will not reveal too much of the content here, but as the title implies, I will be promoting the need of an Agile Architect in every project. Agile or not…