Two Good Practices Agile Says You Don’t Need

There are lots of good practices that people will tell you aren’t agile. Usually, this comes from people who have read a book on Scrum or Extreme Programming and take it literally. They often don’t understand that agile is a set of values and principles, not methods and tools associated with a particular methodology. As long as you follow the agile principles, anything is fair game.

Here are two practices I’ve found useful that many will tell you aren’t agile.

Having Specialists on Teams

There is nothing saying you can’t have specialists on an agile project. The only thing the agile principles tell you about the makeup of your team is “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”

Usually, those who say you shouldn’t have specialists on your team are referencing Scrum, as it says all team members should be able to perform any needed task. While I’m sure there are some teams composed of such superheroes, they aren’t in any organization I work with!

Most agile teams are still cross-functional, drawing from traditional silos of people who spent most of their career working in a particular specialty. Also, there are often part-time or sporadic specialty needs, like secure design reviews, UI and UX design, and load and performance testing, that nobody on your team is able to do.

There is no question that a team composed of superheroes will be more efficient, but that doesn’t mean you can’t deliver working software continuously with specialists. That said, it is in the best interest of specialists (and their teams) to teach team members how to help others around them. Moving toward a “generalized specialist” model will increase team velocity and success.

Performing Release Planning

In the early days of agile, many approaches advocated jumping into a first sprint or iteration without any planning or setup. The argument was usually that the agile principles say “Simplicity — the art of maximizing the amount of work not done — is essential,”, and what is simpler than no planning!

While doing no upfront planning may work in a small set of cases, building industrial-strength applications isn’t one of them. Some amount of initial planning is typically necessary to prepare to enter the first sprint and make it productive.

Here are some things that are commonly done prior to starting the first sprint:

• Define an initial backlog of user stories.
• Create a high-level product architecture, or review the existing architecture your application must fit within.
• Create a test strategy that defines how testing will be approached, who will do what, what environments and tools are necessary, and the role of automation.
• Set up development and testing environments necessary to support work done in sprints, and make sure all needed tools are defined and set up in these environments.
• Create a short release plan that provides some amount of visibility into what work is the highest priority.

Work done by the team on these activities will assure you hit the ground running during your first sprint.