PM Guide

People in projects

Self-organising teams

author: Anna Pinderak

Sometimes, striving for excellence in inspecting and adapting might result in losing sight of the very essence of Agile software delivery: the self-organising team. A culture of openness and creativity, which brings a true understanding of agility, can only be built based on trust and independence.

Easy to say – much harder to implement. Rituals and artifacts have rules and best practices we can follow. Creating self-organising teams, though, is a process with practically no shortcuts. The way to achieve this might be different for each team, project or client. Regardless of the means, the ultimate goal is to give your team the confidence to consult, question and test. There are a few steps that need to be followed in order to initiate and strengthen the independence of your team.

The first is following three golden rules: trust, empower, and iterate.

Golden rule: trust

Before you even think of a self-organising team, you should create an atmosphere of trust between team members. No shortcuts here. As Project Managers, we have the tools to initiate discussion and question the status quo in our teams. The first one, of course, is provided by the Scrum framework – it’s the Retrospective.

In most cases, we are the ones initiating the retrospective meeting and giving it some basic structure, but how it evolves should depend on the team.

  • Do what works best for your team and what leads to the most constructive discussion.
  • Be constructive: don’t let the retrospective turn into a blaming game.
  • Don’t believe that “all feedback is good feedback” during retrospectives. Always dig deeper.

A good retrospective is the first sign that your team is moving towards self-organisation.

The next tool you can use is direct feedback. Provide feedback to each other as a basis for regular evaluation, but also as a tool for improving communication. Open feedback is best. Only if we are straightforward with each other can we keep our cooperation effective and free from assumptions. If you don’t feel confident about providing open feedback to someone, it’s not the feedback you should give. Only if we are mature enough to give and accept constructive feedback, can we think of real trust and teamwork.

Golden rule: empowerment

There is no confidence and independence in a team that doesn't feel empowered. This feeling could come from the client, but also from a Project Manager/Scrum Master encouraging team members to work more like consultants than just coders. As odd as it may seem, most clients really appreciate constructive feedback from development teams. Start from small points – like processes, or perhaps some communication errors – that could be improved and then move on to the role of a real consultant.

Of course, not everything can be questioned. After all, we are working for the sake of our clients, and our ultimate goal is to keep them satisfied about the solutions we provide. There is less room for feedback on business goals than, for example, technological solutions (where we might have more expertise than our client).

Quick wins for team empowerment we use at Netguru:

  • Always keep the development team in a communication loop with the client (and encourage developers, designers and QA experts to be very active in communication).
  • Keep communication transparent to everyone on the team (internal and external), so that everyone can have the same knowledge about the project they are working on.
  • Create balanced teams. More experienced developers tend to be the leaders of change and have the soft skills needed to start a discussion, but less experienced ones offer fresh insights and bring the excitement of discovering something new that can empower crazy and brilliant ideas.
  • Keeping team roles slightly open with room to expand. This helps talents grow and keeps a healthy balance between what needs to be done and what is exciting.

Golden rule: iterative approach

Rome wasn’t built in a day, and neither will be a self-organising team. It’s great to have trust and empowerment within the team, but only by constant improvements can we grow really strong and feel confident about being self-organised. We also need to remember that the path to success in self-organising is not just joy and good decisions. We fail, experiment, and learn. The key goal is to constantly improve, be brave, sometimes even crazy, and test new ideas.

The team doesn’t feel good with the Jira flow? Change it for one Sprint and check whether it works better. The client doesn’t provide you with enough business background for the project? Have a separate call once a Sprint dedicated only to business-related questions from the team. The client is very technical and wishes to consult on the technical solutions you implement? OK, let’s discuss their doubts. Thus, step by step, we achieve our ultimate goal: processes and solutions come from the team, not the client and the Project Manager.


Traditional project roles should be redefined – especially regarding challenges that might prevent your team from being self-organised.

Scrum knows no roles in the development team other than developers. Each team should be able to provide the complete expertise needed to meet the Sprint goal. The software house reality is a bit more complex, as our teams (and skills within the project) are combined based on needs (business goals and technical requirements) and often strict limitations (like budget and scheduling).

For the above reasons, we are not always able to create a team with all the experts who could potentially support the project goals. As a result, our teams are by default more creative and cross-skilled than ones not determined by, for example, budget limitations. Still, the business model of a software house is based on delivering the right talent for our clients’ projects, so we need to stick to some (at least formally defined) project roles.

  • Developers (specialising in different technologies)
  • Designers (UX, UI)
  • Quality Assurance Specialists (responsible for manual testing and for creating automatic tests)
  • Project Managers (filling many different roles, depending on the project)

Each role comes with its challenges and is more demanding within a self-organising team. Let’s start with developers. In an externally-organised team, their only responsibility is to write code according to the specifications provided by the client or Project Manager. In a self-organised team, developers are responsible for all that but also for creative thinking about the implemented solution, providing expertise, challenging existing solutions, and organising their own work. Self-organised teams work on Sprint goals and solutions to be implemented, not on a detailed pre-defined list of tasks to be closed by the end of an iteration.

Next, we have designers. They are UX/UI experts, but also people who provide our clients with the users’ perspective. Their work needs to involve not only creating designs, but also communicating the requirements and goals, defending ideas, and transforming feedback into design. A designer could easily be a key person in a self-organising team, because the specifics of their role and the client’s expectations make them independent specialists.

Quality Assurance Specialists are key figures in every team. Nothing should happen without them knowing about it. The difference in handling this role in directed vs. self-organised teams is as substantial as it is in the case of developers. Traditionally, a QA Specialist’s goal is to test tasks according to a specification. In a self-organising team, QA Specialists also need to challenge solutions, suggest UX improvements, track technical and functional inconsistencies in projects, and underline the priorities for the team.

Even though the role of Project Managers doesn’t sound too Agile, our responsibilities may vary between teams and projects – examples abound here. We can carry out non-Agile management activities like time tracking, dividing tasks between team members or managing the whole communication. On the other hand, we handle tasks based 100% in the Scrum methodology, like facilitating communication and scrum rituals, suggesting improvements, or educating others about Scrum. We aim to be Scrum Masters, but the reality is that our main goal is the success of the project and, for some teams and projects, the path to self-organising is a bit longer and more difficult, requiring an experienced guide (at least temporarily).


The key challenges and difficulties preventing our teams from being self-organised by default can include the reasons listed below.

Short term projects: not every project offers the time to iterate or improve processes. It’s hard to self-organise if the deadline is super short and the client’s budget doesn’t allow for challenging the specifications. Team maturity: it’s no surprise that the longer a team works together, the more improvements it can provide to processes. The projects we deal with have their business goals, and time is money, so there might not be enough opportunity to iterate with every group of people you work with. Lack of initiative to self-organise, in teams or from the client. Not every client values feedback and expects consultancy. Previous experiences of successful (or otherwise) self-organising teams from each team member may differ. The cultural backgrounds on the team may make self-organisation tricky.

A self-organising team is the ultimate manifestation of Scrum. The full potential that lies within our teams can bear fruit only if given the proper soil of independence, trust and encouragement.

How to give constructive feedback

author: Marcela Otulakowska

Using feedback in a way that brings actual value is an art that can and should be mastered. It really does make a difference. Getting regular advice based on your weaknesses and strengths, advice that does not come solely from your leader, but also from everyone who works with you, is extremely valuable.

It can be difficult and stressful in the beginning to give feedback to your colleagues. You may not feel competent, or like you have to judge them. If these worries sound familiar, don’t worry – all you need is to learn the right way to give feedback.

Feedback is meant to help its recipient to look back on their conduct and identify their strengths, blind spots, and areas where they still need to improve. As a Project Manager, you work with a lot of people, and those people count on you to give them feedback that will help them grow. In our experience, the best way to learn how to give good feedback is to understand what it’s like being on the receiving end of it, which is why we will discuss receiving feedback as well.

When to give feedback

  1. Never do it when emotions are running high, but do it sooner rather than later Let’s say you've had an unpleasant disagreement with someone at work and you’re eager to give them feedback right now. Wait. Go for a walk, calm down, and think of the actual content of that feedback. What is it that made you angry? Focus on the facts and write them down. On the other hand, do not wait too long, as the feedback may become outdated and irrelevant.

  2. Do it not only when required Regularly scheduled feedback sessions (e.g. quarterly ones) can be challenging, as you may, for instance, not remember a very valuable piece of information, or you may not have time to share all your feedback during a scheduled session. Just go and give that feedback immediately (as long as there are no negative emotions involved). That will allow the receiver to improve their quality of work now, not in three months’ time.

How to give feedback

  1. Convey feedback in person This is the best way but also the most difficult one. Giving feedback in person will force you to prepare. Sitting in front of the other person and telling them what they need to improve on in their work is hard, but it makes the biggest difference.

  2. Talk about facts and give examples

Your behaviour on calls is always unprofessional is not feedback but a piece of opinion.

Try saying:

During the last call with the client, you used offensive language and you did not prepare the demo you were supposed to show. This made me feel anxious, and the client might have seen it as unprofessional. Next time, try to control your vocabulary and take time to prepare.

Sounds better, right? Also, avoid phrases such as: always, never, usually. It’s better to recount specific situations.

  1. Give real-life advice If you see that someone is struggling with time management, try to not only highlight it in your feedback but also give suggestions that will help them improve. Send them a link to an article or refer them to the time management section in this ebook. Be helpful: listing areas to improve without any proper advice on how to improve them won’t make a difference.

  2. Talk about emotional reactions If someone is acting in a way that makes you feel undermined, do not tell them that they are being arrogant. Tell them that their actions make you feel left out, and list those actions. That person may simply not realise what their behaviour is causing. However, remember that they’re not responsible for your emotions. You are. Make sure not to blame them. Simply list the areas to improve.

  3. Adjust your feedback to the situation Thanks for the Feedback by Douglas Stone and Sheila Heen highlights different types of feedback which should not be mixed. Learn to understand the difference between appreciation, coaching, and evaluation.

  • Appreciation is focused on motivation and encouragement.
  • Coaching is about showing the direction of how you can increase your skills and grow.
  • Evaluation tells you where you are and what is expected of you.

Let’s say you’ve just completed a huge project. It was long and tiring for everyone involved. You’re giving feedback to one of the developers, saying:

You should focus more on estimations next time. Pay more attention to the business perspective – here are a few tips on how to do it.

This is 100-percent valid feedback – it’s focused on facts and contains advice. So what’s wrong with it? That developer may think: “I did a lot of work, we delivered a product, and all I get is a list of things I did wrong?” It was not your intention, but this is what the other person will feel like if you choose the wrong type of feedback. The example above is an evaluation, and what is really needed after such an arduous project is appreciation. A simple “good job” would be more appropriate.

  1. Help others work on their blind spots Focus on what the person who is receiving feedback fails to see (but others can). Each of us has a set of behaviours that may have a negative impact on others and we are often unaware of them. These are our blind spots – if you notice one, try giving feedback on the go. Whenever you see that someone is doing an undesirable thing, just tell them. They will be grateful, and they will be able to understand the factors that caused their behaviour.

How to receive feedback

  1. Feedback is not about who you are. We tend to think less of ourselves when receiving negative feedback, as it impacts our vision of who we are. It is crucial to understand that feedback is not about you as a person, but about the influence of your actions and behaviours on the environment.

  2. Ask the right questions. Companies often collect a lot of feedback, for example through Google forms. This means that very similar questions get repeated, which makes it difficult to receive specific advice. Did my actions improve Sprint planning? is not a productive question. Instead ask: did you notice any improvements that I’ve implemented lately? Make the feedback giver think about the things you want them to share, but do not give them a ready answer.

  3. Even poorly written feedback may be useful. Schedule a call with the feedback giver and ask follow-up questions. Ask for examples on how your behaviour influenced others, and what emotions were caused by the situation. Dig deeper and you’ll get to the core of that feedback.

  4. Understand the relation between you and the feedback giver. Try to keep the relationship trigger outside of the equation. When you get feedback about your weaknesses from the person you yourself consider unprofessional and unfit for their job, you tend to dismiss what they say. In such situations, try to put that person out of the equation and look at the content of the feedback only. You will find value there.

  5. Understand the real matter of the feedback. Make sure you’re not starting a blame game. When you have a close relationship with the feedback giver, you may tend to think that their feedback is about your relationship – not about your behaviour. Look at the system while receiving feedback. Take a step back and understand what your roles are within your organisation.

  6. Look for patterns. If you can see that some aspects recur in the feedback you receive, pay attention, even if you do not agree with it. The root cause is most likely something about your behaviour.

  7. It’s okay not to take feedback. Sometimes, it’s just not the right time to hear particular feedback. Be appreciative, but tell the feedback giver that you do not really need that feedback right now. Maybe you’ve just had a huge crisis in your project. You need to act fast and find solutions rather than listen to someone telling you what actions caused it. Invite that person to an After Action Review or otherwise be clear about when the right time for you to hear their feedback is. Postpone but don’t reject.

Feedback can make you and others grow

You’ll be surprised by how much you can achieve with your team if you give each other feedback. Understand that your characteristics and skills are not set in stone – you can change and improve. Taking a step outside your comfort zone will allow you to truly stretch your wings. Don’t take it personally.

Developing your team through education

author: Ewa Mruczyńska

A project team is an ensemble of different people. They vary in terms of experience, background and character. Their first challenge is often to get along, find a common language, set up rituals, and truly work together towards a shared goal.

Developing the team is an important part of a Project Manager’s role. People need training and support. They need to grow. And as they grow, your projects will as well.

Educating is not teaching

Educating and developing your team should not be considered teaching. You help your team grow in segments, and you push them to look for answers, question the status quo, and broaden their perspective, and work on their mindset. You share experiences, good practices, and tips and tricks. You show each other different approaches to the same issues. In fact, you probably do most of it without even realising that it’s educational.

The goal is to use the natural skills of all team members. Make the team aware of what they are good at and what they need to work on. Challenge their thinking, especially when they hit a roadblock or when they run out of new ideas. Push them a bit out of their comfort zone. Nobody likes that at the beginning, but everybody appreciates it afterwards. Give them valuable feedback so that they can grow.

Remember that it really does not matter whether you have a team of seniors or newbies. People can always develop, and can always learn something new about the project or client-related issues. Especially, when you need to tailor your project to a client’s specific needs. There are no two identical projects.

The main areas of team education

There are many areas where the team can be educated. Early on in the project, the whole team starts to shape the reality in which you will be working for the next few months. It’s up to you to choose the right style of communication, workflow and methodology. The Project Manager can do it on their own, but you can also consult the team. As a PM, you can explore their fields of expertise and find out whether they have ideas on how to be better prepared for the specific kind of project you are about to start.

Focus on the aspects that you, as a Project Manager, are good at. We specialise in communication and Agile management. Within those areas, you can find multiple topics that may be beneficial to your team. Nobody expects you to share tips on keeping the code neat or latest technological innovations. What you can do is educate the team about the importance of the project’s business value, transparency, communication, and the Agile principles.

Agile methodologies

You can never be sure who will join your project. It could be a senior with 10 years of experience in Agile work, a junior who is completely new to the concept, or a regular developer who only stumbled upon Scrum. You can introduce different project management methodologies, but they won’t amount to much if the team doesn’t follow them with a thorough understanding. Why do they need to attend events, stick to time boxes, or follow the rules? How will it affect the project?

Explaining the rules is not enough. Work with your team all the time and improve the way you do Agile. Some things can be difficult at the beginning, especially with an inexperienced team. The first planning can result in totally unrealistic goals, and during the first week, someone is sure to disrupt your Jira flow. But in time, you will see that your team will gradually become more aware, more independent, and more self-organising.

Transparent communication between team members

Transparency can manifest in many ways:

  • Being true and honest about the problems experienced during development,
  • Being eager to admit to mistakes,
  • Sharing feedback,
  • Challenging others’ ideas,
  • Sharing business insights.

Transparent communication is important for constructing our statements and messages to the team. It’s not only what we say that matters but also how we say it.

Team members influence each other, with both their negative and positive behaviours. Project Managers can have a big impact here as well. The role of a PM involves creating a good atmosphere and helping the team to accomplish a common goal. Team members may need examples of proper and transparent communication, as well as a bit of an incentive.

How to do it while avoiding the risk of starting a blame game or creating an unhealthy atmosphere through feedback that isn’t constructive? You’ll need intuition and common sense. Encourage the team through example and create opportunities for discussion.

During Sprint planning, have a session of “planning poker”, where the team members estimate tickets independently and share the outcome at once. To choose the final estimation, they have to explain why they decided on a given number of story points. This triggers a discussion about the complexity of the task, but it also generates ideas on how to approach the issue.

During the retrospective, share your feedback openly and try different scenarios. Use drawing sessions, start/stop/continue, or any other tool that makes sense for your meeting. See what works best, what is fun for the team, and what serves the purpose at the same time. Give feedback yourself to show how it should be done.

Transparent communication will be appreciated by everyone. If the team feels supported by other team members and the Project Manager, they will work under less pressure, be more likely to exceed expectations, and develop more as consultants by trying different approaches and having more willingness to experiment.

Proper communication and establishing a relationship with the client

Communication with the client is crucial in the IT industry. Maintaining it on a daily basis through Slack, emails, or calls should be a team-wide effort. It’s important to know how to construct a good message and set up communication that will help you establish a good relationship with the client, while allowing you to get relevant information about tasks, issues, and priorities in the project.

People working in the IT industry tend to avoid face-to-face communication with the client. They prefer the written form and asynchronous messaging (e.g. via comments in Jira tasks). The reasoning behind it can vary. Encouraging your team to talk with the Client more is one of the toughest jobs of a PM. You can’t force people to do it, but you can help them realise how big a difference it can make.

The Project Manager is not the right person to hand over technical information. Developers are experts in their fields and they should be the go-to people for any tech-related issue. In case of any problems, suggestions, or changes, they should be the ones to talk things through with the client. Sometimes there is even no need to have a PM present. The Project Manager does not work directly on the issues, so they can easily fail to deliver important information or disrupt the meaning by not fully understanding its topic. First-hand information is better.

Presenting yourself as the go-to person for certain areas establishes a better relationship with the client. The more the client sees you as a hard-working, engaged person, the more likely they will be to notice the complexity of issues you are working on and how time-consuming they are. It will thus become easier for the client to forgive you small mistakes or delays.

We are all responsible for the work we deliver. No one should take over presenting your accomplishments, because you know best how much work and effort it cost you to deliver your part of the project.

The business value of the project

We should act as partners focused on fulfilling the business vision. Our clients should feel that we want to help them grow and develop. We can achieve this by delivering beautiful software that is tailored to our client’s specific needs. This is why understanding business value is so important – it helps us build a real partnership with clients and create products that achieve clients’ goals.

As a PM, you need to start conversations on this subject with your client, but once the team understands it, they can keep it going. Encourage your team to ask questions such as:

  • What is the client’s business about?
  • What goals are you trying to achieve?
  • How can the product help with achieving the business goal?
  • How does a specific epic/user story correlate with the business value of the whole project?
  • What do we want to accomplish by adding a given functionality? Is it consistent with the business goal?

These questions can not only help in establishing the MVP of the project, but also in choosing the best tools and technology for different features. They can also give a direction for testing.

Business value-driven development results in confidence and knowledge. If the team is really committed to learning about the client’s business, it will become a natural thing for them to challenge ideas, experiment, and look for solutions that will add more value.

Business value helps in setting KPIs so that we can track the results of our work and see whether we’ve managed to create a product that is consistent with the client’s goals, fulfils all requirements, and does what it was supposed to do.

Who is responsible for educating the team?

Project Managers do well when it comes to communication, consulting, and business value, but other team members also have skills and knowledge that they can pass on to others. Your goal in the project is to create a self-organising team. It will empower them to prioritise work, estimate, and plan without the constant assistance of PMs. They should be able to propose new solutions, improvements, and approaches.

Education comes more naturally with a higher seniority level of team members. This doesn’t mean that only the seniors should be educators. Every team member should be aware that they have a set of useful skills and valuable experience in different fields that can be shared with others.

Education does not have to be connected with improvements, new processes, or new technologies. We can also learn from our mistakes, write case studies based on our failures, and prevent crises by noticing alarming signals based on our experience.

Everyone can contribute to team education. The thing that we, as Project Managers, should educate our teams about is the fact that their seniority within the organisation or project doesn’t matter. Their experience, knowledge and input are always valuable.

Agile and Scrum in remote environments

author: Pola Mikołajczak

Remote work poses some specific challenges to implementing Scrum or other Agile approaches. Scrum does not mention co-location at all, while according to the Agile Principles, ”the most efficient and effective method of conveying information to and within a development team is face-to-face conversation”. Face-to-face conversation is indeed the most efficient and effective. But it’s not the only option and often, remote solutions are the best ones in a given context.

Many standard Agile techniques can’t be copied to a remote environment, thus Agile in a remote environment can be harder to create and maintain. Mature remote Agile teams thrive, while less mature and less self-aware teams struggle. Once you overcome the major challenges, your remote Agile flow can be even more powerful than a collocated setup. Just minimise the downsides and harness the advantages to the maximum.

What is the value of collocation? What are advantages and opportunities in such a setup? Now, think about your remote team. How can you achieve the same results here? What solutions and tools would you need to emulate these opportunities?

Let’s use an example. Teams build stronger connections when they have the space to get to know each other. For a collocated team, it can happen in the office cafeteria: they’ll talk about their vacations, weekends, and afternoon plans. In a remote setup, you can make the Monday daily call a little longer and start a habit of sharing what the team got up to over the weekend.

Important tips

  • Set aside some time for reality checks about communication and transparency, especially at the beginning of your team’s journey. In a remote environment, it’s easier to miss the red flags.
  • Experiment with translating exercises and activities to a remote environment. Think about how a particular technique uses elements of the physical environment, and how you can achieve the same results online. Use online whiteboards, shared documents like Google docs, and video calls. You can split a 12-person call into four 3-person calls to work in groups.

Common challenges

Finding structure in chaos

Software projects can easily become chaotic. To combat this, use a structure such as the Scrum framework. It lays out some must-haves and leaves you space to fill it with content suitable to your product. Write down the meta-information on your product with your team. Naming team rules and flow explicitly is key in Agile approaches, e.g. the Kanban principle. Visualise the workflow.

Some examples of topics to cover with your team can be found below.

  • Meeting flow – when will meetings take place, who needs to be there, what are the goals?
  • Visualise your task workflows (e.g. the JIRA workflow).
  • Write down the roles in the team and what will be expected from each. This is especially useful in bigger teams, and it’s meant to be a group exercise. The process of forging shared expectations is more important than its outcome.
  • Use widely known project management techniques for describing the flow. Write down a DoD, a DoR, a team contract, a release plan.

Share all this with the rest of the team.

Reality check

  • Do you have a shared understanding of your flow (team events, expectations towards roles)? Is everyone on the same page?
  • Have you agreed on communication channels?
  • Is information easily accessible and searchable for each team member?


  • Start with what you have. Don’t try to find the perfect solution. Describe the processes already in place and then gradually improve them.
  • Start with what you know. It’s easier to begin when you have a common ground. You can use the Scrum Guide setup and work with the team to find what you need to add or adjust.
  • Build habits – looking at the Sprint burndown chart at standups, starting the day on a shared dashboard, saying hello each morning on your team channel, etc.

Building trust

Building trust is crucial for effective collaboration. Build trust inside the technical team, as well as between the technical team and the client (or the whole business team on the client’s side). We need transparency between development and business to make sure we are building the right thing. And we need openness inside the team to make sure we build it the right way.

Reality check

  • Is feedback communicated directly (rather than through a manager)?
  • Do you have regular Sprint retrospectives? How does the team behave there?
  • Are impediments communicated immediately to the rest of the team? And to the Product Owner?


  • Agree with the team to always assume good intentions. Remind each other about this as needed. It’ll help you steer away from playing the blame game and towards actionable feedback.
  • Agree on ground rules of cooperation, such as Slack mention usage, do-not-disturb time, etc.
  • Make sure the team has a space for having fun together. Examples include daily standup jokes, sharing photos of beloved pets, or a separate channel for laidback discussion.

Self reliance & self regulation

Remote work requires maturity. Each team member needs to be able to take responsibility for their work environment, and take ownership of their time management. Being a member of a self-organising team requires taking ownership of your work first, and then expanding it to the whole team. Trust, self-reliance, and self-organisation are interconnected. You have to build on all of those qualities incrementally – more trust means more space for self-reliance.

Reality check

  • Does the team deliver the Sprint Goal at the end of each Sprint?
  • Are the team members accountable for their commitments? How?
  • Is responsibility shared? Do people help each other towards a common goal or just take responsibility for their individual delivery?
  • Does the team take responsibility for achieving the business goal? Can they describe the current business goal and how they are contributing to it?
  • Are they giving feedback to each other?
  • Do you trust that your teammates work as much and as effectively as you agreed? What would need to happen for you to trust them?
  • Does the PO trust the team? What would your PO need to build this trust?


  • Lay down the ground rules at the beginning of the collaboration. It’s much easier to self-regulate when you know the boundaries. Be involved in creating practices at the beginning, and then gradually pass the responsibility onto the team.
  • Write down expectations and agree how you will hold each other accountable. You can use a shared drive, a wiki, or even a separate repository, but it’s best to choose a tool that you already use for something else.
  • Leverage the daily standup. It is there to help the development team self-regulate.

The journey

Every team needs structure to avoid chaos. When starting a new project, help establish this first, basic structure. Then focus on building trust and transparency to make sure you are building a real team rather than keeping together a group of great specialists, each focused on their own mini-silo.

Once the team has that covered, the next challenge begins. Build self-reliance (both as individuals and as a team) and encourage the team to create self-regulation mechanisms. They should take ownership of the frame they have been given and adjust it to their needs, then continue creating new team rules, influence each other's behaviour, and learn from each other. Your job as a Project Manager or Scrum Master is to help with the transition.

Agility in your remote environment

If you want to experiment with remote Agile yourself, remember to:

  • Name your values. You need to understand your values first to make sure you share them with the whole team.
  • Meet with the team daily. Give them space to work out their values in practice. A good start is to write a team contract, discuss how you plan to work and hold each other accountable.
  • Look out for possible conflicts and gaps in communication. It’s easier to avoid unpleasant topics in the remote world, and it’s harder to give impromptu feedback. Start from yourself – give small feedback, both good and bad, right after every call or encounter.
  • Remember to leave the team some space to learn from both successes and failures. You are not there to shield them from everything. Step by step, they should be able to handle more chaos themselves, and become less dependent on your support.

Challenges and tricks for working with big Agile teams

author: Anna Pinderak

A big team opens up enormous opportunities for growth for a Project Manager/Scrum Master, but it can also be a source of endless headaches if not guided properly. Let’s take a look at some of the most popular challenges that we face while working with bigger teams, and the tricks that will help you overcome them.

Big teams, according to Scrum, count around 8-9 active developers, a Project Manager, and QA experts. Yes, the Project Manager is not formally a part of a Scrum Team, and there should be no division between developers and QA experts in a cross-functional team. However, describing a team this way is necessary for the purposes of this part.

Core challenges


The issue that big teams struggle with most frequently is chaos. For many people, who likely don’t know each other, working towards a common purpose is a tricky proposition. It’s good to be ready to overcome the chaos accompanying big team setups.

Have a set of shared rules Remind the team that they shouldn’t interrupt each other, as well as being polite and understanding. Introduce the idea of giving feedback and assuming good intentions.

Keep people busy You don’t want to occupy people with work that doesn’t need to be done. You want them to focus on common goals, such as initial estimations, setting up environments, or specifying business requirements. Do this during the chaotic early days of the project to learn about project goals, prepare for the actual work, and get to know each other.

Have everything documented Documentation doesn’t have to lead to the Waterfall approach. Agile doesn’t mean chaos. Use solutions like Jira, the Definition of Ready and Definition of Done, Slack, etc. Choose tools that will provide you with the right information transfer but will not add extra work.

Propose initial roles and iterate Create teams in which everyone can take advantage of their skills to the full. This means that developers should work on code, QA experts on making sure the code is working, and the PM should support them through organisational and communication challenges. It’s absolutely natural that, after a while of working together, the team’s skills will get more mixed, but in the beginning, it’s better to set some rules about who does what and what we can expect from each other. It’ll make work more predictable while freeing the atmosphere up from unmet expectations.

Communication issues

Communication issues can easily amount to 80% of a team’s problems (the ones not caused by a lack of skill or technology blockers). As such, they should be a key focus area of a good PM in the first weeks of work with every team, and especially a big team, in which these problems are more likely to remain under the surface longer.

Things get dire when you notice that one of your four front-end developers doesn’t get along with one of your five backend guys because their favourite football teams are eternal enemies (true story). But what can you do about such an issue?

During the first two weeks, you should see the emerging team dynamics. Who is more extroverted and who prefers to be left alone? Who is a born challenger and who doesn’t like changes? You don’t even need to address these things out loud before they become a big issue.

First, get to know these people, and help them get to know each other. Create a safe communication space for them. Open all the usual Slack channels at the beginning of the project. Yes, it might be a bit quiet on the channels for a little while, but they create the much needed space for the team to get to know each other. Make sure your team members can communicate freely and without impediments. If you discover any, remove them. Then make sure there are no skeletons hidden in the closet. Do all this, and your project will be off to a good start.

Delivering value

The estimation phase is done, the initial setup is completed, the first Sprint is planned, and you are ready to dig in. At this point, you need to focus on maximising the value your team delivers from the very first days, and on building the client’s confidence in you. There should be no tolerance for team members blocking each other (as can happen in bigger teams) or accidentally working on the same things. While the developers need to assess whether four people can work on one feature, it’s the PM’s duty to be the voice of reason when something looks too optimistic or pessimistic.

When needed, split the team into temporary sub-teams. They will be able to work closely on specific tasks, making sure that they haven’t missed anything and that no one is blocked by any missing endpoint. Build a sense of ownership in these sub-teams. They should feel responsible for their features, create estimations, and break features down into smaller tickets. The team should be the ones reporting on their progress – and the ones feeling proud of the outcome during the client demo.

This is the first step to self-organisation that should result in shared ownership over the whole project. The PM’s role is to propose the initial setup, challenge the team to come up with the optimal solutions, and create a safe space for them to share thoughts and recommendations.

You might be worried about the risk of creating silos if you break a big team down into smaller sub-teams, but this is mitigated as long as the sub-team composition remains fluid and the team uses efficient knowledge sharing processes, such as regular technical meetings attended by the whole team.

Overload and underperformance

These two seemingly contrary challenges often go together. Let’s imagine a big project with a massive scope and a relatively tight deadline. It would naturally require a big team, and big teams need to be composed in a balanced way. We don’t put only senior developers together in one team, as it would result in lost potential and risk of misunderstandings or conflicts. On the other hand, a team consisting only of fresh regulars would lack experience-based validation of their technical decisions.

A potentially optimal solution, therefore, would be to create a team consisting of a senior, regulars, and juniors. They would be able to support each other and utilise their skills and experience in the most effective way. But even this setup poses the threat of overload of some team members – either those who feel too much responsibility for the work of less experienced team members or those who want to impress the seniors. The underperformance of the less experienced ones (who are afraid to admit that something is too difficult for them) is also a potential issue.

The solution? A team spirit. Teams should be focused on balancing skills and possibilities, then presenting their work as a result of everyone’s efforts. This way of presenting work not only creates a good environment for learning and knowledge sharing but also redistributes responsibility for the project among team members. Each team member is responsible for the performance of the entire team, so no one is left behind or pushed to the front all the time. This approach is based on building a strong sense of commitment and shared purpose among team members.

Tools and tricks

The challenges that accompany managing big teams can be mitigated with certain tools and tricks. The following selection is not exhaustive, but it should point you in the right direction.


Remember the shared ownership over tasks by sub-teams? Teams sometimes struggle with the complexity of topics described across many tickets and feel lost in the requirements and dependencies. Two tricks you can use to overcome this are:

  1. The master ticket flow, which involves all feature descriptions collected in one task. This is often a giant task, definitely inestimable and undoable for one developer. It carries all the information about a specific feature and acts as a single source of truth during development planning. The master ticket can often be understood as something that comes between an epic and a user story – an additional level between these two stages.

Usually, one epic consists of 2-3 master tickets, making up one user journey or new feature. Each master ticket should have its owners, who are responsible for making sure it’s delivered according to specification. It’s their responsibility to make sure the frontend and backend are connected and no acceptance criteria have been left out. The owners are also responsible for presenting suggestions for technical implementations to the rest of the team. They prepare a technical division of the feature – a list of development tickets that can be estimated and delivered one by one to close the master ticket.

  1. Taking advantage of the “linked issues” feature in Jira. This is the next step after the master ticket flow. Jira gives us a very handy way to connect tickets through numerous relations: caused by, blocked by, connected to, etc. With the help of these connections, we can create a map of master ticket-derived development tickets that are needed to deliver the whole feature. This setup supports transparency and limits the chaos associated with delivering big features.


Certain Slack tricks can help you create an effective and consistent communication setup for your team. Start with creating multiple channels for each project.

The must-haves:

  • The main project channel (e.g. #project-projectname), used internally by the team to talk about the project and socialise.
  • The client channel (e.g. #client-projectname), which allows us to make the client a part of the team. It offers an easy way to discuss tasks, ask questions and socialise. It’s very helpful to share a real-time communication tool with the client.

Optional channels:

  • Channels for each sub-team (e.g. #frontend-projectname, #design-projectname) take some of the technical communication out of the main channel and encourage more in-depth technical discussions (which otherwise would have taken place in private messages exchanged between developers). They also create a repository of know-how and technical decisions you make in the project.
  • Issue/task channels, which come in handy when you have bigger topics that don’t involve the whole team (e.g. #externalAPI-projectname). It is an optional, yet surprisingly effective, way of taking some very detailed feature-based discussions out of the main channel to prevent communication overload.

Calendar and holidays

Big teams come with some organisational challenges related to planning absences. To avoid unnecessary work, create a calendar shared with the client and keep it up to date with any planned absences. Make the information available in advance. One week is enough if a team member is going to be gone for a couple of days, but for longer absences, letting the team know a month in advance isn’t overzealous. Though the Project Manager is not a formal approver of holidays, team members shouldn’t disappear without notifying the PM. We need to be aware of all absences to properly plan the team’s work.

Working with big teams is the sort of challenge that boosts a Project Manager’s creativity, communication skills, and planning abilities. It also requires a good sense of timing, as each day carries a very high cost due to the number of people engaged in the project. The pay-off is worth it. The experience of witnessing a high-performance, effective, collaborative and engaged team achieving goals that could only be dreamed of without this scale is extremely satisfying. Despite the risks and the amount of work required to support a big group of individuals on their path to becoming a great team, the results cannot be compared to any other challenge a PM could face.

Valuable communication with the client

author: Marta Ciesielska

Sometimes, especially when you start your cooperation remotely, establishing good communication from the very start can be fundamental for building a fruitful, long-term cooperation with your client. First impressions do matter. The steps described below will help you avoid miscommunication and find a common language with clients.

Step 0: Gathering insights

If the client has already started the project with you as a Project Manager, this means someone must have sold it to them. The handover process between the manager and a sales representative can give you some insights into the client's personality and level of technical knowledge.

These questions might help you get the full picture:

  • Is the client open to compromise?
  • How does the client communicate? Are they formal or casual?
  • Do they joke around?
  • Do they like and initiate small talk?
  • Do they state their expectations clearly, or do you need to figure them out?
  • Is the client open to feedback?

Step 1: Getting to know each other

During the first weeks of cooperation with a new client, be flexible and closely observe their reactions. It’s good to encourage the client to use their camera during calls.

You can’t avoid making some assumptions. You will either be too formal (assumption: a big banking company with serious money, they for sure wear ties and are very official) or too casual (assumption: a small startup with a 22-year-old as founder, so we can talk like we’re buddies). And that’s fine, as long as you don’t get stuck or afraid to experiment with your style.

During the first week, it’s good to establish a clear distinction of responsibilities, as well as the tools you are going to use for communication. Agree on the roles you are going to take (does the client expect you to be a Product Owner, a proxy, or strictly a Scrum Master?). Agree on what your main communication channel should be: email, Slack, maybe Skype? Write it down and stick to it. If there is a change (e.g. the client’s PO leaves, and they need to put more responsibility on you), reiterate. This will help you avoid conflicts in the future.

It’s also worth noting that without knowing what is your natural, authentic communication style, you won't be able to fully own the communication. I encourage you to write down your personal “manual”, which you could even show to the client at the beginning of cooperation.

Step 2: Feedback time

After the initial weeks, have a one-on-one session with the client. Ask them about their overall impressions and steer the conversation towards more personal feedback about your work. If you will listen to what the client has to say actively, you are likely to find an opportunity to give your feedback to the client as well.

It may be too early at this stage to tell the client some things directly (“the way you aggressively communicate with the team makes them highly demotivated”), but it’s a good moment to check how the client reacts to feedback. Find something small that you think they could improve on (“try to avoid using all caps on Slack, since this is interpreted as shouting in online communication”) and observe.

Step 3: Strengthening the relationship

So you have a strong basis for good and healthy communication with your client. It’s time to leave your comfort zone.

It’s especially important in a remote culture to start meetings with some small talk. But be careful to always start with yourself and what you want to share, hoping that the client will follow. Avoid dangerous topics (politics, religion) unless you’re absolutely sure that they are safe to discuss.

For building better communication, consider meeting the client face to face. Even in a remote-first company, having a conversation in person at least once per project can be a big boost to your relationship.

Step 4: Find a sidekick

Many companies offer additional support to clients, such as people responsible for keeping a good business relationship with them. These team members (e.g. Account Managers) can also be your sidekicks. If you feel that the client is reluctant to be transparent with you during feedback time, ask the Account Manager for help. Your sidekick can help you build a business strategy for the client, find the right people to help reach project goals, and challenge your ideas to keep them sharp and doable.

Will following these steps protect you from all potential risks that can happen in a project? No, but they will help you establish a relationship built on mutual trust. Once the client understands that you're being fully transparent and open, you will be able to put all your effort into delivering the best possible product. Being on top of the client's needs and having open, honest conversations will also prevent you from waking up to a crisis in the project that somehow ended up on your boss’ desk instead of your own.

Educating clients

author: Michał Kamiński

Each project brings plenty of opportunities to help our clients understand the process of developing software better. The need for such an effort will vary greatly depending on the background of our client, and it is crucial to verify this in the first days of the cooperation. After all, we want to work according to the best Agile practices and in order to make that happen, we need to spot potential roadblocks quickly.

Check where you stand

Before we can even think about educating the client about anything Agile-related, we should make sure we’re on the same page in terms of the day-to-day operation of the project and the cooperation between the two (or more) parties. In an ideal world, all this should have been clarified earlier in the pipeline. We shouldn’t take this for granted, though.

What should you want to verify? Here are a couple of questions to consider.

Who’s who?

Is the client clear on who’s who in your organisation and who they should direct their questions to? Depending on their nature, different people might be responsible for answering them.

Client’s capacity

Is the client aware of how much time the team is going to be able to dedicate to the project? We all have our internal responsibilities not strictly related to project work. If the client expects full-time commitment, they might feel cheated when they learn that someone is not available because they have to attend a meeting. It’s worth clarifying that early on to avoid potential conflicts.

Expectations about deliverables

Are you on the same page in terms of the project’s scope and deliverables? What’s the client’s perception of the estimations and the concept of an MVP? Do they consider the provided cost/date ranges as absolute values? As we might not always be able to take part in the initial contact with a potential client, we might end up having to execute agreements that the team deems unrealistic. Spotting such issues early can be crucial in protecting the success of the project as well as the relationship with the client.

Communication flow

Does the client know which channels to use to communicate with the team and how to go about it? If someone is not used to Slack, they might resort to some practices that are, from our perspective, bad, such as starting individual chats with people instead of communicating on dedicated channels, overusing mentions, or sharing information that should be recorded in a Project Management tool like Jira. If we allow them to continue doing so, they could develop suboptimal habits that might be hard to fix later on.

Who we are and how we work?

As part of discussing the communication protocol and other organisational aspects of the project, we might provide the client with some insights on how developers work and what their preferences are. The exact details will depend on who your client is, but even if they come from a technical background, it’s worth explaining the standards and practices your engineers would love to follow. This might be even more important with clients with hands-on experience in development, as they are likely to already have preferences that might not necessarily align with what the team believes is best. It is often much easier to convince a non-technical person to accept your tech-related recommendations.

What do we mean when we say Agile?

This leads us to Agile education. Even though it has become an industry standard, people’s understanding of Agile principles varies greatly, and we shouldn’t take it for granted that they know the methodology well. The thing we ought to emphasise most is the need to follow the guidelines of a given framework, and why it’s important to make time for everything the framework requires to function. In the case of Scrum, this means honouring all the Scrum events without exception and finding enough quality time for all of them.

The terminology, with its focus around the concept of the Sprint, might be confusing for some people as it suggests a continuous, high-intensity effort, when in reality, it can only function if it goes hand in hand with proper planning and Backlog refinement sessions. Sacrificing one aspect of the framework over another will have negative consequences sooner or later. We should make sure our clients understand that in order to execute the method effectively, there has to be equilibrium between its individual components.

Do we understand our tech?

It’s a challenge to make sure the team’s technological choices and solutions are clear enough to the client, allowing the client to justify them to their stakeholders and the organisation. As PMs, we often act as “translators” between the tech and business. The way we go about it is crucial. We don’t want to spend lots of time on technical discussions between the team and the client without the guarantee of a successful outcome: the client’s understanding.

A smart approach here is to align education efforts with work on documentation. By having some feature or mechanism described and illustrated beforehand, we allow the client to become familiar with it before discussing the subject. That way, we increase the chance of achieving our objective, and we can narrow down the scope of the actual exchange. Doing this will also signal the importance of keeping the project documentation up to date and maintaining an understanding of the technology across all interested parties, present or future. It might also help the client to illustrate their business ideas more accurately, which in turn can reduce the cycle time of work on a given feature.

Do we believe in the why of the project?

Sometimes, we might need to challenge or even question the business decisions our clients make with regards to their product. This is potentially the most problematic aspect of client education. After all, who knows their business and their customers best if not them? We should not let such thinking prevent us from voicing our concerns and suggesting a better way when we see one, especially when it comes to adding new functionalities to the product.

The client might be certain that a new feature requested by their users will help them increase revenue or market share, but their assumption might be totally wrong. Has it been tested? If not, what can we do to verify it? Is the cost of implementing the feature justified, considering the projected benefits? We might prevent the client from wasting time and resources by simply asking such questions, which in turn will make them more sensitive about the need to think their ideas through before they are acted upon.

Summing up

Educating should not be confused with teaching. Your efforts to increase the client’s understanding of the development process will most likely fail if they are framed in such a context. Instead, let’s make sure that all of the efforts described here are a part of the continuous improvement of the entire team. As such, each team member can contribute to this effort: whether through setting a good example, asking difficult questions, saying “no” to requests and practices that might compromise the quality standards.

Building partnerships - how to make sure that the client is a part of the team

author: Aleksandra Pyta

Clients are always right. Partners work together to make it right.

These two sentences from Heather Casey’s article Partners, not Clients perfectly sum up why it’s crucial to focus on building partnerships with clients. Our approach towards clients has a tremendous influence on the quality and value of the work we deliver.

The benefits of a partnership

  • Clients who trust us ask for our advice more often, and they are more inclined to accept our recommendations and act upon them.
  • They bring us in on more advanced, sophisticated, strategic projects, and share more information that helps us help them.
  • They treat us the way we want to be treated when we make a mistake – with respect and understanding.
  • They pay the bills without questioning the price.

Partnerships are built on trust. Building partnerships is a complex process that can be made easier by following several rules.

Rule #1: Be patient

It won't happen overnight. Trust is a process – with its own share of ups and downs – that you have to manage actively. It needs to build up gradually, and there's no guarantee of success, as it depends on timing and the attitude of both parties. Remember that none of us began our careers as a trusted partner and advisor, but it for sure should be the direction we're heading. So give yourself time to rise into the role of a trusted partner.

Rule #2: Know the person/company you're working with

Do your research before entering a project. Understand your client’s business. Identify and get to know your stakeholders – the key people for the partnership. Where are they in the company hierarchy? What might their aspirations be? How does this project fit into those aspirations? Who are they outside of work?

Knowing more about the project will help you ask better questions and adjust your offer to the needs of the client’s business. It will also show that you're fully engaged in the project and that you want it to succeed as much as the client does.

Knowing more about the people you're working with will help you tailor your communication and recommendation style to the situation. Having information on what ticks people off can be an excellent ice-breaker and an effective way of building rapport.

But be careful. While research is useful, there's a thin line that separates it from a breach of privacy and trust. Remember to respect your clients and make sure that you're as mindful as possible with revealing the information you have on them. Otherwise, the trust you’ve been so carefully building can be jeopardised.

Active listening

We all know this one person that makes people crazy by finishing their sentences or asking questions before they end up telling their story. Don't be that person.

To earn the right to advise someone, you need to listen to them first. Don't make assumptions. Treat each client as an individual. Don't focus only on their similarities to other clients – pay as much attention to the differences.

Believing that you're right isn’t enough – you must be helpful. And it's hard to help someone if you don't know the essence of their problem, or if they don't believe that you understand it.

Rule #3: Build on credibility, reliability, and intimacy


You've probably witnessed a fantastic expert with vast knowledge and a lot of experience sharing their brilliant advice... which is then ignored. Why does it happen? Because we often forget that credibility is built on two pillars. One is our content expertise. The other is the way we present it – how we look, act, react, and talk.

To improve your credibility:

  • Avoid saying things that others might perceive as lies. Saying that "we'll put our best people on it" inspires thoughts such as: "really? Who are your worst people? According to whom? And how come the best are not busy?"
  • Express yourself with more than words. Use body language, eye contact, and vocal range.
  • When you don't know something – say that you don’t. Quickly and directly.
  • Don't show off. It will bring a result opposite to the one you want.
  • Show that you love your topic.


When you’re perceived as reliable, the client believes that you can be trusted to behave consistently.

In a rational sense, reliability is achieved by establishing connections between promises and actions. It has a strict action orientation, which differentiates it from credibility. It links words and deeds, intention and action.

It also has an emotional aspect – when you do things in the manner the client prefers, or to which they are accustomed. It's achieved through meeting expectations.

To improve your reliability:

  • Make specific commitments to small things and deliver on them. On time and without a fuss.
  • Make sure meetings have clear goals and ensure that those goals are met.
  • Use the client’s style, terminology, formatting, etc.
  • Reconfirm scheduled events before they happen. Announce changes to scheduled meetings as soon as they arise.


It's a bit weird to see this word in a business context. It may seem like keeping emotional distance from the client is the superior approach. However, a business can be intensely personal – due to financing the project from private funds, counting on promotion within an organisation, or personal aspirations.

You don’t have to share details about your private life in order to build a partnership. Intimacy in this context is an emotional closeness regarding the issues at hand. There are no strict guidelines on how to build intimacy. It certainly requires courage and much practice to get it right. There’s also a considerable chance that you’ll have to be the one taking the first step towards establishing intimacy. Take a personal risk and share something that you see, feel, or think.

Let us share a story about intimacy. A client who had been very engaged in the daily work of their team started to regularly zone out during meetings and was less and less involved in their progress. The Project Manager decided to talk one on one with the client, expressing her and the team’s feelings: that the client was abandoning them, and they didn’t understand why. The client was surprised but appreciated the candor. He explained the reasons behind his behaviour and since that day shared more information with us – the type of information that he would not have shared before.

Rule #4: Don't focus on your success

Work towards the mutual vision

Clients are always right. Partners work together to make it right.

Clients tend to know what they want, but some of them have issues with expressing it clearly or with finding the right path to achieving what they want. Your role as a partner is to help clients translate their aspirations into tangible goals, and show how your cooperation can help them achieve those goals.

It might turn out that what you can offer to the client is not the best fit for their needs. It's important to remember that to build a great partnership, you need to care about the relationship more than about closing the sale at all costs.

Forget about your ego

It's amazing what you can achieve when you're not thinking about who gets the credit for what. It's also an essential step in building trust – show your clients that their interests make the top of your agenda and that the partnership is not about you.

Here’s how you can show your lack of self-interest:

  • Use open-ended questions.
  • Don’t give answers until you’ve earned the right to do so (through research and active listening).
  • Focus on defining the problem, not guessing the solution.
  • Listen without distractions (texts, phone calls, emails).
  • Take most of the responsibility for failed communication.

It's in the Team’s best interest to take those rules to heart and start implementing them in their daily work to see the benefits that partnership brings into a project. Building trust and partnership with clients shouldn’t be a concern of only Project Managers and Account Managers.