Efficient teamwork from home

Yesterday I had the honor to participate as a key speaker at an EPAM webinar on the topic of “Efficient teamwork from home”. As the topic is trending and attracted a lot of viewers, let me share some key points, tips and tricks presented.

Started with a brief story of one of the most embarrassing projects I have managed years ago. In short, we were a distributed “team” of 4 (2 Devs, PO and me as PM), working on a Drupal-based learning platform. In just a couple of weeks of chaos and non-working-software-delivery we decided to cancel the project, as the frustration in all the parties went to critical level.

The learning from the experience - we messed up all the vital components of developing a successful product remotely, more embarrassing we failed to do so with only 4-members crew:

• Focus
• Alignment  
• Regular syncing

The project left bad taste in my mouth and since then I have aways been 'a little' skeptical on the performance of distributed teams and folks’ contribution while working from home.

So back in 2020, I worked mainly with a squad of brilliant and motivated teammates on an innovative platform for the Airline industry. The following slide tells our story best

In essence, we are achievers, and happy ones. We owe it mostly to our impeccable face-to-face way of working. And, when in the end of Mar ’20 all of us had to work from home, it’s no surprise we were a little bit worried on the impact of our results.

And… surprisingly it didn't negatively

(backlog items delivered per sprint)

Not only we sustain being efficient and effective, but also keep on improving our delivery... and don't mind S32 results - it was our Christmas sprint with only a skeleton crew left to cover.

And, here are the promised key tips, tricks and advices, provided by all the members in our squad.

I. In general

(communication should be clear, brief and on point)

• Keep a conference room open all the time so the team mates could jump in quickly when needed. We use the daily sync conference room/link for the purpose.
• Put your goal(s) as topic in your team chat channel.
• Use separated team channels for the different topics – to help focusing.
• Remind about the upcoming event(s) on the same day over the daily standup.
• Update tasks and put comments in Jira more often.
• Be available for conversations, anytime. Have the team chat and conference apps installed on your mobile.
• Pair Programming works very well with screen sharing. Just do it :)
• Dedicate time to rest away from the the PC.

II. On tooling we use (free & powerful)

• Planning poker: scrumpoker-online.org
• Retrospective board: funretro.io
• Visualizing tools: awwapp.com, ideaboardz.com

III. Collaborating with the other teams

• Scrum of Scrums. Keep it short. Only share blockers, dependencies and highlights (in that particular order, in up to a minute).
• Attend other teams’ reviews, all-hands gatherings, and any other sync & alignment events. Keep them brief and on point.

IV. Personal

• Isolate yourself in a separate room. Helps with focus.
• Dress for work. Helps with the ready-for-work state.
• Beat the social loafing with team-members keeping each other accountable.
• Exercise regularly – it helps not only your body, but mostly your brain!
• Isolate yourself from your family, to keep distractions at minimum.

V. Extra stuff... good stuff

• Play online games with your team mates. It boosts team morale to extraordinary level.
• Do mini hackathon events online, to keep everybody engaged.
• ... work from your balcony... and get some beer :)... classic

On the research side, Nick Bloom’s study on the "work from home" topic seems to be invaluable. It shows clearly the main benefits: "13% improvement in performance in the working from home teams and 50% reduction of the quit rates in the company". (Watch the full study and research summary here)

In the end, let us remind ourselves the big winner in the working-from-home situation is the nature, and it means that we all win (somehow) being stuck in a quarantine. Maybe it's a good idea to think about the future: how could we keep on reducing the city pollution, caused by the daily commuting even without viruses, aliens, software bugs and all other life threats.

All Blacks scrum… is da best scrum

Over a recent retrospective we inspected and discussed the ‘path to greatness’ for every agile team. To learn from the best, we watched the New Zealand Rugby team’s greatest plays

The idea was to identify traits and characteristics, to help us improve. And here is the list we ended up with

Passion & energy 
As Donald Trump says “If you don’t have passion, you have no energy; and if you don’t have energy, you have nothing”. As mentioned by the developers: It's visible and very obvious the All Blacks’ players live their childhood dreams. The passion and the energy are so strong, and the players are turned into unstoppable team force.

Dedication and Willingness to sacrifice 
The players risk grave injuries and even their lives in many of the runs and plays, all in the pursuit of victory.

Clear vision and goal(s) 
To be the greatest rugby team of all times; To win every game and dominate every other team.

Team results > all 
Every player cares only for the common good; There are no internal competition, envy, jealousy, or destructive internal politics

Teamwork all the time, all the way 
Every time a player runs, he is covered by the team! 4-5 players run in parallel, guarding, supporting, removing impediments or just being ready to help if needed. Often, their support is not even needed, still they keep doing it all the time.

Smashing impediments decisively 
Opponent players are neutralized quickly and efficiently. There is no hesitation, everybody acts quickly and decisively when things go wrong.

Everybody leads 
In different plays, different players lead and score. Everybody is eager to act and lead the team to score yet another point and achieve victory.

Great preparation and training
Strength, speed, reflexes, positioning, timing - it is clear everybody is going the extra mile of the extra mile constantly, to be in the best shape.

   

In the end, a quick reminder, even the best scrum could fail sometimes… and that’s ok, as long as we learn

 

Agile games: estimation

Recently in Bulgarian Agile Community meetup we discussed some games and techniques used in Agile, related to estimating. In this post you will find three of them, related to estimation:

I. Estimation buckets
It is a way to do estimation of large numbers of items with a group of people quickly (a good alternative of Planning Poker). It also provides a way to establish initial ‘reference value’ to story points when new teams need to.

1. The product backlog items have to be written on cards. It is preferable if the team members are familiar with the items. A table or wall is setup with columns as per the example

If you do not have a reference for story points just leave the numbers blank and add them in the end.

2. Pick a random item, read it and put it in the middle bucket (under ‘8’). It is to be used as a reference.

3. Pick another item, read it, discuss it with the group, estimate it relatively to the first item and put it left (smaller) or right of it (bigger).

4. Choose another item, read, discuss, estimate relatively and place it in the appropriate bucket.

Note: If it is clear that the items scale towards only one of the sides adjust them accordingly. If the first item is smaller – scale all the items towards left (‘1’), or if bigger – scale towards right (‘100’).

5. Continue until most of the buckets have at least one reference item, and the team members get used to the relative estimation feeling and doing.

6. If there are still too many PBIs, divide them across the team members and let everyone silently (without any discussions) place accordingly.

7. Everyone in the group reviews all the items and if there is a need for correction, items are taken out, discussed with the group and placed back accordingly.

8. Write the corresponding number to each card to record the estimates.

The final result would be something like

II. Estimation game (sort of)

This we do together with some of the agile teams in Continental AG. The purpose is to foresee how many and which items will go to the next sprint backlog. It is useful when there not all team members have the expertise to do each PBI. The sprint is set to three weeks’ timeframe.

1. The PBIs are written on cards or tracked in JIRA and the team members are familiar with them.

2. We take the top ten PBIs and put them into four main categories: small; medium; large; huge.
Small – item could be finished up to a week.
Medium – item could be finished up to two weeks.
Large – item could be finished up to three weeks.
Huge – item is estimated to need more than three weeks for completion.

3. Items marked ‘small-large’ fit into one sprint. Items marked ‘huge’ need to be broken down / renegotiated.

4. Then we do some ‘typical resourcing’ as not each team member have the expertise to work on each of the PBIs. For example John and George will work on item one. Steve is the only one able to complete item two. Nick takes item three, etc… The resourcing is done according the prioritization in the product backlog so it is clear which stories could go into the next sprint.

5. Sometimes it’s not possible to take all highest priority items and the product owner is triggered to choose between 'competing items'.

6. In the end the team comes with a proposal how many PBIs and which ones could fit into the next sprint, as per the example (the green dots):

7. The product owner agrees or renegotiates the items, together with the team.


III. Project box experiment
The purpose of the ‘project box’ is to define requirements for an MVP. It could be used when a large number of stakeholders (e.g. in different departments) need to provide requirements and priorities for a product.

1. Provide each department/stakeholder group with equal amount of ‘fake currency’ or vote points.

2. Let each group define and visualize their idea in a form of a product with characteristics.

3. Individuals from each group to present to all the other groups the vision of the product (MVP) in just 3 minutes.

4. The other groups have to spend their ‘money’ or vote points on each presented MVP.

5. The most ‘expensive / voted’ MVP wins and is a candidate for production or further discussion / refinement.

---

Hope those are useful to you, guys; as usual please leave your feedback in the comments.

Startups, Entrepreneurship … and Agile

Last Wednesday I had the pleasure to be part of the Startup Founder 101 event ‘Meet Experienced Startup Founders’, and the two major speakers Viktor Bilyanski (Founder and CTO of Scalefocus) and Hristo Neychev (Founder & CEO, Tryad Games), shared their experience in entrepreneurship and startups.

Going over my notes here is some assorted key wisdom:

The reality is brutal - 95% of all new business initiatives fail to survive and die in less than 2 years

The most important for each startup:

• Discover, believe in and communicate your VISION
• Find an amazing CO-FOUNDER (really difficult)
• MOTIVATION – keep going when you are rejected, and rejected you will be… a lot
• Find your first CLIENT/INVESTOR

Starting up a new business is like staring a new project – it has a beginning and an end. And the time slot is really tight. You can always go back to the corporate business if it doesn't work out.

When you fail, you still acquire experience and memories. The successful entrepreneur started approx 10 startups throughout entire life.

What’s really great about startups is that you move with your own speed, you only have to convince your co-founder and then it’s a matter of minutes to work on new idea.

To find a great co-founder look for somebody close, somebody you know for years. Somebody serious, motivated and admirable. Most of the startups die due to co-founders divorce and/or team disrupts. And high pressure is going to increase the chances any of those happening… and high pressure there will be.

Fundraising is difficult and at the same time it is important for every startup to get money as quickly as possible. Somebody investing in your business is good not only because it validates your idea/vision, but also because the clock starts ticking and your startup must start delivering. You all become more disciplined… and discipline you will need.

Your prototype, your product, your numbers worth more than the raw idea in your pitch. The investors will invest in your team and the execution not your idea. They want to see a successful team – members to have successful tracking records.

You pitch on vision or numbers and it is much better to pitch on numbers. The successful pitch would outline two major points:

• The TEAM - who are you; how successful are the team members so far; what is the endurance and the sustainability of the team
• TRACTION – how many users/clients do you have; what is the trend; clients profile and sustainability

Angel investors will invest in 1 out of 40 startups presented to them. Venture capitalists will invest in 1 out of 400. If you have rich friends/mentors try them first.

Coming up with an idea you might follow a process like:

• Set FRAME/ VISION/ the window of opportunity / the market
• And then use standard creative process, e.g. 'brainstorming'
• VALIDATE your ideas fast – use paper; Excel and simple tools to prototype fast

Persistently look for feedback – involve users/clients and improve, discard and innovate.

Most of the startups aim for online business because it is easier to scale online.

The biggest challenge is to define and develop your MVP. It needs to be good enough for your market but at the same time it needs to be built quickly to be validated. Be careful in B2B – you cannot afford to show not-polished product.

Do not hesitate to interview people about your product and expected price, but the only validation for the price happen when real purchases are made.

If your startup product is some sort of a service, keep in mind service offering companies do not scale well and depend on their founder too much. Try growing from service to product business.

--

So far so good… but where is the Agile part?
Everywhere… I have always admired startups as they are the truest possible embodiment and validation of the Agile philosophy. Deliver sooner than later, empower teams, embrace the change and be lightning-fast in adapting, continuously improve and deliver, eliminate waste, collaborate well, promote innovation and bow to enthusiasm – all the major principles are followed relentlessly – and it is pure joy to watch and/or be part of.