Wednesday, May 18, 2016

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?





Saturday, April 30, 2016

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);
  }
 }
}

Saturday, April 23, 2016

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.














Wednesday, January 6, 2016

Useful IntelliJ shortcuts in MacOs

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

Wednesday, December 30, 2015

Experimenting with humans and elfs

Everybody its on holiday, just arrived and It seems like I am the only muppet at the office today.
Oh, cool some body left a designs patterns book on the desk. Hehehe...



I guess it was that communist elf again.  See? that little man even forgot his hat!  


Wait, hold on a sec... ARGGGHHH...! WednesdayThursdayFriday!! My banana case its empty?????? The elf ate my banana!!!

Ok let's calm down its just a banana, the poor guy had to go back to the north pole so probably toke it for the way back.

Anyway, what I do to day?  Let's see:

- Pile of tech debt waiting for a miracle. 
    Uhm... I wonder if Jesus would be able to unblock me if I get started with any of this today.

- Second pile of tech debt. 
     Mayyybe, but wait! there are no story numbers there, better I don't mess up with the process ;)

- Swarm with the tester that just arrived. 
     Regression testing you said?? Yes, yes... sure, all the suffering will end one day, yep... Ok lets continue this conversation next week.

- Pick new story
     Opsy, board is empty! No BA's around, Well, I better mind my own business then.



All right! let's have a look at this book the elf left for me. 

Strategy, Template, Builder... Wow so many patterns which one I read about?

Oh screw the reading!, lets just do some coding. 

Ok, what I code about? Its xmas, let's think about some xmas related code...
...

Oh screw that too, lets just do some human experimentation or something. 

Yes, thats it! Let's experiment with humans! No, no better, let's experiment with elfs hahaha.... 
Im so evil sometimes!

So, what about this one?: Imagine I catch that elf and I torture him in a machine that plays christmas carols infinitely and I log all his reactions, like if it was a proper scientific research.

Mmmm... sounds like an events driven system to me. 

Ok! 

So let's refresh my mind, how did I do events in Java some time ago? 

Let's spike that a little bit for now, this book may be handy I will keep it close.


I said I would create a person, and I would put it in a machine and see how it reacts to the sounds the machine plays. In order to react, to sounds, I better make sure that person has ears(the listener). 


public class Main {
    public static void main(String[] args) {

        SomeListener ears = new Ears();

        Person person = new Person();
        person.addListener(ears);

        SoundsMachine soundsMachine = new SoundsMachine(person);
        soundsMachine.generateSound(new RainSound());
        soundsMachine.generateSound(new CreepyDoorKnobSound());

    }

}


Ok, cool. I remember now. 

So the important thing here its the person because for it to react, it will need to have different types of listeners. But those listeners, may react to specific events only. Well, the events could also be generic something like an interface(function pointer).

Yes, let's keep it simple. I think that is better since the specifics of each reaction could be programmed separately in each different listener...


public class Person {

    private List<SomeListener> listeners = new ArrayList<SomeListener>();

    public void addListener(SomeListener someListener) {
        listeners.add(someListener);
    }

    public void noticeWhatItsGoingOn(SoundEvent soundEvent) {
        for (SomeListener someListener: listeners) {
            someListener.perceive(soundEvent);
        }
    }
}




Fine, so let's then look closer at the ears listener Im using in this example.


public class Ears implements SomeListener {

    public void perceive(SoundEvent soundEvent) {
        System.out.print("Uhm, I hear something: ");
        soundEvent.produceSound();
        System.out.println("I think its " + determineSound(soundEvent) + "!");
        lineSeparator();
    }

    private String determineSound(SoundEvent soundEvent) {
        if (soundEvent instanceof RainSound)
            return "rain";
        else if(soundEvent instanceof CreepyDoorKnobSound) {
            return "a door opening. Hopefully I will be out of here soon";
        }
        return "I can't recognize that sound";
    }
}



So that implements the Listener interface which is basically a functional interface.


public interface SomeListener {
    public void perceive(SoundEvent soundEvent);
}



And that's it then the only thing its just to have a look at the implementation of the events that are sent.


public interface SoundEvent {
    public void produceSound();
}

public class RainSound implements SoundEvent {

    public void produceSound() {
        System.out.println("plop, plop, plop....");
    }
}

public class CreepyDoorKnobSound implements SoundEvent {
    public void produceSound() {
        System.out.println("KnJjjeeeeee...");
    }
}



I will sketch this to summarise:





The listening object(Person) is used by the application code which is what uses it and also where the action of registering the listeners its done(Main and SoundMachine). 

Also that listening object holds all the listeners in a list and acts as a gateway, to where the events are sent (noticeWhatItsGoingOn() method).

This was Javing's last post of 2015

Merry Xmas and prosperous new Year!



                              

When it’s the 5th one who tells me ‘see you next year’ when leaving the office




Tuesday, December 15, 2015

Consensus decision making

I was just tidying up room, moving things here and there and in an old shoe box I found an old paper script I had for long time. It's  around 25 pages,  a good friend of mine gave it to me time ago and told me to read it carefully. I did read it long ago, I was reading it again tonight and I thought that It would be interesting to just share some parts of it in the blog.
Is not related to software at all, but it describes in great detail the process of consensus decision making which I consider an extremely important thing to understand by every person in a self-directed team or organisation.

As you probably know, the "Agile Manifesto" in one of its clauses says that the best work its done by self directed teams. Unfortunately in many organisations today "Agile" is just a buzz word and doesn't go beyond the developers desk...

So without saying much more, I will just paste here some parts of that text, which I hope you find interesting and also help you get a grasp of what it means to decide in consensus.


CONSENSUS DECISION MAKING
Consensus decision making is a creative and dynamic way of reaching agreement between all members of a group. Instead of simply voting for an item and having the majority of the group getting their way, a consensus group is committed to finding solutions that everyone actively supports – or at least can live with. This makes sure that all opinions, ideas and concerns are taken into account. By listening closely to each other, the group aims to come up with proposals that work for everyone. Consensus is neither compromise nor unanimity – it aims to go further by weaving together everyone’s best ideas and most important concerns – a process that often results in surprising and creative solutions, inspiring both the individual and the group as whole.

At the heart of consensus is a respectful dialogue between equals. It’s about everyone working together to meet both the individual’s and the group’s needs – working with each other rather than for or against each other, something that requires openness and trust. Consensus is looking for ‘win-win’ solutions that are acceptable to all - no decision will be made against the will of an individual or a minority. Instead the group adapts to all its members’ needs. If everyone agrees to a decision they will all be much more committed to making it happen. Consensus decision making is based on the idea that people should have full control over their lives and that power should be shared by all, not just concentrated in the hands of a few. It’s about having the freedom to decide one’s own course in life and the right to play an equal role in creating a common future. This is why it is used widely in groups working towards a more just and equitable society such as small voluntary groups, co-operatives and campaign networks.

CONDITIONS FOR CONSENSUS
Common Goal: Everyone in the group needs to share a clear common goal and be willing to work together towards it. Work out together what your goals are and how you will get there. If differences arise later, revisit the common goal to help to focus and unite the group. 

Commitment to reaching consensus: Everyone needs to be willing to really give it a go. This means being deeply honest about what it is you want or don’t want, and properly listening to what others have to say. Everyone must be willing to shift their positions, to be open to alternative solutions and be able to reassess their needs. 

Trust and openness: We need to be able to trust that everyone shares our commitment to consensus and that everyone respects our opinions and equal rights. It would be a big breach of trust for people to manipulate the process of the meeting in order to get the decision they most want. Part of this is to openly express both our desires (what we’d like to see happening), and our needs (what we have to see happen in order to be able to support a decision). If everyone is able to talk openly then the group will have the information it requires to take everyone’s positions into account and to come up with a solution that everyone can support.

Sufficient time: for making decisions and for learning to work by consensus. Taking time to make a good decision now can save wasting time revisiting a bad one later. 

Clear Process: It’s essential to have a clear process for making decisions and to make sure that everyone has a shared understanding of how it works. 

Active participation: In consensus we all need to actively participate. We need to listen to what everyone has to say, voice our thoughts and feelings about the matter and pro-actively look for solutions that include everyone.

Good facilitation: When your group is larger than just a handful of people or you are trying to make difficult decisions, appoint facilitators to help your meeting run more smoothly. Good facilitation helps the group to work harmoniously, creatively and democratically. It also ensures that the tasks of the meeting get done, that decisions are made and implemented. If in a small group, you don't give one person the role of facilitator, then everyone can be responsible for facilitation. If you do appoint facilitators, they need active support from everyone present.

KEY SKILLS FOR CONSENSUS
Active Listening: When we actively listen we suspend our own thought processes and give the speaker our full attention. We make a deliberate effort to understand someone’s position and their needs, concerns and emotions. 

Summarising: A succinct and accurate summary of what’s been said so far can really help a group move towards a decision. Outline the emerging common ground as well as the unresolved differences: “It seems like we’ve almost reached agreement on that bit of the proposal, but we need to explore this part further to address everyone’s concerns.” Check with everyone that you’ve got it right.

Synthesis: Find the common ground and any connections between seemingly competing ideas and weave them together to form proposals. Focus on solutions that address the fundamental needs and key concerns that people within the group have. 

FACILITATION
In most meetings, there are one or more facilitators. Their role is to ensure that the tasks of the meeting get done: that decisions are made and implemented. They also help the group to work harmoniously, creatively and democratically. The facilitators might take steps to keep the meeting focused, or make sure a few people don’t dominate the discussion. They might suggest a break when people are getting tired; they might have prepared an agenda and process that will help the group achieve its goals. The facilitators shouldn’t have any more power than anyone else and should stay neutral on the issues under discussion. They’re not there to make all the proposals and decide things for a group. They can only do their job with everyone’s support and co-operation. If a small group doesn’t give anyone the role of facilitator, then everyone can be responsible for making the process of the meeting work.

GUIDELINES
  • If you don’t understand something, don’t be afraid to say so.
  •  Be willing to work towards the solution that’s best for everyone, not just what’s best for you. Be flexible and willing to give something up to reach an agreement.
  • Help to create a respectful and trusting atmosphere. Nobody should be afraid to express their ideas and opinions. Remember that we all have different values, backgrounds and behaviour and we get upset by different things.
  •  Explain your own position clearly. Be open and honest about the reasons for your view points. Express your concerns early on in the process so that they can be taken into account in any proposals.
  • Listen actively to what people are trying to say. Make an effort to understand someone’s position and their underlying needs, concerns and emotions. Give everyone space to finish and take time to consider their point of view.
  • Think before you speak, listen before you object. Listen to other members’ reactions and consider them carefully before pressing your point. Self restraint is essential in consensus – sometimes the biggest obstacle to progress is an individual’s attachment to one idea. If another proposal is good, don’t complicate matters by opposing it just because it isn’t your favourite idea! Ask yourself: “Does this idea work for the group, even if I don’t like it the best?” or “Does it matter which one we choose?”
  • Don’t be afraid of disagreement. Consensus isn’t about us all thinking the same thing. Differences of opinion are natural and to be expected. Disagreements can help a group’s decision, because with a wide range of information and opinions, there is a greater chance the group will find good solutions. Easily reached consensus may cover up the fact that some people don’t feel safe or confident enough to express their disagreements.

AGREEMENT AN DISAGREEMENT
At the decision stage people have several options:

Agreement with the proposal. 

Reservations: You are willing to let the proposal go ahead but want to make the group aware you aren’t happy with it. You may even put energy into implementing it once your concerns have been acknowledged.

Standing aside: You want to object, but not block the proposal. This means you won’t help to implement the decision, but you are willing for the group to go ahead with it. You might stand aside because you disagree with the proposal, or you might like the decision but be unable to support it because you don’t have the time or energy. The group may be happy to accept the stand aside and go ahead, or they may work on a new proposal, especially if there are several stand asides. 

A block: always stops a proposal from going ahead. It expresses a fundamental objection. It isn’t “I don’t really like it,” or “I liked the other ide a better.” It means that you cannot live with the proposal. The group can either start work on a new proposal, or look for amendments to overcome the objection.

 In an ideal consensus process a block wouldn’t happen since any major concerns about a proposal should be addressed before the decision stage. However, sometimes people aren’t able to express their concerns clearly enough, or aren’t heard by the group. In such situations the block acts as a safeguard to ensure that decisions are supported by everyone.

 Being able to block is an integral part of consensus, but it comes with a big responsibility. A block stops other people from doing something that they would like to do, and it should therefore only be used if serious concerns are unresolved.

 Make sure everyone understands the different options for expressing disagreement. Often people are confused and block when they’d actually be happy to stand aside. Sometimes people are scared of blocking, even if they are deeply unhappy and use a milder form of disagreement instead. 

THE WORKFLOW OF CONSENSUS
There are many different ways of reaching consensus.

This model outlines the common stages and will work well with up to about 20 people. 

Step 1: Introduce and clarify the issue(s) to be decided Share relevant info. What are the key questions? 

Step 2: Explore the issue and look for ideas. 
  • Gather initial thoughts and reactions. What are the issues and people's concerns? 
  •  Collect ideas for solving the problem write them down. 
  • Have a broad ranging discussion and debate the ideas. What are the pros and cons? Start thinking about solutions to people's concerns. Eliminate some ideas, shortlist others. 

Step 3: Look for emerging proposals Look for a proposal that weaves together the best elements of the ideas discussed. Look for solutions that address people’s key concerns. 

Step 4: Discuss, clarify and amend your proposal Ensure that any remaining concerns are heard and that everyone has a chance to contribute. Look for amendments that make the proposal even more acceptable to the group. 

Step 5: Test for agreement Do you have agreement? Check for the following: 
  • Blocks: I have a fundamental disagreement with the core of the proposal that has not been resolved. We need to look for a new proposal. 
  • Stand asides: I can't support this proposal because ... But I don't want to stop the group, so I'll let the decision happen without me. 
  • Reservations: I have some reservations but am willing to let the proposal pass. 
  • Agreement: I support the proposal and am willing to implement it. 
  • Consensus: No blocks, not too many stand asides or reservations? Active agreement? Then we have a decision!
If test for agreement fails, go back to Step 3
Step 6: Implement the decision Who, when, how? Action point the tasks and set deadlines.


This text in my opinion is really good, I just pasted there some of the key important things but there are so much more to it such as: how to deal with disruptive behavoir, larger groups, quick tips for emergency decision making and much more... 

Being capable of consensus decision making is probably one of the greater skills a team or a company can have. If you are interested on the topic, I would suggest you to search online on the topic, because there are plenty of stuff. A true agile team is transparent, has an spirit of shared ownership and responsibility and is capable of self organising. 

Selenium automation design pattern - The Journey Pattern

Browser automation is becoming more and more popular. Many people use it today: IT companies, automation testers, hackers, etc ...

Its possible to do lots of things with it; testing a website, scrap some latest changes, social media bots, and much more...(I stop there, Im not wearing my black hat today, no worries ;) )

You probably know, that there is a tool out there called Selenium for those who like Java and want to do browser automation. As per what I've seen so far from working in large companies, automation tasks are not always done by programmers, more and more often testers are writing pseudo-java code to do this tasks.

For the purpose of testing, Selenium code should always be treated in the same way as every other Java code. By this I mean, that clean coding and Object Oriented principles are still important.
A clean and understandable test harness is extremely important for being able to scale automation testing.


Unfortunately testers that are given automation tasks often lack the Object Oriented background that Java developers have and unless the company is willing to provide the proper programming training or the task is actually done by a programmer alongside, the chances of ending up with an unmaintainable UI automation test harness are high.


When it comes to using selenium for browser automation, the most widely used pattern is the PageObject. Basically page objects are just classes that represent each screen in the webapp. The PageObject its a good pattern that its being around for long time, but unfortunately the practice shows us that following this patter we often create duplication and we are not always capable of reusing the page objects.

A colleague not too long ago, told me to have a look at the Journey Pattern.
The idea behind the Journey pattern is that the automation is done around journeys. Every journey is composed of actions such as Enter text into, Click...

So lets have a look at 2 sample journeys:


 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
        //Just preparing selenium
        WebDriverBackedSelenium selenium;
        WebDriver driver = new FirefoxDriver();
        selenium = new WebDriverBackedSelenium(driver, START_URL);
        selenium.open(START_URL);
        selenium.waitForPageToLoad("2000");


        // Journey 1 - to verify login works (assertions omitted)
        LogIn.as(driver, "myUsername", "myPassword");
        // Journey 2 - write a comment on the news headlines
        WriteComment.in(driver, HeadlinesPage.commentBox);

The driver is passed around and its state is modified during each journey. In this example, we choose to create 2 separate journeys, where one Journey starts when the other ends. Since we pass the driver around, we don't need to worry about the user not being logged in before writing a comment(DRY). Each journey is composed of different action, and their components may be reusable across journeys:


 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
//Login is the Journey
public class LogIn {
    public static void as(WebDriver driver, String username, String password) {
        Enter.textInto(driver, username, LoginScreen.usernameBox);
        Enter.textInto(driver, password, LoginScreen.passwordBox);
        Click.on(driver, LoginScreen.loginButton);
    }
}

//Write a comment is a Journey
public class WriteComment {

    public static void in(WebDriver driver, By commentBox) {
        Enter.textInto(driver, "test comment", commentBox);
        Click.on(driver, HeadlinesPage.commentButton);
    }
}


Each of this Journeys as you can see reuse actions, such as Click, Enter, etc ...


 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
public class Enter {
    public static void textInto(WebDriver driver, String text, By selector) {
        driver.findElement(selector).sendKeys(text);
    }
}

public class Click {
    public static void on(WebDriver driver, By selector) {
        driver.findElement(selector).click();
    }
}


And finally, the actual pages just contain selectors to get access to the elements of the page:


 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
public class LoginScreen {
    public static By usernameBox = By.cssSelector("#username");
    public static By passwordBox = By.cssSelector("#password");
    public static By loginButton = By.cssSelector("#loginButton");
}


public class HeadlinesPage {
    public static By commentBox = By.cssSelector("#commentBox");
    public static By commentButton = By.cssSelector("#commentButton");
}


The journey pattern is very simple to learn, flexible and also scalable. If you are a tester with some notions of Java and Selenium, play with it, give it a try,


Share with your friends