The Kick Off

What is this?
This document describes an internal(team) designed and agreed mandatory rules for the process that just precedes the development of a story, This process is commonly known as the "Kick Off".

Why?
The main reasons for this are:

• to make sure that the team is aligned/understands the story that is about to be developed
• distil the requirements given to the team by the business analyst and early spot errors in them
• revisit and adjust the scope of the story if necessary 
• create a mandatory repeatable process so the risk of early introducing an issue is less
• agree upon work that need to be done

THE KICK OFF

1. Read the story description independently
   Regardless of if we work in a pair programming environment or not, we(each member of the team individually)  will take some time in our own to read the requirements that were written in the ticket management tool(e.g JIRA). The time this first glance takes is somewhere around 5' and 20'.
2. Gather questions
   We must understand that the kick off is a team activity. We are not expected to understand everything in the requirements at 100% neither to know exactly everything that needs to be done and how it should be done. We will write down all our concerns, doubts, assumptions, questions, etc... in a list and we will keep it for the time of the kick off. Individual solutionising is not an acceptable behavoir.
3. Craft a task proposals list
   Now with our pair programmer or by our own if we don't have one, what we will do is to write down a list of proposed tasks, based on our understanding of the story so far. This list is just a draft, not a final decision. The purpose of this draft is:
   - To make visible to others our views/sense about the story in hands.
   - To make it easier for the developers to spot task parallelisation opportunities.
4. Empty acceptance test
   An empty acceptance test(just text in the Given When Then format) will serve as a conversation starter during the kick off. The propper creation of the real failing acceptance test will be done as an independent task, later since only when all is clarified in what regards to requirements, we can write an accurate and meaningful acceptance test.
5. The Kick Off
   At the kick off all the team gathers and look together at the story. The BA will start by giving a brief summary on what is the story about. Then the developers will show the empty acceptance test they've written. Now is the time to use the questions, assumptions we gather initially. If any discrepancy exist, it will be clarified by the team and the acceptance test will on spot be corrected. At this point, the story is considered to be kicked off with the team(but yet not officially marked as started).
6. Dev's talkWhen the kick off is complete and we know exactly what needs to be done, we will huddle with the rest of the colleagues to distil the proposed task list we made and agree on what tasks we can parallel. It is highly likely that after the kick off toke place that initial draft is no longer accurate at 100% so the devs will revisit it and distil the final version. This final task will be published in the same place where the requirements were published, so the progress of the story is transparent to everybody.
7. Start development
   The developers will now prepare their tools for development(e.g rebuild local DB, synchronise VCS, awake zombies...). When this is complete the developers will move the story into "dev in progress" and development begins. Good time for a coffee now ;p

Mockito ArgumentCaptor example

Lets observe the following class

1 2 3 4 5 6 7 8 9 10 11 12 13 14

public class MyService { private Collaborator collaborator; public MyService(Collaborator collaborator) { this.collaborator = collaborator; } public void doSomething() { Thing thing = new Thing(); thing.setType("ABC"); collaborator.doStuffWith(thing); } }

If we were to test the method doSomething() what we would be interested in,
perhaps mostly is to make sure that the collaborator that it uses is reached and the appropriate
parameters are passed. We could do that very easily by just verifying on a mock

1 2 3 4 5 6 7 8 9 10 11 12

public class MyServiceTest { private Collaborator collaborator = Mockito.mock(Collaborator.class); private MyService myService = new MyService(collaborator); @Test public void shouldDoSomething() throws Exception { myService.doSomething(); verify(collaborator).doStuffWith(any(Thing.class)); } }

But there is a peculiar thing about this method. The argument that is passed into the collaborator
function doStuffWith() its using an object. Objects as its well known, contain other objects and/or
primitive variables. Since the object thing its being created internally in the method rather than be
injected(Its a hardwired dependency), we have no way of accurately knowing about it anything else but its type. So if we were curious about knowing more precisely about that object, what we would have to do is to spy on it. Mockito, allows us to spy on the objects that are passed to the mocks using a little tool called Argument Captor.
Let's have a look at how this test would look like if we were spying the object thing.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

public class MyServiceTest { private Collaborator collaborator = mock(Collaborator.class); private MyService myService = new MyService(collaborator); @Test public void shouldUseTheRightThing() throws Exception { ArgumentCaptor<Thing> argument = ArgumentCaptor.forClass(Thing.class); myService.doSomething(); verify(collaborator).doStuffWith(argument.capture()); assertThat(argument.getValue().getType(),is("ABC")); } }

As you see, spying is an interesting way of in a non intrusive manner(without having to refactor), you can discover things about your code.

Now a question comes to our head. But declaring that object of type Thing in the method like that, is not an smell? Well, maybe but have in mind that if you were to inject that object from either the constructor or via a setter injection, we could say that you would be changing the api of the class. So that is not very good, because maybe you don't know if the clients that use the class are actually capable of providing the object thing or if would that even make sense form a design point of view.

To express this last point in a more pragmatical form, I am going to show you another 2 more intrusive refactoring to this class that could help you test that object, but that will need from you to sacrifice in design.  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

public class MyService { private Collaborator collaborator; private ThingBuilder thingBuilder; public MyService(Collaborator collaborator, ThingBuilder builder) { this.collaborator = collaborator; this.thingBuilder = builder; } public void doSomething() { Thing thing = thingBuilder.withType("ABC").build(); collaborator.doStuffWith(thing); } }

If you had a builder, you could mock it and train it, but you would pay a design price of having to add the builder to the constructor.

Even if you choose to use a setter to set the builder or keeping the original constructor as it is(so you don't affect the clients) and overloading, you are still sacrificing your design for the purpose of the test. Your test would also become more complex. It would look like this:

1 2 3 4 5 6 7 8 9 10 11

@Test public void shouldUseTheRightThing() throws Exception { Thing thing = new Thing(); thing.setType("ABC"); when(thingBuilder.withType(anyString())).thenReturn(thingBuilder); when(thingBuilder.build()).thenReturn(thing); myService.doSomething(); verify(collaborator).doStuffWith(thing); }

The other alternative I was thinking about would be to override equals and hashcode, so you could do a comparison in your test against a newly created object that would be the

expectation.

1 2 3 4 5 6 7 8 9

@Test public void shouldUseTheRightThing() throws Exception { Thing thing = new Thing(); thing.setType("ABC"); myService.doSomething(); verify(collaborator).doStuffWith(thing); }

It looks naive, but again is intrusive. You are adding 2 methods in your entity, just for the purpose of making the test green.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

public class Thing { private String type; public String getType() { return type; } public void setType(String type) { this.type = type; } @Override public boolean equals(Object o) { if (this == o) return true; if (o == null || getClass() != o.getClass()) return false; Thing thing = (Thing) o; return type != null ? type.equals(thing.type) : thing.type == null; } @Override public int hashCode() { return type != null ? type.hashCode() : 0; } }

Remote debug - IntelliJ + Java + Gradle + SpringBoot

This brief video just shows how to hook IntelliJ's remote debug config.
If you want to try this yourself, here you can find the app I am using in this demo:
https://github.com/SFRJ/hitthegroundrunning

Debugging for hours and still you didn't found the bug? No panic, just call this guy, he can solve all your problems:

Retrospectives - "Who are those guys?"(Part 3)

Big IT companies are often very siloed environments. It's not uncommon to see everyone segregated by their role: Devs in one corner of the open space, testers in another, DBAs in another floor, SAs in a different building, project owners in another country, etc ... This silos are in my opinion very dangerous for the organisation and sometimes we are not even aware to what extend the environment is siloed. Let me give you an example:

Have you ever noticed how many developers that work in the same floor as you, say hi to you in the corridor while going to the toilet, the coffee machine or even at the street at lunch time? Interestingly, those who you frequently talk to would probably smile, say hi or give you some sort of greeting. But, there are others that when you cross paths, regardless that you work in the same floor as you for years, will look at the ground, at the sealing, at their phone or elsewhere just not at you. This are not people with a different role or rank than yours, this are the exact same people as you. So this little experiment shows to what extend the companies are siloed, If we are unable to say hi to each other when we cross paths, how on earth can we expect from us to be influential and drive change in an organisation?


Regardless of all this things, many recruiters still dare to write in their job specs the word 'Agile'. The obvious question arises: how is it possible for a little naive agile team to have significant impact in the overall organisation? All those cool 'Agile' ideas which could perhaps save millions, create a much better work environment for all, bring innovation ... are at the risk of slowly dying in the minds as time passes and the old school overwhelming corporate traditionalism just keeps on the same line of thought.

The answer to the question it's not brief and neither trivial to present since it's composed of many parts. But for now in this post I will gently scratch the surface of one of those partial answers, which is "Agile Influencing".

There is retrospective format which is actually a reverse organisational engineering exercise, which is specifically designed to help the agile self directed team, to pinpoint key players and elements in the organisation and craft and influencing plan that could help them gain some terrain (and who knows maybe even save some life's ;) ). Let's have a look at it.

Step 1 - Switch on the radar
At the retrospective, the facilitator will draw on the whiteboard, 3 concentric circles that will look like the image below. And will explain the purpose of each circle.

- The most inner circle will represent the areas of direct control by the team(e.g test environments, development tools ...). Of course all this areas will be different for different teams, maybe some team will have total control over their production database, while other team will not have the database under their control.

- The second circle represents the area of direct influence. This is the area where the team cannot directly control, but can influence(e.g line managers, other development teams, etc ...)

- The most outer circle represents what is totally out of reach for the team or even unknown(e.g Companies chain of command, board of directors ...)


Step 2 - Tuning the right frequency
The facilitator, will ask the team to decide on or many goals or topics, they feel they need influence in order to achieve it. And will ask them to stick them in the outer area of the circle.

Step 3 - Scouting
The facilitator will ask everybody to write in post-it notes, names resources(e.g hardware, software, databases, processes, etc ...) and also the names of people(e.g managers, team leaders ...) that could potentially be connected in one way or another, with the topics/goals in the outer area. They participant will put all this elements in any of the 3 circles based in how they consider their influence around them looks like.

Step 4 - Triangulating
In one way or another, either directly or indirectly elements that are on the board will be conected to the goal the team want's to achieve. Ask the members to draw dashed lines for those relationships they are less confident about and solid lines for those relationships they feel more confident about.

Step 5 - Firing
Once you know how things are connected, you can craft a plan for influencing. Don't worry if you don't get it right at the first go or you didn't really pinpoint the right person, this exercise will probably need to be repeated in multiple sessions, until the team discovers how to get to their goal. Every time write the actions you will take and assign them to your team members.

Tips to have in mind when crafting the strategy
- Not everybody equally aligned
People have different characters, priorities, ambitions... It is important to understand that many times the reality is that in the corporate environment people, for whatever reason pull in different directions. Being aware of this and understanding in which direction the influencers are pulling is key to develop a good tactic.

- People might ask for something in exchange
Sadly very few things are free this days, so don't be surprised if you have to often apply the first law of economics in order to get somewhere "If you want to get something, you have to give something away".


- Certain fears can be proven irrational
A well crafted proof of concept, an excellent presentation or maybe an in depth conversation with the right person, can help you win over hearts and minds. Many of the fears that people have when it comes to change are mainly founded in the uncertainty. If you are going to lead for change, you will have to lead by example.

- Where things are more obscure and unknown more light is needed
Don't confuse uncertainty/unknown from conflict of interest. Many influencers that are in a conflict of interest with you or your team will not tell you that directly. They will instead put some excuses such as risk, cost, time ... When in reality the real reason is probably just a self interest on guarding a position or a key resource. There is many of this scenarios, specially among management, make sure that you either bypass those influencers by finding others or ask more and more questions and clarifications when you suspect that their real reasons are not what they are saying they are. No matter how strong they are, never be afraid if your cause is just.

- Sum forces with those who suffer alike in order to gain greater visibility
You and your team are probably not the only ones, summing forces with others like you, no matter if you will have to negotiate certain things or arrange certain favours. The friends of your friends will become your friends and their influence will become your influence.


This article was part of  a series of articles I started writing time ago on retrospectives. Here my previous posts on the topic:


Retrospectives – “Discovering our selves”(Part 1)
Retrospectives – “Lets talk about it”(Part 2)
Meditating about the self directed I.T company
Why big corporations don't like retrospectives?

null again! WTF(Wednesday Thursday Friday ;p)

1 2 3 4 5 6 7 8 9 10

public class SomeClass { public void method(Something argument) { if(argument != null) { //Do stuff... } } }

The above piece of code contains what we commonly refer to as a "verbose null check", in other words, validating that the incoming parameters exist. This is not a nice practice often because it tends to add noise to your code and also doing stuff and validating something, are different concerns and the methods in order to be clean, should be just caring about one thing.

People often wonder, what to do then to not let the null get any further. Let's have a look at some options.

Do nothing
One option is to just do nothing, the caller of the function, should be cautious and make sure not to pass a null. But if he does and this leads to a NullPointerException, this is a good way of knowing that the way that function is being used is wrong.

                                                                       

1 2 3 4 5 6 7 8 9 10

public class SomeClass { public void method(Something argument) { //Do stuff... } }

Using assertions
The java keyword 'assert' can be used in combination with a boolean expression to stop the program execution by throwing an assertion error. While this seems like an interesting alternative to the if statement, assertions are disabled by default in java. They are a nice debugging tool for those who want to use them with care. Sometimes some programmers will enable them during a bug fix, but they will always be disabled in the production environment.

1 2 3 4 5 6 7 8 9 10

public class SomeClass { public void method(Something argument) { assert argument != null : "Can't pass a null"; //Do stuff... } }

Null Object Pattern
The idea behind this behavioural design pattern is to use polymorphism to create null versions of an object(M.Fowler also refers to them as missing objects). This null objects will have a function called isNull(), which for the source class will always return false, but for the null object will return true. The client will be able to choose to pass a null object instead of a null, and this will avoid having to do a verbose null check in method().

public abstract class Something {

 // ...

 public boolean isNull() {
  return true;
 }
}

public class NullSomething extends Something {

 public boolean isNull() {
  return false;
 }
} 


public class SomeClass { 

 public void method(Something argument) {

  //Do something ...
 }
} 

public class Client {
       
 private Something something;
 //...
 // The client avoids passing a null by using a null object
 if(something.isNull())
  someClass.method(new NullSomething());
 else
       someClass.method(something);  
 //...
}

Optional
Latest versions of java have a class called Optional that can be used as a way of avoiding returning nulls. It is basically an implementation of the null object pattern. By using optional on the client we can avoid passing a null.

public class Client {
       
 private Optional<Something> something;
      
 //...
      
 if( ! something.isEmpty())
  someClass.method(something.get());
 //...
    
}

public class SomeClass { 

 public void method(Something argument) {
  //Do stuff ...
 }
} 

Validators, IllegalArgumentException and Business Exceptions
If the caller of the function is out of our control and we cannot be confident on the value that will pass to our function there are other alternatives to the null check that maybe regardless of also being defensive are probably more business friendly and perhaps more informative.

Validators
I mentioned at the beginning that methods should not have multiple responsibilities. If for whatever reason we must do that null check or some other type of validation, we could delegate it to a validator object.

public class SomeClass { 

 private Validator validator;

 // ...
 public void method(Something argument) {
  if(validator.validate(argument))
  //Do stuff ...
  return;
 }
}

Sometimes this validator is also not seen as an smooth solution and probably an unnecessary dependency into the class. It could be replaced using the Decorator pattern. Basically a wrapper around the function being called by a decorating object.
Read more about it in another article from this blog:
http://javing.blogspot.co.uk/2013/10/can-you-please-wrap-gift-it-is-for-my.html

Illegal Argument Exception
NullPointerException its not a very informative exception for the client. So if we decide that we are not going to do any kind of null check but we are still afraid of the null, perhaps we could just throw an IllegalArgumentException instead.

public class SomeClass { 

 // ...
 public void method(Something argument) {
        
         try {
             //Do stuff ...
         } catch(NullPointerException e) {
       throw new IllegalArgumentException(e);
         }
 }
}

It is not a good practice to catch runtime exceptions(aka. Swallowing exceptions), since as you know, the program just carries on working. It is highly recommended that if you are going to do something like this, at least you add a Logger.log() statement to help the developer that will be debugging in the case there is some problem.


Bussiness Exception
As I just mentioned in the previous alternative Runtime exceptions are not a good thing to catch. Instead of that, we could use Business/Declared exceptions, which will mandate the caller function to get ready(by adding try and catch blocks..) for a potential fault.

public class SomeClass { 

 // ...
       public void method(Something argument) throws YouArePassingMeNothingException {
        
       try {
  //Do stuff ...
  

               } catch(NullPointerException e) {
   throw new YouArePassingMeNothingException(e);
  }
 }
}

agile soul

Agile, agile, agile and more agile! Are those programmers beach body ready yet?

New fancy mac-pros, sushi for lunch everyday, the cool managers wearing shorts and tie on summer, all the walls in the co-work space decorated with gratifies, etc...

That definitely sounds much more fun than the office of many of us working in the corporate world. Who wouldn't like to work in such environment ... ;p
But is there anything else apart of those things that really makes your team an awesome agile team?

We know well that agile its about the feedback loops and there are a huge amount of books written on the topic, practices, principles, etc... So in order to put in practice an agile development style, what kind of characteristics should the team have? In my opinion there is an expense list of characteristics that the best agile teams have. Let's  a look at some of them:

Communicative
There is nothing worse than being in a non communicative team. It is essential for the agile team to communicate both internal and external whenever is necessary regardless if the current task in hands have to wait for a clarification. The team leader or the business analyst are not postman that carry messages outside of the team. Also agile teams and agile developers don't hesitate or doubt when they have to say something to somebody and they are not afraid of making a critic or taking a critic.

Transparency
For the agile team every aspect of their daily work its 100% accessible to everybody. There is no place for secrets. Everybody knows everything about everybody. Business roadmap, planed stories, passwords, colleagues salary... Absolute transparency is the best to build trust and cooperation.

Cooperative
There is no mine or yours for the agile developers. We are all in the same ship and we work based on 100% consensus agreement basis. We not just help each other and do pair-programming, we also swarm with other members of our team or even other teams, no matter how big the current priority is. Team building is more important than the business itself, we do not hesitate if we have to stop what we are doing and swarm with testers, analyst, architects, junior team members or anybody that needs a hand.

Fearless
Agile teams are well known for their incredible capacity to spike, prototype and challenge everyone and everything. There is no process, language, task or challenge that can stop the agile teams.

Experts
Due to its role diversity and multidisciplinary nature, agile teams have huge experience in what they do. The redirection that characterises agile teams gives space for every member to gain experience in any field that is needed or they have interest in. The agile team members enjoy and are always eager to learn new things no matter if it is outside of their comfort zones.

Solid relationships
When it comes to relationships between team members, there is no just silly small talks next to the coffee machine. Team building its something very important in the agile culture and doing all sort of team activities(e.g night outs, sports, quests, hobbies...) out of the office it is important for the agile team. To be able to enjoy being with each other in the office, we have to be able to enjoy being able to be with each other also outside of the office.

Effective self management process
Even if the agile team culture in occasions gives the impression of being laid back and informal, the process that governs the daily work its very well understood and defined by everybody. The difference between agile management and the old school command and control management is that in the agile everybody natural finds its place and knows what to do without the necessity of being told by a manager.

Context aware
Sceptics sometimes believe that agile teams are not aware enough about what are the priorities for the business. That they only care about their cool development tools, clean-coding and having fun while developing whatever they want. But it is not like this at all, sometimes agile teams are more aware about the business than the business itself. The agile company is a better prepared company to compete in the market than the non agile one. This is due to the multi-directional capacity that exists when having self-directed teams.


Agile practices and culture keep evolving. From the first ones who wrote the agile manifesto, to the most radical practitioners , everybody agrees that agile teams, are changing the industry for good.

Useful IntelliJ shortcuts in MacOs

December 2021 update
You can find more detailed information about my favourite shortcuts in this link:
Useful Shortcuts To Code In IntelliJ Without Mouse(mac)

I never find this post it when I need it so thats it, Im uploading it to the blog