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!”

System Requirements of Enterprise Library 4.1

For all application blocks except for the Unity Application Block, the Enterprise Library core features, and the configuration tools, the minimum requirements are:

Microsoft Windows XP Professional, Windows Server 2003, Windows Server 2008, or Windows Vista operating system
Microsoft .NET Framework 3.5 or later
Microsoft Visual Studio 2008 development system (any of the following editions):
Standard Edition
Professional Edition
Team Edition for Software Developers
Team Edition for Software Testers
Team Edition for Software Architects
Team Suite

Note:
The Unity Application Block is a general-purpose dependency injection mechanism designed for use in applications that run on the .NET Framework 2.0 and later. It is not limited to use only within Enterprise Library. For details of the system requirements and development software requirements for the Unity Application Block, see System Requirements for the Unity Application Block.

To run the Unit Tests, the following is also required:

Visual Studio 2008 Professional or Visual Studio 2008 Team Edition. Enterprise Library includes both unit test binaries and source code. You need a version of Visual Studio that supports unit tests. For instructions about how to use the unit tests, see Unit Tests. If you modify the unit test source, you will need to recompile it, which also requires Visual Studio 2008 Professional or Visual Studio 2008 Team Edition.
For the Data Access Application Block, the following is also required:

A database server running a database that is supported by a .NET Framework 3.5 data provider. This includes SQL Server 2000 or later, SQL Server 2005 Compact Edition, and Oracle 9i or later. The database server can also run a database that is supported by the .NET Framework 3.5 data providers for OLE DB or ODBC.
For the Logging Application Block, the following is also required:

Stores to maintain log messages. If you are using the MsmqTraceListener trace listener to store log messages, you need a message queue. If you are using the DatabaseTraceListener trace listener to store log messages, you need a database server. If you are using the EmailTraceListener trace listener to store log messages, you need an SMTP server.