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 architecture. Part 2.1 - Layered architecture example

-
Image
Let's consider an example of what Layered (Tiered) architecture may look like for a test automation framework. As a system under test, we're going to use this simple and neat "Todo list" application. First, let's do a brief analysis of the application. From my brief exploration I came up with the following checklist: Area/Group Things to check Comments Todos CRUD 1 Create item Basic scenario, UI-level case 1.1 Create an item with the same name The case is not valid. There's no validation for that - nothing to check really. 1.2 Create an item with an empty/not valid/malicious name While it would be a nice thing to test manually, from test automation standpoint I would expect this to be filtered on service or repository level, so either integration or unit test . 2 Mark item complete Basic scenario, UI-level case 2.1 Un-mark item complete Basic scenario, UI-level case 3 Delete item Basic scenario, UI-level case 3.1 Delete item
Read more

Test automation framework architecture. Part 2 - Layered architecture

-
Image
Probably the most popular architecture pattern used for test automation frameworks (TAF) is layered architecture. This pattern is so well known that on job interviews for some companies when they ask you about TAF architecture you are supposed to describe this one. If you don't - they think you know nothing about the architecture altogether. I suggest you first read a brilliant description of the pattern at the O'Reilly web page , cause in this post I am going to describe the pattern in a way it is usually applied to build test automation solution. Usually, there're three distinct layers, which may have different names, but follow the same logic mostly. Sometimes those layers called test layer , business-layer and core layer , but there're no standard names really. Key rules for layered architecture are the dependency direction (each level depending on the level below) and call direction (no level can call/reference code described in the level above). The rough
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