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 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.
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.