Do Agile Teams Take on Hard Problems?

We often hear that agile software development is fine when you face a simple problem, but that agile isn’t sufficient for more difficult problems.  Of course this falsehood is promoted by people who have little or no agile experience, or who have been involved with a failed “agile adoption” (usually these teams adopted ad hoc strategies thinking they were agile).  Anyway, we decided to look into whether agile teams are taking on hard domain problems in practice.

The following diagram summarizes the responses to our question around agile teams and compliance from our 2016 Agility at Scale study.  As you can see, 40% of respondents indicated that their agile team faced either complex or very complex problems, and that a further 38% faced medium complexity.  Interestingly, only one in eight respondents said that their team faced a straight forward problem.

Agile and Domain Complexity

The bottom line is that agile strategies, and in particular disciplined agile strategies, are in fact applicable for taking on complex problems.  More importantly, this is happening in practice around the world on a regular basis.

Related Posts

Have any Question or Comment?

2 comments on “Do Agile Teams Take on Hard Problems?

It’s funny how people bash Agile from both sides. They say “it doesn’t scale” and then they’ll say “and it’s only good for unicorns solving greenfield problems.” The bottom line is that hard problems with “unknown unknowns” respond best to iterative and collaborative approaches to knowledge discovery. Ken Schwaber has discussed the process control theory behind this, and Don Reinertsen has discussed the information theory.

Paul Tomlin

Good point Charles. I would suggest adding ‘rigorous’ to your comment that ‘hard problems with “unknown unknowns” respond best to iterative and collaborative approaches to knowledge discovery’. Do the two references you mention there have anything to say on this subject – I’m thinking in terms of how much beyond the current ‘known’ you should attempt to accommodate when designing/developing or, put another way, when to stop. (My area is looking to adopt agile and I am interested in getting a clear understanding of what to do to minimise technical debt in early iterations impacting results in later iterations. )


Leave a Reply

Your email address will not be published. Required fields are marked *