People who switch from process based to non-process based organizations

Ok, first off, as per the title, non-process based organizations mean companies, concerns etc that do not FOLLOW completely/partially a specific lifecycle for something. They also include such establishments that "advertise" that they have a so & so certification and/or they have such & such SOPs but when it comes down to the hard reality of it, they choose to ignore them.

Definition done.

Now, there are major establishments that actually do what they are supposed to do in terms of following a software development lifecycle as well as adapting their own operating procedures to best suit their work and make continuous improvements to cater existing issues as well as future prospects. 

In my geographical location (country wise), these are normally big companies which have been running since way before I was born and some which sprouted up recently. Some have tons of employees, some have enough to form a football team, some don't even have that but what they do have in common is their work methodology. They have standard processes, which they follow and optimize to suit their needs as per their own change process etc


They train their resources to follow such methods religiously and in fact, it is a way of life for their projects and products to go through each and every phase that is defined (give or take a few exceptions which have been approved as per the exceptions & exemptions process).


The resources know what to do and how to do it as per guidelines and plans etc. They are happy but then again most of them were not when these processes first started to take form. They considered them to be unnecessary overheads and a pure waste of time. Some of these people even went so far as to oppose any such change which would ultimately lead to something better. Such people never saw the complete picture or even the bigger picture, they were just concerned with a portion of a picture.


But change comes and in such companies if one is to survive, one has to adapt new ideas or make way for the next young blood coming out.


Now most companies don't share that philosophy. They have work, they really don't care whether functional specifications are documented or not, they really don't give a rat's *beep* whether they have proper domain knowledge or HOW new  team members are going to get the domain (sure they say, we have the code, any new development resource can come and reverse engineer the business processes & functionality), but that is easier said than done for most people.


Now, no offense to developers (coders) and/or to testers who follow this way of thinking, but wake up and smell the coffee! In this way, most of the people would not have an idea about what is going in in the bigger picture, which in itself is a major problem.

Now, for developers, without proper documentation, have to reverse engineer the code and get the business logic/functionality from it and this is the way for each and every new developer which is hired, which itself is a overhead. The same is the case for testers (and if they cannot reverse engineer the code, its exploring the application and getting feedback from developers who know nothing beyond the code and/or business analysts).


No baseline is established. Since there are no proper processes in place and there is a lack of documentation, it is only to say what the configuration management would be like? :)

That is the hard truth here, that such places exist and they are thriving. The higher management does not care because come the end of the day, they are getting their huge paycheck from their clients and they are happy.

Now for people who have worked in process based companies, when they switch to NPBs (non-process based), they normally go into shock for the first week or so.

They are not used to the work methods there. In their previous process based company, they thought, they can go out and take over the world but in the true sense of reality, that ain't happening, not immediatly, anyway.

Hey, its not the end of the world. One has to adapt oneself in such companies and go with the flow till its time to optimize the work you are doing and people are doing around you. Sometimes, people join in positions in which they cannot do anything, at least thats what they think. Optimize your work by coming up with new innovations that HELPS you first and makes your task easier. I have done it. I have introduced new innovative ways to complete my tasks and my team's that no one in their right mind would not adopt it. At first there was resistance but finally because of the output, things went smoothly.

One thing for testers is that when they move to an NBP, they have this weird egotistical horse, which they ride and expect everything handed to them on a silver platter. Ok, something should be done like that but wake up! If its not happening that way, what do you do? Do start moping around or pouting?

Heck no! one should grab the bull by the horns. If there is not sufficient and/or no documentation for an application, then why don't you start documenting stuff slowly? If its an existing application, then exploring it will yield a lot of results. You might answer a lot of questions and in doing so are getting one thing which will make you standout and that is the DOMAIN.

Reverse engineer the code. Testers are computer literate and have had programming experience (in their respective studies) and if they have done automation. Get the code and reverse engineer the logic. Make notes, write details, create a document which will help you and in the long run, everyone.

If schedules are not maintained, make one for yourself. People will see how useful they are and might start using them for the whole project and if not, then at least you have done things right. Your work is getting easier and better.

Ask people questions, do follow-ups, get yourself included in meetings and sessions (if not included).

Remember, for you its not necessary whether you are working in process based or NPB, its the work that you do. You have the skills, just implement them and adapt as you should and eventually, you will be working comfortably in a place which hasn't even heard the term of "Project Management Plan".


Change is only accepted if the other person believes it can help and with facts and figures its easy to do.


And even if it isn't, at least your work has improved. Self satisfaction is pretty cool too.