The starting point for adopting agile is for a team to learn the mechanics of an approach such as Scrum.  They write user stories instead of use cases, do daily standups dutifully, and replace their lessons learned meetings with sprint retrospectives. Eventually the rest of the business comes on board, and the Product Owner takes over writing the user stories and maybe even attends the retrospectives. The product backlog gets populated in time for the next sprint planning session.  The team might spend some time talking about some of the upcoming stories before the next sprint.

A novice golfer often focuses too much on swing mechanics and less on the desired end result of putting the ball on the target.  In doing so, he is “doing golf” rather than “playing golf” and his improvement typically plateaus at a mediocre level. Agile teams can also plateau and fail to realize the full potential of an agile approach by “doing agile” rather than “being agile”.  Here are some of the smells of teams that are doing agile:

Detailed user stories

One of the principles of the Agile Manifesto is that “the most efficient and effective method of conveying information to and within a development team is face-to-face conversation.” Product owners who are accustomed to waterfall methodologies may still be tempted to put all of the requirements in the user story rather than using stories as placeholders for conversations with the developers.  Detailed user stories are both inhibitors to conversation and wasteful since it makes more sense to capture detailed requirements as test cases.

Obsession with metrics

The first step in replacing traditional project management methodologies with agile approaches to is to stop equating hours worked with progress.  In agile, stories that are “done” are the only true measure of progress. As such, it can be very tempting for an organization to put emphasis on user story completion rates as a key metric for judging the performance of agile teams. The danger is that when a team is considered a failure if it does not deliver 100% of planned stories for every sprint. The natural reaction is for the team to work very hard to eliminate all uncertainty and risk before starting a sprint. This can quickly lead to a culture of big, detailed user stories and excessive story grooming and sprint planning efforts in order to eliminate all possibility of not delivering 100% of stories in the sprint. In extreme cases, a team may spend an entire week planning a 4-week sprint!

Fear of building features over many sprints

The misconception that it is best to develop an entire feature in one fell swoop may still be present in some organizations.  Usually the rationale is something along the lines of building the entire feature in a single sprint makes the process more efficient by only having to test it once.  This misses the point of agile, which is to build feature and product increments, learn from user feedback, and make adjustments by adding to the feature in subsequent iterations. This brings to mind the old adage “Users don’t really know the requirements until they fail to be met by the software.” But what about having to regression test as increments are added?  Automated testing can eliminate alot of that effort.

Stories not considered done when new requirements discovered

New requirements will surface as the software comes to life in a sprint.  That’s good!  The key is recognizing these new requirements as new user stories rather than as defects that must be corrected in order to consider the story “done”. This requires strong trust between the users, Product Owners, and development team to recognize that the new requirements were not factored into the story sizing for the current sprint (remember – requirements are not detailed before starting a story).  If team starts to feels like story is a lot bigger than what they thought when they sized/estimated it, this culture of trust allows for a new user story to be created to handle that additional work in a subsequent sprint.  The “doing agile” version of this is where CYA kicks in and the Product Owner and team members run for cover to avoid the organizational fallout from additional work coming out of a sprint.

Reflections

• Being agile allows a team to focus on building great software that delights customers rather than merely creating the illusion of progress.
• Just like becoming a great golfer, this is often the most challenging part of an agile transition.