The Agile Manifesto is the founding document of the Agile movement. It can be found at http://www.agilemanifesto.org and if you haven’t read it, it is strongly recommended! Living values and principles is an act of striving for excellence. There are no mechanisms in Scrum to force people to live the values and principles of the Agile Manifesto. Scrum relies on individual team members to strive to develop an understanding and practice of Agile values and principles in and of their own volition. If Team Members do not live the values and principles of the Agile Manifesto in their team many other things will take priority such as creating a complex document. The team could think of Scrum as a tool for project delivery, without really working to change the culture of their organization. Since Scrum empowers individuals and makes obstacles visible, if the team doesn’t live the Agile Manifesto principles then they may be disconnected from the roots of Scrum and make it a lesser version of itself, sometimes known as Scrumerfall (where you blend some elements of Scrum with other elements of waterfall which provides little to no benefit).
As a Team Member, it is my job to figure out how to solve a problem or request that is stated by a Product Backlog Item (PBI), with the help of my team. It is the responsibility of the Product Owner to give us the vision of the product and decide how much scope is to be done to satisfy the PBI. One simple way to think about this concept is that the Product Owner is responsible for the “what” and “why” and the Scrum Team is responsible for the “how” and “who”. If the Team Members decide on the product vision by themselves, they run the risk of misinterpreting features, moving down a path that is not valuable or even creating work disconnected from the needs of those who will be using the software. If the Team Members choose their own scope they may do much less than is needed or much more than is required. There is a balance in the Product Owner providing vision and scope, and the Scrum Team providing knowledge and experience in its execution.
The Definition of “Done” for a Scrum Team makes transparent how close the team’s work is coming to being shippable at the end of every Sprint. Expanding the Definition of “Done” until the team is able to ship their product increment every Sprint is a process that every Team Member helps advance. Team Members expand the Definition of “Done” by learning new skills, developing trust and gaining authority to do work, automating repetitive activities, and finding and eliminating wasteful activities. When every Team Member is systematically expanding the Definition of “Done”, the team builds its capacity to satisfy business needs without relying on outside people, groups or resources. If Team Members are not actively working on this, then many of the obstacles to becoming a high-performance team will not be discovered.
Scrum Team Members, excluding the ScrumMaster and Product Owner, must be completely open-minded to learning new skills. Skills can be technical, business, personal, tools-based, etc. A Team Member is sensitive to the needs of the Scrum Team and will learn skills by multiple means as the needs of the team evolve. A Scrum Team where people are not willing to learn new skills will suffer from bottlenecks, time pressure, quality problems, and often will become generally demoralized as the willingness of some people on the team turns into apathy and cynicism when others refuse to learn. In a team where everyone is willing to learn new skills, there will be a consistent raising of capacity and the team will be able to do more and more work more effectively. This attitude is a key requirement for the formation of high performance teams.
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.
A Scrum Team Member is aware of the work that other Team Members are doing, notices if others are struggling with their tasks, and if so, offers to help them. A Scrum Team Member is not just focused on their own personal tasks. This help can be offered as ideas, powerful questions, sharing the work of the task, or even offering simple encouragement. If Team Members are constantly seeking to help each other, this actively contributes to team cohesion, cross-training, and the development of a high-performance team environment. Of course, if people don’t help each other, then individual Team Members may struggle for a long time without making progress and overall productivity will be dramatically hindered.
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.
This report provides some excellent information about the state of Scrum based on a survey of over 500 professionals. I hope that the scope of this survey grows to include many more people over time so that the results are more reliable.
Here is one interesting quote from the report:
Insight #3: The long-term success of Scrum is about creating a culture and making Scrum principles and practices the “new normal.”
Lots of interesting data in the report that backs that up!
The link to the report as well as a webinar and presentation deck are available on the Scrum Alliance site.
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.