How do you recruit a manager?

300hFor a bit more than half a year ago I decided to leave the corporate world. I moved to Ocado Technology which was starting a new office in Wroclaw at that time. I guess I forgot to boast about it.

This post won’t be about how great Ocado is or anything like that (however if you ask me, it is). I just wanted to share one thing that we did in Wroclaw, which for me was pretty awesome and quite unique when you look at other companies.

I want to share, how we hire managers.

Meet your new boss

Wherever I worked before, when the company was going to hire a manager, they just did it. Some uber managers held the interviews and finally, after time of gossips and keeping stuff super secret, the uber manager’s representative was meeting the team to share a fantastic, game-changing, long-awaited news.

‘You have new boss. Listen to him. Work with him. Finally, like him. We say he’s good.’

I have heard it more than a few times in my life – sometimes it worked, sometimes it didn’t. Sometimes the manager was actually good and we liked him, sometimes he sucked and after 3 months ‘decided to follow his career outside the organisation’, as the uber manager said.

The biggest problem of this approach is that managers don’t work with other managers only. They work mostly with people they are responsible for. However, during the recruitment phase no one asks the people about anything. Often they don’t even see the candidate before he is hired and has his day one. How can you then be surprised when the people don’t simply like the new guy?

I don’t know if uber managers (never been one, so I can just make a guess) think they are so senior, experienced, skilled and strong leaders that everyone will follow without any questions just basing on their word. That they know what is the best for everyone. Isn’t it a bit conceited?

Meet the candidate for your new boss

homer-job-interviewWhen in Ocado the time came to hire a manager, we decided to do it differently. The first stage of the process was interview with the team. The candidate was put in front of all people in the office, which was quite easy as there were less than 20 of us,  and asked to give a really short presentation. Afterwards we had a simple chat together to see if there is the chemistry between us. If the team wasn’t happy about the candidate, we thanked him for his time.

Stopping the entire office for 1.5 hour may seem like a waste, but for me it’s an investment. When I remind myself the corporate world, I can only guess how much time was wasted during pointless discussions or solving conflicts with managers? Far more. How was the team’s motivation and performance affected by making a wrong recruitment decision?

If the people don’t fell like they want to work with a given candidate, does it make any difference that the guy is experienced or skilled? Even if later he passes all the other stages, you have to convince the team that they should trust recruiters instead of themselves. If the candidate makes a great impression on the team, when he actually joins the organisation, he’s not a stranger. It’s their guy, they hired him. Saying ‘yes we want to work with this guy’ builds a commitment.

Of course one can say ‘people don’t know what they want’, but if you really think so this post, even this blog is not exactly for you. I believe that people exactly know what they want, especially in IT.

Short summary

Should the team have an interview with a candidate for their manager? Yes. It’s not easy, but doable. The question is, if your organisation is happier with long-term value or short-term profit. If you want to have great people, who will do a great job, you have to invest your time and effort in recruitment process. There is no other way.

 

Advertisements

What are estimates for?

Estimates are all about time. During one of last retrospective I realized that for some people estimates, and their role, are not that well understood. If not perceived well they can create pressure. Because what happens when we estimated the amount of work needed wrong? What happens when what we declared is significantly different than what we actually needed to fulfill our task?

Estimates are provided by developers and mean the most probable time when a given task will be finished. The most probable, not exact. Exact time can never be provided, at least not in software development.  This is something that both managers and developers need to remember.

Sometimes due to various reasons developers are afraid that breaking the estimate will cause troubles. When during the work some unplanned task shows up a question arises – should I take more time and work on the proper solution or do the task using duct tape and deliver my code on time? For me the answer is obvious, but as I lately learned not for all. Take all the time you need to rethink and redesign the solution, and implement it in the proper way. Ask yourself a simple question – what will satisfy your product owner or client – desired functionality that is working as expected or piece of crap delivered on time?

If your manager will be mad explain what is happening and why you have a delay. If you care about transparency and visibility of your work you manager will trust that you do all you can to deliver the code. If not, well then I’m sorry but the company should change the manager… Otherwise sooner or later the team will simply leave.

If you are a manger please remember what estimates are. If you create pressure on the team, the estimates will quickly become surprisingly high. People will start to add significant safety buffers just to be sure that in the worst case they will still manage to meet the deadline. In 95% of cases they will actually finish before time, but remain silent – wasting your time and money. Of course this will be the less professional part of the team – the more professional will be already working for some other company where the word ‘estimate’ is well-understood.

Agile By Example Light – subjective summary

IMG_20140510_135308798_HDRFor me Agile By Example Light which took place May 10th 2014 was really important event. Mainly because for the first time I had a chance to be a speaker on a bigger agile event, which I consider quite an achievement for such a newbie as me. I had more than a few presentations before, however speaking on such event is a bit more complicated and stressful experience. You’re not speaking in front of your colleagues anymore, but strangers who paid to be there and have certain expectations. Not in front of beginners, but in front of scrum masters, agile coaches or generally speaking experts with lots of knowledge and experience. That’s tricky…

First things first. The topic of my presentations was ‘Agile Games’ so I gave some examples of games I played with different teams and a bit of theory of games psychology, but not to much not to bore people. How it went? I think really not bad, could have been worse, much worse I guess 🙂 I really wanted the topic to be interesting to the audience and was a bit afraid that it might be too simple, however there was quite a lot of questions during and after the presentation and also a few people questioned me directly for details at the after party, which is even better. I hoped for negative feedback, but didn’t get any, which I think was more of politeness than my prodigious show.

The event included six presentations including mine and a little game called Ball Point Game. Everything very was well prepared and going smoothly, so big congrats for the organizers. Also the location was awesome with astonishing view on Warsaw city center.

Now let me briefly go though all the presentations done by other speakers.

Paweł Lipiński – Agile Bullshit, what’s really important in Agile?

Paweł did awesome, provocative and sarcastic presentation about marketing and hype around Agile and for me he got to the point well. Agile, Scrum etc. are just methodologies – a bunch of rules, which are not that complex to be honest – why we try to make it a kind of a religion? With all the coaches, masters and gurus the industry made Agile a mystical Holy Grail of software development with some convoluted, psychological aspects that were revealed only to the chosen ones (preferably with appropriate certification of course 🙂 ) leading people to forget that what really matters is common sense and hard work.

Marcin Kwieciński – Understand your boss

Marcin focused on showing people the other perspective on the everyday work – boss’ one. “Remember that each boss has a boss too” – good to have this in mind to understand some of your boss decisions and actions.

Agata Czopek-Rowińska – Lean Startup in practice

Agata described her work on mobile, educational application for children in mid school, which was a great example of application the Lean Startup principles – iterative approach, hypothesis validation, minimum viable product, testing with potential users (the children) etc. It was so nice to listen about such an interesting project with a positive influence on kids education. Even though I didn’t learn anything new as I know Lean Startup quite well, the general overview was extremely positive.

Michał Ślizak & Danuta Bemowska – Stakeholder jungle – a survivor’s guide

Really valuable presentation for all people who are thinking about introducing Kanban in their team. Michal and Danuta described their team before and after the transition giving a measured benefits such as increase in lines of code delivered per day and decrease in number of bugs. As I have seen transition from Scrum to Kanban done by 5 teams in my previous work the presentation didn’t give me any new knowledge, however I strongly appreciate its value for people who never witnessed it.

And last but not least.

Jacek Wieczorek – Agile Bootcamp. How to use Agile, to teach Agile.

Description of interesting and innovative approach to the process of training new scrum masters in the company. Instead of some standard theoretical in class trainings, “junior scrum masters” were working in a scrum like process – having all meeeting like planning session, retros etc. – where their tasks were for example join 5 teams retrospectives or facilitate planning meeting with one team. Of course junior had their mentors (like Jacek) who were not only helping them, but also performed a role of product owner in the training process. As for me this idea seems absolutely great!

Thank you

At the end I wanted to say a big thank you to Piotrek Burdyło, who gave me a chance and invited me for the event. It was great and I hope to have another chance to give a presentation in the future. It was really challenging, but also I felt so honored, to speak in front of such an audience and to be in a group of such experienced and professional speakers.

Photos by Agile247.pl here:
https://www.facebook.com/media/set/?set=a.863272843699964.1073741829.786798948014021&type=3

Simple steps to make your JUnit tests better (part 1)

One of my latest tasks was to review and refactor unit tests in our system, which I found especially suitable for me. After presenting my results to the team guys asked me to create a page on Confluence describing my remarks and proposed practices we should follow – what a great occasion for a blog post. So here I present some practices that in my opinion (and my team’s opinion too) can improve your tests and make them cleaner, simpler and more readable.

Proper test method naming

The name of the test method is as important as the test itself. The key is that it should describe the behaviour that is tested – not the name of the method that is tested, not all the arguments that are taken, but the behaviour. So names like testMethodA are absolutely wrong and please never use such a construct. Also have in mind that such naming lead to monsters like testMethodA2, then 3, 4, 64, 382 and so on leaving the code in a state that nobody knows what is actually tested and where. If naming was done well you don’t even need to look inside the test method to understand what’s going on and what is actually tested. To achieve it use on of BDD naming conventions which enforces you to think about the behaviour that it under test before you start coding and describe it well. Personally my favourite naming convention is “should do something when something” In example:

@Test
public void shouldPopulateAuthorDataWhenGeneratingReport()

This is a powerful practice for beginners as starting the test method with the magic “should” word makes you literally stop and ask your self “Yeah, what it actually should do?”.

Don’t be afraid of long method names – we’re not having any limits on that so you can put inside method name everything that you consider essential to fully express what’s going on under the hood. Test are for developers and developers should read camel case text as fast as normal one so argument that long names are unreadable for me is invalid. However, if you method name is getting longer and longer check if the test isn’t doing too much and if you design is fine.

 Use matchers instead of simple asserts

Using matchers library will make working with test much simpler because of two reasons. First, tests are more readable. Your assertions are starting to tell a story describing the behaviour. To give an example look at these two assertion below and for full effect try to read them aloud.

assertTrue(!(shoppingList.size() > 2));
assertThat(shoppingList, hasSize(not(greaterThan(2))));

Hope you got the point. I have seen lots of tests with all assertions done with assertTrue only and this is why I used it here. Even though using hamcrest gives you a bit more code, you gain on readability – you don’t have to analyze carefully what are the conditions, it’s given on a silver platter. Here the assertion is quite simple, but imagine analysis on more complicated cases.

Secondly, matchers simplify debugging a lot providing elegant logging when assertions fail. Let’s look at logs from both failures of assertion given in the code above. When using first assertion all we get is

java.lang.AssertionError

which literally tells nothing and we have no information what went wrong. On the other hand using matchers we get quite informative log giving us a first place to start analysis.

java.lang.AssertionError:
Expected: a collection with size not a value greater than <2>
but: collection size was <3>

 Write concise tests

You should keep inside the test method only things that are essential to describe tested behaviour, extract everything else to increase readability and the ease of understanding what is going on inside the test. Take a look at this example.

	@Test
	public void shouldDetrminePaperAsPackingMaterialIfItemIsRound() {
		Item item = new Item();
		item.setWidth(10);
		item.setHeight(20);
		item.setColor(RED);
		item.setShape(ROUND);
		
		Material material = packingAdvisor.determinePackingMaterial(item);
		
		assertThat(material, is(instanceOf(PAPER)));
	}

Do we need all the details of an item inside the test when the only thing that matters is it’s size? This is nothing but a noise in the code leading to more time spent on understanding it. Person looking at this test will try to analyze all the fields, thinking that possibly the values have some kind of influence on the test result. Item’s size and color are values that are not tested and should be extracted to separate method used to construct items – how to do it well is a topic for another blog post of course.

Setting up all items fields in each test case is causing also code duplication which is one of basic faults.

To be continued.

Hello world!

Changes came to my life, quite huge ones I must say…

First of all I change my place of residence from Krakow to Wroclaw, which was quite an expected change as for last 1.5 year I had to travel these 300 kilometers almost every weekend. Of course a change of work place came along so… I moved from one investment bank to another. And here begins the story of this blog.

For a longish time I was thinking about starting a blog and now finally I found a moment which gave me a boost to put thoughts into action. In Krakow I was working in a very mature environment with well developed agile practices. Working there was a great pleasure and I must admit that I learned more then anywhere else before. In Wroclaw the situation appeared to be quite different – I joined a quite new team, where the very first members have been there for less than half a year. New situation brings new opportunities of course.

In this very moment the team is definitely in the forming stage, looking forward to finding their own best practices for the delivery process. The environment is a greenfield, which satisfies me a lot as since the very beginning I can propose process improvements and put my current knowledge and experience into test. Having a lot of challenges ahead I decided that it can be useful to share my experiences with the community for both sharing and gaining new knowledge. I really hope that by describing my experience I will receive advises and also I hope that my thoughts shared here will possibly help others that are facing similar situation.

I hope that many of you will find this blog useful or at least interesting. I also hope to find enough time to share as much of the things happening as possible so you will be able to see the change that is ongoing in my working environment. I am really looking forward to see this happening as the team is very open-minded and one can fell that their need to change and improve is huge.

Of course I would also like to share my thought about all other agile related stuff that I will find interesting and worth sharing in my very own opinion. I will be very glad if you find my posts and thoughts useful.

Stay tuned.