Wednesday, May 20, 2009

People Over Process and Tools

People and Interactions Over Processes and Tools. In other words: Brain over Fingers.

If Agile values people over processes and tools, why does it require so much automation? Reality is that people is good at creative tasks, so in order to really use their potential we need to free people from tedious and sequential tasks. People: We need your brains not your fingers!


Perhaps my biggest challenge implementing Agile so far has been convincing people to let go of their repetitive tasks and automate their processes. This is not always the case with software development professionals, but in general it is the case with the other "delivery functions" (QA, Operations, Project Management).

I'm not sure if it is related to people's background, but I find that QA analysts and System Engineers that were once developers are more receptive to automation and have greater success with it.

It is not hard to convince a developer to automate his build process for example. In fact, I haven't seen a manual build in a long time now. That's definitely not the case with QA Analysts and automated test cases or System Engineers and their deployment or monitoring processes.

The way I normally approach this issue is by selling the benefits to the professional in question. I show engineers and analysts how much easier and pleasurable their lives would be if they didn't have to do the same repetitive task over and over again. For example, I tell QA analysts how much more challenging their job would be if instead of executing their tests if they spent most of their time coming up with new test cases. In this case, we need QA analysts to use their brain to come up with test cases and not fingers to type or click the mouse.

By shifting the work of the QA analyst to test case development and automation we are now using their brains and not only their fingers. 

It is true that automating test cases might require as much software development skill as coding the system being tested. In cases like this, I'd have the QA analyst define the test cases and have developers automate them. I found that QA analysts are sometimes comfortable reading the test code and are willing to "audit" the automated tests to make sure they are indeed covering their intended cases.

Deployments is another area of the software development process that is ripe for automation. How much better life would be if instead of spending a few hours deploying an application in the middle of the night, System Engineers spent those hours coming up with scripts that would deploy the application in minutes? What if they spent time figuring out how to break the deployment apart enough to be able to have all of the components in production inactive ahead of the deployment? These are tasks that require brains and not fingers.

Once again, we need your brains and not your fingers!


ShareThis