2 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 a first sprint and make it productive.
Here are some things that are commonly done prior to starting a 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 provide some amount of visibility into what work is highest priority
Work done by the team on these activities will assure you hit the ground running during your first sprint.
Great points Jeffery. I still remember Bob Hartman pointing out in his CSM training course that the Scrum Framework is missing the release planning ceremony. It's such a fundamental part of the planning process for my Scrum teams that I can't imagine life without it.
"...Scrum, as it says all team members should be able to perform any needed task." Don't recall where I've heard that said by anyone. It says the needed skills all need to be on the team (which is what "cross-functional" means). Now on the early XP teams there were only "developers" and they coded, tested, documented, etc.
As to "Some amount of initial planning is typically necessary," I agree. At least some time must be spent to get a few Sprints worth of backlog items in decent shape for the team to be able to consider implementing. Guess it's how big some folks believe "Some" means.
I believe folks overlook another dimension of cross-functional teams. The Scrum Guide (your reference to what scrum says) does suggest that cross-functional teams have all the competencies necessary to accomplish the work, a notion you refute with "part-time or sproadic specialty needs." Nowhere does the Scrum Guide use the words or notion that "all team members should be able to perform any needed task."
Consider how cross-functional also applies to individual team members - your generalized specialist model to which you credit "increased velocity and success." Generalists with specialties allow team members to grow and deepen their skillset over time--thus being of more value to the team, themselves, and the organization. The needs for backup and benchstrength dissipate over time as well. You refer to these folks as superheroes. I consider this ongoing growth, a healthy professional target for "motivated individuals." Hope this helps the reader audience expand their understanding and thinking around agility, scrum, and cross-functional skillsets.