Scrum master vs project manager? A high-level guide for making the right decision.

Designer team's role in creating business value
Attrecto team

Attrecto team

Scrum master vs project manager? A high-level guide for making the right decision.

The Manager and the Master: Choosing Between A Scrum Master and Project Manager

If you’re transitioning from a waterfall to an Agile model of software development, you might be wondering about the roles of scrum master vs project manager.

What’s the difference between the two roles, and aren’t they basically the same thing? Isn’t a scrum master just an Agile project manager? In short: No, they’re not the same, and it’s essential to be clear what the responsibilities of each position are in project management.

While there are many similarities between the role of project manager and scrum master, the differences are more than just semantics.

You can’t employ one person to act as both scrum master and project manager. Similarly, if you’re moving from a waterfall development method to Agile, don’t just rename your project manager as “scrum master.” Adopting an Agile methodology is about much more than just changing the language you use.

Agile project management is quickly becoming the industry standard for good reason. But some web and app development companies are adopting Agile practices without having a sound understanding of the 12 Agile software development principles.

Likewise, the term “scrum master” has become somewhat of a buzzword, and more and more teams are employing one. But having a scrum master doesn’t necessarily negate the need for a project manager.

Scrum master vs Project manager. Color image showing the main differences between traditional and agile team building
The main differences in the structure of the agile and traditional teams.
The role of a project manager has fallen out of fashion somewhat, but it’s still a vital and necessary role for most teams. The project manager performs functions and responsibilities that are beyond the scope of the role of scrum master and vice versa. So let’s take a look at each of these specific roles, in turn, to get a better idea when each is needed and the individual skillset needed to excel in each role.

What Does a Scrum Master Do?

The scrum master sits between the development team and the customer’s requirements, supporting the product owner, and coaching the team.

Rather than acting as manager, the scrum master’s role is more facilitator. They act as “supports”, guides, observers, and protector and nurturer of ideas and processes within the scrum.

The scrum master is a servant leader for the scrum team, meaning that they focus on the needs of the team so they can serve the customer better.

The scrum master is not involved in decision-making, and so their role is narrower than that of the project manager. The scrum master is responsible for:

  • Making sure all members of the project team understand the scope and goals of the project.
  • Helping them to organize themselves and work together to get their jobs done as efficiently as possible
  • Helping to remove obstacles that are slowing the team down, such as slow or unnecessary approval or processes and outdated hardware.
  • Handling development tasks as requirements change.
  • Relaying information about development status and progress to the project stakeholders.
  • Supporting and guiding the product owner (who may also be the project manager) and working together to design product backlog items for the next sprint.
  • Facilitating the daily scrum meeting.
  • Promoting and supporting the scrum framework as defined in the scrum guide and helping everyone to understand and follow scrum implementation, theory, practices, rules, and values.
Colorful picture shows the four main responsibilities of a Scrum Master
Responsibilities of the Scrum Master.
A scrum master doesn’t plan, doesn’t manage, and ultimately isn’t responsible for the project’s success or failure. Their priority is to help the development team focused on their main priority: creating the best product they can.

What Does a Project Manager Do?

The project manager’s role, on the other hand, is to communicate directly with the customers, allocate tasks to the development team, and make decisions that affect the project.

Some of the key responsibilities of the project manager include:

  • Understanding the project scope and creating the project plan.
  • To manage the work, budget, resources, and project timeline.
  • Allocating tasks to team members and ensuring they get done in the allotted time.
  • Reporting to stakeholders and leadership on the state and progress of the project.
  • Communicating and coordinating with multiple development teams.
  • Managing and mitigating risks.
  • Managing the relationship between the customer and the stakeholders.
  • Ensuring the quality of the final project and that it meets the customer requirements.
Colorful picture display the main responsibilities and tasks of a Project Manager
Project Manager’s main tasks.
In many organizations, a single project manager works with several scrum teams, but each team should have its own scrum master.

Scrum Master Vs Project Manager - Which one do you need?

Project manager and scrum master are both important roles. But how do you decide which of these positions you need to hire for?

You need a scrum master if:

  • You already have a product owner in-house, and you want to break down the development into smaller tasks.
  • You are using an Agile methodology exclusively.
  • Your developers can self-organize and work without strong supervision.

You need a project manager if:

  • You want to give decision-making authority to a designated person.
  • You are using a mixed methodology or using Agile practices in waterfall projects.
  • You need someone who can maintain your backlog, task list, and administration.

    In summary, the two roles have fundamentally different focuses and viewpoints. To attempt to cross or merge the roles would produce a conflict of interest.

    The project manager’s focus is on the project and making it a success, whereas the scrum master’s priority is the team and ensuring their success.

    Ultimately, the project manager answers to the customer and must prioritize their needs along with the interests of the development company or organization as a whole.

    The scrum master, on the other hand, is responsible for encouraging, supporting, and enabling the team to produce the best product they can, shielding them from disturbances and threats. This includes any disturbances from the customer or other project stakeholders.

    Our approach:

    Regardless if it is a Scrum Master or a Project Manager who guides you through the project, here at Attrecto we always provide the most relevant support to our clients. Throughout the last decade we always kept up with the market changes and adopted the latest (proven) trends to best meet the business needs and requirements of our clients. That is why besides a waterfall approach, where the team is led by a PM, we also provide agile methodology (already since 2012), with seasoned Scrum Masters.

As at the “first step” at the very beginning of each project, we have a consultation phase, when we perform deep client interviews, with the purpose of finding out the most about the client’s business needs , the project’s complexity and the underlying tech-stack (if already available).

After we get a more comprehensive and accurate assessment, we can decide which approach best fits for the client and the project.

Generally, we go on with an Agile methodology when the requirements are not “set in stone” by the customer. In this methodology, clients may even ask for changes in the requirements during the development process. With this strategy and the comfort of the Scrum Master’s (SM) experience, we can:
– break down the processes into smaller parts
– respond promptly to the needs of any changes
– and provide faster review cycles, so the client is always up-to-date in terms of the status of the development.

With the guidance of the SM, the developer team can focus on its primary goal, which is to create an outstanding product.

The classic Waterfall methodology comes into play at Attrecto when customers have their exact specifications ready (and have no intention to change them later). After we agree on the terms of the engagement, the project kickoff is already set up by the designated PM, who also remains the point of contact to the product owner of the client. In this case it is our PM who makes sure the delivery team works well together and there is no communication barrier between us and the client.

Summing, when you have clearly defined roles and assign them appropriately, every individual in the organization can work efficiently and achieve their highest potential, depending on their individual skills. This results in a more productive team, better communication at all levels, and ultimately a better product – and a happy client.

Download your free guide for development process in UX driven projects

Share this post

Share on facebook
Share on google
Share on twitter
Share on linkedin
Share on pinterest
Share on print
Share on email

SCRUM in a nutshell

Meeting Discussion Ideas Communication Corporate Concept
Attrecto Team

Attrecto Team

SCRUM in a nutshell

The “manifesto” for agile software development starts with a curious sentiment: 

“Individuals and interactions over processes and tools” 

It’s not that there isn’t value in the stuff on the right, continues the manifesto. It’s that the stuff on the left is even more valuable. 

Scrum, agile and sprints are more than just development buzzwords — they’re ways of working and approaching complex problems that put values like communication, knowledge-sharing, embracing failure, introspection and observation front and center. 

Besides the fact that working with Scrum has brought our software projects major results, there is also something very human about the methodology. 

So instead of having you wade through a number of complex and jargon-heavy white papers, we thought we’d give you the TL;DR version that still answers questions like “What is Agile project management?” and “How can our team begin to use Scrum for software development?”

Source: Unsplash

Scrum in Software

Agile methodology gets a lot of fancy press but there are a number of other similar methodologies, including: 

  • eXtreme Programming
  • Crystal Clear
  • Agile Unified Process 

Scrum’s rise to the top, however, is because of its simplicity, straightforwardness and the ease with which teams, across functions, can implement and collaborate. Often, team members experience perks like: 

  • Feedback gathered from stakeholders, customers and end users throughout the process of development
  • Rapid and aligned reactions to changing requirements
  • The dev team’s increased velocity, thanks to 1-4 week sprints, which provide a sense of urgency and focus
  • Shippable increments delivered early and often, enabling stakeholders to provide real-time feedback (and team members to observe customers in action)
  • Productive, effective, and efficient meetings to help ensure that developers get help when they need it

Scrum is not a process, technique, or definitive method. 

It is a framework that offers freedom of implementation. 

Through organized yet creative “sprints”, Development Teams bring a design thinking and problem-solving mindset to software. User experience is not in the rearview but right in front of you so the team can bring real customer value, which translates to real business value. 

Scrum’s power and potential, then, is all in adopting a user-centered development mindset. This is what can help web development companies create and deliver complex but successful products users can actually benefit from. 

Source: Unsplash

The basic framework consists of Scrum Teams and their associated roles, events, artifacts, and rules, detailed by Ken Schwaber and Jeff Sutherland, who developed Scrum. 

Yet, there are now quite a few successful “Scrum”mers (like Kai Haley, leader of the design sprint training program at Google) and “Sprint”ers (like Jake Knapp, design partner at Google Ventures) who have perfected the art of running a successful Sprint and the formation and facilitation of a Scrum Team to a tee. 

To get started, you’ll need to have an understanding of its structure and working style. 

The Scrum Team

The Scrum Team is made of a couple of concrete roles, which we’ll look at here. Teams are self-organizing and cross-functional.

The Product Owner: responsible for maximizing the value of the product resulting from the work of the Development Team.

The Development Team:team members who work on delivering a potentially releasable Increment of the “Done” product at the end of each Sprint. Development Teams are structured and empowered by the organization to organize and manage their own work.

The SCRUM Master: responsible for promoting and supporting while also connecting with those outside the Scrum Team, helping them to understand which of their interactions with the Scrum Team are helpful and which aren’t.

Source: Unsplash

Scrum Events

Pre-determined Scrum “events” are a great way to create regularity and minimize the need for meetings. Events have a set time duration they can’t go beyond. 

The Sprint

The heart of Scrum is a Sprint, which usually runs anywhere from 1-4 weeks. The goal is a useable, and potentially releasable product Increment. Sprints have consistent durations throughout a development effort. Don’t be surprised if you’re facing 8-hour days of consistent focus. 

Another principle is that a new Sprint starts immediately after the previous one wraps up. 

Sprints consist of the following activities: 

  • Sprint Planning
  • Daily Scrums
  • the development work 
  • the Sprint Review
  • the Sprint Retrospective

While no changes are made that might take the “Sprint Goal” off-course, the scope can be clarified and re-negotiated with the Product Owner and Development Team as more is learned.

Source: Unsplash

Sprint Planning

There’s no need for your team to do much homework prior to the Sprint. But, the designated Sprint Planning stage is where the team creates a plan for the collaborative work to come. It’s also considered an event so, naturally, it has a time limit: a maximum of eight hours for a one-month Sprint.

Daily Scrum

Every day of the Sprint, there is a 15-minute event called the “Daily Scrum”. There is where the Development Team plans work for the next 24 hours and inspects the work done yesterday. The Daily Scrum is held at the same time and place each day to reduce complexity.

Sprint Review and Retrospective

A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. It is informal and lasts, at most, for four hours. 

The Retrospective is a chance for the Scrum Team to inspect itself and create a plan for improvements for the next Sprint. The atmosphere is open to feedback and sharing because presentation of the Increment is all about getting feedback and fostering collaboration. 

Source: Unsplash

Scrum Artifacts

So Scrum Teams engage in Scrum Events. And Scrum Events inevitably result in Scrum Artifacts. Think of these as the “residue” of activities and events that also give the team opportunities for inspection and adaptation.

  • Product Backlog:an ordered list of everything that is known to be needed in the product. Any requirements for any changes to the product go here. It’s the domain of the Product Owner to advise on/tend to content, availability, and ordering.
  • Sprint Backlog: from the list of “Product Backlog”, the “Sprint Backlog” items are those that are selected for the Sprint; this includes a plan for delivering the product Increment and realizing the Sprint Goal. 

While some software teams decide to cleave design and development into two separate sprints,  others favor an integrated sprint approach that brings together UX designers, developers and testers working together as a scrum team.

The benefit to this integrated environment, especially using Scrum, is that it allows you to constantly maintain a UX mindset and focus. You’re actively testing the product in iterations as you go along, allowing the next increment to thoughtfully reflect improvements from the previous version.


Source: Unsplash

Of course, this calls for a well-functioning development team in order to build a powerful and ingenious product.

However, Scrum comes with a caveat: using it is not a guarantee that you’ll end up with a successful product. 

Agile development companies must embrace the idea and reality of “failure” and ask themselves what this term means to them. 

The other consideration is the role of a UX designer within an integrated Scrum team. It’s the UX designer who keeps a finger on the pulse of the project’s alignment with the customer, constantly bringing a clear understanding of product vision and its requirements. 

This UX focus, then, directly translates into a superior customer experience. 

So, at its core, Scrum ultimately provides a better CX for clients and internal teams. Customers are integral to the framework and need to be deeply involved in the development process. 

It’s the interactions with the customer and their observed experience that help to guide each successive iteration stages. It’s direct involvement coupled with ongoing, incremental working that makes the Scrum framework so powerful in software development.

Download your free guide for development process in UX driven projects

Share this post

Share on facebook
Share on google
Share on twitter
Share on linkedin
Share on pinterest
Share on print
Share on email

The truth about the accuracy of software estimations

Programmers working on computer program
Attrecto Team

Attrecto Team

The truth about the accuracy of software estimations

Have you ever heard of a “Standish Chaos Report”? Trust software developers to come up with fantastic terms for an otherwise prescient trend occurring in development projects: the incidence of project failures and the factors that contribute to them.
The failure records of software projects in the United States alone is quite staggering. According to the Chaos Report

  • 31.1% of projects will be cancelled before they ever get completed
  • On average, across small, medium and large enterprises, over half of projects will cost 189% of their original estimates
  • While companies in the U.S. spend more than $250 billion each year on IT application development, spanned across approximately 175,000 projects, only 29% of these are ever counted as “successful
  • Meanwhile, Tricentis estimates that software failures cost the U.S. economy up to $1.7 trillion in financial lossesSource: Chaos Report 2017

The truth is that poor estimation can lead to a score of issues, besides simply a time or cost overrun.
It can lead to changing requirements, poor testing practices, software vulnerabilities, glitches, bugs and overall “challenged” projects doomed to reproduce technical failures if launched merely to meet cost and time budgets but not quality standards.

Source: Software Fail Watch — 5th Edition

In a survey of the negative effects and the “erosion” of value on a brand, Tricentis found that, in 2017, consumer tech companies were most vulnerable, with software challenges spanning everything from cost overruns, failures and recurring bugs.

So why aren’t estimations more aligned with the project’s development and parameters?

If failures are occurring consistently, costing companies more than just money — crossing the boundaries into brand equity and power territory — then why can’t we aim to use better estimation methods on projects?

The Cone of Shame

Dog-owners will know how much their furry friends resent the cone of shame.

Software development and estimations are not too fond of the cone either. In our case, it’s the Cone of Uncertainty that hangs, like a dark specter, looming above the commencement of every single project.

Where there should be enthusiasm and anticipation, there is dread. Even though we’re eager to roll up our sleeves and learn from our “past mistakes,” there’s still an edge of uncertainty when we recast our estimations for projects.

In almost 30 years of software development project studies, expert research has concluded that initial estimates on a project can vary as much as four times more or less because neither the estimating team nor the client can yet fully define the scope of the project right at the outset.

In the “waterfall” method (which is the classic approach to development), the Cone of Uncertainty tracks the variance in these estimate-versus-reality scenarios.

As time progresses, a greater amount of the project reveals itself and the scope narrows — which then trickles down to a tighter estimate and a reduction in uncertainty.

Source: Envoc Glossary

But — you knew there was a “but” coming, right? — can we reduce uncertainty to a greater extent and even earlier in the process? Notice that a “reduction” doesn’t have to be an elimination in order to make the project successful.

There are three specific aspects of software development that the brooding Cone of Uncertainty affects:

Consistently “good” products — Maintaining a product or project’s quality requires a particular standard to be set and achieved in a short period of time. Software projects usually have changing features, according to customer needs, and this calls on either a greater level of agility (towards deployment) or more certainty, earlier on in the project’s development.

The requirements of “custom” built software The Cone of Uncertainty undercuts the amount of foresight and planning that custom software development requires. The latter is more about engineering, where even the foundational building blocks must be custom-built. Integrating these building blocks then initiates multiple possibilities and logical paths to be covered so teams will need to constantly refine these concepts.

The ongoing nature of development  —As the Cone of Uncertainty progresses over time, the variance in estimation versus reality reduces. But using the waterfall method also significantly bloats the time that teams spend in the phases of “What are we building?”, “How does it work?” and “What will it look like?”

So we know what those failures look like — but what about success?

In its survey of IT executive managers, the Standish Group’s “Chaos Report” found that, besides user involvement and executive management support, a “clear statement of requirements” (i.e. scope maturity), tied into proper planning can yield overall consistently successful project results.

Source: Chaos Report 2017

The Cone of Uncertainty, however, seems to make even these success criteria seem less than certain.

How can we hope to have more accurate estimations in an ever-changing environment?

Because the consequence is not only a possible failure or a particularly tricky bug that could, as in the case of Provident Financial, a U.K.-based sub-prime loan company, result in a £1.7 billion loss, the largest one-day share price plummet and a CEO resigning over the fiasco.

Factors Affecting Estimations
Now that we know what failure looks like (and, worse yet, feels like), let’s take a look at the factors that affect the estimations on a project.

Massaging the scope into proper maturity

Scope maturity is tied into estimations on software projects. During the planning phase, the development team will need to finalize requirements and think through the requirements from a few different angles.

But the Cone of Uncertainty almost guarantees that designing and anticipating everything up front is almost an impossibility — especially with proper depth.

So what is the solution?

Favoring the incremental approach helps smooth out the development process, making it much more responsive, shortening the initial phases of variance within the Cone of Uncertainty. That’s because the “responsibility” of accurate estimations is spread over the whole development.

In our own experience with developing a web app that models a Digital Transformation Company’s internal processes, we had two parallel goals: to lay down the foundations of a long-term project and to deliver features within hard deadlines.

The custom solution needed to be the only app/tool the business used for internal researching, analyzing and planning. So we allowed the scope to evolve to maturity along the way, using our automated deploy-and-build process.

This bias for agile development is also what enabled our QA team to provide the best quality code for the client.

Concept elaboration
Estimation accuracy relies on more than just scope maturity — it also calls on the elaboration of the concept.

With custom-designed software projects, there is an opportunity, as with digital transformation projects, to use the principles of continuous and iterative building and deploying in order to mature the project in a way that costs less time and cost up front.

But this also calls on developers to have a firm grasp on the concept or specification up front.

This is one factor in estimations that provides more control than others. Teams will no doubt have to perform sprints and rely on breakout sessions to really get to the heart of the concept.

The details uncovered therein for the requirements on a project — such as problem, solutions, features, technical requirements, marketing requirements, etc. — can help anticipate a more aligned budget.

The point is to get as detailed as possible because details uncovered after tells the development team that an estimation was based on basis of flawed assumptions.

Change requests

You may have noticed by now that time is the wily variable that can bog down or uplift a project. Certainly, development teams are always racing against time to capture the right scope and concept.

It’s a reality our team has come across in our over eight years of development and one that especially pitted us against time during a project for Mitt Telenor’s official iOS and Android app.

If the product is set to launch at a specific date, we need to keep CRs at bay and be transparent with the client about how their ever-changing concept puts their project at risk of running well beyond the estimated project numbers.

CRs may well be warranted — but if they’re not anticipated, as agile SCRUM methodology allowed us to do with Mitt Telenor, the project can quickly become “challenged.”.

Source: Chaos Report 2017

Change requests and re-writing code are tasks that fare best in shorter, more responsive sprints.

In the case of Mitt Telenor, these short sprints are exactly what allowed us to uncover issues at an earlier (and more critical) point in development. This then allowed us to keep the development lights on, so to speak, continuing in a more self-aware (or, rather “software-aware”) manner.

The Place of Estimations in the Agile Methodology
To handle these changes and deliver a successful project, both parties (Client & Developer team) are better off with an agile methodology.

Agile allows us to be incremental, responding to a change in business as well as project needs in a more natural way. It’s also easier and more realistic to estimate and then implement changes in small increments, at closer intervals.

Software development is all about change, by its very nature. It is not now, nor has it ever been, a static undertaking. This is why development cannot employ a templated approach, especially in the landscape of digital transformation.

Source: Envoc Glossary

Notice how the Cone of Uncertainty here is significantly leaned out, from its original bloated physique. The result of a consistent diet and exercise? Not in this case. This is the benefit agile methodology brings to the table.

You’ll notice that we’re not claiming that we can simply eliminate or mitigate the Cone of

Uncertainty — no. To do that, we might as well not embark on a development journey at all.

What agile does allow us to do, however, is to drastically reduce the time spent at the initial stages, those questions of:

  • “What are we building?”,
  • “How does it work?” and,
  • “What will it look like?”

And the rest of our time? Well, instead of hemming and hawing, thinking and scratching our heads, only to come up with shaky estimations that are flawed at best and wrong at worst, we can spend our time in our zone of genius: Development.

Indeed, the “development” zone is where our initial estimates are proven or adjusted, requiring less upfront and overall time, and with greater accuracy.

A more aligned estimate and a smoother planning process.

That’s the advantage of agile

Download your free guide for development process in UX driven projects

Share this post

Share on facebook
Share on google
Share on twitter
Share on linkedin
Share on pinterest
Share on print
Share on email