Category Archives: IT Management

Agile in Distributed Team Setups

Conference Call Bingo

“Conference Call Bingo” – Source: https://imgur.com/gallery/rfnve

Working in distributed team setups has a bad reputation – for good reasons. I remember many frustrating and useless telcos, so how can this kind of collaboration possibly work out in an agile team setup?
Spoiler alert: if you allow people to do home office you already have a distributed team setup.

After I had blogged about this some weeks ago, I was lucky to give a presentation on this topic at the ProductPeople conference in Cologne in May of 2019. You can find the slides on SlideShare: https://de.slideshare.net/AndreasCzakaj/agile-in-distributed-team-setups

How to deal with boring tasks

Source: pixabay, https://pixabay.com/photos/person-little-boy-kid-child-731165/

Over the years I’ve had some conversations with people in my teams about them feeling bored with their tasks.

In my early days as a manager my natural reaction was something along the lines of “that’s why it’s called a job, not the fun-hobby-zone”, sometimes just in my head, sometimes spoken out loud.

Fun fact: this does not help.

First, as a manager you should always be happy when one of the people you are responsible for approaches you. They are the few that speak their minds, while many others don’t and will potentially vote with their feet and quit the company.
Ever heard someone say in a job interview “I left my previous company in order to learn new things/become more experienced/felt stuck and wanted to progress”? Yeah, that’s boredom their former managers ignored.
That’s why I’m always glad when people approach me with any of their problems and I always take them seriously.

Second, empathy.
Let’s be honest, we’ve all been there. Everybody has had to work on things they found boring. It’s a real thing. The subsequent content is based on what I found useful for myself first.

When someone tells me they feel bored I reply in 2 ways:

1 – Intrinsic View – Set yourself a challenge

  1. It’s in your head
    No task is boring per se. “Boring” is just your own interpretation of a task that should best be called “repetitive“.
    Look at it this way: It probably wasn’t boring to you when you did it for the 1st time.
  2. Automate it
    If it’s a repetitive task that you understand well, how could you automate it?
    For instance, if you have to copy data from one place to the other, then how about writing a script?
    Many great inventions were driven by boredom or laziness.
    Check out “jobs-to-be-done” for example. Everything that feels annoying to a large enough number of people is a hidden business opportunity that’s waiting to be picked up.
  3. Vary
    I’ve programmed a ton of pretty common functionalities in my days like login forms, registration forms, deployment scripts etc. How about trying something new while you do it, leveraging your experience?
    Maybe try to validate the data with a different and more elegant approach, avoid conditions and favor stateless functions? Get to 100% code coverage this time, try data driven or mutation testing? Try a different set of libraries or framework? Increase security, e.g. using a Captcha, honey pots, or try to hack yourself with a fuzzy logic attack script?
    #TimTowtdi (There is more than one way to do it)
  4. Abstract it & teach it
    Everyone who is an expert in anything was at a crucial point in their career: “OK, I understand it now. I could move on to the next thing – or I could dive deeper into it, abstract it, teach it to others”. See also the “Feynman Technique“.
    Repetition is a core element of becoming an expert.
  5. Improve it
    If you’re really familiar with a task because you’ve done it a bunch of times, then you could think about how its execution can be improved so everyone benefits from it.
    Your experience is a chance to make a difference.
  6. Delegate it
    Last but not least: repetitive tasks are good candidates for things you can delegate to more Junior staffers. This implies that you have to explain the task to that person, see “Abstract it & teach it”.

2 – Mix it up

Common sense tells us that having the same people do the same things for as long as possible should yield efficient results. We can assume that they have become true experts by now.

In my experience this has proven to be a fallacy in many cases:

  1. If people do the same things over and over again they do not necessarily get to the point of “Vary” and “Improve it”. I’ve seen teams being stuck with tools and practices like ant scripts and Subversion while the world has moved on to Ansible, Docker and git.
    This is partly the reason why people go from bored to fearful about their careers when they feel that they might not be up-to-date with the job market’s demands and then, eventually, quit.
  2. Even worse, work might be so “optimized” that it’s very hard to change anything later on. And there will always be the need for change some time.
    A process designed for maximum efficiency is a common antipode of agility.
  3. Assuming a “steady-state universe” is dangerous because there will always be fluctuation in your teams to some degree, be it attrition, parental leaves, promotions, sabbaticals, retirement – you name it.
    You should have a plan for how to retain knowledge when people leave and how to onboard new people.

That’s why I recommend mixing up teams every once in a while so people get to know other tasks as well – and to ensure back-pressure against a “steady-state universe” attitude.

From a business perspective, if you do it to early then the invest of time for onboarding might not have paid off yet. If you do it too late then people might leave or work might have become “rusty”, see above. Find the sweet spot.

From a people management perspective, some people are bored faster that others. Get to know everyone well enough to know their personality and ambitions so you can identify when it’s time to shake assignments up.

 

Agree?
Leave your comment, like and share.

Reality-checked Tips for Working in a Distributed Agile Team

Source: https://pixabay.com/en/handshake-hands-laptop-monitor-3382503/, CC0 Creative Commons

Tip 1: Don’t distribute your team members.

Instead, co-locate everyone in a place of their own.

 

Tip 2: Fight hard for tip 1.

Establish a relocation service if needed, find temporary apartments, … be creative.

 

OK… now the problem is that, in 2018, people don’t want to work onsite every day anymore. If you, as a company, don’t offer home office, flexible work hours and support for work-life balance you’re out of the hiring game.

And it keeps getting harder to find good people, too. I don’t know about your company but we’ve been looking for talent from all over the globe, and some of them actually want to stay where they feel at home.

So…

Tip 3: Personal contact is key

Distributed agile teams CAN be successful – but you need to meet in person when you start working and repeat that move every once in a while. I cannot imagine doing a retrospective – in a psychologically safe and effective way – with people that I’ve never met in person before. Lunch or drinks work even better.

Here’s a model that I know to be effective:
Each developer starts onsite, stays for a couple of weeks (3-4), returns back home and works there. Repeat this so people work onsite at least twice per year.

As a result…

Tip 4: Professionalize travel and accommodation

Visas need to be renewed, flights need to be booked. You might want to rent company-owned apartments because hotels are expensive. People need to be picked up from the airport, apartment keys need to be handed over, cleaning service must be managed.

Get good at this.

BTW: keep the additional cost in mind. A distributed team is not cheaper per se.

 

Tip 5: Technology is key, too

Personal contact is the foundation – but you also need decent technology for your in-team communication:

Network

  • Good internet connectivity at each end-point
  • Low latency. It’s super-annoying when someone tries to reply but lags 5 seconds.

 

Audio

  • Good microphones and speakers!!!
    When these are bad you just can’t understand each other which is the end of all communication. And they must be REALLY good because reality makes people with Indian English, German, Russian, Polish, Serbian, Macedonian, Ukrainian, Cockney etc. accent work together.
    For example I learned that “what about the books?” is British “English”(?) for “what about the bugs?”.
  • Good: Headsets
  • Bad: Conference Phones
    If you see any of these (regardless of make and model) throw them away.

    Source: https://www.cyberport.at/haushalt/telefon-fax/telefone/polycom-/pdp/a014-107/polycom-soundstation-2-konferenztelefon.html

    Source: https://www.cyberport.at/haushalt/telefon-fax/telefone/polycom-/pdp/a014-107/polycom-soundstation-2-konferenztelefon.html

  • (There are OK-ish alternatives that can be connected to a PC via USB.)

 

Video

  • Every remote participant should have their cam switched on to promote focus and a more personal experience.
  • For the onsite people:
    • You should have at least 1 high resolution camera so you can film a whiteboard when someone writes stuff on it.
    • You should also have at least 1 more cam to capture the room and people. This makes the experience more natural.
  • Alternatively, you might also choose to have everyone use remote access, even those who could potentially meet onsite. See also tip 6.

 

Tools

  • I love physical boards and stickies. However, with a distributed team, you will have to take pictures of them and send them around. As this can get tedious fast you might want to switch to JIRA, Trello, Targetprocess or similar to do this electronically.
  • For some events you might want to try out some specialized tools. Funretro for example helps you do your retros with distributed people. There are tools for doing planning poker online as well like Estimation Poker, PlanITpoker and many more.
  • Evaluate the right conferencing tool. Google Hangout is reliable and super-easy to use, WebEx also supports telephone dial-in, Zoom allows for handing over your mouse to a remote user, etc. Try some.

Preparation

  • Make sure your tech is up and running by the start of the meeting.
    If 10 people have to wait for 10 minutes it will be a total of 100 min of wasted time. Also, it’s just unprofessional.
  • Even better, have the tech ready some minutes earlier. This way the early participants can just chat and do small talk. This helps getting the team spirit up in spite of the distance.

 

Tip 6: Integrate them all

Make sure working onsite and offsite are truly equal – and be consistent about it.

Do pair programming, feedback talks, trainings, etc. with everyone, regardless of their current location. Do career planning with them and promote people based on their merits, not on their location or onsite-time.

Also, you might want to abolish the concepts of “onsite” and “remote” altogether – make everyone use the same remote technology even if they could meet in person. (As a positive side effect each participant will use headphones so good audio is most certainly a given.)

 

Tip 7: Ensure “mental health”

A CTO Think podcast reminded me of this: Remote work is different whether you work in a remote office, co-working space, a shop of some sort – or if you work mostly isolated in your home office.

Getting a regular, minimum dosage of human interaction has proven to be important, even for nerdy introverts.

 

Agree?
Which tools do you recommend?
Leave your comment, like and share.

The managing n3rd, part I

Source: https://pixabay.com/en/pen-glasses-study-planning-project-2504607/, CC0 Creative Commons

When you write software, let’s say with a code base of 100,000 lines of code, and you screw up only 1 thing then the consequence might be that the program won’t work. You forget to close 1 parenthesis or 1 line is missing the semicolon at the end – as a result it won’t compile.

When you do sales, let’s say you contact 10 potential clients, and 1 of them eventually signs a 6-figure contract then you’re actually pretty successful.

When the software you wrote does not work properly then the reason MIGHT be because of a flaw in the operating system, some bug in a library you use or even cosmic rays – but in 99% of cases it’s just your own fault. The good news, though, is that it’s also you yourself who can fix it.

When you deal with people, e.g. in sales, line management or simply finding a mate, then your strategies need adjustment.
As a coder you’ve been successful by being critical and especially self-critical. If you apply the same attitude to people related situations you’ll fail.

In management, success is not having it right 100,000 out of 100,000 times. Not even close.

In people situations, failure does not necessarily demand diligent analysis. This can lead to over-thinking and making you feel bad about yourself. Failure does not necessarily demand ignoring it either.

Sometimes it’s best NOT to assume it’s your duty to fix something you messed up. Being smart but still just listening to others, showing empathy for the other instead of mainly trying to fix things – that’s the challenge.

Just as you keep learning new programming paradigms, patterns and languages you can also learn new and different ways to deal with people situations and, as a result, advance in your career to a management position.

I know it’s hard for nerds but we’re smart, creative and friggin’ hardcore. You can do it!

 

Agree? Leave your comment, like and share.

XLS Management vs. People Management

Source: https://pixabay.com/en/business-businessman-male-work-2879465/, CC0 Creative Commons

As a manager, how do you make decisions?

Do you mainly base them on spreadsheets and then just pick the lowest or highest value, e.g. the cheapest product or the highest profit opportunity?

Well, tough news for you: that’s what a machine can do and, boy, can it do it better than you!

If you have no empathy, no understanding of values like trust, courage and integrity or any other skill that a machine does not have (yet) then get ready to be replaced soon.