Common Challenges in Scrum

Scrum is not a process – rather, it’s a framework which provides a lot of visibility to the team, and a mechanism that allows them to “inspect and adapt” accordingly. Scrum works by making visible the dysfunction and impediments that are impacting the team’s effectiveness, so that they can be addressed. For example, most teams are not good at estimating how much they can get done in a certain period, and so will fail to deliver what they committed to in the first Sprint. To the team, this feels like failure. But in reality, this experience is the necessary first step toward becoming more realistic and thoughtful about their commitments, and also being even more committed to delivering what they signed up for. This pattern – of Scrum helping make visible dysfunction, enabling the team to do something about it – is the basic mechanism that produces the most significant benefits which teams using Scrum experience.

One very common mistake teams make, when presented with a Scrum practice that challenges them, is to change the practice, not change themselves. For example, teams that have trouble delivering on their Sprint commitment might decide to make the Sprint duration extendable, so they never run out of time – and in the process, ensure they never have to learn how to do a better job of estimating and managing their time. In this way, without training and the support of an experienced Scrum coach, teams can morph Scrum into just a mirror image of their own weaknesses and dysfunction, and undermine the real benefit that Scrum offers: Making visible the good and the bad, and giving the team the choice of elevating itself to a higher level.

Another common mistake is to assume that a practice is discouraged or prohibited just because Scrum doesn’t specifically require it. For example, Scrum doesn’t specifically require the Product Owner to set a long-term strategy for his or her product; nor does it require engineers to seek advice from more experienced engineers about complex technical problems. Scrum leaves it to the individuals involved to make the right decision; and in most cases, both of these practices (along with many others) would be well-advised.

Something else to be wary of is managers imposing Scrum on their teams; Scrum is about giving a team space and tools to self-organize, and having this dictated from above is not a recipe for success. A better approach might begin with a team learning about Scrum from a peer or manager, getting comprehensively educated in professional training, and then making a decision as a team to follow the practices faithfully for a defined period (say, 90 days); at the end of that period, the team will evaluate its experience, and decide whether to continue.

The good news is that while the first Sprint is often very challenging to the team, the benefits of Scrum tend to be visible by the end of it, leading many new Scrum teams to exclaim: “Scrum is hard, but it sure is a whole lot better than what we were doing before!”

Scrum Basics

Scrum is an iterative, incremental framework. Scrum structures product development in cycles of work called Sprints, iterations of work which are typically 1-4 weeks in length, and which take place one after the other. The Sprints are of fixed duration – they end on a specific date whether the work has been completed or not, and are never extended. At the beginning of each Sprint, a cross-functional team selects items from a prioritized list of requirements, and commits to complete them by the end of the Sprint; during the Sprint, the deliverable does not change. Each work day, the team gathers briefly to report to each other on progress, and update simple charts that orient them to the work remaining. At the end of the Sprint, the team demonstrates what they have built, and gets feedback which can then be incorporated in the next Sprint. Scrum emphasizes producing working product at the end of the Sprint is really
“done”; in the case of software, this means code that is fully tested and potentially shippable.
Scrum Roles
In Scrum, there are three primary roles: The Product Owner, The Team, and The
ScrumMaster. The Product Owner is responsible for achieving maximum business value, by taking all the inputs into what should be produced – from the customer or end-user of the product, as well as from Team Members and stakeholders – and translating this into a prioritized list. In some cases, the Product Owner and the customer are the same person; in other cases, the customer might actually be millions of different people with a variety of needs.
The Product Owner role maps to the Product Manager or Product Marketing Manager position in many organizations.
The Team builds the product that the customer is going to consume: the software or website, for example. The team in Scrum is “cross-functional” – it includes all the expertise necessary to deliver the potentially shippable product each Sprint – and it is “self-managing”, with a very high degree of autonomy and accountability. The team decides what to commit to, and how best to accomplish that commitment; in Scrum lore, the team are known as “Pigs” and everyone else in the organization are “Chickens” (which comes from a joke about a pig and a chicken deciding to open a restaurant called “Ham and Eggs,” and the pig having second thoughts because “he would be truly committed, but the chicken would only be involved”).
The team in Scrum is typically five to ten people, although teams as large as 15 and as small as
3 report benefits, and for a software project the team might include analysts, developers, interface designers, and testers. The team builds the product, but they also provide input and ideas to the Product Owner about how to make the product as good as it can be. While team members can split their time between Scrum projects and other projects, it’s much more productive to have team members fully dedicated. Team members can also change from one
Sprint to the next, but that also reduces the productivity of the team. Projects with larger teams are organized as multiple Scrums, each focused on a different aspect of the product development, with close coordination of their efforts.
The ScrumMaster is one of the most important elements of Scrum success. The
ScrumMaster does whatever is in their power to help the team be successful. The ScrumMaster is not the manager of the team; instead, the ScrumMaster serves the team, protects the team from outside interference, and guides the team’s use of Scrum. The ScrumMaster makes sure everyone on the team (as well as those in management) understands and follows the practices of Scrum, and they help lead the organization through the often difficult change required to achieve success with Agile methods. Since Scrum makes visible many impediments and threats to the team’s effectiveness, it’s important to have a strong ScrumMaster working energetically to help resolve those issues, or the team will find it difficult to succeed. Scrum teams should have someone dedicated full-time to the role of ScrumMaster (often the person who previously played the role of Project Manager), although a smaller team might have a team member play this role (carrying a lighter load of regular work when they do so). Great
ScrumMasters have come from all backgrounds and disciplines: Project Management,
Engineering, Design, Testing. The ScrumMaster and the Product Owner shouldn’t be the same individual; at times, the ScrumMaster may be called upon to push back on the Product
Owner (for example, if they try to introduce new deliverables in the middle of a Sprint). And unlike a Project Manager, the ScrumMaster doesn’t tell people what to do or assign tasks – they facilitate the process, supporting the team as it organizes and manages itself – so if the
ScrumMaster was previously in a position managing the team, they will need to significantly evolve their mindset and style of interaction in order for the team to be successful with Scrum.
In addition to these three roles, there are other important contributors to the success of the project: Perhaps the most important of these are Managers. While their role evolves in Scrum, they remain critically important – they support the team by respecting the rules and spirit of
Scrum, they help remove impediments that the team identifies, and they make their expertise and experience available to the team. In Scrum, these individuals replace the time they previously spent “playing nanny” (assigning tasks, getting status reports, and other forms of micromanagement) with more time “playing guru” (mentoring, coaching, helping remove obstacles, helping problem-solve, providing creative input, and guiding the skills development of team members). In making this shift, managers may need to evolve their management style; for example, using Socratic questioning to help the team discover the solution to a problem, rather than simply deciding a solution and assigning it to the team.

Excel 2007 Developer Reference

This reference contains conceptual overviews, programming tasks, samples, and reference documentation for developing solutions that are based on Microsoft Office Excel 2007.

Publish date of this reference: April 2009 (version 2007)

This documentation can be accessed from the following locations:

• From the product (most recent version):  If you are connected to the Internet, you can view the most recent version of this reference in Excel. Click Help, and in the Search box, under Content from Office Online, click Developer Reference.
• From the product (installed version):   If you are not connected to the Internet, you can still view the version of this reference that was included with your product. Click Help, and in the Search box, under Content from this computer, click Developer Reference. October 2006 (version 2007) is included with the product.
• From the MSDN Library.  To view the April 2009 version of this reference in the MSDN Library, click the items in the MSDN table of contents that is displayed in the navigation pane of your browser.