Friday, 28 June 2019

Estimating - There is no such thing as a 1 hour task

Introduction

Estimations in software development have always been a problem. Many teams and organisations struggle with finding the right way to do estimations. There is no right answer, and it really depends on your organisation. 

If you are measuring by the hour, then perhaps you have struggled with understanding why you are not as profitable as you could be. This may arise from the fact that your lower estimates are just not realistic. I will explain what I mean in the following examples.

In these scenarios we assume that the developer deploys to an environment, then confirms that the functionality works before handing it to a QA/UAT person.

Example 1 - The perfect case (no defects or problems)

In this example I will outline a 1hr task in a "best case" scenario which has no defects or problems. The order of events will differ depending on your processes. 
  1. Download repository & get code running locally - up to 0.25hrs
  2. Do the work - 1hr 
  3. Deploy to a development environment & test (0.25hrs)
  4. Commit code, create pull request, & participate in the code review (0.25 x 2 devs = 0.5hrs)
  5. Deploy to a QA environment & test (0.25hrs)
  6. Tag & cut the release (0.125hrs)
  7. Deploy to a UAT environment & test (0.25hrs)
  8. Deploy to production environment, put live, then quickly smoke test (0.5)

As you can see, a single 1hr task can actually take 3hrs in a good scenario. This does not even factor in the time of the QA or UAT people. Also, the context switching of doing all these different steps is a significant time drain.  

You are thinking that many tasks together can be bundled, so we would save time on deployments. As you will see in the next example, the math still does not work out.


Example 2 - The perfect case (no defects or problems) with multiple work items

In this example I will outline 5x 1hr tasks in a "best case" scenario which has no defects or problems. 
    1. Download repository & get code running locally - up to 0.25hrs
    2. Do the work - 5x 1hr 
    3. Deploy to a development environment & test (0.5hrs)
    4. Commit code, create pull request, & participate in the code review (5x 0.25 x 2 devs = 1.25hrs) - Note: each task has it's own code review
    5. Deploy to a QA environment & test (0.5hrs)
    6. Tag & cut the release (0.125hrs)
    7. Deploy to a UAT environment & test (0.5hrs)
    8. Deploy to production environment, put live, then quickly smoke test (0.75)
    As you can see, 5x 1hr tasks can actually take 9hrs in a good scenario. We are not really saving much time by bundling. On average, our  1hr tasks are actually taking almost 2hrs per task.



    Example 3 - The bad case (defects & problems)

    In this example I will outline a 1hr task in a "bad case" scenario which has defects and problems. 
    1. Download repository & get code running locally - up to 0.5hrs
    2. Do the work - 1hr 
    3. Deploy to a development environment & test (0.25hrs)
    4. Code does not work. GOTO step 2
    5. Commit code, create pull request, & participate in the code review (0.25 x 2 devs = 0.5hrs)
    6. Code is rejected. GOTO step 2
    7. Deploy to a QA environment & test (0.25hrs)
    8. Fails QA. GOTO step 2
    9. Tag & cut the release (0.125hrs)
    10. Deploy to a UAT environment & test (0.25hrs)
    11. Fails UAT. GOTO step 2
    12. Deploy to production environment, put live, then quickly smoke test (0.5)
    I hope my following calculations are correct...
    0.5 + 
    1 + 0.25 +
    1 + 0.25 + 0.5 +
    1 + 0.25 + 0.5 + 0.25 +
    1 + 0.25 + 0.5 + 0.25 + 0.125 + 
    1 + 0.25 + 0.5 + 0.25 + 0.125 + 0.25 +
    1 + 0.25 + 0.5 + 0.25 + 0.125 + 0.25 + 0.5
    = over 12hrs

    It is important to note that this is a really bad scenario. Something has gone wrong at every part of the process. Failing Code Review and QA and UAT should be very rare. However failing at least one Code Review or QA or UAT is quite common, and should be expected.

    Programming is very difficult. So the reality of bugs/issues falls somewhere between the ideal (no defects or problems), and the bad (has issues at all stages).

    It is also important to note that unknown obstacles pop up which a developer must address. For example, any frontend developer will know about versioning/dependency issues with their tooling. I have never met a seasoned .net backend developer who has not yelled at the top of your lungs when they realised a Windows update has broken something.


    Final Thoughts

    In reality there is no such thing as a 1hr task. Even the most ideal scenario has parts of the process which are not accounted for, which can easily push the real time spent to 3hrs. Even bundling items together does not effectively eliminate this reality. 

    Programming is hard, and there is no such thing as bug-free software. A release with multiple tasks will have at least one item which is rejected at Code Review, QA, or UAT. Good processes only mitigate defects and problems. 

    I hope that this article has given some insight in what it is like to estimate effort in hours. There is no such thing as a 1hr task. What ever your estimation strategy, you need to account for this reality so you can stay profitable.











    Sunday, 9 June 2019

    Umbraco Codegarden - Moving to dotnet core

    A little over 2 weeks ago I ran an open circle which was aimed at getting Umbraco transitioned to dotnet core. The discussion group centred around what the community can do to help speed up the transition.

    Umbraco's Current Structure

    As it stands, the current Umbraco solution structure looks like this:



    Umbraco's Future Structure

    Moving forward, the proposed solution structure will look something like this:



    Note: The new solution structure will be maintained in a separate branch. The rationale is that the changes required to get there will create many frequent breaking changes.


    Community Tasks

    The stages to reach the proposed structure will require significant refactoring. There are various tasks which are simply too complex (with too many interdependencies) for non-HQ people to accomplish. However, we managed to pull out specific tasks which are isolated enough for the community to have a go with.

    I have created issues on the Umbraco issue tracker for these items:


    Requiring Discussion

    A more complicated issue arose from the discussion around how Umbraco does imaging. Namely, how do we abstract that functionality? 

    Shannon suggested to create an RFC so it can be discussed:

     

    Final Thoughts

    Dotnet core 3.0 is coming out at the end of the year (November?). Umbraco realistically needs to wait until at least this time before it can investigate MVC related refactoring. In the mean time, there is a huge amount of refactoring to do. The items in this article are available to the community, and are just the first wave of refactoring which is required.





    Sunday, 2 June 2019

    Good Help Is Hard To Find - Tips When Hiring Digital Producers

    This is the seventh in a series of articles which will summarise my last half decade of hiring/outsourcing/offshoring experience as Head of Technology at the Cogworks.

    Firstly, I will only be using the term Digital Producer, rather than Project Manger.

    Read more about Digital Producers vs Project Managers.

    Introduction

    The best Digital Producer I ever worked with was a great facilitator. They didn't manage people. They managed obstacles. They lined-up work and unblocked our path.

    Hiring a Producer with the right background and attitude can be great for your work and company culture. If you work in software development you can almost always benefit from Agile methodologies, and that's what this article will feature.

    On a related note, in Scrum there are no Project Managers, only Scrum masters and Product owners. This article will dabble with a few Scrum terms, however it is aimed at companies who are not yet very Agile, and are still hiring "Project Managers".  Learn more at scrum.org


    Attitude

    Having a good collaborative attitude is probably the most important attribute to any Digital Producer. 

    Developers can self-organise, and don't need an overlord *ehem* "Project Manager" to question what they are doing. They just need someone who can line up features so the developers can swarm on them. They need a person who can manage obstacles, not people. 

    Here are a few useful questions I wish every company would ask during the interview process:

    1. On a scale of 1-10, how much do you trust the developers in your current company.
    If the answer is anything less than an 8, then you should raise an eyebrow. They are essentially saying that they don't really trust the people they work with, and might be micro-managers.

    2. When a developer told you that something was taking longer than expected, what was your response?
    The answer you're looking for is something similar to: "I asked them is there was anything I could do to help us deliver?", then "Let's talk about the things we can deliver, and then go talk to the Product Owner / stakeholder to discuss re-prioritising the backlog and next steps".

    3. Can you tell me about your daily stand-ups?
    The answer you are looking for is: I try to facilitate the team talking to each other to solve blockages. I don't understand everything they're saying, but after 10-15mins if they have determined a plan of action for the day then I've done my job.


    Agile / Scrum / Kanban

    If your organisation is producing software then Agile experience should be very important for you. MVP, iterative releasable sprints, get feedback, adapt. 

    If you have Producers who are not at least scum certified, then definitely make this your first priority. 
    The scrum.org certifications have a pass mark of 85%, so if the person has a certification from there, it is an indication that they have actually learned something about scrum and agile. The courses really challenge your views on how a project should operate. Someone who is Scrum certified is much more likely to be a facilitator. 

    Kanban is all about smooth flow, throughput, visual cues, measurement, and swarming. If person has this experience (ideally a certification), then it is more likely that they know how to facilitate smooth running of a team. Kanban doesn't care about assigning tasks to people, but rather encourages a pull based workflow where anyone can do the work. Kanban coupled with Scrum is a sweet spot which will see benefits of both.


    Tooling 

    An experienced Producer should be able to tell you about the pros and cons of the tools they have used in regard to:
    • Feature mapping
    • Task tracking
    • Burn-down & burn-up charts
    You should be able to ask them about Stories on Board, Feature Map, Jira, Kanbanize, Leankit, Trello, spreadsheets. They should have an opinion. 

    If they are struggling to articulate their options then you should support them in their learning. Give them the task to review other platforms and present their views to other Producers. 


    Prince 2 & Waterfall Experience

    I'm not a Prince 2 expert, but I'll do my best...

    This type of certification has specific uses. For example, fields where safety and regulation matters such as construction, medical, legal all lend themselves to heavy documentation / regulation / check & balances. The functional requirements and initial documentation are heavily front-loaded.

    It is useful to understand different methodologies, however if you are working in digital agencies, software, or an organisation which is wanting to "be more agile", then this qualification / experience is not a priority on your search. People with this experience will likely be more inclined to be a "classic" PM who "controls" the workflow, rather than facilitates it. It might be hard to shake that habit. That said, if the person is smart and has a good attitude then get them Scrum certified ASAP and see how they adapt to your environment.

    On side note, you can definitely run a Scrum/Scrum-ban workflow inside a waterfall project. Just keep in mind that if you already have Scrum running relatively well, then a person with only Prince 2 experience might appear as being a micro-manager.



    Final Thoughts

    Attitude is super important. It can make or break your culture. Put heavy emphasis on finding out if the person you hire can jump in and facilitate your team, not "run" it.

    Having Agile experience (ideally scrum and kanban certifications) can give you some confidence that the person will be more likely to be collaborative, and facilitate smooth workflow.


    Check out my Scrum certification reviews below:


    Posts In This Series

    1. Interview Tips for Technical Leaders
    2. Tips To Ensure Quality Delivery When Outsourcing
    3. Tips When Taking On An Intern
    4. Tips When Hiring Senior Developers
    5. Tips When Hiring Junior Developers
    6. Tips When Offshoring Development Teams
    7. Tips When Hiring Digital Producers
    8. Tips When Hiring Remote Developers (coming soon)
    9. Tips To Improve Developer Retention (coming soon)
    10. Tips When Hiring Lead Developers (coming soon)
    11. Tips To Improve Developer Retention (coming soon)













    Saturday, 1 June 2019

    Technical Director at Radley Yeldar


    Three weeks ago I ended a 7.5 year run at Cogworks. I was planning on taking a big break, do some contracting, and see what the universe had to offer. Then came along a role which I could not pass up.

    Where Did I Land?

    Three days ago I started at Radley Yeldar (based in Shoreditch) as their new Technical Director. The organisation came from a business reporting background. They moved into print, brand & strategy, and now into digital.

    Staff perks include a roof terrace with a BBQ and a hot tub, and yoga on Tuesdays.


    What Will I Be Doing?

    Organisational and production processes are the things which I find very interesting, and I have been hired to usher in a new age for the digital side of the company. In the coming months I will be putting my energy into educating people from various disciplines about what it means to be Agile. I will be talking about Scrum, Kanban, and Lean Agile at every level of the company.

    I will also be looking at the current technology stack, how to optimise dealings with technical partners, project rituals, workflow management, and even sales incentives. Exciting right?!


    What About Tech?

    There is a lot of work coming up, and this is a very exciting opportunity. The team will help guide improvements in all of aspects, so this will be a clean slate where the team can choose the right technologies, the right tools, the right processes, the right training, and the right new people. I started this initiative on the second hour of my first day, where I held developer meeting and asked these questions:

    What do we do well?
    What can we do better?


    And before you ask...Yes Umbraco all the way!


    What About Developers?

    To meet the needs of up coming work, the team needs to expand rapidly! I have already put together a plan to hire 7 more developers. I will immediately seek to hire 1 lead, 3 seniors, and 3 mid-weights, with an initial requirement of 5 contractors (Umbraco) until we fill those roles.


    Final Thoughts

    When I left Cogworks I didn't actually want to take on another a full-time role so quickly. However, this role at Radley Yeldar  was so appealing to me that I could not resist. Organisational & Production processes are really interesting to me, and the prospect of rapidly scaling a development discipline is too exciting to turn away.

    Keep an eye out for great new tech deliveries coming soon from RY!








    Monday, 27 May 2019

    Stop Booking Developers

    Introduction

    If your organisation is booking developers then your quality could be better, your delivery could be faster, and your developers could be happier. 

    Organisations with digital/development departments will very often have projects, maintenance, support, and emergency work. When trying to mix these types of work, common questions you will hear include: How is this work scheduled? Who is working on this task? If your company is asking these questions then you are doing it wrong. 


    Class of service Issues

    Projects & Large Features

    Note: I tend to lump Projects and Large features into a single category as the development cycle tends to span many weeks. Projects tend to take months.

    This type of work would typically be booked in for specific developers to start on a specific date. That sounds quite normal, but what happens when their current work is taking longer than expected? What if a work item is super hard and a dev doesn't know how to do it by themselves?


    Support & Maintenance 

    Support & Maintenance work is typically small and might include small-medium features. The timing would likely be hours to days and is normally scheduled for specific developers to work on. That sounds quite normal, but what happens when they are sick, or are taking longer on previous tasks?


    Bugs & Emergencies

    If bug is not critical then it is common to schedule it in the same way as Support & Maintenance (see above). If the severity of a bug is high, then you will often see devs pulled off from other projects / work so they can deal with the emergency issue. That sounds quite normal, but what if the emergency is super hard to diagnose by a single person? Also, didn't you just kill the velocity of another piece of work?


    The Problem with Booking People

    All of the scenarios above have been examples of optimising for utility. As you can see, the practice of booking specific people for specific work is very fragile and susceptible to variances (eg. sickness, delay). Another important issue is that very often devs need help from other devs. How does this affect the other work?

    If you are booking developers then you might often see Project Managers fighting over "resource". This is really dehumanising for their colleagues, and causes a great amount of unhappiness.

    A better approach is to forget about booking individual people, and start thinking about how to optimise for throughput. After all, it's the delivery (throughput) which the customer requires.


    Optimising for throughput

    The first thing you need is a mindset shift. Forget about booking people. Throw this practice out the window. It's full of problems. The key is to have a pool of developers who organise themselves to adapt to the situations. 

    When developers self-organise this will often involve 2 or more devs swarming on a single work item. For example, it is very common for a single dev to take 2 hours to find a solution to an issue, where 2 or 3 devs working together might solve it in 10mins. This is optimising for throughput. Do the math!

    When developers self-organise, the work will be done quicker, and actually be better quality as the devs will need to come to a consensus about the approach. There will be less bugs!


    Kanbanizing Bugs & Emergencies

    In this situation we have a team of devs who tackle tasks together like a wolf-pac. All you need to do is line up the work in priority order, and they will handle it.

    If and emergency comes in then it goes to the top of list. Just notify the wolf-pac and someone / some people will deal with it. 


    Kanbanizing Support and Maintenance

    This class of service can be handled in the same way as Bugs & Emergencies. Depending on your requirements, you may have a team that can handle small work from several projects. This is ideal as it spreads knowledge among many people. Depending on the situation (eg. size of team), you could merge this team with the bugs and emergencies team. The key is to have enough devs to actually swarm on work.


    Rotating For Projects and Large Features

    But what about Projects & Large Features? Shouldn't you "book" those developers? Well kind of but not really.

    For example, every project should have a technical lead. However, it doesn't mean that they need to be developing. They can take a technical oversight of the project, and attend initial meetings. In fact, I recommend at least 2 technical people attending all meetings. So you really only need to ask the devs who will be the tech lead.

    The devs on a project should come from a rotation of the the other teams (Bugs & Emergencies, Support & Maintenance). Obviously you need to have enough devs for all classes of service otherwise they cannot rotate. When some work comes in that requires you to augment your capacity, then the new developers go into the pool, and the existing developers will help decide who is best suited for the new project.



    But When Will It Be Started?

    I have been in situations where people are pushing for work to start. This inevitably means stretching out the developer pool to only 1 developer per task. This means no more wolf-pac, and no more swarming. It is totally bonkers!!!

    Asking "when will it be started" is the wrong mindset. It means nothing without knowing your Cycle Time.

    The questions should be "What is our Lead Time?" and "What is our Cycle Time".

    This is a very easy question to answer. Based on the current team, they will have a known average throughput. If a team delivers 5 items per week, with a standard deviation of 1, then 20 items will be delivered in 4-5 weeks. This is our Cycle Time. If we already have 5 items in the pipeline from a previous set of work, then our Lead Time is about 5-6 weeks. I hope my maths is correct :)

    You don't need a gantt chart or even a burn down chart to figure this out. More on this in a later post.

    To find out more about Kanban and statistics, check out Lean Kanban University.


    Final Thoughts

    Booking developers comes with so many problems. You will constantly be chasing people, asking when people will be available, wondering why another work item is taking too long, appologising to clients etc. Creating developer pools really elevates all of this stress. Using Kanban to manage workflow also gives you very clear statistics of how the workflow is going. 

    I hope you have seen the benefits of optimising for throughput. The work output will be more predictable, faster and better quality.




    Monday, 13 May 2019

    Job Titles Form Mindset - Digital Producers VS Project Managers


    Introduction

    Job titles form mindsets and behaviour. I have been working in digital/web since 2007, worked at several companies and with dozens of Project Managers. Many organisations want to be "more agile", and it is my opinion that one of the first baby steps is to fix job titles. An attitude change requires a mindset shift.

    In this article I will discuss how to get your Project Managers to become more collaborative and less authoritative. This is a stepping-stone to a more collaborative Scrum mentality, as Scrum does not have the job title of Project Manager.

    If you come from a traditional project management background, then I ask that you please keep an open mind.


    Project Managers

    Project Managers are not evil, and most of them are not jerks. Very often the pressures that are felt by designers and developers are due the pressures "pushed" onto the PMs from further up stream (eg. client services, the company). This can exacerbate undesirable behaviours such as micromanagement.

    Many would agree with the opinion that this stems mindset of what a "Project Manager" is meant to do. They are meant to "manage". However, this elicits certain types of communication and behaviour which can dehumanise their colleagues. It is obviously not the PMs intention, however this is a result.

    Every time I hear these phrases / questions, I cry a little inside:
    • How do I book a designer for my project?
    • How do I know which developer will be assigned to my project?
    • When will you be done using Greg? I need to use him for my project
    • Can I have Greg next week?
    • I need a QA resource

    These are common things you will hear in a standard digital agency. The problem with these phrases is that they dehumanise the people who they are referring to. The people you work with are no longer people. They are resources to be handled and monitored. I have seen how developers and designers have been micromanaged and traded between PMs as if they were sauce bottles on a dining table. I have also seen really poor behaviour where PMs have become aggressive when it came to "protecting their resource", they were untrusting, micromanaging, and have even stopped other developers asking "their developer" for advice/help. This totally sucks, and is very bad for your work culture and morale.

    But but but... how else is a Project Manager is meant to manage things? Isn't a manager meant to manage tasks, people, time, etc. My project success means that I will get a promotion/pay increase.

    It doesn't have to be this way...


    The Best Manager Does Not Manage Anything

    The best "PM" I have ever worked with was an absolute joy. He didn't manage people, he didn't manage our time, he didn't manage our tasks, he didn't manage the client, he didn't assume any type of authority over anything in the project at all. He wasn't a Project Manager in the traditional sense. He was a facilitator

    He lined-up work, collaborated at ground level with everyone, asked if we needed him to do anything, he let everyone make their own decisions, he unblocked our obstacles, he cleared our path so we could succeed. He was an absolute joy to work with. He helped us produce great products for our customers. But he was not a "Project Manager". He was part of the project team, and trusted his teammates to do their part. The projects where he was involved in were the smoothest I have ever had the pleasure to work in.

    What I have just described is a person who would pass a scrum.org certification without even doing the training.


    The Mindset of a Digital Producer

    When you refocus people on producing value rather than managing people/things, then a shift in mindset occurs.

    If you work in the digital space, you may have come across the role of Digital Producer at some point. It is very interesting that when a Project Manager title is changed to Digital Producer, then a load of different behaviours can emerge.

    There are plenty of PMs out there who are "managing" projects which have little value to the stakeholders/customers. However, a Digital Producer is actually meant to "produce" value. This is a mindset shift which can encourage more a collaborative attitude and behaviours.

    Many would agree that the job title Digital Producer better suits an Agile environment. The job title of Digital Producer not only sounds cool, it doesn't come with all the baggage of being a traditional PM. There is no longer an expectation for you to "manage" anything or anyone. The team/company/organisation only expects the person to facilitate the "production" of value for the customer/stakeholder. 

    If you are a Project Manager at a digital/advertising agency, you should totally ask for your title to be changed to Digital Producer. It is so much cooler!


    Digital Producers, Scrum Masters and Product Owners

    Let's talk briefly about Scrum...

    The next evolution of Digital Producers, is a splitting into 2 different roles which are Scrum Master and Product Owner.

    In scrum a Product Owner understands the stake holder's needs. They line up the features, and have full control of the backlog because they know what is most valuable to the stakeholder/customer. The Scrum Master is the facilitator of smooth workflow. This person is a coach. They prompt and facilitate conversation, and encourage people to be more mindful of good habits and processes. They are a servant leader.

    I have seen scrum work properly. It is amazing!


    Final Thoughts

    Job titles actually form a mindset, and these mindsets form behaviours. "Project Managers" are not bad people, however their title and role elicits some behaviour which really can dehumanise the people who are meant to be their colleagues. This is especially the case when the PM is getting pressure from further up stream.

    By changing the job title of Project Manager to Digital Producer, it can drastically affect the mindset of those in this position. People will start to be focused on "producing" value, rather than "managing" tasks & people. It is one potential first step in becoming more agile, and on the right path to facilitating production and fixing your work culture.

    I hope this article gave you some food for thought.




    Agile Mindset 

    A mindset shift starts from the right knowledge and training. If you are a leader who wishes to promote a real organisational change, then I highly recommend the Professional Agile Leadership certification.

    Check out my Scrum certification reviews below:





    Wednesday, 8 May 2019

    Good Help Is Hard To Find - Tips When Offshoring Development Teams

    Good Help Is Hard To Find.

    This is the sixth in a series of articles which will summarise my last half decade of hiring/outsourcing/offshoring experience as Head of Technology at the Cogworks.


    Introduction

    Finding good developers is especially difficult during rapid scaling, and even more so when you have budget/time constraints. Offshoring is a potential solution, and can potentially save your company a lot of money.

    I helped to set up our Krakow office way back in 2015. I tried to keep the Polish developers integrated as much as possible, and devised policies to help with communication and team building. Part of this involved travelling to Krakow very often. I got to experienced the culture, food and of course the vodka.

    In this article I will present a few of the challenges I tackled when offshoring.


    Currencies

    Before I get started on the real part of this article I just want to touch briefly on fincances.

    Back in 2015 the Zloty was 1/6 of the GBP. Then June 2016 came along and the GBP took a nose dive. Suddenly our staffing costs and office increased by 20% literally within 1 day. All I can say in this scenario is, ensure that you give yourself a buffer to account for fluctuations in your exchange rate.

    The next thing we didn't expect was that the Polish developer market started to boom. Much larger companies were opening offices in Krakow and Warsaw, so the competition for workers was fierce. Suddenly our devs were being offered double the amount that we were paying them. We couldn't keep up with the pay increases so we had to offer much more flexibility and other work perks.

    If you believe offshoring is a great way of saving money, I hope this story prompts you to think about mitigating these issues. We definitely didn't think of the possible financial consequences when we started.


    Understanding The Workers

    There are stories that float around which can be quite damning of Indian developers, however the people complaining about them tend not to understand the type of developers they are getting.

    Indian IT has a reputation for workers who do what they are told... to the letter. This can be a great advantage if this is what you need.

    If you want to create an offshore office, then you need to understand the type of workers you are getting. Culture and work culture need to be understood.


    Culture Gap

    There are definitely some cultural, work differences, and faux pas which you need to look out for.
    Offshoring from the UK to Poland and surrounding countries is relatively painless. Although, if you ask anyone from Poland about "Eastern Europe", they will remind you that they're not in "Eastern Europe", as they are actually geographically central to the continent. So don't tell a Polish developer that they are in Eastern Europe, as they might get annoyed at you.

    Basically, you need to ask questions. Ask your new colleagues if there is anything that foreigners say/do which they find annoying or offensive. This is a great way to actually begin to bond with your new colleagues.


    Time Zone and Office Hours

    The time zones can matter if you need crossover hours for meetings, pair programming, code reviews etc. Even if you are in Europe, and offshore within Europe then you still need to consider differences in office hours.

    For example, the Polish work life-balance is one to be envied. Generally, they drop their kids at school around 7-7:30am, start work by 8am, then pick up their kids at 4pm. It's is a very natural time schedule. Contrast this with UK working hours, and you essentially have Poland starting at 7am GMT , having lunch at 12pm GMT , then leaving the office by 3pm GMT . You realistically only have around 3hrs of crossover time once you factor in lunch. This is with only a 1hr timezone difference!

    The issue of crossover office hours obviously becomes more prominent with larger time zone differences. My personal opinion is that it is far easier to work with offshore offices if your timezones give you at least 2hrs of crossover. You cannot realistically expect that someone living in Sydney can be on regular calls to the UK. You really need to consider how you can adjust your processes, and what type of crossover is acceptable (if any).


    Integration

    I have to say that my experience offshoring to Poland has been very positive. Polish developers are very high quality, they have a good work ethic, and give you opinions and feedback. They are highly educated, and can argue with you about architecture and design patterns. I couldn't ask for a better team.

    I made a concerted effort to integrate the Polish staff with the rest of the company. This took a lot of work, and I personally flew to Krakow very often to ensure that they felt like we were all one family. I often came with office improvements, gadgets / equipment, and even pay increases. You could probably make the analogy of a father coming home with gifts after a long trip. Part of the integration was also daily video calls so everyone could talk about what they were doing. This also becomes a great perk for your staff. I personally love seeing a new city.

    Remember that your offshore office is as an expansion to your current office. Don't call them your "offshore team". They're not another team. They're just working remote all the time. To avoid an organisational silo you need to put in the effort to make them feel that they are part of the family.



    Team Building

    Video calls are essential for ensuring that people feel connected. It is very easy to just use voice calls, or slack messages, however seeing people is far more powerful when creating human connections. So get your Internet connection fixed! No excuses!

    Another important practice is physically sending people between offices. Nothing beats working across the desk from someone, small-talk at the coffee machine, and going for lunch. Do this every month. When a person is booked to come to your office, people will get excited about it, especially if the person has never come to their country before.

    An important note about Polish culture... The first time you go out with your colleagues in Poland they will feed you more vodka than you ever thought possible. Team bonding drinks will take a year off your life. It might also costing you an extra cleaning bill at your Hotel/AirBnB *eyes rolling*.


    Tips For Offshoring Your Development Team


    1.  Know your workers, and what you're getting
    2. Understand the culture of the people you're hiring
    3. Try to only offshore to a location within a few hours plane trip away
    4. Send staff to and from the offshore offices at every month
    5. Enforce a video policy
    6. Treat your offshore office as 1st class citizens in the company


    Final Thoughts

    Many companies treat their offshore office as an outsourced office. It takes a lot of effort to ensure this doesn't happen. Treat your offshore workers as 1st class citizens, and try to understand them & their culture. Be diligent and you can build far better relationships between your staff.




    Posts In This Series

    1. Interview Tips for Technical Leaders
    2. Tips To Ensure Quality Delivery When Outsourcing
    3. Tips When Taking On An Intern
    4. Tips When Hiring Senior Developers
    5. Tips When Hiring Junior Developers
    6. Tips When Offshoring Development Teams
    7. Tips When Hiring Digital Producers
    8. Tips When Hiring Remote Developers (coming soon)
    9. Tips To Improve Developer Retention (coming soon)
    10. Tips When Hiring Lead Developers (coming soon)
    11. Tips To Improve Developer Retention (coming soon)