Complex Problems, Simple Practices
I see a lot of confusion between the nature of emergent, complex problems (as opposed to simple or complicated problems) and the agile practices used to address complex problems.
Agile methods are good for solving complex problems
We generally accept that agile methods are good for solving complex problems such as developing software with uncertain yet-to-be discovered requirements. (There are also simple and complicated problems or alternatively, known and knowable problem domains where agile practices may not be suitable or are suboptimal, but we are not talking about those right now.)
Many agile practices are well understood
It’s something else , though, to say that the agile methods themselves are ill-defined and/or have emergent definitions. These agile practices are well understood, known and knowable. Learning these (discrete) practices can be done somewhat prescriptively. (Most agree, however, that these practices can’t be fully learned until they are successfully applied). For example:
- Scrum is a tight integration of cohesive processes that can be (and should be, if you ask its inventors) applied in the same way to solve any number of different emergent problems.
- Test-driven development (TDD) and refactoring are two different XP practices. Both of them depend on the proper use of unit testing to be effective. Therefore, there is a preferred sequence in learning (and applying) these practices: first, learn unit testing.
Designing and implementing agile adoption programs
There is also the problem of designing the right program to choose what agile practices to use and how to successfully teach them under specific business constraints. This problem has both emergent and knowable features. For example:
- You may decide to teach TDD and after feedback, reset expectations to teach unit testing when you realize that client does not know how to do unit testing.
- You may learn in a retrospective that you need to change the time of your daily standup for it to be more effective (or attended!)
- You realize that you are not ready to teach Scrum because currently the developers are matrixed across too many projects.
In the case of agile program design, it would be a mistake to apply an inflexible standardized template to every engagement. In fact, an agile program should be designed so you can adapt (and improve) your program on the basis of feedback (for example, respond to emerging understanding of needs), while you execute the program.
On the other hand, it would also be a mistake if you approached a new engagement and expected that the complete program design would somehow emerge in the best possible way. To do so would be to turn a blind eye to valuable knowledge about what conditions are necessary and desirable for agile practices to take firm root and thrive in any organization.
Tags: problem solving