The Daily Scrum meeting supports the Scrum value of Openness and the principle of self-organizing teams. This rule of Scrum also aligns with the Agile Manifesto principle “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.” In-person attendance of all Scrum Team members allows for the fullest level of openness among Team Members. If even one team member attempts to attend this meeting by any other means, either by phone or even video conferencing, efficiency and effectiveness of the openness and self-organization becomes compromised. Compromised self-organization yields compromised collective ownership. The successful delivery of the Sprint Goal requires full commitment on the part of the whole team. Lack of in-person participation increases the likelihood that the team will fail to deliver on its Goal because the openness and self-organization will lack effectiveness.
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.
Every Scrum Team Member should be working on tasks in the Sprint Backlog. Generally speaking, this should be one task at a time with little or no work done on work that is not on the Sprint Backlog. The visibility of the Sprint Backlog is an important part of Transparency within the Scrum Team. As well, doing one task at a time helps with Focus, another of Scrum’s values. If team members follow this rule, then the work of the Sprint is done in a reliable way. When team members take on multiple tasks simultaneously or when they take long breaks to do non-Sprint Backlog work, then the team’s focus is substantially diminished and overall productivity suffers.
A Team Member is defined by their commitment to the goal(s) of the Scrum Team. If a person is not personally committed, they are not part of the team. Commitment cannot be imposed. A person’s manager can’t force them to be part of the Scrum Team by telling them to be committed. If all the members of the team are committed to the Sprint goal, then they will all work in whatever way is necessary to accomplish that goal. This commitment willingness to do what it takes is a key factor in creating a high-performance team. If any individual is not committed to the Sprint goal, they aren’t really part of the Scrum Team. Having someone how is not committed but is constantly interacting with Scrum Team members, who is doing work that is properly owned by the team, and who participates in team meetings as if they were a member of the team is incredibly disruptive. This “false” participation can cause morale problems if not eventually fixed either by the person becoming committed or by the person leaving the team. Having people who are on the team in name only will prevent a team from reaching a high-performance state.
All Scrum Team Members, including the ScrumMaster and Product Owner, should understand the high-level technical aspects of the product that is being built. As well, that understanding should be solid enough, that it can be communicated to other people. This understanding helps the team members in many situations dealing with each other and with stakeholders. Understanding the structure of the system is an aspect of Transparency. This is essential for maintaining overall quality of the product. Development in one part of the product or system should never cause problems for any other part of the product or system. If team members do not know their product in this way, it can cause significant problems in communication and in how Product Backlog Items are implemented.
All Scrum Team Members, including the ScrumMaster and Product Owner, should understand the high-level business aspects of the product that is being built. As well, that understanding should be solid enough, that it can be communicated to other people. This understanding helps the team members in many situations dealing with each other and with stakeholders. Understanding the purpose of the system is an aspect of both Focus and Transparency. This is essential for maintaining overall quality of the product. Development should always be done in a way that moves the system towards fulfillment of its intended purpose. If team members do not know their product in this way, it can cause significant problems in communication and in how Product Backlog Items are implemented. Finally, and perhaps most importantly, understanding the overall purpose of work is critical for a team to become a high-performance team. Without knowledge of this purpose, a high-performance team is impossible.
Scrum is team-focused. Fixation on optimum (individual people) resource utilization is a major obstacles for effective Scrum implementation. Doing Scrum right and deriving the benefits of team-focus that it has to offer requires full-time dedicated membership of all team members. A Scrum team should be delivering the highest value product of an organization. Having team members assigned to other projects at the same time means that the focus on delivering the highest value is being disrupted. Furthermore, a Scrum team needs to be able to establish and maintain a constant velocity from Sprint to Sprint. This is impossible to do if team members are being shared with other projects and/or teams. Also, there is tremendous waste associated with task switching that is eliminated by this single rule. The hang-ups of resource utilization need to be left behind if an organization is to mature into one that is Scrum team-focused.
All Scrum team members must be committed 100% to the Sprint goal of their team. If people are trying to be on more than one team, then they are not able to be fully committed to the goal of either team. This means that neither team can be fully committed to the deliverables of their Sprint Plans. Failure to commit to the Sprint goal results in failure to deliver and a failed Sprint. When people are working on more than one Scrum team, the teams are being set up to fail at Scrum. This rule is often counter-intuitive to traditional project management, which tends to be obsessed with resource utilization. The problem with managed resource utilization that this rule of Scrum solves is the complete lack of commitment that it forces onto the people doing the work. Scrum creates a sense of ownership of the delivery of the whole product in each and every team member when they are allowed to work with one Team.
Scrum relies on the truthfulness of Team Members to allow for transparency about the internal quality of the product. Internal quality is primarily related to the technical aspects of the product: its design, its architecture, lack of duplication in the code, and the level of coverage of the product with automated tests. Scrum relies on the professionalism of the Team Members for the proper implementation of this rule. Being upfront, transparent, and truthful about the internal quality of the product allows for the Product Owner to understand how much time and effort the Team will allocate to improving the internal quality of the product and how much will be allocated for new features. This also gives the ScrumMaster an opportunity to connect with stakeholders who may be able to help remove technical debt and waste that is continuing to exist. If Team Members are not truthful about the internal quality of the product, over time the system will become more cumbersome, more complex, and more painful to improve. This will also lead to a culture of hiding problems, which diametrically opposite to the intended use of Scrum: to uncover problems and allow us to solve them. Another downside is that morale will begin to decrease as Team Members care less about the quality of their work. This, of course, will ultimately lead to external quality problems that result in customers being unhappy and looking for someone else to work with.
Scrum is an Agile process framework that is optimized for product development. The rules of Scrum are fine-tuned after decades of use to help product development teams become hyper-productive and to maximize business value. If you use Scrum for product development, then you are applying it to the right problem. If you use Scrum for some other type of work (e.g. general project management) then you are mis-applying Scrum and it probably won’t give you the ideal results. Scrum is not simply a collection of best practices. Therefore, if you are using Scrum by picking and choosing some of its pieces, it is likely that you are using a sub-optimal approach to product development. In this way, Scrum is like a tool rather than a toolbox with many tools. When you take a hammer out of a toolbox, you don’t pull the head off and start pounding nails without the handle. Likewise, if you only use some parts of Scrum, you are missing the benefits of using Scrum as a tool. As a Scrum Team Member, you should know the purpose of Scrum and be aware of applying it correctly to the right problems.
Since the Scrum Team only includes three roles: ScrumMaster, Product Owner, and the Team Members, there is no need to have other people on the team. Each of the Scrum roles has a specific function that requires their full-time attention. These roles are all the roles necessary to accomplish the creation of a high-performance Scrum Team. Adding people to the team who have any other roles will hinder the team from engaging in the requisite amount of self-organizing behaviour.
There are three roles on a Scrum Team, no more and no less. These roles are: ScrumMaster, Product Owner, and the Team Members. It is critical to have all three roles present on the Scrum Team to get all needed responsibilities taken care of in an effective way. The Product Owner is responsible for the product and how the team connects with that product. The ScrumMaster is responsible for improving the use of Scrum in the organization and team, as well as removing any obstacles that slow the team down. The Team Members are responsible for getting the work done by self-organizing and finding ways to improve their own process and work. Without one of these key roles, the team would be missing a key focus and job. As well, Scrum specifically disallows any other roles on the Scrum Team. A person who has an official role of Tester cannot be on a Scrum Team. However, the same person, if given the official role of Team Member can be on a Scrum Team. If people have their official titles, performance evaluations etc. done in their traditional roles, it hinders self-organizing and causes conflicts of interest. A team is not a Scrum Team until those old roles are eliminated.
The Daily Scrum meeting is a critical method for creating transparency between Team Members. Every day, each Team Member in turn answers the three questions of the Daily Scrum: what tasks have I completed, what tasks will I complete before the next Daily Scrum, and what obstacles do I have to doing my work? These questions are designed to ensure that all team members know what everyone else is doing regardless of if one or another team member thinks something is “important” to know. This transparency gives the team a regular rhythm of “Inspect and Adapt”. Since the Daily Scrum is meant to be short, any discussion of the work should be held until after the Daily Scrum is complete. To be clear: the Daily Scrum is not meant to be a problem solving meeting and treating it so can lead to people failing to be as transparent as needed (or to breaking the timebox for the Daily Scrum which leads to other problems).
Most business persons and businesses understand the concept of strategic alliances. The reason to form alliances are many and varied and include such reasons like; monetary, distribution, market access, shared technology and others. My reason for joining Berteig Consulting is a little unusual. First reason is that I am an international consultant, trainer and coach. My international work requires 100-150 days of travel outside North America every year. I have been doing this for 10 years and it does not hold the same appeal it did in the beginning of the travel. Don’t misunderstand me, I still like the travel but I pay a price physically. So joining a reputable and successful Canadian company was appealing to me.
My second reason for the alliance is that I am very impressed with the knowledge, skills, abilities and professionalism that exists in the Berteig Consulting team. Their values were consistent with mine. During the summer of 2008, Mishkin Berteig (the co-founder of the Berteig Consulting) and I began to investigate how we could work together.
Needless to say we hit it off. There is mutual respect. So I made the move to become a CSM and begin to train, coach and consult within his company. Mishkin and I have already decided to co-write a book about Agile. I have currently written 5 books which are published in 10 languages, one of which is a best seller. Mishkin and I hope to publish in late 2009. I will continue my international work to some degree, but my strategic relationship with Berteig Consuting will become more important in the coming months and years.
I look forward to adding value to Berteig Consulting, the team members and all of our clients. I will do what needs to be done to insure the existing and future customers receive the best advice, coaching and training available in the Agile marketplace. I care about the people at Berteig Consulting and will make sure they receive value from me. There is a quote I respect … People don’t care how much you know until they know how much you care! We at Berteig Consulting care about the quality of our interactions with our customers and the results of our efforts.
James M. Heidema, CSM, CLU, CIAM
Berteig Consulting team member
James Heidema’s Profile