Scaling Agile to an enterprise can be such a heavy endeavor to begin. Most businesses that move towards Agile software development find their initial success in the teams that employ it first. At the team level, it is usually very easy to see why software development should be built in an Agile-like manner. I’ve found that the team is always the least resistant to that kind of change.
What happens when a software development department that goes Agile doesn’t roll it out to all team members?
Well, David Bland tells us that sometimes they break down and cry.
As a developer myself back in the mid 90s I’ve never witnessed this firsthand, but I can tell you that I know exactly how the crying-developer feels.
Agile is a team-focused framework.
One of the reasons that Agile is successful is because it requires (in a lot of ways) participation throughout the entire process. Whether you have only one team or multiple teams, they need to be saturated in the knowledge-share that comes with foundational Agile principles such as: co-located team rooms, daily stand-ups, product owner and prioritized workload management, frequent collaboration, and constant adaptability and flexibility to change.
I couldn’t tell you how much I learned as a developer when I was in and around the other team members in an open work environment. Cube farms = #fail. Something about being able to photosynthesize knowledge just being around the core work group was crucial to my learning of new coding structures and practices, as well as in early 2001 learning C# even when I wasn’t developing in it! Just because I was around those that were.
If at all possible, involve all your team members in some aspect of the Agile process. Trust me, they’ll learn something valuable. Hopefully they won’t be found in the fetal position under a desk sobbing bitterly.