There's a saying in the Agile community — Agile is simple, but it's not easy. All too often Scrum teams cut corners or abuse the Scrum framework — they do the easy parts of Agile without doing the hard parts. These teams may see initial short term gains, but sooner or later, meet challenges, frustration, and in many instances, failure.
For example, one of the principles behind the Agile Manifesto is "Business people and developers must work together daily throughout the project." This is usually a big cultural change and can be uncomfortable for developers and business people who often don't speak the same language. Daily collaboration between developers and business people creates the feedback loop and ability for course correction that ensures what's delivered at the end of the sprint is just what stakeholders want. This collaboration is critical to the Scrum process, and is sometimes one of the hardest practices to begin and maintain.
How often do you leave software documentation undone because it is seen as a low priority compared to moving on to the next coding assignment? Similarly, some Scrum teams forgo Sprint Retrospectives due to lack of time or perceived lack of value. Inspection and adaption are cornerstone principles to building high-performing Scrum teams. You can only achieve continual improvement when you pause to reflect on what's working well, what's not working well, and make a conscious decision to adjust your practices. Small tweaks can mean the difference between project success and failure. Done right, the Retrospective can be an interesting and even fun meeting that yields valuable results.
Agile development is very different from waterfall development. Sometimes a new or untrained Scrum Master or Tech Lead tries to manage the team instead of leading and guiding the team. Scrum Masters are not Project Managers. A command-and-control mentality is counter to the Agile/Scrum framework. A manager assigning tasks and dictating effort is an Agile anti-pattern. Great Scrum teams are self-organizing, the Scrum Master is a servant leader. Thus, teams learn to become better at working together and delivering greater value more efficiently by regular inspection and adapting to overcome challenges. Often the lesson is learned better by experience (good or bad) than by just being told what to do. Figure out solutions to problems yourself — don't rely on the Scrum Master to solve all your problems.
Good communication is essential to successful Scrum projects. Something I see quite regularly on newer Scrum teams is people using the Scrum Master to deliver their messages to others. For example, a Developer has a question about a User Story; instead of going directly to the Product Owner, he emails the Scrum Master to obtain the information. A key Agile principle is communicating face-to-face whenever possible. The time it took to compose the email would likely have been all that was needed to get the answer directly from the stakeholder. But, for many technical people, face-to-face communication is a scary thing when we're used to living in a safe cubicle world, without needing to talk to people. This is a cultural or personality issue that must be overcome. It wastes time and increases the risk of miscommunication.
As the beginning of a new sprint approaches, it is important that the Product Backlog be ready. An unready Product Backlog is one of the most common reasons for sprint failure and for demotivating a team. It is also a root cause of low delivery velocity and not delivering high value. New Product Owners need coaching and hand-holding the first few sprints as they learn to develop and maintain a Product Backlog that has enough valuable features, that have been estimated at a high level, and are prioritized by business value. While not the responsibility of developers to hold the hand of the Product Owner, the development team can be a valuable asset to the Product Owner while the backlog is created. High-level estimation is also needed during backlog grooming or refining, and those who will do the actual work are the best ones to provide estimates. Preparing the backlog far enough in advance of the next sprint is a must. Help the Product Owner keep the flow of value coming.
The Daily Stand-up is a key Scrum meeting that adds tremendous value from several points of view. It puts the core team face-to-face every day for 15 minutes, it forces communication and collaboration, and it provides visibility and transparency into the project. For such a key meeting, it needs to be taken seriously. Attendance at the Daily Stand-up is never optional for anyone who has a task due: The meeting starts on time, never goes beyond 15 minutes, and everyone answers three questions (What did I accomplish for the project yesterday? What will I work on today? What obstacles are blocking me from completing my work on time?). There should be no side conversations, discussions, or problem solving during the meeting. The Daily Stand-up also provides the opportunity every day to communicate impediments to getting work done. One of the primary functions of the Scrum Master is to remove obstacles so the team can focus on delivering software; but if obstacles are not raised, the Scrum Master can't help remove them. Waiting to raise an obstacle until it's too late to recover from it is unacceptable. Until the team is accustomed to communicating obstacles in a timely manner, team members need to constantly remind each other to bring up even potential obstacles, if there's any chance something might delay the work or cause the sprint commitment to be missed.
Agile is more about people, interactions, and culture than about processes, practices, and tools. While Scrum practices are important and provide practical guidelines that can help increase project success, the principles — the hard parts — are what make Agile sustainable in the long run and maximize the great benefits it has to offer.
Dwight Kingdon is a Principal Consultant/Agile Coach at the Mindtree US Delivery Center in Gainesville, Florida. He possesses over 25 years of project management experience leading complex information technology projects, and over nine years of Agile/Scrum experience coaching and leading high profile, mission critical projects.