Polymorphic Rants

Friday, 20th of November 2009, the 6th Italian Agile Day will be held in Bologna.

It’s a great opportunity to share experiences and practices, learn, discuss and meet other praticioners part of the  Agile community…and moreover it’s free

I’ll see you there !

The beginning of a project is always a hectic period where several things have to be put in place in order to be able to start the actual development from a solid position.

Interestingly enough, I see that what is important to have ready for ThoughtWorkers most of the time is not what has to be ready for other people.

Given that obviously every project is different and deserve specific attention, here is my list of things that has to be ready before the kick off of iteration 1.

Infrastructure

A repository, a Continuos Integration Environment with Cruise (or suitable alternatives) installed and working, a QA environment where we can deploy every successful build whenever we want, a basic build script (i.e. build/run tests/package). Pairing boxes, each one with exactly the same configuration.

Architecture

Just identify the core services/components, there’s no need to go into detail for each one at this time of the project. If we identify what is the main responsibility of a service is good enough for now, the details will be discovered later in the project. If we can easily identify the way services will communicate (web service ? message broker ?) good, if not through good OO principles we can abstract the low level mechanism and reduce the cost of change later, deferring the final decision to the point in the project where we have more understanding of the technological constraints.

Patterns

Pairing and frequent pair rotation will help in spreading the knowledge of the approach to solve specific problems and in maintaining consistency throughout the code base, so most of the time there is no need of defining a sort of “project dictionary” of valid patterns at day 1.
If we’re introducing new approaches to solve a specific problem, it’s important to highlight pros and cons of the approach so that people know what they are doing once pairing.

Most of the time these are probably enough to start Iteration 1.

All the other decisions can (and sometimes should…) be deferred to a later stage.

In a lot of companies  the productivity  of a QA is measured through the number of defects she raised: the  more defects she finds, the harder she works, therefore the better she is.

This approach has an interesting corollary:  if you have really good QAs you don’t have good developers. If your QAs are finding a lot of defects this means that your developers are quite poor and are regularly introducing defects in the code base.

This approach isn’t obviously team oriented: QA and Development are seen as two separate and independent entities that interact through a specific contract.

If we truly believe in collaboration the most important productivity metrics are not related to a specific role/set of skills but to the team capability of deliver quality software in time and in budget.

We need to ask ourselves why the defects are finding their way into the application deployed in the live environment (incomplete acceptance criteria ? not enough analysis or understanding of the domain ? gap in the test suite ?), and fix the issue as a team, not just using that number as the boundary between two streams of work.

Delivering software is a pretty complex activity that requires interaction between people with different skill sets.
One of the cornerstone of Agile Development is continuous improvement, and one of the tool often used to learn and improve  is the retrospective.

In a context where the collaboration is not effective, people tend to look for local optimization instead of seeing the big picture, and you have things such  the “QA retrospective”  or the  “Developer retrospective”.

In this scenario a “QA retrospective” (as the Dev’s one, or a BA’s one)  is probably more harmful than anything else; the specific issues that will be identified won’t address the whole activity of delivering software but will only be focused on that specific step (“we need x to do y”).

But what is the impact of that step in the overall process ?

How that step fits into the chain of event that will take a business idea to be delivered as a software artifact (hopefully in a timely and quality fashion ) ?

Don’t get me wrong: it’s definitively through specific improvements that you improve your overall process but if  don’t frame your changes in the big picture, it’s more likely that your changes will impact your process in the wrong direction and actually cause an additional waste.

Each attempt of optimization should therefore start from the clear analysis of what is wrong from a high level point of view and only then it’s time to shift our attention to the specific details of each step.

Walking in an office and just looking around for 10 minutes is enough to have a feelingof the level of communication in the environment.

When:

• co-located people communicate mainly via IMs, mails, or comments on online collaborative tools instead of face-to-face conversation
• a heavyweight tool is the preferred way for driving the work flow instead of using it only for backup and tracking
• on the whiteboard you can read the outcomes of the retrospective of 7 months before

There’s definitively something wrong.

What about your team ? How many of the above bullet points are you ticking off ?

Here on InfoQ some interesting thoughts around Seniority and Authority in an Agile team.

For the third year the European Summer School of Agile Programming(Essap) is a great opportunity to learn more about Agile Methodologies.

Here the website of the school: check it out.

For the last two weeks I’ve worked with EasyMock and coming from a JMock background it’s easy to make a comparison between the two libraries.

I have to say that I’m less than impressed by EasyMock: the whole concept of the two different states (recording and active) for the mock library looks unreasonable.

Let’s look on how we can create a mock with EasyMock:
MyInterface mock =EasyMock.mock(MyInterface.class);
//expectation
mock.myMethod();
//activation step
mock.replay();
//actual call to the mock
mock.myMethod();
//verification that the method has been called
mock.verify();

There’s also a more DSLish style of defining expectations, that I personally prefer (it differentiates clearly the definition of the expectation from the actual method call).

EasyMock.expects(mock.myMethod());

This style is the only one available when the expectation is more complex:

EasyMock.expects(mock.myMethod()).andReturn(true);

But what if I want to define that a certain method will be called on the stub, no matter how many times ?

I can either use a different way of creating the mock:
EasyMock.createNiceMock(MyInterface.class);

or using the DSL way:

EasyMock.expects(mock.myMethod()).anyTimes()

I think that having two ways of defining the same expectation pretty confusing, specially when you’re using the API for the first time.
What I’m looking for in a mock library is the possibility of defining the expectations in a concise but expressive way (DSL please…) and then inject the dependency in my main object. Period. Done.

JMock2 is pretty close, but I have to admit the the inner class notation with all those curly brackets around is not helping.

A fellow ThoughtWorker have just released Mockito: it looks like it’s taking the best from EasyMock and JMock and put in a single library..will it be true ? I’ll give it a try and I’ll let you know

I’m just back from the ThoughtWorks Immersion in our Pune office and one of the most interesting concept that came back to London with me is lo-fi.

Yes, lo-fi: nothing about planning, TDD, gummy bears and other fancy core agile things.

Just about being lo-fi.

This has actually been a core concept for me in the last years, but hearing it from the trainers has been a pleasure confirm.

What do I mean with “being lo-fi” ?

That concepts are trillions of time more important than the way we capture the them.

Write your stories on cards, play with them, move the cards around, rip them off if they are useless.

Design, architecture and layout of a UI can be fleshed out on a whiteboard and captured with a photo; big flip-charts are working lot better of mails and Word documents for defining agreement in the team.

All these lo-fi techniques help you focusing on the values of what you’re doing: if after a design meeting you roll out a lovely UML class diagram  you will be a bit reclutant to throw it in the bin if in the next meeting the team decides to take a different solution just because ittook you a decent amount of time for creating it with all the necessary details with Visio).

If you’re able to work on your ideas and not on the artifacts you will keep your process light and flexible as you need, able to quickly adapt to changes and decided improvements.

And if at the end of your process (but only at the end !!) you really need to formalize all the outcomes, do it…but keep in mind that from that point in advance you will be naturally less open to changements.

The fifth edition of the Agile Day has been announced.

As usual it’s an incredible opportunity to talk with a lot fo smart people of everything is related to agile methodologies; either if you are an experienced agile pratictioner or you are just starting knowing this world this is an appointment you can’t miss !!