If you’ve experimented with Scrum before, you’re likely familiar with the Scrum Master and Product Owner roles. In case you’re not, here’s a quick breakdown: the Scrum Masters are responsible for improving and maximizing the productivity of the Scrum Team. They have three essential priorities – support the Product Owner, support the Development Team, and support the Organization. The Product Owners are the customer representatives; they ensure that the team spends time building things that bring the most value to the organization.
These roles sound so deceivingly simple that sometimes a single person will try tackling both roles. This can happen in a ground-up implementation of Scrum when a Product Owner is never officially assigned to the team, like in startups or the digital agency world, leaving the Scrum Master to wear multiple hats. It can also happen when the team’s Scrum Master is also an individual contributor (for example, a full-time Developer) and simply too overwhelmed to focus on the Scrum process. In this case, the Product Owner may try to step up to lead the process and their own responsibilities. Regardless of the reason, when a team attempts to combine all duties into a single role, it seldom ends well.
Scrum Masters are part of the Scrum Team trinity, including the Scrum Master, Product Owner, and the Team. Scrum Masters play their part by ensuring that the entire team is familiar with the Scrum Guide, Scrum framework, and all the Scrum events. These methods provide a smooth delivery of all user stories, requests, incidents, and enhancement capabilities.
Great Scrum Masters spend a lot of time nurturing the skills they need to get really good at their work. In the Scrum Master job, there is a vital people component and an organizational component. Scrum Masters are like skilled engineers solving complex problems: their thinking and effort is around uncovering barriers and figuring out how to overcome them.
Product Owners are responsible for utilizing the team to ensure the correct product completes development. For that planning, they need a clear vision that emphasizes the product’s value. As a result, they develop the product vision using user stories, research, product and business requirements. The product backlog is a crucial component of Agile product development; thus, backlog management is the top activity of the Product Owner.
Furthermore, Product Owners are the first ones to get the release date. While Product Owners can’t single-handedly control the release of a product, they can call for the enactment, pause, or cancellation of the release.
Besides the different responsibilities of the Product Owner and Scrum Master, the skills needed to perform each role are also quite different. To manage and prioritize the backlog, the Product Owner needs to analyze market data and have domain expertise to make the right decisions. For the Scrum Master, people management skills such as resolving conflict or facilitating communication come to the forefront. Given the disparate priorities and abilities associated with each role, there is a solid reason the Scrum Guide separates the two. Imposing the responsibilities of both roles onto one person may be overwhelming and cause distress.
Now let’s go back to our question: Can the Scrum Master and Product Owner be the same person?
The answer is that they can, short-term, but they shouldn’t. The Scrum Master and Product Owner should always be separate roles, as they are full-time roles. Of course, there are exceptions to the norm, and one person could do both roles, but we need to bear in mind that many teams split these jobs out for a good reason. Combining the posts might be necessary short-term but, in reality, may not be sustainable for long periods. We shouldn’t burden one exceptional person to do two jobs at a subpar level.
Here are a few reasons why having different persons for each role is beneficial to a business. First, when Scrum Masters act as Product Owners, they don’t have the same access to customer feedback. Without this data, it’s challenging to create products that fulfill the customers’ needs and goals. One could spend all this time creating products that the customers don’t like or aren’t what they expect.
The next issue is that when Product Owners act as Scrum Masters, they take on new responsibilities that devalue their original ones. If they’re taking time to perform Scrum Master duties, they’ll have to cut corners when creating the product backlog and managing the development process. There’ll be less room for innovation and more focus on completing tasks before deadlines. Since the Product Owner has too much on their plate, the product’s value will begin to suffer.
When the Product Owner acts as Scrum Master, the solution is to find a new Scrum Master inside the team who can dedicate time to the role. Placing trust in our team is a great way to show leadership, and we might be surprised by their capabilities. Not only does this free the Product Owner from managing the Scrum process, but it also helps create a healthy tension between Scrum Masters and Product Owners.
When the Scrum Master is filling in the Product Owner’s responsibilities, the simplest solution can be to free the individual of their Scrum Master responsibilities, allowing them to focus on the Product Owner role entirely. This, of course, only works if the individual is interested in the Product Owner career path.The Scrum Master and the Product Owner roles are complex. If both of these voices reside in a single person, it will confuse the team. We won’t have that check and balance, and we’re going to end up underperforming – this thought would be daunting for anyone on the team. Single Product Owner; Single Scrum Master – let’s try not to blend them in the same person.
Self-organized teams in an organization is not a new concept, this management approach has been used years ago, even in the previous century, and it is becoming increasingly popular nowadays with emerging software development methodologies.
This concept has increased its popularity after the broader adoption of Agile. If we are to look into the Agile Manifesto, we will find that “the best architecture, requirements, and designs emerge from self-organizing teams”.
A self-organized team is where your teammates are not afraid of picking up a work item that they have not tried before, and would not be scared of the feedback when showing the work done in a demo session with the client and the team. This is a way to grow and evolve as an individual, and as a team. A self-organized team is most successful when there is enhanced communication among the team members and they trust each other to get the job done.
The first step for cultivating self-organized teams is to enable self-organization and remove the misperception that the leader makes the team. We believe that the leader is the hero of a successful team and manages the team to achieve greatness. As it turns out, the hands-on activities of the leaders of a group make a difference to the team. However, the type of activities are different from common belief. Enabling the team members to manage themselves is the most powerful service a leader can provide to a team. Another thing a leader can do is effectively launch the team, as this accounts for a crucial part in the success of the team. Coaching the team, constantly and on time, significantly contributes to a team’s smooth journey.
When forming a team, it is advisable to choose the right way of working from the beginning. For example, Agile and its framework Scrum totally share the same principles and in fact, a Scrum team is a self-organized team. The way to get to a self-organized team comes down to serving the team, building up team capabilities, and instituting a solid team launch and onboarding process.
Although self-organizing teams have extensive freedom and autonomy, they aren’t one hundred percent independent of outside control. Managers still play a role in the direction and ultimate success of their teams.
As a manager, serve the team instead of managing them. For example in Scrum, instead of managing your teams within the sprint, let them self-organize around what they can control. If you can switch your focus as a leader to helping the team remove waste that they cannot remove themselves, you will serve your team best.
Effective leaders know when to let go and when to stay close to their teams. By letting go, trusting your team, and allowing them to take control, they will self-organize if they have the capability to do so. This is a critical point — a team can self-organize only if they have the needed behaviors and skills. Your job as a leader is to support the acquisition of these behaviors and skills. You need to coach your team to trust their abilities and overcome the fear of becoming an incapable team.
Make sure that in each team roles are assigned, making it clear for everyone where they stand. Team members should understand each other’s responsibilities. For example, in Scrum, we have predefined roles and the essential roles include the ScrumMaster, Product Owner, and Developers. In that way, everyone knows what to expect from each other.
Another vital aspect for nurturing self-organization is to make information transparent to everyone. Enabling easy access to information will encourage your team members to make decisions on their own, give them a wider perspective and remove all excuses for not acting. You can improve the transparency of information in your team by encouraging people to share their personal and project goals with others, granting access to available tools or software to your team, and creating digital and physical information radiators. As a leader, consider what and how you’re sharing with others — don’t share unconfirmed information, noise, rumors, or things that might create more confusion than bring benefits to the team.
To experience a major impact on the business organizations, we need agility not just at the individual or team level, but across the entire organization. To this end, helping teams become self-organizing is a crucial step. However, self-organization can’t be imposed. We can only help it evolve and later nurture to bring about the transformation. We need to keep in mind the most important characteristic of a self-organizing team: the need for greater freedom. However, freedom is often misunderstood to mean more and more options. Contrary to the common belief, a person or a team is comfortable with only as much freedom as they have the ability to cope with successfully. Beyond that point, freedom of choice becomes an overhead and they look for freedom from choices. For the team and its members, the kind of freedom needed is not static, it evolves as they become more and more self-organized.
Some think that these roles or positions if you will are one and the same. That a ScrumMaster can easily fill the role of a Project Manager and vice versa, however, a closer look reveals some large differences in mindset and execution. Let?s dig in.
Unlike a Project ?Manager? a ScrumMaster is a servant leader, not a manager. The ScrumMaster is responsible for ensuring that the project is carried out according to the agile framework and values.
On the other hand ? the Project manager?s duties are broader and not always clearly defined. Some responsibilities include: building and managing the team, managing the timeline, the scope, the budget, and risk. This diversity of tasks makes the manager?s focus a desired commodity for all stakeholders on the project.
Main Project Manager?s responsibilities
Managing the scope ? i.e. the total amount of work; defining all of the deliverables and the WBS (work breakdown structure). Understanding which tasks are within the scope and which are outside of the scope?s boundaries.
Managing the timeline ? ensuring that all tasks are started and completed on time, controlling and extending the task duration if necessary. Also ? taking care of tasks ordering and interdependencies.
Managing the resources (the budget) ? this is a complex process, involving: estimation of required resources, planning (procurement) of resources, and resource control/ monitoring ? how are they spent during the project lifecycle.
Managing the people (team) the Project Manager should always be helpful, honest, and transparent, and put the well being of his team ahead of his own. Also he should assist the team to achieve predetermined milestones.
Managing the risk can be abundant and very complex. It can negatively impact all three project components the budget, the timeline and the quality of the outcomes. The project manager should anticipate the risk, estimate the consequences and propose risk mitigation strategies.
The Project manager should also resolve issues that obstruct the team?s progress. He can do this by removing them himself, enlisting others to take care of them, rallying the team to overcome them, and/or introducing a change in policy or rules in the organization.
Main ScrumMaster responsibilities
The most important task of the ScrumMaster is to ensure that Scrum is well-practiced. He doesn?t have to conduct Scrum ceremonies but it helps. He engages with the team, connects with stakeholders, and, most importantly he is an example by living Agile thus actively proliferating them with the organization.
Another important duty is to organize and attend all Scrum ceremonies (daily Scrum meetings); he should carefully consider the scrum artifacts, and let the team optimize the process and their performance step by step in every subsequent sprint.
Also, an important duty is to build the capacity and agile maturity of all team members. It is important to improve their skills in using Scrum. If the ScrumMaster overlooks this, Scrum will not be applicable and will lose its power in effecting change as well as outcomes.
An advanced task of the ScrumMaster is to use Scrum to improve the creativity, learning, and abilities of the entire team. This is not an easy task and requires large support from senior management. And this is the responsibility that has the best chance of making a long-term and meaningful impact.
Soft Skills of Both roles
The successful ScrumMasters and Project Managers will always try to create a new management approach. It is well explained by the experts that the ScrumMaster should be the conscience of the whole team, and the Project Manager should be a leader.
Both of the roles are demanding and not easy. You should be patient, kind, passionate, hungry to learn, and to ask for support from others. If you want to become a ScrumMaster or Project Manager, adopt a curious mindset ? this will make your future role so much easier.
vs and Project Manager
Basically, the ScrumMaster?s duty is to improve the team’s effectiveness and productivity. This is opposite to the focus on managing the project which is done by the Project Manager. Other differences between the ScrumMaster and Project manager include (not an exhaustive list):
Assist the team to use Scrum efficiently, and not managing the team;
Remove impediments (of all types), instead of removing only difficulties tied to the project deliverables and timeline;
Provide help to others in the facilitation of the key Scrum phases, instead of leading the status updates and giving direction;
Concentrate on the team’s progress, instead of focusing on the project plan;
Hold the team together after the project, instead of working with a group of individuals for the duration of the project, and then working with others for the next project.
However, this is only a shortlist of differences. There are other interesting concepts to note, such as the roles and responsibilities of a typical Project Manager. They are split between the ScrumMaster, Product Owner, and Team Members, but that?s for another article.
The best project teams, whether practicing an agile development framework or not, work together. They are focused on what?s best for the team and the project. Whether ScrumMaster or Project Manager the main goal is to deliver a product experience that exceeds customer and market expectations.
A significant barrier many teams face in their operations is the undeniable communication barrier between non-tech and tech teams. For instance, project managers and marketers may want projects done quickly in a typical marketing agency, while software engineers typically want to take their time on projects.
Also, these teams speak different languages (both figuratively and literally) and often work in different ways. Therefore, bridging the gap between non-tech and tech teams is crucial to reducing friction and boosting performance and efficiency throughout your organization. Here are some key ways to bridge the gap between your technical and non-technical teams.
It is essential to begin every project by ensuring that both teams plan together extensively. Therefore, companies must create all-inclusive planning processes, ensuring that everyone understands the other teams’ roles and functions concerning their own. This way, teams can identify potential bottlenecks early on and streamline communication to prevent confusion and possible delays down the line.
Recognizing all contributions and positives from both teams is essential to bridging the gap between non-tech and tech teams. Many companies put too much emphasis on their software engineers’ capabilities and accomplishments at the expense of everyone else’s. Although your tech team might be accomplishing big things, it is essential not to let non-tech teams feel as though they are only playing a supporting role in the organization.
Also, recognize non-tech team members who put in the effort to learn about the tech world. For instance, if your manager is learning website development or your marketers are learning Photoshop, you can commend them for the effort to encourage other non-tech members to do the same.
To save time and billable hours some agencies exclude production from product vision meetings and only communicate requirements. Though understandable this leaves the development with only part of the story. To be wholly successful the entire team needs to know why they are building something and what problem they are trying to solve. This perspective not only dignified the team but contributes to a phenomenal amount of collaboration since everyone is on the same page trying to solve a problem and not just check off a requirements doc.
Companies should always look for ways to intertwine tech and non-tech teams, ensuring that their roles aren’t too far apart. For instance, you can have non-tech team members participate in application and website development instead of making it the sole responsibility of tech teams. If collaboration is made a mutual aspect of work, tech and non-tech teams can collaborate better, leading to stronger bonds and more efficient teams.
To address the communication challenges, you must be patient and constant. Coaching is also a powerful instrument for turning your team around. Keep up the good work; it will pay off in the end.
The outsourcing vs in-house subject has been debated for the last two decades in almost all industries, including agencies. Some companies prefer to expand their networks, reduce overheads and outsource, while other companies prefer in-house for native language skills and easy timezone management. There are plenty of reasons to choose between in-house vs offshore, so it’s best to get informed before making the call for your agency. No one wants to have to make a mistake on this one. It’s costly.
The key question is pretty straightforward. Do I need in-house or offshore development teams for my agency? The reasons for deciding on one or the other are unfortunately a little less simple. Looking into the pros and cons of each option can help to find the gaps and reach the solution that works for your needs.
To start with, take a thorough look into your specific delivery requirements and identify activities that can be bundled as McKinsey terms it. Bundling is the systematic analysis of business processes in scope at a business, client, and project level. The objective is to discover activities that can be combined under the same ownership and location model. Each agency will be unique in terms of its bundled activities and the sourcing strategies that it will need to follow based on those requirements. Things to look out for when doing your analysis are:
A change from the core vs non-core activity approach, bundling allows a more flexible strategy that can mitigate geopolitical or currency rate risks, in addition to being purely a cost reduction or margin increasing exercise. Apple bundles all R&D, product development, and design in-house while keeping all manufacture offshore with their partner in China, Foxconn.
When you have the overall approach to defining your sourcing strategy needs in place, you can look at the pros and cons of outsourcing and in-house to select the best combination for your agency.
For those of you who are start-ups on a bootstrap budget, this first one’s for you.
The Deloitte 2016 global outsourcing survey reports that 59% of companies consider outsourcing a cost reduction tactic. A large portion of savings comes in the form of salary differences between a developer team in India and one in the US, for example. The difference between salaries listed by Deloitte shows that an agency could outsource its development and save 3/4 of its salary costs a month.
Added to the salary savings are the other overhead savings that can be gained.
A key advantage for agencies that have some project-based clients that have future retainer potential is the ability to quickly onboard an expert team for a short-term project.
There are several options for hiring a project team:
Offshoring can allow your agency to take on projects outside of your core expertise, leaving you free to do what you do best in-house. With the number of new technologies launching and the depth of specialization required for many types of digital projects, it is not always feasible to team up internally to deliver a broader range of projects.
With offshoring, you can follow Warren Buffet’s advice to “stick to your knitting” without losing out on additional revenue-generating business that can be delivered in partnership with an expert vendor. This approach can help to expand existing retainer accounts as well as build currently project-based relationships into more long-term and predictable revenue streams.
It is worth mentioning that your core competencies are not necessarily your core activities, which have been used to determine offshore strategies. McDonald’s core competency is probably standardization, while one of its finance function’s core activities may be sales.
For businesses, risk mitigation is an important thing to consider. Offshoring, through SLAs and legal contracts, shares your project risks with another company that has expertise in the field that your project requires. Win!
Lack of control
You need to be able to trust your outsourced partners to do their job without the need to micromanage. If you find yourself needing to manage the tactical details of an entire scrum team, you are not saving time or money and probably have the wrong vendor in place.
Good outsourced partners will be able to understand the key project documentation or requirements and implement them, all while regularly collaborating and keeping you up to date.
Offshoring does represent a delegation of control vs in-house teams but should you have a good partner that does what you can’t do in-house, the risk is well justified and mitigated.
Communication and time zones
Multinational teams soon become masters of the ‘meeting time optimization’ but if you add language barriers to your team’s time zone hurdles, you are reducing the benefits of outsourcing.
Having a local team in the same space can help build comradery, good communication, and streamline processes. Changes often get done in real-time. Agile teams can display visual artifacts and project information in a shared space.
Whether your company’s social culture is centered around food, drinks, sport, or charity, local teams can build out of work social bonds that keep them with your company long term.
With in-house teams, you have total oversight and more immediate control over your projects.
Especially with agile projects, in the long-term, your in-house team’s velocity increases over time as they become more accustomed to working together, improving cost efficiency.
Being able to offer top local talent a stable environment with long-term prospects and career growth, will always ensure that you have good people and low staff turnover rates. Those hidden rehire and training costs are not worth it.
You can combine in-house roles with outsourced roles. For instance, your single point of contact can be in-house, in the same city as the client. The delivery and development team can be outsourced to a city or country with skilled people, better salary rates, and global network opportunities. There is no need for black and white in-house vs outsourced solutions. Do what works for your business.
Teams of local professionals can be expensive depending on where you are based.
Recruitment, training, benefits, office overhead, and career progression costs all add up to the cost of running an in-house team.
Finding and hiring top talent is not easy or cheap. While you spend time building up a great team, your company is operating at reduced efficiency. In a fast-paced and competitive marketplace, this puts your agency at a distinct disadvantage. Deliverables need to be on time and of high quality. Projects tend to go to the agency that can deliver quality, quickly.
Each agency is different. Do your analysis, assess your requirements, and use hybrid models as needed. Doing your due diligence will make sure that your unique sourcing strategy is informed by sound business logic. Lastly, your sourcing strategy can and should be fluid and adapt as your agency and project’s needs develop.