Category Archives: Agile

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

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 PokerPlanITpoker 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.

You screwed up. Now what? 8 things professionals should do next.

It wasn't her.

We’ve all been there:
We missed a deadline.
We promised something but didn’t keep the promise.
We let a bug go to production.

Sometimes the effects are just annoying, sometimes they may have a big impact for other people:

  • If your deadline is “before that super important event” and you miss it then, well, an event like the FIFA World Cup won’t be postponed just because you‘re late.
  • If that bug you deployed to production messes up data and you need to restore from yesterday’s backup then you’ll lose today’s data. At least this way you can undo the damage…
  • …but if that bug causes a zillion mails to be sent out containing coupons for a web store then you won’t be able to undo it.
    (Yes, this is based on a true story. Interestingly, although it had caused some financial damage on the first days, eventually, it turned out to be the most successful marketing measure ever for that store. Still embarrassing for us developers, though.)

Sometimes we find out by ourselves that we screwed up.
But sometimes it’s other people who break the news – clients, bosses, co-workers, friends.

So, what should you do?
Here are 8 recommendations on how a professional should handle it:

1. Listen

First, listen to the person who is complaining to you.
Don’t defend yourself, deny it, wipe it off, ignore it or pull an excuse.

Be open.
Mind your body language:  avoid crossed arms, aggressive, exasperated or amused facial expressions.

Listen calmly, even if the other one speaks emotionally.
Showing this kind of respect and interest is the first step to restore your integrity.

You needn’t be mute all the time, though.
Ask questions: “what happened?”, “when did it happen?”, “who was involved?”.
Ask for facts – but don’t ask “why did it happen?”. It will only blur the facts and might lead to premature bias. Plus, it’s actually your job to find out the reasons.

2. Show you understand

Listening is good but you should also assert the other person that you’re not just play “the nodding game”.
Paraphrase what you have just learned.
Show you understand the impact, the problem that the other one is facing now.

3. Be grateful and show it

Always – really: always – say “thank you for telling me that”.
You may not always fully share the other one’s opinion but he/she talked to you – and that’s great.

Why?

Criticizing someone is tough. It makes people feel uncomfortable when they do it. Some folks go to lengths in order to avoid criticizing someone else to the face.
Anonymously? “Oh sure, no problem. Let’s post something on the internet…”
By email? “Yeah, and I’ll send it out late so the addressee can’t call me back today.”

But those people who criticize you do give you direct feedback although it may make them just as uncomfortable as you if you were in their position.
Ultimately, this means they care about you, especially if the criticism was face to face.

Be grateful for it and say so.
It will be the first step to restore the relationship between you and the other one.

4. Apologize

Say you’re sorry.
What exactly you are sorry about depends on the situation:

If you know you screwed up personally then say “sorry I screwed up”.

If you’ve just learned about the issue for the first time or you’d like to investigate some more before you “confess” then there’s still something you should always show empathy for:
Someone (who obviously cares about you) is having a problem, so say
“I’m sorry that you’re in this mess now”.

This way you avoid a premature confession but you still continue restoring the relationship between you and the other one.

(If you later find out you or someone else you are accountable for really did cause the problem then don’t hesitate to apologize for screwing up.)

5. Take responsibility

If you are personally accountable then say so.
Continue by promising you will take measures to prevent the problem in the future.

If you are not personally accountable or not sure if you are or who is to blame in the first place then, at least, say:
“I’ll take care of it”.

It’s important to show the other person that the time, emotional strain and courage talking to you were not in vain:
You’ll take care of it, albeit just delivering the information to the people you know are really responsible and will take it from here.

Even more importantly, this step should be the turning point.
So far you have been the “receiver” of information, the more passive partner of the conversation.
Now it’s time to become active.

You can start by saying that what happened is clearly not how you / your team / your company usually work. Continue by explaining what should have happened instead.
Say “I’ll take care of it” and start being the active partner. Assert the other person of your skills and your drive to fix and improve things in his/her interest.

6. Fix it, help fixing it

The most important task should be to fix the problem.

If you can’t fix it yourself at least ask the other one if there’s anything you can help with.

Restoring your integrity and the relationship is selfish if you don’t focus on the problem resolution first.

7. Learn your lesson

It feels strange saying this, and it might upset people who had to criticize me but screwing up is the best driver for learning.

Embrace it.

A lot of the things I know today, maybe even most of them, I know because I learned from having screwed up or being criticized for.

Analyze the problem, drill down to the root cause, research potential solutions, evaluate, implement… this is how I learned about estimations, deployments, hiring, quality assurance, project management, Oracle’s bizarre licensing terms and many more.

Also, use this step to make sure you don’t run into the same mistake or a similar problem for the same reason again. The first time it’s a tragedy, the second time it’s a farce. If you keep screwing up eventually you will lose credibility.

8. Follow up

You said you’d take care of it, so get back to the person who criticized you and show what you’ve taken care of so far, e.g.

  1. The fix. And ask if it worked.
  2. Show you care: ask if the other person’s problem has been resolved or at least mitigated.
  3. You will most likely have new, updated or revised information. Share it.
    Show you’ve worked hard.
  4. Show your lessons learned and the measures you have taken to prevent the same thing from happening again.

What do you think?
How do you handle negative feedback?
Please leave a comment and let me know.

If you like this post then please share it.

Happy hacking!


Image: my wild princess at the age of 2.
(c) Andreas Czakaj, all rights reserved.

100% Code Coverage via automated tests in Symfony applications

On 2017-04-26 the Symfony User Group Cologne gave me the opportunity to speak about Code Coverage.

If you create software that is planned for continuous enhancements and maintenance over several years then you’ll need a sustainable strategy for code quality.
Code coverage by automated tests is one important metric, and its value should equal 100% at all times.
My talk shows why this is so and how it can be achieved in PHP / Symfony based applications.

See the full presentation at Speaker Deck