DZone
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
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones AWS Cloud
by AWS Developer Relations
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones
AWS Cloud
by AWS Developer Relations
  1. DZone
  2. Culture and Methodologies
  3. Agile
  4. 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 · Opinion
Like (2)
Save
Tweet
Share
19.27K 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

  • How To Handle Secrets in Docker
  • 10 Best Ways to Level Up as a Developer
  • Unlocking the Power of Elasticsearch: A Comprehensive Guide to Complex Search Use Cases
  • Create Spider Chart With ReactJS

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • 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: