Just completed my 'Agile Business Analysis' course in Kuala Lumpur with a great group of participants who asked some challenging questions.

In response to some of their questions, I drew this diagram on the whiteboard in an attempt to summarise the major themes of the course.


As the title suggests, the main topic of the course is Business Analysis but in order to understand the roles of a BA, we also cover agile software development. For many participants, this is their first exposure to the agile approach and so they have many questions about the cultural changes required to adopt an agile at their organisation.

In the end some participants reject agile, on the grounds that it will never work at their organisation. Accepting their point of view, I point out that they can also learn a more agile approach to business analysis from the course. An approach that can also be applied to traditional software projects.


Another question challenged the idea that an entire team could work on defining requirements. The question was based on a waterfall workflow that insists requirements must be complete before coding can start and that coding must be complete before testing can begin. I usually answer this question by discussing 'dependencies' rather than workflows.

It is true that writing code 'depends' on an understanding of requirements and that testing 'depends' on the availability of code to test. But these dependencies can easily be accommodated in a more iterative workflow. I compared it to an orchestra and a jazz band.

Team soloist. Look for YouTube videos of orchestra and jazz band playing Beethoven's ninth symphony.