How to Overcome Three Myths of Agile With Real Practices

Myths teach us concepts through a narrative. For example, before we had scientific proof that the earth’s rotation caused our sunrises and sunsets, ancient civilizations believed the sun rose and fell because it was driven across the sky on a chariot. Myths help explain things we don’t understand, which is why it’s not surprising that Agile has a few urban legends of its own. However, once you really understand and practice the methodology, these Agile myths are quickly disproven.


Myth #1: “Agile means no planning!”

A common misunderstanding many organizations have when adopting Agile is that Agile practices don’t have the same amount of rigor when it comes to planning a team’s work – especially when they’ve been doing more traditional development practices, which generate a large amount of up-front planning.

When done well, Agile can actually provide more opportunities to plan and more visibility on how your team is doing. Scrum, for instance, has five distinct levels of planning.

 

Planning the Vision
An organization adopting Scrum should take the time to plan out their long-term vision– where they want your product to be in the next two to three years. As you learn more from their customers and validate their product assumptions, your vision can change.

Implementing the Vision with the Roadmap
A well-understood vision will be achieved by implementing a roadmap, which is the 12- to 18-month journey to deliver value to your customers and validate your Vision. As you learn more, your roadmap may change to better meet your customer needs.

Delivering the Roadmap with the Release
In order to deliver value to your customers and test hypotheses, your Product Owner will create a release plan that details the features and functionality your team should deliver to your customers over the next few iterations. As you gain feedback from your customers, your Product Owner may move features in and out of their release plan, and adjust it to deliver the most value possible.

Evolving the Release through Sprint Plan
Every iteration, your Scrum team will review the Product Backlog and create their Sprint plan; they’ll review the most important work on the backlog, and figure out how to deliver as much of it as they can to your customers.

Updating through Daily Scrums
Every day, your Scrum team plans their work for the day during the daily Scrum. Based on what happened yesterday and what they were able to get done, they plan out the work for the day and adjust their sprint plan accordingly.

So, while it’s true that Agile eschews big, upfront planning it’s definitely a myth that Agile doesn’t require any planning. In fact, when done well, Scrum requires you to plan every day and presents you with an opportunity to adjust your plan whenever you need to in a lightweight method.

Myth #2: “Agile Means No Dates or Commitments!”

Another problem organizations have when examining whether to adopt Agile is the idea that, unlike large project plans with their Gantt charts and (typically false but comfortable) milestone dates, Agile doesn’t provide an organization with any mechanism to know when something will be released. Liar, liar, pants on fire!

Scrum again provides specific ways to get a near real-time understanding of just how far along your team is to delivering value to your customers through Sprint and release burndowns.

Every day, your Scrum team gets together to plan their work based on what they were able to get done yesterday, and, they update the amount of work they have remaining to do this iteration. Over time, this provides the team and their stakeholders and organization the visibility into the team’s progress toward getting to done in the form of a Sprint burndown chart.

Using that information from the Scrum team, your Product Owner will also be able to update how much work has been done toward the current release in the form of a Release burndown chart. The Release Burndown provides the team, stakeholders, and the organization visibility into two different pieces of information: when all the work planned for the Release should be done, and a view into how much work can potentially be done by a given date.

Instead of providing you with a date far off in the future and a strict project plan that needs to be followed precisely to achieve a given outcome, Scrum instead provides you with near real-time information about what’s done now, and a greater certainty as to what your team could potentially deliver.

Delivering on a Cadence

A second way Scrum breaks the myth of not knowing when something will be released is by providing a Potentially Shippable Increment at the end of every iteration.

Using more traditional project management methodologies, teams typically can’t deliver value to customers until all the phases of a project are complete. Scrum turns that notion on its side by delivering slices of value every iteration. Your Product Owner has the option of shipping at the end of every Iteration, changing the question from “when can we ship our project” to “what will we ship this Iteration”?

Scrum provides the option of shipping every iteration, and the data to help continuously manage customer and stakeholder expectations for when value will be delivered.

Myth #3: “Agile Means No Documentation!”

A third common misconception about Agile is that Agile teams are so focused on building and releasing software that they don’t actually deliver documentation. I’ve even had a team tell me, “We’re Agile, so we don’t do documentation!”

The Agile Manifesto itself can even be interpreted (incorrectly, mind you) to reinforce this idea:

“We value… working software over comprehensive documentation.”

With so much ammunition supporting this myth, it’s no surprise that this one’s so deeply ingrained in some teams.

Done Done
When I see teams that are shipping features without documentation, the first thing I look at is the team’s Definition of Done.

Part of the role of the Product Owner is to help the team understand what it means for a Product Backlog Item to be complete, and most teams memorialize that definition in a Definition of Done: a set of testable criteria the team can use to have confidence that their work meets their customer’s needs.

When a team is shipping software without required documentation, the first thing to do is have a conversation about changing their Definition of Done; just like a mature team shouldn’t call a user story done before their code has passed the tests they’ve written, or before automated regression testing is done, a team shouldn’t ship software without the necessary documentation.

Whether you need well-documented code or updated manuals and FAQs, it’s up to the Product Owner and the team to negotiate how much documentation is needed for the customer, stakeholders, and the organization as a whole.

 

Many of the Agile myths surrounding these projects come from Agile done poorly, where teams don’t understand the principles behind complete working deliverables, or Product Owners don’t understand the responsibility and flexibility they have with planning and delivery.

When done well, Agile provides more planning, more opportunities to deliver value, more visibility and transparency into your team’s work, and more opportunity to include the right documentation for your customers and stakeholders.

To learn about our approach to building lasting business agility, you can check out our Transformation Services page.