Why not to “agile” everything or "always think before do anything"

Initially I planned to write response to this article http://xpinjection.com/2013/01/31/stop-scrum-and-kanban (Russian) since my comments raised a discussion point. But I found that from start number of details for response grows endlessly and I need to stick to some really important things, so I will try to do that below.

First of all I will clarify my personal point of view:

• Agile is a great vision for development processes but it's not applicable everywhere, absence of understanding this leads to big problems in development;
• professionals prior to processes - we should have professionals that developing product using specific processes and tools, but not a processes and tools that uses people to develop a product (that's what agile manifesto is talking about - http://agilemanifesto.org, but it's not an agile only idea, we might be non-agile, but this principle should be used anyway);
• products should be always done with high quality and processes and tools should help to do that - if used process or using of proposed tools leads to lower quality of products we should cancel using of them;
• people should have ability to do things easier and faster - all things that makes process harder or slower should be eliminated or replaced with helpful stuff;
• any rule - is not a rule if it turns work into a stuck or a problems or leads to providing low quality products (especially for commercial software), dogmas are not a part of software development but professional knowledge and mission to get best quality are;
• cannot be agile and non-agile in a same time, if there real needs to change the process from non-agile to agile - old logic should go away
• context - it's what really drives development, development without relation to context and without understanding the purpose - completely wrong. Eventually - testing without counting on product context does not have any sense http://context-driven-testing.com.

So let's see what we have in development processes of commercial software now:

• market and business expects continuous delivery of new features, new products, new solutions - no time to stop and think what and how we doing
• agile and scrum became "trends" - everyone says it's good and everyone tries to apply agile processes for all IT development because see magic words "fast and continuous delivery of products" - result looks as http://www.halfarsedagilemanifesto.org = FAIL
• everyone trains how to communicate but mostly nobody trains how to work (Dan Kennedy raised this in his work "No B.S. Ruthless Management of People & Profits: No Holds Barred, Kick Butt, Take No Prisoners Guide to Really Getting Rich")
• outsourcing (even instead of outstaffing) is a rule, because better to have cheap and easy controlled people for "dirty" work, than good and enterprising but not-very-cheap and not-so-easy-controlled professionals. This is especially true for big and old companies with long history products in development.

That's not only problems but main ones. I won't say that they are everywhere, but this article is about projects (not even companies) when such problems are exist. Trying to be in a trend and to be agile people forgets that if we need to build something new and do that right we should break old and wrong stuff and sometimes even break or hardly change even that old things that looked right. I will try to describe those things (maybe it will look as some how-to and it's good if it's really will be how-to).

I did split for psychological/philosophical part and technical part.
And before you read next part of my article: please read 2 links with word "agile" above again incl. http://agilemanifesto.org/principles.html, http://manifesto.softwarecraftsmanship.org and read and try to understand article form SCRUM Alliance:
http://scrumalliance.org/articles/483-you-may-be-a-scrumbut

Psy and Phy:

• Agile - is not process or tool or business model, this is a vision how to deliver high quality products to users. Understanding of this should be first thing that should be done on all levels of product development: from marketing to last junior tester/developer that joined team right now. There will be no agile development if no agile vision applied on psychology level of each person involved to development.
• Now part of trend is to compare "agile vs waterfall", in terms of the people that advertising this - you could not be agile if your vision on things in development is completely waterfall-ed. I think that it's not completely true but in most cases it's correct - while switching to agile better to proceed with complete instead of partial movement because any "merge" error will lead to unrecoverable break of process.
• Agile - is not a magic stick, it just a vision that might or might not be used depends of what we want. But it won't work if it's unapplicable or we won't use it's key principles (it won't be Agile so).
• SCRUM (as an example and as a most popular trend within agile models) is not a process itself. It's a framework/model to build agile development process. It have limitations and should be applied with complete understanding about goals of product, it's context, expectations and it cannot be applied as a "tool only" or "management only" feature. SCRUM-based development should use all main model ideas and should be configured with involving whole team and not some parts.
• Not applicable if:
• one part of team to be "scrummed" and others are not
• management is "scrummed" but development is not
• programmers are "scrummed" and testers are not
• from team of 100 persons on all levels 99 are in scrum and even 1 is out
• ...and vice versa of course
• Agile processes and SCRUM model (as well as Kanban, XP, MSF4Agile and any other agile-oriented models) requires that all people be self-organized and professionals in their work. No exceptions. Of course - there will be more and less experienced people with different skills, but each of one should be professional, should understand what the product is, self-educate and understand what and why he/she doing that.
• I like to call agile models with term "predicable but flexible". Predictable - because we can estimate results and track what's happening, as a result - deliver working software with predicted and even predefined/expected quality. Flexible - because we expect to be available to work with dynamically changed situation and change things to match new requirements/expectations.  That's initially 2 of 4 main items of agile manifesto, but not understanding of them makes process unmanageable.
• Before SCRUM all the team needs to understand 2 things: 1) what is Agile, 2) what is SCRUM. Saying to people "now we SCRUM" without sure that they understand at least all the key principles of agile vision and selected model does not make things agile - it pushes things to butt.

Tech (I will talk mostly about testing here but not only):

• I used word "professionals" 4 times above and will repeat that again: no one should develop or test without understanding what to do. Functionality should not be developed without understanding goals of implementing it and proper design, testing should not be done without understanding expectations from working functionality and knowledge of functional details and design.
• Developers should not be just "coders" and testers should not be just "clickers". No details here - it's mandatory and it's a one of key things that makes process agile. We are non-agile if disagree.
• Testing should be started as earlier as possible. Testers (does not matter will we call them QA or not) should be involved starting from requirements analysis and even creation (again - depending of product context).
• Vision of expected behaviors of product should be the same between management and development (incl. testers). Communication must be organized in a way to reduce possibility of misunderstanding.
• Development and testing results should be easily accessible to each team member  in easy and fast way.
• Testing should proceed until release simultaneously before, with and after design of functionality and it's implementation (coding, integration).
• There is no manual or automation testing - that's the testing or coding and that are not definitely merged things.
• No test should be written without understanding the product and functionality details.
• Test cases and scripts are not the manual or rule - we might have no strictly defined tests but functionality should be tested well.
• Testers could or should use automation scripts and tools depending on context of testing needs. There could be manual only, automated only or mixed auto/manual testing depends from what we really need but not what someone decides.
• There could be non-automation testing artifacts and tools (for example, cases/scripts for manual passing) - they also should be created and used depending of context and real needs. For example:
• if tester see that test-cases not needed to test functionality well - he/she should not spend time for writing them
• if tester see that functional map or mind-map with be more effective to describe what to test - he/she should create it while testing. Example: http://www.bettertesting.co.uk/content/?p=956
• If tester see that writing test script/cases most effective - it also should be done.
• Any of such decisions should be made on initial planning process stages and testers should be involved to them.
• If tester see that some initial decision/plan was not effective - decision or plan should be changed.
• Automation team should be part of development even in non XP agile processes.
• Automation scripts writers should always work with development directly.
• Automation is a tool, not a solution.
• Automation code is a code - not just tests.
• Cases for manual runs should not be mixed with automated cases, but automated cases should have proper references to existent manual ones.
• Exploratory testing is not a strictly defined part of agile testing. It's an idea of creators of Context-driven school and it could be used if it's effective independently of process. When we planning exploratory testing we should not forget this map:
• James Bach described principles of exploratory testing and I should not add more, since he is one of creators :-) http://www.satisfice.com/articles/what_is_et.shtml
• Exploratory testing is trackable and well reported if well organized, it's really hard to be agile and deliver software fast without doing exploratory testing.
• Exploratory testing in most cases requires more understanding product (but not knowledge), testing types and methods than scripted testing but it's faster and in most cases it provides better results than scripted one.
• Testing team should work directly with programmers. When saying "development" we should mention whole development team and testers as a part of it (if we have dedicated testing team within project).
• Developers should write tests. Unit tests of course, integration and code acceptance tests (especially using effective fault injection methods) and white box regression tests. White box testing is a developers responsibility and must be in any testing process, especially agile-based. http://softwaretestingfundamentals.com/differences-between-black-box-testing-and-white-box-testing/
• Bugs are prior to test-cases as a results of work. No matter how to report them. I found that a lot of people really think that agile requires to minimize writing of bugs but that's not true. Really only clean eXtreme Programming and Test-Driven Development (as a separate process or as part of XP model) does but not because bugs not needed, but because XP expects pair development/testing process and bugs expected to be fixed directly after test running and TDD because tests created and executed before working code written, so bugs also expected to be fixed directly in most cases. If those practices/models not used then reporting of issues should be mandatory and high priority, reports might be direct to developers of using bug-tracker but they must be in.
• automation should write auto-test code based on bugs, it might be per-bug solution if needed but not a rule, better to have improvement of acceptance criteria and updated test for it
• scripts/cases for manual runs could but not should cover even critical bugs - depends on purpose of method used to test each particular functionality, also filed bug - is already a test case
• question: what to do with regression? see answer below
• Term "regression testing" for doing functionality tests even for legacy and "expected to be unchanged" functionality should be excluded from usage. It's NOT a regression. It's acceptance or usual functional tests. Regression testing - it's limited number of tests that recent change in code does not break related functionality. That statement lead to other four:
• regression statement important ONLY in compare with last build before recent change of code/bug-fix, it's not important in compare with any released product or any other functionality
• no need to do any "regression" runs of scripts/cases/functional maps etc. each functionality should match current release acceptance criteria - it should pass it and it's OK when functional tests on acceptance runs will contain extensive exploratory run as well as running automation script or additional manual script. Decisions should depend on actual expectations from functionality and it's context (again, yes)  and should be planned within sprint as usual User Stories/Tasks, not as just "number of test suites/cases/scripts to pass" or something like that
• decisions to fix the bug should depend from acceptance criteria for current release only, even if it's "old missed bug" and "no users get it" - there should be no checks to confirm that. If the bug is serious - it must be fixed, if not very serious - let's decide this on scrum meeting or sprint review or sprint retrospective or triage (if present)
• all bugs should be fixed and closed, dropped and technoted if known but fix postponed, release could not be counted as succesful if not so
• all technotes should be documented and in case of decision to fix them for next release they must be turned on to user stories and tasks for dev team.
• Team should get all process related information in a same time - on scrum meetings (and be involved to all of them). There should be no practice not to notify someone about any decision for process/product/results - team should be considered as a single unit.
• There should be no limitations for direct connection within team (from junior participant of development team to product owner and vice versa).
• Team should be self-organized (directly from Agile Manifesto) - means that high level planning and priorities might be done w/o involving development team, but decisions how to do and how much time required to do any task should be always done based on what developers say. All planning details should be based on development team participants comments/suggestion and requests. We should trust to each team participant, but also it means that everyone should trust to each other and provide required information with important details and in time to all team.
• Reporting stage should be easy to proceed for any participant. Scrum Master should make reporting easy and results clear and transparent.

That's the main things that I wanted to take attention too. But really it's a much more details and maybe sometimes I will extend them. But for now that's mostly all what I wanted to say what we should do if we want not to get wrong behavior when changing process to SCRUM (all the things I got from practical experience, not from theory).

P.S. Some discussion points:
I still think that critical/primary (does not matter what terminology to use, btw, but it should be unified for whole project) cases should be described in testing documentation independently of type of run. Means that we should should have test scripts for manual runs always. But they should not be used as main and strict todo manual. It should be as small as possible, but should cover all critical areas and be key point to run into details from it.

Scrum is not good itself, Kanban or, at least, Scrum-ban is better and actual.

I welcome any discussion or pointing me to incorrect or confusing statements, ask question or propose addtional info to extend article or create second part of it.

P.P.S. I'm really thinking that article should be divided into mgmt/dev/qa parts but for not don't see proper way to do that correctly without duplicating info, so for now I left it as is.