There is some confusion around what agile is versus what agile methodologies are, and often people lump them together. Agile is a mindset (not a methodology) that encompasses a set of values and principles that were compiled by a group of software gurus in 2001. These values focus on customer collaboration, flexibility, a short iterative cycle, value delivery, people centricity, sustainability and simplicity, among other things. These values and principles are not to be confused with the frameworks that have been developed to assist teams in “becoming agile.”
What if the enterprise won’t change? Is it worth it to have Agile teams? I have long felt that certain parties in the Agile community are too quick to judge teams as not being agile because they are forced to function under less than ideal organizational structures. The mantra I was taught (and often repeated myself) was, “The leader is the limit.” Agile transformations will only be effective as far up and across the org chart as there is support from leadership.
My first piece of advice is this: DON’T DO IT!!!
Probably the worst possible setup for a team is spreading them around the country, world, or the universe and expecting them to behave and deliver like a close, cohesive team.
My second bit of advice for those of you that blame it on management and say you don’t have any say in the matter, is: wrong. You have lots of say in sustaining distributed teams or creating another strategy!
A seasoned director of software development was championing agile adoption at her company. It was a moderately scaled initiative, including around 100 developers, testers, project managers, BAs and the functional management surrounding them. They received some initial agile training, seemed to be energized and aligned with the methods, and were set loose to start sprinting.
I was at a conference not long ago speaking on and sharing various agile topics. After one of my presentations, a young man stopped me to ask a few questions. We struck up a nice conversation that eventually discussing sprint dynamics within Scrum teams. I mentioned that I usually coach teams toward declaring their sprints a success…or (pause for meaningful effect) …a failure.
I do this as part of the teams’ Sprint Review, with the Product Owner being the final determinant based on whether the team achieved their Sprint Goal(s). He was visibly upset with my view. He said they (he worked at a well-known Atlanta company) had never failed a sprint. Never! They could not, nor would not, use that WORD in their culture.