DZone
Agile Zone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
  • Refcardz
  • Trend Reports
  • Webinars
  • Zones
  • |
    • Agile
    • AI
    • Big Data
    • Cloud
    • Database
    • DevOps
    • Integration
    • IoT
    • Java
    • Microservices
    • Open Source
    • Performance
    • Security
    • Web Dev
DZone > Agile Zone > Two Good Practices Agile Says You Don’t Need

Two Good Practices Agile Says You Don’t Need

Two common practices that, according to Agile, are unnecessary.

Jeffery Payne user avatar by
Jeffery Payne
·
Aug. 09, 19 · Agile Zone · Opinion
Like (2)
Save
Tweet
19.11K Views

Join the DZone community and get the full member experience.

Join For Free

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.

agile scrum Sprint (software development)

Published at DZone with permission of Jeffery Payne, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Event-Driven Order Processing Program
  • Unified Observability Exporters: Metrics, Logs, and Tracing
  • How Low Code Demands More Creativity From Developers
  • Complete Guide to TestOps

Comments

Agile Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • MVB Program
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends:

DZone.com is powered by 

AnswerHub logo