Let’s address this right away: The idea that a traditional project management background and the scrum master role or agile team leadership are incompatible or mutually exclusive is total bullshit. If you need any convincing of this, please know that one of the best agile coaches, trainers, and writers in the business, Lyssa Adkins, transitioned from traditional project management to renowned agile practitioner. With all due modesty, I’ve made the transition myself quite successfully. If you as a reader or practitioner are interested in these debates, jump online and enjoy. I’ll focus on the role of the scrum master or agile project manager and the practical ways in which this servant-leader role functions to help agile teams self-organize and deliver value while constantly learning and improving.
In practice, many organizations have sought to convert their project managers into scrum masters or agile project managers. In hybrid approaches, this is an effective approach because these practitioners can apply elements from both waterfall and Agile frameworks as appropriate to the project and the organization.
The success or failure of these efforts varies greatly depending on the organization, their culture, and their willingness to recognize the inherent challenges of adopting agile as an approach for getting work and projects done. The single most critical factor is the individual. Some people cannot make the transition from plan-driven project manager to the type of servant-leader that agile requires.
The key determiner is the personal and professional maturity and experience of the individual. If a person can carry around in their head different approaches to doing work while executing the work using these approaches, not only can they be effective scrum masters or agile project managers, they can also continue to effectively manage plan-driven projects. We’re talking about work, not religion. As long as people can perform their roles effectively and embrace and practice the tenets of agile, former plan-driven project managers can be very effective as scrum masters and agile practitioners.
The practical reality is that many organizations have invested in project management as a business function. As these organizations make the transition to using more agile practices and recognize the advantages of organizational agility throughout the entire enterprise, leveraging this existing cohort, their skill set, and their existing knowledge of the organization just makes sense.
The mistake that some organizations make is thinking that one round of scrum master training or agile training and then certifying everyone will make for a successful implementation or transition to agile. Some of these organizations probably made the same mistake when they sent their project managers to PMP bootcamps with the expectation that the PMP training and certification would automatically make for effective project managers and successful projects. It doesn’t work that way, regardless of the project management approach.
Having said that – scrum master or agile leadership training is necessary and valuable. This role is critically important, and training for this role will ensure that the aspiring agile servant-leader adds this to their foundation of learning.
The Scrum Master
In the Scrum framework, the scrum master enforces the values of Scrum and helps the team with the framework and process. The word “enforce” should be interpreted carefully. This is not a command-and-control role. The scrum master is there to remind, to coach, to help the team, to help them be organized, and to help the team get the most out of Scrum. The scrum master protects the team and acts as a process enabler. The scrum master, in short, does whatever he/she can to help the team accomplish their work and meet their commitments to the project and to each other and is always alert to opportunities to teach, learn, and help the team improve their practices and use of Scrum as a way of working.
The Agile Project Manager
The agile project manager role functions very much like a scrum master, but in practice is influenced heavily by how the organization is using agile frameworks and practices. If the organization is using an agile hybrid or an approach other than Scrum, the role will manifest in different ways. Anything that the agile project manager can do to help the team self-organize, stay focused, and do what they’re best at is how the agile project manager provides value to the team and the organization. The agile PM will remove any impediments or obstacles that they are capable of moving and escalate any impediments that are outside of the team’s control.
In many cases, the agile project manager retains traditional project management functions, such as tracking and reporting of project team progress into other business functions such as a PMO or other middle management layer. By performing these functions, they protect the team and prevent these from becoming a distraction to the team.
The agile project manager facilitates the various processes that are being used in whichever agile approach is used. For example, in Scrum, that agile project manager may be serving in the role of scrum master and therefore is facilitating Scrum process. They interface with the product owner or the project sponsor and in that role not only convey information and help the product owner or sponsor do their jobs, but they also shield and protect the team from the occasional distractions that a product owner or project sponsor or a stakeholder sometimes poses to the project team. The agile project manager also helps to shield and protect the team from outside interference from people who may have personal interests in the project, who may be coming from a management perspective without direct knowledge of how the team is functioning.
Servant-Leadership
Agile depends on a scrum master or agile project manager who understands and embodies the concept of servant-leadership. Servant-leadership is a deep topic, and I won’t dive into it here. Start with the work of Robert Greenleaf if you are interested in deeper understanding of servant-leadership (Greenleaf.org). For practical agile, it’s enough, but critical, to understand what servant-leadership looks like for the scrum master or agile project manager.
A servant-leader sees leadership as an opportunity to help others maximize their performance, enjoy their work, and achieve goals vs. seeing themselves as a manager or boss of other people who just wants to get the work done. As a servant-leader, a scrum master or agile project manager is not a task manager and doesn’t ask teams to work harder or faster. Instead they focus on the team and seek ways to improve team performance, remove impediments, and provide resources that are needed to be successful. People who truly embody servant-leadership earn respect as leaders through their actions. Let’s look at specific practical examples.
Practical Examples
How to help teams self-organize during sprints.
How to facilitate agile processes effectively.
How to work with product owners to maximize their role and contributions to the team.
How to use artifacts and metrics to benefit the team and communicate to customers.
How to practice servant-leadership.
Helping Teams Self-Organize
Teams self-organize through the entire agile project life cycle. During initial project planning (whether done in sprint zero or waterfall initiating and planning phases), teams decide things like sprint length, place, and time of the daily stand-up, location, estimating processes, and other working norms. A scrum master or agile project manager can help the team with this self-organization and getting ready for their initial sprints.
The scrum master/agile project manager helps the team with these planning activities by referencing and recommending agile best practices and leveraging and sharing their own training and experience. They facilitate planning discussions and allow the team to take the lead while at the same time stepping in when necessary to steer the team toward best practices.
The scrum master/agile project manager could offer suggestions to the team on time and location for daily stand-ups, help the team reach consensus on this, and ensure a meeting space is reserved. Offering recommendations for the team be co-located in a single space and for the team to use a real-time collaboration software tool that is integrated into their office productivity suite in order to share comments, code snippets, and artifacts in real time are other examples.
A new team could be discussing sprint length and their estimating scale. The scrum master/agile project manager could remind the team that sprints should be four weeks maximum and recommend two weeks. If a team member advocates for a story estimating scale of 1 to 100, recommend using a modified Fibonacci scale, because training and experience points away from a 1 to 100 scale.
Scrum masters/agile project managers help teams make realistic commitments and facilitates this by organizing a meeting with the team and the product owner (PO) to review the product backlog, discuss priorities, and consider an initial set of user stories for the first sprint backlog.
Let’s say the team wants to commit to 30 story points of work for their first two-week sprint. Because this is the team’s first sprint, it could be helpful to recommend that the team reduce their commitment for the first sprint to 21 story points and remind the team that their initial velocity is a guess, and after a few sprints, their velocity will normalize. In future sprint planning sessions, the scrum master/agile project manager should ensure the team uses their velocity to make commitments. If the team shows signs of undercommitting, the scrum master/agile project manager should remind the team of rapid value delivery and ensure that commitments match their capability.
The scrum master/agile project manager plays an important role in the sprint review and retrospective by ensuring that the team gets feedback and recognition for their work and identifies opportunities to improve. The scrum master/agile project manager can organize a sprint review, which includes a demo of the team’s work followed by the retrospective.
Some scrum masters/agile PMs use a survey tool to get anonymous feedback on the sprint they are completing and transfer that feedback to sticky notes. The scrum master/agile PM must be sure to note the team’s velocity and committed versus completed user stories from the sprint to include in the retrospective. During the retrospective, the main objective is to help the team identify one or two things they could do in the next sprint that the team agrees will improve some aspect of their performance (once again – the plan-do-check-act cycle).
Facilitating Agile Processes
Scrum masters/agile PMs must be skilled at agile process facilitation, which can help to remove impediments like lack of access to the product owner (PO) or lack of a regularly groomed backlog that can slow teams if not addressed quickly. Without effective process facilitation, these impediments can impact an entire sprint and decrease the value the team can deliver. The scrum master/agile PM helps the team with sprint planning, ensuring that work is done and validated, helps the team run effective daily stand-up meetings, and helps the team handle the impediments that routinely surface during sprints.
Agile projects rely on consistent performance of certain activities to ensure that the team is able to focus on work that creates ongoing value for their organization. These activities include backlog grooming, user story evaluation and sizing, sprint planning, and sprint reviews. The scrum master/agile PM serves the teams by facilitating these processes.
For example, it is important to schedule regular backlog grooming meetings with the PO and the team to ensure a steady flow of ready stories for each sprint. It may be necessary to remind the PO and the team to balance customer value stories with mandatory dependencies and technical risks to ensure a coherent flow of completed work. It is also important to set up a regular occurrence of future sprint planning meetings at the start of every new sprint. Failure to do this can negatively impact ongoing sprint planning and slow the overall progress of the team.
The scrum master/agile PM facilitates processes like estimating, using planning poker or other facilitation process to help the team size user stories with their agreed-upon story point scale and facilitating discussions to reach consensus on sizing by ensuring that team members whose estimates differ from the team’s initial consensus explain their thinking. The scrum master/agile PM also helps guide discussions to break stories down into component tasks as they start the sprint.
Finally, an effective scrum master/agile PM ensures that sprint reviews inclusive of a demo and retrospective are scheduled in advance to ensure availability of the PO, key stakeholders, and customers who should see each demo.
Rigorous Definition of Done and Avoiding Technical Debt
The definition of done is critical to the success of agile teams and projects. When teaching, I state that there is no such thing as “done except for….” I like to share the story of the first real scrum team and project I worked on. I was scrum master with four experienced developers, and we were really working closely to the Scrum framework and values. At the end of one sprint, in the morning stand-up prior to the afternoon demo, the team shared their updates inclusive of what they were calling “done” for the sprint and the demo.
One of the developers (Dave) shared his update and done items and described one as “… done except for…” and the rest of us nearly tackled him. We took this nearly completed story out of the demo because it was not really done. User stories must be totally clear on their definition of done, and it may fall to the scrum master/agile PM to enforce this rigorous definition of done.
This is how scrum masters/agile PMs help their teams avoid the accumulation of technical debt such as unfinished documentation or incomplete regression tests. By ensuring teams maintain the discipline of done and avoid technical debt, agile teams are always in the position to wrap up a release early. This means that if the PO is satisfied with the value delivered and is ready to deploy or release the latest version of the product earlier than the original release plan called for, the organization can maximize the value of the team earlier than expected.
Another important component facilitating the validation process: First, this is everyone’s job – the whole team. Effective agile teams ensure everyone is accountable for the quality of the team’s work and to help the team meet their commitments by sharing the responsibility of validation and testing. Note that the validation process must run continuously through the sprint. A common mistake is to allow work to accumulate to the end of the sprint and get backed up or, worse, be rushed through validation to complete the sprint goal.
The scrum master/agile PM should consider how to engage testers and reviewers early in the sprint as well as help the team break features and user stories down into smaller pieces that can be validated incrementally. Another way a scrum master/agile PM can help is to arrange for customers and stakeholders to agree to test or review work in progress during sprints and after normal hours to maximize the amount of work their teams can complete during their sprints.
Technical Debt
Mounting technical debt
Technical Debt and the Case for Demos
This is a good time to go deeper into technical debt, and how holding agile teams accountable to the discipline of doing demos after every iteration helps to avoid accumulation of technical debt and helps teams maintain their velocity.
Agile project teams that skip demos put their outcomes at risk – for each sprint as well as the overall release. The reason often given for not doing a demo at the end of a sprint is that whatever the team is delivering as “done” that sprint is not interesting enough to demo. After a couple of sprints where this thinking goes unchallenged, the team will not only accumulate technical debt, but their velocity will slow and progress on the overall backlog will slow.
Teams that demo every sprint tend toward better performance. Teams that skip demos tend to underperform. The reasons behind this deserve further examination to help build the case for doing demos every sprint.
The most obvious issue is that without the need to present a demo of what the team completed, it is easy to say, “we can finish that in the next sprint.” Small things like documentation, bigger things like tasks, and processes like full regression testing can easily slip without the healthy pressure to be accountable for being “done” and able to demo at the end of a sprint. From this mindset, it’s a slippery slope to accumulating technical debt and other partially finished backlog work that could require the team to add sprints to finish needed features, or to deliver less valuable scope in a schedule-driven project.
Teams That Demo Ship
- 1.
Commitment and accountability – Agile project teams operate on shared commitment and accountability to themselves and to the organization to deliver on these commitments, every sprint and every release. Committing to complete a sprint backlog and then being accountable to demo what is done forces a team to be accountable to that commitment.
- 2.
Transparency – One of the great things about agile is that showing what is fully done every sprint is a true and transparent way of measuring the overall project progress and leaving no doubt as to what is really complete.
- 3.
Healthy pressure – Some pressure is healthy for teams. Knowing that they must demo their work at the end of each sprint adds enough of this pressure to help teams push themselves to get to “done.”
- 4.
Pride in work – Doing a demo every sprint encourages the team to be proud of their work every sprint no matter what they are delivering – even if they think the deliverable is uninteresting.
- 5.
Motivation – Points 3 and 4 help with overall motivation. Project team motivation is an aspect of projects that is not always easy. Leveraging a degree of healthy pressure to deliver the demo as well as the team’s pride in their work can go a long way.
- 6.
Agile discipline – We demo because we are using an agile framework, and demos every sprint are part of the discipline of most agile methodologies. Rigor and discipline in execution is crucial to project success as well as improvement in use of agile methodologies.
Think the sprint deliverables aren’t interesting enough to demo? Make them interesting! Find the value in each one and focus some element of demo or presentation around it. While at CloudCraze, I had an architect (Les) who worked for an entire release cycle on a set of application programming interfaces (APIs). These valuable, incremental software product enhancements did not lend themselves to demos, but that did not stop Les. For each sprint, he would pick a theme for his slides (Game of Thrones, Star Wars, Family Guy, etc.) and create a humorous and effective presentation on that sprint’s API advancements with the theme. It communicated well to the demo audience and added humor to an otherwise dry topic.
Another story harkens back to my first true Scrum team (the same one with Dave, the “done except for” guy). Part of the team’s first demo consisted of a blank web page with two fields and a control button. A numeric value was placed in one field, the button clicked, and the same value came back in the other field. Not too exciting – until the technical accomplishment of building first-of-its-kind middleware to communicate with a particular ERP system was explained. The product owner and sponsors immediately understood the value, making it a worthwhile demo.
In summary, demos are an integral part of agile projects. They are necessary to show the value completed each sprint and ensure the project maintains momentum. Remember: Teams that don’t demo will slip – teams that do demos will ship.
Facilitating the Daily Stand-Up
I have been in organizations where the scrum master/agile PM’s main role was to set up and “run” the daily stand-up. In fact, that was one of my main roles on my very first agile team doing Feature-Driven Development. I learned some good habits as well as developed and broke some bad habits during that experience.
My good habits included ensuring that less-vocal team members had the opportunity to provide input and advice and share their thoughts on team issues and technical problems. Another was taking quick notes so that on Friday the team could remember what we discussed on Monday. My main bad habit was not confirming with the team’s functional manager her role and level of accountability – she insisted on being present but deferred any accountability for the team’s performance.
Since the daily stand-up is the most critical meeting in agile (and in some instances, constitutes an organization’s entire implementation of “agile”), it is critical to ensure this is an effective and meaningful meeting. First – know that this is not a “status meeting.” The team is not reporting to the scrum master/agile PM or anyone else present in the meeting that is not part of the core team. As Lyssa Adkins puts it, this is a commitment meeting (Adkins, 2011). The team is discussing how their work is going using the framework of “what I did, what I am doing, and my impediments, if any” to be accountable to the team and each other to complete their commitments in every sprint.
Scrum masters/agile PMs facilitate effective daily scrums by ensuring the team always has their stand-up space available and scheduled and reminding the occasional straggler to be on time and not let their team wait for them. My colleague (Dave, the “done except for” guy) tended to elaborate on how he did his work each day, and so I had to politely remind him to keep his update to the team focused on what work he did vs. how he did the work.
Our functional manager learned early in the project that the team met daily at the same place and time, and so she began to show up daily to listen in and occasionally interrupt the stand-up with questions. I found this to be pretty common behavior on agile teams on which I served as a scrum master or agile PM, so I learned to politely ask them to hold questions until after the stand-up and then coached them on how the stand-up was for the team to discuss its work and process and not a status meeting.
Identifying and Removing Impediments
Effective agile teams and projects are ones that can keep moving, and that means quickly identifying impediments. A key role of the scrum master/agile PM is to help and coach the team to identify impediments, to be open about potential impediments, and to raise them immediately.
Some common scrum team impediments include a need for a decision or input on a story to complete it, access to tools or resources outside of the team’s control, assistance from other areas on work such as testing, and even simple things like supplies and snacks so a team can keep working.
An example I encountered while doing agile coaching and training in an organization was of a junior developer who did not share that they were stuck on a user story for fear of being judged by the rest of the team. This developer who had been added to the team partly to gain experience in working with more experienced developers was a bit in awe of some of them.
Part of the coaching and training I did was to remind the organization’s teams that they share accountability for their commitments and must help each other succeed. That includes sharing impediments and helping each other resolve them as well as teaching and helping each other.
Agile teams are most effective when impediments that might keep them from accomplishing their daily goals and sprint goals are quickly identified and removed. The scrum master/agile PM must help remove them as quickly as possible. One common impediment is a need for a decision or input on a story to complete it. Therefore, the scrum master/agile PM must work closely with the product owner (PO) and when necessary track the PO down or get the information needed from other sources.
The scrum master/agile PM acts on behalf of the team to resolve other impediments. In one consulting engagement I worked on, the new agile teams wanted to use a software tool (Azure DevOps) that was administered by another area to track their sprints. The Azure DevOps admin was rather protective of the tool’s configuration, and that impeded the team’s ability to use it. In my role as an agile project manager, I convinced the admin to open the access needed for the teams and worked with him to ensure we could all use the tool effectively.
Scrum masters/agile PMs can add a lot of value to a team by doing little things like tracking down supplies (e.g., wireless mouse batteries from a street vendor in Lower Manhattan) and arranging for food when the team is staying late to complete work. Anything a scrum master/agile project manager can do to remove impediments helps the team focus on their work and reach their goals.
In summary, the scrum master/agile project manager is a servant-leader and agile process facilitator. They help the team self-organize and help keep things moving on behalf of and for the team. Scrum masters/agile PMs are responsible for facilitating ongoing agile processes like backlog grooming and sprint planning. They work with the team to define and enforce a rigorous definition of done and to ensure that validation and testing runs smoothly and consistently to deliver “done” every sprint. The scrum master/agile PM should ensure that the daily stand-up is an effective meeting and works to identify and remove impediments coming out of the stand-up and throughout the sprint cycle.
Working with Product Owners
The product owner (PO) role is a critical individual role in Scrum. A PO can make or break an agile team and project. To maximize the benefit of the PO role for their teams, scrum masters/agile PMs must collaborate closely with POs at all points in the agile life cycle. This can help avoid the impediments that can arise in the event of an ineffective PO and allow agile teams to deliver working product and value in every sprint.
Backlog grooming is the constant, iterative process of prioritizing, reviewing, and refining backlog items and transforming them into a steady stream of valuable work that the team can perform. In agile, a PO is accountable to ensure the priority of user stories and their value to the organization.
It is important at the start of a new project to discuss with the PO the backlog grooming process, its importance, and how to ensure that backlog grooming happens regularly through the sprint and release cycle. I’ve found it useful to meet twice a week to perform backlog grooming. Each meeting should include prioritization of stories, discussion of new and existing stories, refinement of stories tagged for upcoming sprints, and ensuring that those stories planned for the next sprint are fully defined and understood.
Release Planning, Sprint Planning, and Prioritization
Scrum masters/agile PMs and POs work together to ensure that the backlog items are groomed and organized into coherent releases and sprints. The objective of a team and the sprint is to produce a complete and working increment of product, every sprint. To do this, the scrum master/agile PM and PO must plan and coordinate the work and consider how all the pieces fit together.
Release planning is an important element of this process. The scrum master/agile PM and, when necessary, key members of the team educate the PO on mandatory dependencies and technical risk items that should be combined with the high customer value items that a PO prioritizes. This ensures that the evolving release plan delivers customer value in each sprint. This also ensures the team delivers work that builds an ongoing foundation for the project as well as solving risks and uncertainties that could impede the project.
The scrum master/agile PM and the PO must consider the goal for each sprint within the larger context of the release and then work with the team to plan sprints that deliver the goal of incremental product value, completely done, in every sprint. They ensure that each sprint, while delivering value on its own, acts as a building block to the overall objective of the release of a new version of the organization’s product.
Of the roles a scrum master can assume in an organization, one is coaching to ensure that all other roles are supporting the team and using scrum effectively. Since the PO role is so critical to the team’s success and value realization, the scrum master coaches the PO as a key part of the job. The most common PO issue is lack of engagement or availability which renders the team and the sprint less effective. Scrum masters/agile PMs should discuss this with POs early, and, when necessary, often. It can be valuable to remind the PO of their importance to the team and to value realization for the organization.
Protecting Teams
Scrum masters/agile PMs are accountable for protecting their teams from distractions and interference during sprints and often must partner with their PO to do this. This is important to ensure that the teams stay focused during sprints and meet their commitments. Sometimes this means intercepting possible interruptions and having direct conversations with people who might distract the team.
Here’s a practical example I have personally encountered: A sales executive interrupts the work of a developer during an in-flight sprint to discuss a customer-specific feature and requests the developer do the extra work to help close a deal or please a customer. At this point, the scrum master/agile PM should intercede and reinforce that the team is in midsprint and that any changes to the sprint or release plan must be discussed with the PO.
Using Agile Metrics, Artifacts, and Reporting
Agile frameworks typically use velocity as a metric and tools like burndown charts and scrum boards to enable teams to self-manage and plan. The scrum master/agile PM helps make these artifacts and metrics valuable to agile teams and the organization and ensures that metrics and tools are visible to the team and owned by the team.
Organizations using agile need accurate reporting for overall project governance. A scrum master/agile PM who can synthesize this information while enabling the team to stay focused on their work is valuable to the team and organization. The scrum master/agile PM coaches and leads by guiding the team to maintain their metrics and artifacts for themselves. The scrum master/agile PM should use this same information as needed to maintain and provide reports required by the organization and its management processes.
The key metric in Scrum and other agile frameworks is team velocity. It is an important metric for determining the team’s capability to commit to and complete work in upcoming sprints. It also helps in predicting and updating the overall time required to complete the project, or the amount of work that can be completed in a fixed timeframe.
The scrum master/agile PM helps the team track its velocity in each sprint and release. As a team works together for eight or more sprints, the velocity outliers – that is, sprints where the team had a very low or very high output as compared to their average – can be treated as anomalies when calculating velocity and planning future capacity.
It is also valuable to track the hours of effort that the teams invest in sprints. In practice, agile teams are sometimes pulled into nonsprint work. By tracking the hours that go into a sprint, you can compare these with velocity to evaluate the impact of nonsprint hours on teams’ velocity. This data is valuable in discussions on having teams be dedicated to a single project.
Example screenshot of visual release metrics in Jira
In practice, it is not unheard of to devote an entire stand-up meeting or to call a separate meeting to work with the team to update the scrum board. This is not a desirable outcome and should be reinforced as an opportunity to remind the team of the shared accountability for these artifacts. In these situations, it can be useful to remind the team that people outside of the team such as functional managers and POs rely on these artifacts to understand the progress of the project. I’ve found that these people are less likely to join and interrupt a daily stand-up to ask about progress when the burndown chart and scrum board are kept up to date.
Regardless of the project management methods, organizations need to know how their projects are performing within portfolios and programs. One of the roles of the agile project manager is to know the reporting and governance requirements of their organization and ensure that the artifacts and metrics the team uses can also feed the reporting and governance processes required by the organization.
Example biweekly release health update
Practicing Servant-Leadership
Agile leaders must know the meaning of servant-leadership and embody these values every day. Effective scrum masters/agile PMs are servant-leaders who can guide their teams to focus on meeting their commitments in every sprint. Effective servant-leaders are invaluable to their teams, their organizations, and help ensure rapid value creation through the use of Agile.
Servant-leaders create an environment where the teams feel accountable for and valued for the work they do. A scrum master/agile PM should be available to help the team accomplish the objective, lead them, and guide them in the use of agile.
A practical example: Let’s say a team is a bit behind on their committed sprint backlog items and will have to take action to meet their commitment. In a stand-up meeting, the scrum master/agile PM asks the team if they have ideas on how they could get back on track. The team suggests working late for a couple of days. The scrum master/agile PM encourages the team for reaching this decision, asks them what kind of food they want to have on those days, and also volunteers to line up people to do after-hours testing on the items the team will be working to complete.
Another practical example: Before the sprint review, a scrum master/agile PM should have made all arrangements such as booking the room, inviting the attendees, finalizing the presentation deck, setting up the conferencing system, and any other necessary arrangements. Then, the scrum master/agile PM should start the sprint review by thanking the team for their efforts (and any extra efforts as per the previous example) to complete their committed backlog items.
Servant-leaders help the teams they work with maximize their value delivery to their organizations. Simple things like taking care of the team’s needs and handling the administrative work such as meeting scheduling and planning and creating reports and presentations allow the teams to focus on their work. More involved leadership work like coordinating with the PO and working with organizational project governance ensures that the teams have the information they need to make progress.
Over time, an effective servant-leader will help their teams make measurable and sustained improvements to their velocity and become models for good agile practices for other teams in the organization. While this type of servant-leader always ensures that the credit goes to the teams, the teams and other leaders in the organization will know and appreciate these skills as an effective agile servant-leader.
Summary
This chapter has focused on the role of the scrum master and agile project manager and their focus on servant-leadership in service of the team. Practical examples helped to illustrate how this role performs critical functions to help agile teams self-organize and maintain their commitments and efficiency in various agile project scenarios.
Chapter 8 will focus on the critical role of the product owner in agile and hybrid agile scenarios. The product owner (PO) is a role that can make or break an agile project and team, and understanding this role’s importance and responsibilities is a key to success with agile hybrids and any kind of agile project.