Blogged on:

Reasons why your team has trouble adopting Agile

Moving a team to Agile can have benefits- if your organization has committed to moving their methodology to an Agile based (Scrum, Kanban, XP, FDD, Crystal, Lean) and things aren’t going smoothly there can be any number of reasons that account for this.

Culture: Agile requires an organization that is flat, relies on accountability and ownership, and a high degree of trust in the team. If your organization is top down or blame centric (as opposed to problem solving centric), it’s going to have a harder time adapting Agile methodology into its practice. That’s not to say that it won’t work- you can tailor the agile practice in such a way that respects the organization’s needs in terms of hierarchy and ethos. I’ve worked in places like this using a Kanban methodology, but there was significant resistance compared to other organizations which were flat and problem solving oriented.

So- the question is do you slog through it and try to force agile down the throats of an unwilling team, or do you try to facilitate a change of culture. It could come down to analysis of which is easier- fighting a strong tide pulling away from Agile, or undertaking the complex, high risk, and often frustrating long term project of transforming culture.


DLC: My expertise lies in Software and digital, so my experience is mostly in the life cycle related to software development. I cannot say with any authority how the Lifecycle applies to any other industries or project types- but I’ve encountered resistance to adopting Agile from the development cycle. The legacy cycle was structured in such a manner that when before I created the agile the project plan which applied the Features to Sprints, I discussed it with the architect, and got his sign off. Then the project kicked off and the team commenced development, and it was nothing like how the sprints were structured. Mainly because my plan assumed FDD, while what made sense from a technical point of view was global module development at the outset. Perhaps this example had to do more with communication and accountability on the part of the architect, but they were following a strong Legacy DLC structure.

So- how did I handle this? Did I pull the brakes on the entire process and have the team start over inside the structure of FDD? Of course not- I revised the project plan to reflect this approach. They were still doing to develop the feature modules independently, they were just building the global modules at the outset. So, got asked if this would impact the magnitude of each feature, and I was told it would reduce the effort. I got re-estimates from the team for each feature, and updated the plan with Global modules to fill the first 2 sprints and then building out the feature set (with the revised estimates).

Requirements: In order for a team to follow user stories, they need to be versed in how to develop to spec, and QA needs to be versed in how to test to spec. If they don’t have adequate training in how to tackle the new formulas for what’s getting built, quality and velocity will drop significantly. There are also cases where user stories cannot apply- for example- technical dependencies.

The way to deal with this is with patience and training. Remember that adopting a new way of viewing requirements can be tricky, and you need room for this learning curve through consistent repetition on the correct approach (returning back to the culture not of blame but of problem solving)

No Retrospectives: I know that Lessons learned aren’t specific to Agile, but properly communicated retrospectives are an essential part of the Scrum process. Too often it’s either seen as unnecessary or ignored entirely. The sprint retrospectives serve a few functions- including ensuring the team is receiving proper information of what has been accomplished in the last sprint, what didn’t work (so they can learn from it) and what tweaks are coming to the process. Scrum should be a continually evolving methodology- if you’re not making continual improvements to the process; you’re missing some excellent opportunities to bring greater value to the organization.

So, in conclusion, an agile transformation may not always be easy, and may or may not be worth it (without information about your organization, I cannot say), but if you’re committed to making an attempt at delivering in the Agile framework- an impediment doesn’t necessarily mean you need to abandon the process.