The Scrum framework can open doors to endless possibilities for problem-solving. It can help Scrum Masters, Product Owners, and the Development Team make decisions quickly, incorporate customer feedback efficiently, and keep everyone on the same page. As a Scrum Master, when it comes to knocking on the right door for the best Scrum tools, the decision isn’t easy. It can be as scary as choosing a new house.
A Scrum tool is an agile solution that helps businesses implement the Scrum methodology while managing projects. Scrum project management software offers capabilities such as sprint planning dashboards, reporting tools, and project analytics to track the progress of projects. It also provides reporting dashboards and shared workspaces that facilitate team collaboration and help the team visualize the amount of work required for each iteration.
Most of us have probably heard of JIRA because it is one of the most widely used Agile tools for Scrum teams. Atlassian products were built to help teams of all sizes and types manage their work, and it provides nearly every Agile capability imaginable. Though many teams worldwide love Jira, it isn’t without its flaws. The biggest pitfall to Jira is due to its steep learning curve, slowness, and clutter. It can be hard to get started with Jira if it hasn’t been used previously.
Nevertheless, Jira comes with a whole pack of features: Customizable Scrum boards, Backlog management, User stories mapping, Bug and issues tracker, Time tracking, Sprints management, Real-time reporting, Integrated roadmaps, Customizable workflows, Third-Party Application Integrations.
This tool is a flexible management software that any Scrum Team needs in a dynamic environment. Monday.com makes cross-functional work easy, and it includes features covering all project phases, from pre-planning and development to user feedback.
This tool is recommended for first-timers having a shallow learning curve. Scrum Masters can check their team’s work in views, such as a Kanban board.
Monday provides real-time reports that show the team’s progress, continuous improvement, and product backlog. It can also be used for tracking bugs and reporting them quickly in a single place.
MeisterTask is a great tool for Scrum Masters working with companies that are just starting with the Scrum methodology. However, it can scale quickly, thanks to its built-in automation and many integrations with other tools.
Some basic features of MeisterTask include Backlog Management and Sprints Management. It has a tagging feature for prioritizing tasks and visualizing dependencies. Real-time notifications keep the Team and stakeholders up to date about project progress, and detailed statistics and reports provide insight into the Team’s performance. A personalized dashboard ensures you see at a glance what you need to focus on today and keep track of all tasks.
Miro is the definitive Agile tool for teams that help put our ideas into real action with boards like Kanban, Jira, Asana, etc. It’s a cloud-based collaboration tool that features a digital whiteboard that can be used for research, ideation, building customer journeys and user story maps, wireframing, and a range of other collaborative activities. The solution’s whiteboard toolkit enables Scrum Teams to create mockups and schemes, write down ideas and leave feedback on other members’ input. Boards can be created using preloaded templates and converted into a presentation or saved as a PDF.
Instead of working hard on documentation with Miro, Scrum Teams can engage remote users for Sprint Plannings and Retrospective online.
While its name might sound puzzling, a Lean coffee is simply an informal meeting designed to allow participants to set the agenda as they go. During Lean Coffees, everyone participates and gets a chance to contribute by suggesting topics and voting. It opens up a conversation around the most important issues and questions.
In Scrum, this is the easiest way to start a community of practice or a working group. It brings people from different teams together and starts discussions around topics that matter. As a Scrum Master, you can also use it in retrospectives and workshops to collect subjects for discussion. To find out more about Lean Coffee, you can check this article from scrum.org.
Impact Mapping is a graphic strategy planning technique to decide which features to build into a product. As it begins with the intended goal and extends out from there, all identified features directly impact achieving that goal and a clear rationale for how they will do so.
Impact mapping incorporates multiple viewpoints, experiences, and opinions. When the Scrum Master conducts multiple impact mapping exercises with different groups, it will help to deduce where there are overlaps and divergence of impacted deliverables based on the biases of the other cohorts.
This technique is excellent for building a solid foundation for a new product and clarifying the vision for an existing product in development. It can be used with a newly formed Scrum Team to define the product vision, the assumptions and constraints that we have to keep in mind. A great example of an Impact Mapping exercise can be found here.
Having a good understanding of the needs and interests of the people in our team or the users we design the product for, is essential if we want to have a healthy team dynamic and build a successful product. As the name suggests, empathy maps help product teams build empathy among themselves or with their end-users.
Empathy Map is a great tool to use as a facilitation technique in conflict resolution. If used correctly by the Scrum Master, this tool can help people in deep conflict to understand each other’s point of view.
When used in product teams for building empathy with their end-users, it gets team members thinking from a user-centered perspective and helps them understand the users needs and wants. If Empathy Map has captured your attention, check out this blog entry, including more details and examples.
Yes, just sticky notes, these small squares that we stick on a board or a wall have power. They are the best thinking tool, an awesome communication tool, they know how to manage meetings and set order in things and discussions. They are colorful and easy to carry around, easy to throw away and never depend on a process implementation to visualize anything.
Scrum Masters use them for almost anything – from simple tasks on the board to the team’s schedule, as a planning tool, hideouts, reminders or notes.
Of course, the above compilation barely scratches the surface of the current tools used by Scrum Masters around the world.
However, as the saying goes, “A fool with a tool is still a fool”. As a Scrum Master, it is crucial to choose the right tools for your team. First, you have to understand the need that has to be fulfilled or the problem you’d like to solve with a tool. Then, you need to do extensive research on key features and pricing details to make an informed decision. Hopefully, the above list will help you get a head start searching for the best tools.
The roles in Scrum are quite different from other traditional software methods. Given the flexibility and adaptive approach of Scrum, as team members, we get the opportunity to experience new responsibilities and broaden our skills. For example, one can start as a Developer and then migrate to a Scrum Master role, while another can transition from Scrum Master to Product Owner or vice versa. Our focus today will be around Developers and how they can become Scrum Masters.
The Scrum Master educates, coaches, and guides the Product Owner, Team, and the rest of the organization in the skillful use of Scrum. Because Agile processes are entirely dependent on people and collaboration, Scrum Masters must possess both soft skills as well as technical skills in terms of using the latest tools and collaboration methods. The Scrum Master is not the manager of the Team members, nor does she act as project manager, team lead, or team representative. Instead, the Scrum Master serves the Team, helps remove impediments, protects the Team from outside interference, and helps the Team adopt Agile development practices.
The Development Team builds the product that the Product Owner indicates: the application or website, for example. The Team in Scrum is “cross-functional” and includes all the expertise necessary to deliver the potentially shippable product each Sprint. The Team takes a few user stories from the top of the product backlog and turn them into features.The members of the Development Team could be any of: developers, testers, ux designers, business analysts, dev-ops specialists, architects.
Any Scrum experience is better than no Scrum experience. If you are already part of a Scrum Team as a Developer, that is great. If not, there is no need to focus solely on Scrum Master opportunities. A first step could be to join a Scrum Team in another role suited to your skills and experience. Gaining Scrum experience as a Development Team member is very valuable. Ideally, you’ll have an experienced Scrum Master on the Team that you can also shadow and learn from. Many great individuals started their careers as Developers before successfully transitioning into a Scrum Master role.
One does not need a degree to become a Scrum Master. However, every person interested in this career path needs a good knowledge of Agile and of the Scrum framework. Larger organizations might require a Scrum Master course or a certification in order to get started, while for smaller organizations, like start-ups or agencies this won’t be mandatory.
There are different levels of certifications, you can start from the basic ones and then level up as you gain more knowledge and experience. The most popular certifications out there are from Scrum Alliance (Certified ScrumMaster) and Scrum.org (Professional Scrum Master).
Depending on each one’s professional goals, from Scrum Alliance you can get one of the following certifications:
For each certification level, following a specific training course is required, along with other prerequisites and requirements. More information can be found on Scrum Alliance’s website.
The certification levels from Scrum.org are similar to those from Scrum Alliance and start from a fundamental level, then they move up to advanced and mastery levels:
Scrum.org certifications attending a course is not mandatory for taking the certification exam. For beginners, it is recommended to follow a training course for at least the first certification level.
Once you learned the basics about the role and responsibilities of a Scrum Master, it’s time to test and sharpen your skills. The best way to do it is to shadow a Scrum Master (or even better, to have a Scrum Master act as your mentor), ideally in your organization. You could do this by starting to join the Scrum ceremonies of another team, for example, the Daily Scrum, Sprint Planning, Sprint Review, Sprint Refinement, and also help the Scrum Master of that team on the day to day activities.
If you can’t find a Scrum Master to shadow in your organization, look for a Scrum Master buddy from the Scrum community. Then get involved by helping the Scrum Master solve their day-to-day issues. You can do this either by active listening or by serving as a brainstorming buddy.
There are many great communities out there supporting Scrum, some more formal and some informal. Don’t be afraid to join a community, even if you have little or no experience with Scrum. Being part of a Scrum community helps with networking, exchanging ideas, learning new things from the experience of others, and many more.
These communities are organized groups of people who have Scrum as a common interest, or more specifically, are focused on the Scrum Master role. They regularly collaborate to share information, improve their skills, and actively work on advancing the general knowledge of the domain. Healthy communities have a culture built on professional networking, personal relationships, shared knowledge, and common skills. Communities enable practitioners to exchange knowledge and skills with people worldwide.
We’ve left this for the end, but it’s paramount to become a successful Scrum Master. Scrum Master are facilitators, not direct contributors on building product backlog items, as Developers are. This is the most important change between being a Developer and being a Scrum Master.
As a Scrum Master, you need to be aware of the context you’re working in, it’s all about delivering products (not projects) and it’s not about completing a specific user story or task you had assigned. Transparency is your new best friend, as transparency is one of the pillars of Scrum. Perhaps as a Developer, you didn’t always consider sharing best practices with everyone or making transparent a specific issue. As a Scrum Master, your first thoughts in any situation should be: “What would be an effective way of making this issue transparent?” Transparency about problems, issues, challenges, questions, etc., creates opportunities for Inspection and Adaptation, which leads to the continuous improvement of any Scrum Team.
Another critical aspect is that the Scrum Master shows people that they should talk with each other instead of about each other. Some killer sins of Development Team members are talking about people at the coffee machine, in informal calls or chats, or talking with management about their complaints on some of their colleagues. Doing such things reduces the Scrum Team’s trust, courage, openness, and respect. Once you’ve gone through all the above, get out there and start your journey as Scrum Master. A good start could be a volunteering project and then you can apply for Scrum Master jobs. It can be either in your organization or outside. The important part is to land your first job in the Scrum Master role. Once you get to practice, your day-to-day activities will become easier, and you will also sharpen your skills. Later on, to level up, you can transition to other teams or other types of products, with varying complexities.
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.
If you are reading this, you already know that Scrum has three roles: Product Owner, ScrumMaster, and the Development team members. These three roles make or break Scrum, having a crucial role in delivering successful products.
These Scrum roles are often different from official job titles, meaning that the development team, for example, can be composed of testers, designers, programmers, and more.
When we think about traditional projects, the roles in Scrum could be confused with the functions of the project team.
Let’s start with the ScrumMaster role, as it often gets confused with the team’s Project Manager. Upon hearing about these two roles, one might think that they are similar because they interact a lot with the development team, have management responsibilities, know the processes very well, etc. On a more careful thought upon the ScrumMaster role, we see that they are a facilitator or mentor who empowers and motivates a team and has a certain level of technical proficiency. The Project Manager helps manage and monitor the resources, project schedule, and scope to meet business objectives to make the project successful.
Moving forward to the Product Owner role, this one can be confused with the Client’s Project Manager, as both the Client’s Project Manager and the Product Owner oversee teams who strive and work hard to bring projects across the finish line together. This means both of these roles need excellent communication and people skills. The bottom line is that they are responsible for successfully delivering the project’s outcome. The critical difference between the two revolves around their mindset when approaching a problem to be solved and a project to be delivered – the Product Owner will be more interested in delivering successful products. In contrast, the Project Manager will ensure the project’s success in terms of time and cost.
In Scrum, the Developers are the people in the team that are committed to creating any aspect of a usable increment each sprint. They plan the sprint, perform the sprint execution, inspect and adapt each day to meet the sprint goals, and continuously refine the product backlog. In Scrum, a developer can cover different job titles, which is when the confusion with the roles from traditional projects occurs. A Developer could be covering any (one or more) of the following roles: programmer, quality specialist, software tester, business analyst, UX designer, dev ops engineer, and so on. The vital aspect to remember here is that each team member must be committed to the project’s success no matter the job title.
Many organizations have embraced Agile teams and Agile ways of working, but very few describe themselves as truly Agile.
The most significant barrier to agility is the inability to embrace risk. This can be a particular issue in heavily-regulated industries, where conformity can reduce the risk appetite of leaders.
There is a big difference between “being” Agile and “doing” Agile. By adequately implementing Agile, teams can leverage increased transparency, communication, and flexibility, reducing the risks of building the wrong product and creating more substantial alignment among the organization and its customers.
Understanding the difference between these two concepts will help define what organizations can do to implement Agile.
The Waterfall model is the earliest Software Development Lifecycle approach that was used for software development, long before the Agile approach was embraced.
As the Waterfall Model illustrates the software development process in a linear sequential flow, it means that any phase in the development process begins only if the previous phase is complete. In this model, the phases do not overlap.
This way of working is quite different from the Agile one, as the main philosophy of Agile is centered around the idea of iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams. In Agile, the software development phases overlap, as each iteration progresses.
Given this, one might think why not always use Agile, given that value is delivered faster.
There are certain types of projects which could be more successful using the Waterfall model or, why not, by combining Waterfall with Agile, to give us what?s most suitable for a specific project.
Some situations where the use of the Waterfall model is most appropriate are:
The organization is more traditional and prefers a linear process
The requirements are very well documented, clear, and unlikely to change
The technology is understood and is not dynamic, for example on a project consisting of building a website, there are already multiple coding languages that can be used and the project team can choose the appropriate one from the beginning
The project has ample resources, with the required expertise available to support the product
Although we are starting to see mass adoption of various Agile methodologies in all enterprises, even more, traditional ones, like public institutions and federal agencies, there are still many organizations that are slow to make the change. It is also very common for an organization to transition into more of a hybrid approach that combines aspects of both Agile and Waterfall.?
Waterfall is not the fastest way to work. Deliverable results will only show at the end of the development cycle, so it could take months or even years before the customer sees the final product, as well as proving hard to keep the development team engaged, given that the release process is not incremental. As Agile shortens the delivery time and makes it easy to gather feedback in the early stages, one successful recipe would be to use Waterfall with a spice of Agile.?
Let?s think of an example of a technical project, consisting of developing software. In this example let?s use a website for a public institution.
Some of the main reasons for using a combination of Waterfall and Agile models are:
In a public institution, the adoption of the Agile culture might prove problematic, as this kind of organization is heavily relying on defining the scope upfront and on a thorough paper-based approval process. Thus, using the Waterfall model, with some elements from Agile will prove to be more efficient.
It shortens design, analysis, and planning, but lets the organization define project frames including budget and time of delivery, compliance with standards, and enhancement collaboration.
The blending of waterfall and agile should occur at the beginning of the project, as both the customer and the team will start with this mindset from the beginning, not jeopardizing engagement. For example, in the Waterfall model all requirements must be defined and approved, and in the Agile – Scrum way, a product backlog must be prepared. A key success factor to blend these in a technical project is to define the customer journey upfront. In this way, the entire team can participate in this phase and engage with the customer from the start. Let?s say we agree with the customer to deliver a batch of requirements every 3 weeks. In a Waterfall world, we would have said that the requirements and design phases will be completed after delivering all batches. And we could do all this by adding spice from Agile, as iterations (batches) were used to deliver the requirements, keeping an Agile mindset inside the team.
Another way of combining Waterfall with Agile could be to do the planning, design, and requirements definition with Waterfall, but development and test in short sprints using Agile (Scrum). In this approach, the development team gets to keep working Agile, using iterations, and does not have to wait for the entire project to end in order to see the result of their work. This approach proves to increase the team output, as well as keep the customer involved, by providing feedback at the end of each development & testing iteration.
Most importantly, let?s not forget that customers want to see their products yesterday. In today’s competitive world, time to market is a key factor for success. Basically, our customers want the speed of agile, combined with the predictability of a thorough and traditional project schedule from Waterfall, that eases their anxiety in launching new products and services to an increasingly demanding customer base.?
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.
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.