Agile team - rockband metaphor

-
I've been thinking about a proper metaphor about traditional (aka waterfall) and
adaptive (aka agile) process and came to this - let's think about a rock band.

Waterfall

You can create a neat studio album using random people. First, you will record drums, then bass. After that, you can try different guitars...

If the guitar sounds badly you will try to fix it or use something else. Then you will do mastering and mixing, adding effects and creating a nice cover. In a couple of months, you will have an album with a clean sound and neat content, great cover.

The key is that here you should pay more attention to the process. You need to have a good plan (lyrics and music). This going to be lengthy but you will be fine even if bus guitarist decides to leave in the middle of the process - just arrange a replacement. In music, it works fine, but in business, time plays against you and plan may not be relevant.


Agile

You with your band are on a stage. You did have time for soundcheck but was drinking beer instead. So you are here and you just need to start rocking. In the process strings going to burst, occasionally singer will forget lyrics and sometimes guitar will play something different from what was expected. But the song is going on and you have only one option - continuously adjust in order to keep rocking.

You going to screw things if guys in your band see each other for the first time and haven't had a chance to get to know each other. Process much less relevant here - in one band the guitarist going to lead and others need to adjust, in the other it would be a bass guitarist. However, these people should able to work effectively together and have a certain level of skill and trust.

This metaphor is helping me to coin the two most important factors of being Agile:

One is to adapt a plan to reality.
If front-man suddenly starts to sing refrain others needs to follow. If the guitar gets broken, the show still must go on.

People and their ability to work together is more important than process they follow
Which means that you should probably pay less emphasis to the certifications, skillset, trainings and Agile conference participation record, but more how these particular people can work together.

Comments

Post a Comment

Popular posts from this blog

Test automation framework - do I need it at all?

-
Image
While there're lots of information published on the internet about how one should develop/buy a Test Automation solution, there's an elephant in the room - which is the fundamental question "Do I need to do it at all?". That is a good question. While I think that there’re some legitimate contexts where product/project/team can benefit from having a sophisticated test automation solution/framework, my general rule of thumb is “If you need a framework - you do it wrong” . There’re at least several decent papers showing the benefit of unit-testing ([1],[2], [3]), while I could not find any research proving that system level tests could bring better results. Please let me know if you can prove me wrong. There’s at least one half-scientific paper showing the benefits of unit tests in comparison to integration/system level tests [4] There’s a good paper bringing a notion of running/writing and maintaining test vs. the benefit of having/running it at...
Read more

Efficient test automation - Secret #1 | Test Club

-
Image
It seems everyone talks about efficient test automation, but not so many people have actually seen it! To cover this I decided to make several videos regarding the secrets of efficient test automation. Today we will talk about the first (and, arguably, the main) secret - realistic expectations. Very often, test automation projects or initiatives are started with the following unrealistic expectations: "Test automation will replace 'manual' testing" "Test automation will provide fast results and benefits" "Test automation efficiency depends solely on test automation engineers" Unfortunately, all those expectations are not realistic! Watch the video to know more!
Read more

An alternative to ubiquitous UI-level checking - Subcutaneous tests

-
Image
Let's assume a hypothetical situation - you were assigned to a project to help with the "test automation" initiative. You have a huge "test plan" as an input, containing hundreds (if not thousands) of "test cases" and you need to do something about it, quick. Problem statement Your first urge (if it is a Web application) may be to write some UI-level automated checks using tools like, you know, Selenium. In fact, there's a huge demand for such "Selenium test automators" in the industry these days. But please, please, don't do this. There're lots of things which make UI-level automated checking the least desirable approach: UI-level automated checks will be slow. There's just no way to avoid it. You can parallel them or do some other tweaks to speed them up somehow, but they still will be slow. UI-level automated checks will be flaky. Partly - because they're slow. Partly because Web browser and UI interface w...
Read more