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.

Team leading :: Find some time for everyone personally

It was many years ago I managed web design projects for a major USA hosting company. On that day I rejoiced after completing successfully some major projects I managed for the past couple of weeks and months. And suddenly the phone rang…

A second before picking up I glanced at the display and the name there surprised me. It was the name of the high level major department manager (position just a level below the company CEO). He was responsible for probably more than 300 folks in different departments and units across the Globe. I had only spoken with him once during my initial interview before joining the company (and it was only a brief talk for a couple of minutes). My initial experience with high level managers up to that moment had one common trait ‘None of them ever speaks to the grunts’. The folks, doing the real job – the high management don’t have time for them. The grunt’s contribution is just part of their gantt chart, report or plan – that’s it, plain and simple.

“Hey Simeon, how are you doing… remember me… I am…” and he started introducing himself. And I knew very well who he is and what did he do. I just didn’t have a clue why he called me, but I suspected I am in trouble.

In the next five minutes I was amazed that not only the manager was familiar with my clients, projects and progress but also congratulated me frankly on my successfully completed work. In the end he just thanked me and wished me even more successful projects in the future. It was a very short call but I felt so validated and my achievements recognised. As a result my motivation was skyrocketing and so was my level of respect for this guy and the company itself.

I also learned probably the most valuable lesson in leadership ‘Find time to say 'thank you' and recognise the work of your folks personally’.

Tips for leading global project teams successfully

Being involved in supporting and leading multi-location / multi-cultural teams there are some general guidelines I follow (more or less). The list turned out to be quite big:

* Find some time for everyone personally. Use the phone or face to face (no e-mail, or chat)

* Start each project with big bang. Team members and stakeholders must get to know and talk to each other

* Use weekly catch-up meeting. E.g. ‘scrum of scrums’ and involve relevant team-members / stakeholders

* Use technology to bring people together (ONLY as a last resort). Use video, not only voice, screen sharing and chat

* Share a common project management platform. E.g. Jira, Basecamp

* Encourage different team members to talk to each other – over the phone or in person. The e-mail communication is to be used only as a back-up channel for the requests

* Have a clear vision and communicate it openly (long & short term)

* Set clear goals

* Have clear responsibilities (could change in long term)

* Don’t stop supporting the coordination between the teams even if it goes really well

* Encourage open communication and listen to the feedback

* Talk to the clients and share the feedback among the teams

* Trust is everything – build trust not only within the same team but also support building trust within members of different teams

* Encourage cooperation

* Friendly competitiveness is also beneficial

* Keep focus on what is really important (never stop prioritizing and get rid of the ‘non-essential’ stuff)

* Celebrate and reveal each success. Spread the successful stories

* Be a good example

* Balance your time well, between stakeholders and team members

* Share and do some of the work. Fill some gaps and support your teams

* Be enthusiastic and positive

* Focus on effectiveness and delivery

* Don’t waste your and your people’s time. Avoid pointless meetings. Be quick and to the point

* Self-management is blessing but don’t be afraid to manage when needed or the teams are in doubt

* Don't just follow the traditions and the rules set. Innovate together with the folks

* Be a human being – it’s not only work. Offer empathy and sympathy when needed


My general vision is to elaborate more on some of those and provide examples in my future posts.

The Scrum master role (advanced)

So let’s start from the basics. As we all know the Scrum books mainly describe the role of a Scrum master as:
- Facilitator / host / organizer
- Impediments remover / support

…And as we all know (again) nowadays there are two major types of Scrum masters hired in the development industry. The first one, we may call Scrum 'masteloper', is part of the team as a developer and contribute directly to the development of stories/tasks. And usually the person is struggling to find the balance between development and Scrum activities. The other type of Scrum master, I also consider part of the team, might not be a developer or should not contribute (often) directly to burning down stories/tasks and is dedicated entirely to coaching, training, supporting, negotiating and running the process as smoothly as possible for everyone.

It’s been a while and, after assuming both roles for different teams, I am now fully convinced that a team could only fully benefit from a Scrum master when his/hers responsibilities are closer to the second type of a role, described above. A Scrum masteloper is simply too busy and too logically oriented to contribute well in all the communication activities, and easily could lose focus on the big picture.

On the other end a full time Scrum master, dedicated only to Scrum activities could pace well, organize well, communicate better and even bring joy and fun to the team. But above all this person would be able to lead the team if leading is within his/hers personal abilities and characteristics. For example, here is a list of what I perceive and do as a Scrum master for my team of software developers:

* The typical stuff any Scrum masteloper will do

• Organizing and facilitating the Scrum ceremonies and process
• Supporting the tools and the stories/tasks organization (e.g. Jira, Trello, the sticky notes and the physical board)
• Keep a list of impediments and resolve or supporting the team in resolving them

* And beyond

• I am persistently negotiating to help different parties (PO, team, stakeholders, clients, management) get to consensus and stay on track
• Clearly communicating the good and bad news (on a daily basis) inside and outside of the team
• Keep myself informed about the importance and priorities of the items in and outside of the Sprint (it’s simply not enough to just look at the backlog – you need to talk to people… a lot)
• I lead and guide the team to reprioritize and commit to deliveries on a daily basis. Developing sophisticated software requires a lot of ongoing effort in discovering risks, issues and sometimes benefits. How we react and handle them on a daily basis is crucial. (Sprint planning can’t identify and predict everything)
• Keep everybody focused on the big picture – the important stuff. It is crucial as most of the developers tend to lose the big picture focus, doing the mundane stuff
• Coach and train the team members so everybody could grow to their best and beyond :)
• Speed the support and consulting provided or received for/by different teams/clients. I just find enough time to talk to other teams, clients and stakeholders. And it’s invaluable to support the Product owner in deciding priorities or even by taking ownership of a client’s issue until full resolution
• Keep the management well informed about the good and the bad within the team. No blame and shame here – only glory :), transparency and real picture. When we are victorious we celebrate together, when we fail we face the consequences together again – but the management team need to be fully aware of what’s going on
• Responsible for the fun and joy within the team. Scrum is meant to be fun… at least more fun than any other software development framework/methodology. I keep the folks spirit high, for example by revealing a funny collage of the last sprint effort I photo-shopped a day before the retrospective or by presenting a useful topic in a funny way
• Keep myself informed of the innovations in the Agile world, my team could benefit from 
• Coaching the guys and spreading the good practices in a specific way that would fit into our particular environment
• You could even see me doing some Project documentation… but that’s more on the PM part :), and only if needed

Scrum issue #08: The Product owner can’t provide enough details

It’s going to happen, sooner or later, but what I would like to write about is the scenario when the issue becomes a repetitive habit.

In some organisations, the role of the Product owner is some sort of promotion or higher step in a corp. career path. A good example would be a development department (a couple of teams), developing complex software (the platform) for internal use within the company. As expected, there would be many clients/users/stakeholders using the platform within the different departments, e.g. the management, sales agents, marketing folks, project and account managers, IT, SYS, HR, etc… They all are going to provide requirements and feedback to fill into the platform backlog. So far, so good.

Let me engage your mind with a tricky question. Who is the most appropriate person for the role of a Product owner in this scenario? To your surprise in many similar cases the manager of the development department will be given the honor. As a result the guy will be overwhelmed with emails and other comms full of requirements and features to feed into the platform backlog. But as he is already a manager, with a lot of responsibilities, do we expect him to clarify and negotiate all those items? Hell, yeah… but it simply does not happen.

As a result during the Grooming sessions you will get used to hear something like ‘And here is a very important story for the next sprint, could you guys groom it a little bit and estimate’… then the team start asking questions and the answer is ‘It comes from Melinda – the chief of Marketing and unfortunately I can’t offer any more details than what she wrote, maybe you could find some time and talk to her before the next sprint planning.’

Okie-dokie… in Agile we are used to the team effort and support and as we love our Product owner we accept him as part of the family, even if he is not developing and delivering stories. And we are going to help him, either the Scrum master or somebody from the team is going to speak to Melinda, clarify the stuff and contribute to the story or the acceptance criteria. In the best possible scenario it works … almost ok.

And let me explain why… The role of the Product owner in Scrum is similar to the role of the Executive in PRINCE2, or the Lead project manager for a project. He is the budget holder, and he is responsible to approve the requirements, the priorities and deliveries negotiations with all the clients, users, parties and stakeholders. He also is solemnly responsible for the approval of the deliveries. Difficult job indeed. In our scenario the Product owner should trust the team’s ability to catch Melinda’s explanations completely and to manage her expectations well. Surprise, surprise – in the end of the sprint the story delivery and approval only led to a new story (rework of the last sprint item), and Melinda communicated she is not happy with the delivery. And it happens again and again with different stakeholders.

What could be done better?

• Convince the Product owner to dedicate more time understanding the stories, the business value and the use cases. He needs to work closely with all the clients and users. Will be difficult – he is a manager already spending a lot of time, for example with the higher level management (his boss)
• Invite Melinda for the next grooming or planning session to explain the story and negotiate acceptance in the presence of the Product owner. Sounds good … if Melinda is available. (if not - ask for a somebody to represent her)
• Invite Melinda for the sprint review. Still the Product owner will approve the story, but Melinda might come up with a follow-up story and requirements based on the functionality delivered
• Don’t be afraid to ‘interrogate’ the stakeholders – for example ask the ‘five whys’ to get to the root of the use case and what the users really want to achieve
• Negotiate deliveries with the stakeholder. Almost all features consist of more and less important parts – reduce scope and commit to deliver only what is needed today (and tomorrow)
• Have the Product owner presence be some sort of assurance (to the stakeholder and the team) regarding the clear commitment
• Assign more Product owners (be careful). It’s not ideal but for a complex product like ‘the platform’ there might be a product owner for each team and a ‘chief product owner’ to resolve conflicts (for example priority ones). Those ‘team-product-owners’ should be empowered and would be expected to dedicate full time working with the clients/users/stakeholders and the team on the other side
• Don’t rely on written information only. It’s all about conversation and negotiation for each story

And to answer the tricky question above:
The most appropriate person for a Product Owner is a business person, who communicates to clients and users on a daily basis. A person, who communicates clearly, negotiates with ease, manages own time well and is not afraid of taking responsibility for his decisions. Account manager or project manager, business analyst, even sales person in some cases could make a good product owner. Technical knowledge is usually not required, and user empathy and the ability to clearly understand what the user would like to achieve is. Depending on the product you would expect at least 50% of the person’s time to go for PO activities (in our scenario it would be at least 95% to manage the amount of stakeholders).

Mobile version of Dnes.bg

I am very proud that I and my team were able to complete this huge project just 2 weeks before I left Investor.bg Group (IBG). It was a real challenge to project manage the idea, the design and the development of entire new mobile web site for the largest news portal in Bulgaria – Dnes.bg
Today, the mobile website is up and running, so please feel free to visit it at: m.dnes.bg

Project scope

- To develop a modern mobile web portal for Dnes.bg
- User friendly and easy to navigate home page
- Article page with various placeholders
- Comments functionality
- Listing pages
- Gallery page with thumbnails
- Horoscopes section
- Currency rates section
- TV and Cinema programmes sections

The main goal of the project was to design, develop and deliver a great mobile web site for the largest news portal in Bulgaria – Dnes.bg

Project team

Lubo – Chairman of the board of directors of IBG
Iana – OPS director (at IBG)
Alex – External UX/Design consultant - https://posteffects.bg/
Emarketing – External Web marketing agency - https://emarketing.bg/
Hristo – External Web developer
Dnes.bg Media team (at IBG)
Simeon – Project manager (at IBG)

The team consisted of IBG members, External UX/Design consultant, External Web developer, External Web design agency. I, Iana and Alex were responsible to elaborate the idea, I was responsible to write project specifications, project roadmap and to communicate with Emarketing and Hristo so they could deliver the final product. Emarketing were responsible to do the mock-up, the design and the front-end coding, and Hristo was responsible to do the development of the web site. Lubo acted as the manager who provided final approvals at the stages and Dnes.bg Media team supported the project once it was published live.

Project resources

Lubo, Iana, Dnes.bg media team and Simeon – employees of IBG
Alex – External consultant – hourly based cost
Emarketing – External/Web marketing agency – design & frontend. Fixed contract
Hristo – external web developer - hourly based cost

Costs:  ~100 000 EUR
Time: ~ 82 working days (4 months)

The costs calculations were done based on the fixed contract with Emarketing, the hourly based payment rate of Alex and Hristo and also the time that the IBG team members spent on the project. The exact number is confidential information, so 100k is just an example number.

The project checklist

Here is the checklist I used to manage the project. I also used project specifications document and my project/task list to write down notes about the project. Also a flowchart containing all the pages and functionalities (and the logic behind them) was created by me. The tasks were broken down using simple waterfall technique. The project roadmap was:
1. I, Iana and Alex discussed the project, the pages and the mock-ups with Emarketing.
2. Emarketing delivered mock-ups for the major pages.
3. We discussed the mock-ups at IBG and provided revisions.
4. Emarketing implemented the revisions and then authorization was granted to proceed with the designs of the pages.
5. Again, the designed pages were revised and approved after that.
6. The frontend coding was done by Emarketing.
7. The project and the project specifications were sent to Hristo for development.
8. The beta site was revised.
9. The site went live – and we (IBG team + Hristo) continued to monitor and maintain it.

After the new mobile site was launched live – we received tremendous amount of positive feedback. Our managers were happy but most importantly the users using the mobile web site were very happy about it. And all the team members were very proud that we managed to deliver such an outstanding product.

PRINCE2 project management basics

PRINCE2 project management methodology is a Registered Trade Mark (Crown Copyrighted) of the Office of Government Commerce in the United Kingdom and other countries. Due to this fact I am only going to share some basics of PRINCE2. The following article is not to be considered as a substitute of the official PRINCE2 documents but just to serve as a basic source of information and also to provoke your further interest in PRINCE2. It is highly recommended to purchase additional materials and courses and also to visit the official PRINCE2 site for more information.

PRINCE2 introduction

The Projects in a Controlled Environment is effective and widely used Project Management methodology. It is a structured method and could be incorporated in the management of very huge and expensive projects in different fields. PRINCE2 is also pretty much traditional kind of approach – very structural and the idea is to ensure that the project is broken down into stages and each stage is delivered in terms of scope, cost and due time.

PRINCE2 principles

There are seven basic PRINCE2 principles:
- Business justification at all stages of the project
This is to ensure that the final product delivered by the project should remain valuable at all project stages. The product idea should constantly be checked regarding the environment and if any changes and updates need to be introduced – they should be. It is imperative that the product/change is still important and valuable for the company while the project runs – otherwise the project should be canceled.

- Adjust and learn from experience
It is important for the PRINCE2 team to learn from the experience of the past projects. And it is even more important to adjust the current project management style based on the experience with the current team and project scope.

- Clearly defined roles and responsibilities
It is pretty much self-explanatory. All the roles and responsibilities should be defined in a clear manner.

- Manage by stages
As a traditional project management methodology – PRINCE2 – encourages the project manager and the project board to break the project into stages and implement them one after another (using waterfall method).

- Define management boundaries
For example the project manager could be allowed to do some changes in the scope of the project if they are not going to cost more than certain amount or take more time to be developed than certain time frame.

- Focus on product
The focus should always stay on the product that is supposed to be delivered/achieved by the execution of the project.

- Tune up to the specific project needs
As PRINCE2 methodology could be used to manage small and huge projects – the method could be tuned to fit the current project needs.  Some projects could just incorporate some parts of PRINCE2, for example the project management team structure.

PRINCE2 themes

- The Business Case
The business case is usually the initial idea of product/change that needs to be introduced for the organization. It pretty much answers the question “why should we do this?”

- Organization
The project is always a temporary organization. The sponsoring organization needs to ensure that the proper team members are assigned and available to participate in the project. It should answer the question – “who is involved in the project?”

- Project scope and quality boundaries
The project scope should outline what needs to be delivered in details.

- Planning
The planning is very important part of PRINCE2 project management. All the plans should include the costs, the teams involved and the due dates for all the stages.

- Risk management
Just like in any SWAT analysis - it is important to identify the potential risks/threats for the project and to assess the impact if a particular risk situation happens. There should also be a backup plan “what to do if there is a significant threat to the project”.

- Change management
Although PRINCE2 is a traditional project management method – it allows introduction of “change” in all project stages. The project scope, specifications, team and developments - could all be a subject of change.

- Keep track of the project progress
Following a PRINCE2 project roadmap, the project manager should always be aware of “where is the project now”, “what should be done next” and “what was already done”.

PRINCE2 team

There are four major parties involved in PRINCE2 project management.
- Corporate and Programme management
These are usually the stakeholders or the board of directors of the company. They are responsible for authorizing and funding the project. They also need to delegate the proper management rights to the Project Board.

- Project Board (directing project management)
The company directors – like the CEO, OPS director, Business development director, other directors, senior users of the product, etc... They are responsible for the major project directing and need to authorize the project initiation, the different project stages and to quality check the completed stages in terms of the project scope.

- Project Manager (project management)
The project manager is responsible for the daily project management. The project manager is the liaison between all the involved parties and reports directly to the Project Board.

- Team Manager and The Team (delivering management)
There could be several team managers. Development team manager, design team manager, Q/A team manager, etc... The project manager should delegate the proper development and implementation of particular tasks to the team managers/leaders. The team managers are responsible for the development of the product in terms of costs, due dates and quality assurance.

Account Management or how to be a great Account Manager

This article is part of my presentation and training I do for account managers. So let’s dive into the deep immediately.

Account Manager – Primary goals

Your two main primary goals are happy customers and completed customers projects in that particular order. Happy customers are extremely important, because even if you deliver a perfect project when the customer is not happy for any particular reason he/she is not going to form a long-lasting relationship with your company.

Top 5 Account Management rules

- Plan, Plan, Plan.
The account manager needs to plan the execution of the project (even before the first call with the customer). Also he/she needs to plan some back-up scenarios if something goes wrong. This way the account manager ensures the smooth execution of the project.

- Befriend your customer and keep close distance.
Customer who is your friend will collaborate and thus support you to finish the project.

- Create timeline/strategy and also deadlines including the tasks for the customer.
Part of account manager's planning is a checklist/task-list and timeline of the project itself.

- Create the project specifications document and send for development.
Once the account manager has enough information about the project he/she should elaborate the project specifications and send the project into design and/or development stage.

- Keep track of the Project history into Task/Projects list and CRM system.
It is mandatory for the account manager to keep record of the Project history for his/hers reference and also to generate reports for the customer and the superiors.

Top 5 Account Management mistakes

- Do not call back or return e-mails back to the customer.
The account manager should always call back and return e-mails to the customer. This is the way to establish a good connection between both of the parties.

- Do not plan. Just wait for the things to happen all by themselves. Do not take ownership of the project.
Half of the account management duties are concerned with planning… the other half is managing customers :).

- Do not inform the customer regularly for the execution of their project.
The customer should always be informed about how the project goes. And it is important to inform the customer even when there are only good news.

- Often go above the terms in the contract to make the customer happy.
A situation like this will happen to the account manager sooner or later. All additional work the customer is requesting should be discussed with supervisor and then it should be decided if the work should be done at no additional cost.

- Store negative emotions. Forget that this is just a business.
Sometimes everything goes wrong and the customer is very unhappy. At this point the customer is sometimes mean or very harsh with the account manager. But the account manager should always remember that it is just a business, and should not take it personally.

Top 5 Account Management challenges

- Ignorant/indifferent customers.
Ignorant customers who are ready to learn are not a problem, but indifferent customers who do not support the project and do not provide the materials/information on their end may even fail the project.

- Wrong rough estimation of the project.
That’s a very bad situation for the account manager when it happens. Usually this should be escalated immediately and the project should be returned to sales to be estimated and sold properly.

- Delays in the design and development of the product/project.
This could always happen. Though, a good account manager should have planned some additional time in the project/account plan to ensure some time shifts are possible.

- Major changes after the project is released live.
The customer just got his/hers project live and realized that’s not what they wanted. If the changes are significant, the issue should be escalated by the account manager and a decision should be made by a superior.

- Clients/Projects that are just too much pain in the ass.
We all know those kinds of people that would do anything to ruin our day. But it is even worse for the account manager to have such a customer because he/she needs to complete the project. As always stay professional and avoid any confrontations and pointless chat with the customer – just stay focused on finishing the project.

Top 5 Account Management advantages

- The complete project happens with the account manager.
It is fantastic to see how a piece of paper (contract) turns into a real, finished and great product. It is even better when the account manager knows he/she is the person, mainly responsible for this transformation.

- Account managers create connections.
Many customers + many projects = many connections. If the customers are happy with the account manager’s work they could help advancing his/hers career and also they could be useful in many other situations.

- Every new customer/project is a new challenge.
And new challenges are great and always welcomed.

- Developing many skills.
The account managers need to have knowledge and skills in everything – design, programming, plans, marketing, seo, communications, leadership, etc… It is great to be a good “jack of all trades”.

- Account managers are better looking than the rest of the team.
It is simply a fact :)