On Agile, SCRUM and agility

These are interesting times for me, the transition from a management position where a team would do all the work and my role was mostly to shield them from the politics and planning problems, to a role where my production is determined by the amount of tests automated and the strength of my code.

After joining a new team a while back, I could not help but notice the wide variety of methods, tools and general ways of working across the several team members tasked with testing. While trying to understand what was going on and how to connect to the team effort in the best way possible, this variation struck me as a Bad Thing. It prevented me from following the determined path and fitting in, it obstructed adherence to the standards and it didn't allow me to meet expectations by replicating what others did. All because there was not one way to do things.

So the manager in me did the thing managers do, which is to create structure where there is none. I lobbied with my colleagues for some standards in ways of working, for detailed documentation on methods and for a singular environment to the benefit of all, to get clarity, conformation and unity. Most agreed with me that for newer folks and transparency's sake, guidelines and standards would be a Good Thing.  There was one guy who pointed out the principle from the Agile Manifesto that says: "People and Products over Tools and Processes." as some sort of warning not to go overboard.

Somehow I ran into a wonderful 2014 blog post by Dave Thomas Time to Kill Agile in which he argues that the word Agile has been hijacked by consultants who have something to sell that is not software development and that will be more about their Tools and Processes than anything you want to achieve in the first place. Then the weekend started and I promised my fellow team members to think over the best way forward to reach the goal of uniformity and standards.

On Saturday evening (I know, I know), I send out the following email:

Hi All,

A few thoughts to begin with:

Individuals and Interactions over Processes and Tools
Working Software over Comprehensive Documentation
Customer Collaboration over Contract Negotiation, and
Responding to Change over Following a Plan

The above are the practices from the Agile Manifesto and we need it to keep things in perspective. From my background, I have a tendency to write everything down into minutiae and setting an approach that leaves little room for creativity and personal preferences from those who have to work with it. In earlier roles this was a boon, now it is a burden. I wish to apologize if I go back to what I know, the transition to real agility surprises me from time to time.

What the practices tell us is that basically every team member can work the way he likes the most, instead of tying things down and stifle creativity.

The difficulty starts when one is no longer operating in a vacuum, some things will have to be agreed upon and synchronized across the various members of this team. So my proposal is that we as the testers find some sort of common ground, agree on that and write it down in whatever wiki/forum/repo is best.

These are the topics I think we should agree upon:

·         How to deal with old tests and old code

·         What toolset is preferred (what fits the client as well as the team)

·         How to set up new tests

·         what is the definition of done

·         What quality standards should tests meet before we go to production

·         But mostly: how will we work together

Looking forward to have this conversation with you, afterwards I will put up the things we are willing to put down.

Thinking about the why of this made me realize that the deep core of the wish for standardization came from my own desire to have a benchmark to which I am measured. I want to do a Good Job so what are you guys doing, if I do that well, will you like me? And somehow, by trying to add value I was busy removing value in the form of creativity and freedom from people. It can be traced back to a long history of workplaces where freedom and creativity is shunned and conformity and standards are celebrated, as well as my personal need for approval, to do a good job.

The take away is of course that any person who complains about a lack of standards and guidelines in whatever software development team they join, are in the core people who want to do a good job and are uncertain on how to move forward OR are genuine in their desire to kill off freethinkers. The first group is easily helped out, the second only need to see your back as you walk out the door to a better place.