During the recent panel debate in Colombo Agile Meetup my colleague Lasantha Bandara asked the following question: How do you start an agile project and ensure room for future enhancements? How can we achieve flexibity at the beginning? This is my answer: Flexibility is about having an acceptable cost of change. Sometimes, the best cost of change is to create something and throw it away early to try something else if it doesn’t work out.

There are only so many ways to test that your persistence layer is implemented correctly or that you’re using an ORM correctly. Here’s my canonical tests for a repository (Java-version): import static org.fest.assertions.api.Assertions.*; public class PersonRepositoryTest { private PersonRepository repository; // TODO < == you must initialize this @Test public void shouldSaveAllProperties() { Person person = samplePerson(); repository.save(person); // TODO: Make sure your repository flushes! assertThat(repository.find(person.getId()) .isNotSameAs(person) .isEqualTo(person) .isEqualsToByComparingFields(person); } @Test public void shouldFindByCaseInsensitiveSubstringOfName() { Person matching = samplePerson(); Person nonMatching = samplePerson(); matching.

Two of my favorite libraries in C#: FluentAssertions and NUnit (of course). NUnit has a “hidden” gem (that is, it’s well documented, yet few developers use it): [TestCase]. Look at this: using FluentAssertions; using NUnit.Framework; public class RomanNumeralsTest { [TestCase(3333, "MMMCCCXXXIII")] [TestCase(555, "DLV")] [TestCase(999, "CMXCIX")] [TestCase(444, "CDXLIV")] public void ItConvertsNumbersToRomanNumerals(int number, string roman) { ToRoman(number).Should().Be(roman); } } The [TestCase] lets us easily have several test cases implemented by the same method.

After having worked with Scrum for a number of years, I still witness sprint reviews where the team’s demonstration of the product is confusing and the value produced in the sprint is unclear. The demo may consist of just a bunch of different functions and screens without any meaning. Or maybe the team is just talking about what happens behind the curtains in the database. Or maybe the demo just doesn’t display the value that the team was supposed to give to the stakeholders.

When I learned math in elementary school, I would reach for my calculator. But my father stopped me: “You only get to use the calculator when you can do math without it.” As you can imagine, at the time I though this was unfair and unreasonable, but later I have discovered what advantage it is to understand the basics before you reach for a powerful tool. Many developers are focused on what fancy framework they will learn next.

When a software architect gets a good idea or learns something new, he has a problem. The main job of the architect is to ensure that the right information in present inside the heads of the people who should build the application. Every new piece of information in the architect’s head represents a broader gap between his brain and that of the rest of the team. The classical ways of adressing this gap is for the architect to write huge documents or sets of wiki pages.

Do you ever feel it’s hard to get real progress in a sprint towards the business goal? Do you feel the feedback from a iteration picks on all the details you didn’t mean to cover this sprint? Do you feel like sprint planning meetings are dragging out? Then a Rainbow Sprint Plan may be for you. Here is an example of a Rainbow Sprint plan: A customer wants cheap vacations The customer signs up for daily or weekly notifications of special flight offers Periodically the System checks which customers should get notifications The System checks for offers that matches the customer’s travel preference by looking up flights with the travel provider system The System notifies customer of any matching offers via SMS Variation: The System notifies customer of any matching offers via email The customer accepts the offer via SMS The System books the tickets on behalf of the customer The system confirms the booking by sending an SMS to the customer The customer can at any point see their active offers and accepted offers on the system website The customer enjoys a cheap vacation!

Sometimes, small questions lead to big answers. Sometimes these answers are controversial. One such question is “What does this warning about serialVersionUID mean”? All the advice out there basically is for developers who don’t know what’s going on to write code that will ignore errors when something unexpected happens. In my view - this is exactly the wrong approach. The safe way to act is to make sure that your program crashes if you don’t have control.

I have tried to create a simple process for debriefing workshops. This is the current process I use, and I think it may be useful for others. I give everyone sticky notes with three colors I ask everyone to write “a thing that surprised you about the workshop”, “a thing that you learned today” and “a thing that you plan to do as a result of the workshop”. Each question goes on a different color sticky note.

We were taught to categorize, but we know that searching beats sorting We were taught that information is scare, but we know that the real problem is too much information, not too little. We were taught that information must be protected from being viewed, but we know that the greatest threat to information is irrelevancy We were taught to estimate and plan what the marked wants, but we know that our customers don’t behave according to our plans We were taught to guide our customers, but we know they want to serve themselves.