Great new video about Kanban by Michael Badali. This is the third video in a regular series:
Great new video about Kanban by Michael Badali. This is the third video in a regular series:
Often in my classes, I’m asked for a clear comparison between the various traditional roles and the new roles in Scrum. Here is a high level summary of some of the key responsibilities and activities that help highlight some important differences between these four roles:
|ScrumMaster||Product Owner||Project Manager||Team Lead|
|NO||Define Business Requirements||PARTICIPATES||NO|
|NO||YES (Deliveries)||Define Milestones||NO|
|YES (process and people)||YES (business)||Risk Management||PARTICIPATES|
|Organizational Change Agent||NO||NO||NO|
|NO||Accountable for Business Results||RARELY (just costs)||NO|
Of course, there are many other ways we could compare these four roles. What would you like me to add to this list? Add a comment with a question or a suggestion and I will update the table appropriately!
Organizations like to have clear role definitions, clear processes outlined and clear documentation templates. It’s just in the nature of bureaucracy to want to know every detail, to capture every dotted “i” and crossed “t”, and to use all that information to control, monitor, predict and protect. ScrumMasters should be anti-bureaucracy. Not anti-process, not anti-documentation, but constantly on the lookout for process and documentation creep.
To help aspiring ScrumMasters, particularly those who come from a formal Project Management background, I have here a short list of exactly which artifacts the ScrumMaster is responsible for.
– None – the ScrumMaster is a facilitator and change agent and is not directly responsible for any of the Scrum artifacts (e.g. Product Backlog) or traditional artifacts (e.g. Gantt Chart).
– Obstacles or impediments “backlog” – a list of all the problems, obstacles, impediments and challenges that the Scrum Team is facing. These obstacles can be identified by Team Members at any time, but particularly during the Daily Scrum or the Retrospective.
– Definition of “Done” gap report, every Sprint – a comparison of how “done” the Team’s work is during Sprint Review vs. the corporate standards required to actually ship an increment of the Team’s work (e.g. unit testing done every Sprint, but not system testing).
– Sharable retrospective outcomes report, every Sprint – an optional report from the Scrum Team to outside stakeholders including other Scrum Teams. Current best practice is that the retrospective is a private meeting for the members of the Scrum Team and that in order to create a safe environment, the Scrum Team only shares items from the retrospective if they are unanimously agreed. Outsiders are not welcome to the retrospective.
– Sprint burndown chart every Sprint – a chart that tracks the amount of work remaining at the end of every day of the Sprint, usually measured in number of tasks. This chart simply helps a team to see if their progress so far during a Sprint is reasonable for them to complete their work.
– State of Scrum report, every Sprint – possibly using a checklist or tool such as the “Scrum Team Assessment” (shameless plug alert!).
NOT RECOMMENDED (BUT SOMETIMES NEEDED):
– minutes of Scrum meetings
– process compliance audit reports
– project administrative documents (e.g. status reports, time sheets)
– project charter (often recommended for the Product Owner, however)
– project plans (this is done by the Product Owner and the Scrum Team with the Product Backlog)
– any sort of up-front technical or design documents
The ScrumMaster is not a project manager, not a technical lead, not a functional manager, and not even a team coach. There are aspects of all of those roles in the ScrumMaster role, but it is best to think of the role as completely new and focused on two things:
– improving how the team uses Scrum
– helping the team to remove obstacles and impediments to getting their work done.
One of the valuable and important responsibilities of the ScrumMaster is to remove obstacles that impede the team’s work. This is necessary so that the team can become more and more productive in their work which gives greater value to the company. If the ScrumMaster does not work diligently on removing these organizations obstacles, the team will get bogged down by challenges and become demotivated to progress, and their morale will drop and become apathetic to the work and to Scrum. The benefit of removing these large obstacles is that it speeds up the cycle time of the work by the team. This is essential so the Team Members can focus their energies on delivering working software.
To learn more about organizational obstacles, visit the Scrum Team Assessment.
One of the primary ways that the ScrumMaster serves the team is by removing impediments to the progress of the team. If the team does not have what it needs to progress in its work, whether it be technology, tools, the right space, etc., the ScrumMaster must have the authority to immediately fill those gaps for the team. The ScrumMaster should not need permission from management in order to get the team what it needs. There should be request procedure that the ScrumMaster needs to go through in order to get sign-off from acquisition departments and what not. At the same time, if there are interpersonal issues between team members, the ScrumMaster must be empowered to intervene and help individuals overcome their differences without the involvement or permission from their direct line managers. Any process or procedure that the ScrumMaster is forced to follow prolongs the impediment for the team as well as the consequential waste and unrealized delivery of value.
To learn more about in-team obstacles, visit the Scrum Team Assessment.
The principles of openness and transparency include being able to be truthful about ways that you are struggling. A Team Member must share their struggles with their Scrum Team and with the ScrumMaster so that the team, at least, knows your status. Without that visibility, the Scrum Team may make decisions that are difficult or impossible to implement due to hidden obstacles. At every Daily Scrum, each Team Member should think carefully about the challenges they are currently facing, and share those challenges. The ScrumMaster cannot do a good job without that transparency since a core part of their work is to deal with obstacles. If a Team Member fails to be open about obstacles, or fails to recognize something in their environment as an obstacle, this can slow the team in its progress towards becoming a high-performance team. Obstacles that persist for a long period of time simply because they are not openly discussed can have a demoralizing effect on the team. On the other hand, a team that creates full visibility into their obstacles can enlist the help of stakeholders, work together to overcome those obstacles, and systematically become better and better at doing their work.
Agile Work consists of seven core practices. These practices form a solid starting point for any person, team or community that wishes to follow the Middle Way to Excellence.
Any group of people that wish to be an Agile Team need to take the initiative to determine for themselves how they are going to work (process) and how they are going to do the work (product). The term “team” really applies quite broadly to any size group of people that are working together towards a common goal.
Teams go through stages of development as they perform their work. The most important result of team development is the team itself, and not the specific skills and abilities that the individuals learn.
If the team is part of a broader organization, that organization must give the team the authority, space and safety to learn to be self-organizing. The organization’s leadership is responsible for determining the “why?”, some constraints on “how?”, and then letting the team respond to the need as best as it can.
Also Known As: Whole Team (Extreme Programming), Cross-Functional Team (business management).
Agile Work uses short fixed periods of time to frame the process of delivering something of value. Each of these iterations or timeboxes is structured so that the team or group actually finishes a piece of work and delivers it to stakeholders. Then, the team builds on what has previously been delivered to do it again in the same short amount of time.
The sooner that valuable results can be delivered, the more value can be obtained from those results. This extra value is derived from opportunities such as earlier sales, competitive advantage, early feedback, and risk reduction.
There is an explicit tradeoff: the shorter the time to delivery, the smaller the piece of value will be. But, like investing in one’s retirement account, the earlier you start, even with small amounts of money, the better off you are in the long run.
Also Known As: Sprint (Scrum), Iteration (Extreme Programming), Timeboxing (generic), Time Value of Money (accounting).
Plan to Learn
Every type of work is governed by a Horizon of Predictability. Any plan that extends beyond this horizon of predictability is bound to fail. Agile work uses an explicit learning cycle tied in with the planning of work to accomodate this inevitable change.
First, a goal is required. This goal can be long-term. Teams using Agile Work then create a queue of work items to be done in order to reach this goal. Each iteration, some of these items are selected, finished and then the queue is adjusted. The changes in the work queue are based on external factors, and learning that the team does as it goes.
One of the most effective methods for the team to learn about how it is doing its work is the retrospective. After each delivery of results, the team holds a retrospective to examine how it can improve.
Also Known As: Inspect and Adapt (Scrum), Kaizen (Lean), Adaptive Planning (generic).
A team needs to have effective means of communicating, both amongst team members and also to stakeholders. To Communicate Powerfully, a team needs to prefer in-person communication over distributed communication. Synchronous over asynchronous communication. High-bandwidth over low-bandwidth communication. Multi-mode communication over single-mode communication.
The results of failing to communicate powerfully include wasted time for waiting, misunderstandings leading to defects or re-work, slower development of trust, slower team-building, and ultimately a failure to align perceptions of reality.
The single most effective means to communicate powerfully, is to put all the team in a room together where they can do their work, every day for the majority of the work time.
Some types of work do not lend themselves to this approach (e.g. creating a documentary video), but every effort should be made to improve communication.
Also Known As: Visibility (Scrum), Whole Team and Team Room (Extreme Programming), War Room (business management).
Defects are one of the most critical types of waste to eliminate from a work process. By testing everything, by driving all the work of a team by creating test cases to check the work, a team can reach extremely high quality levels. This ability to prevent defects is so important that only an executive level decision should be considered sufficient to allow defects into a work process. Quality is not negotiable.
In Agile Work, removing a defect is the only type of work that takes priority over any new features/functionality/production. If the end result desired is to maximize value, then removing defects is an important means to that end.
A team has an ethical duty to discover new ways to effectively test their work. This can be through the use of tools, various feedback mechanisms, automation, and good old problem-solving abilities.
Also Known As: Canary in the Coal Mine (Scrum), Test-Driven Development (Extreme Programming), Defects per Opportunities (Six-Sigma).
Since Reality is Perceived, it is important for an agile team and organization to have a clear method of describing and perceiving what is important for the organization. Measuring value is a critical method for describing and perceiving what is important.
A single metric can be used to drive all the measurement and goal-setting and rewards in an organization. All other measurements are secondary and must be treated as such: limited in use and temporary.
There are many things which are easier to measure than value. It is often easy to measure cost, or hours worked, or defects found, or estimate vs. actual… etc. However, all of these other measurements either implicitly or explicitly drive sub-optimal behavior.
Also Known As: Measuring Results (Scrum), ROI (business management), Economic Driver (Good to Great), Running Tested Features (Extreme Programming).
Clear the Path
Everyone in an organization using Agile Work takes responsibility for clearing the path, removing the obstacles that prevent work from being done effectively. Clearing the Path doesn’t just mean expedient, quick fixes to problems, but rather taking the time to look at an obstacle and do the best possible to remove it permanently so that it never blocks the path again.
In the Agile Work method, the Process Facilitator is the person who is responsible for tracking obstacles and ensuring that the path is cleared. To do this, the Process Facilitator maintains a Record of Obstacles.
Clearing the Path is sometimes painful work that exposes things we would rather not deal with. As a result, it is critical that people build their capacity for truthfulness and work to develop trust amongst each other. Building a capacity for truthfulness is not something that can be done by using an explicit process.
Also Known As: Removing Obstacles (Scrum), Stopping the Line (Lean).
Remember also, that these practices must always be viewed and implemented in the context of the Agile Axioms. These axioms provide a check to ensure that the practices are not being applied blindly, but rather applied appropriately to the given situation.