Monday, December 1, 2014

Process for Art vs. Commodity

I am thinking a lot about process of late. People talk about Scrum, Kanban , XP blah blah. We all agree that none of the process is perfect to solve all your problem. Mostly everybody talk about organization culture, context and business problem influences your process model.

I am not denying about their importance but I strongly believe there is one more factor which is equally important if not more.

Your engineering team. How team feels about writing code? do they feel it as form of art ( I know it's very subjective) or as bunch of functions to complete a business objective? We all write software for business, government or other institution and we know customer only cares about FUNCTIONS.

Question is WHAT YOUR TEAM CARES ABOUT? How they feel about code? Understanding them and their need will be base of any process you put around them.

To my experience if you have a team which treats code as commodity would be happy, following any well define process. Whereas passionate people, who would like to be creative, would prefer little unstructured but responsible system.

May be their own customized personalized Kanban or LeanBan or ScrumBan. First understand the team and then define the process which fits their developer personality.

In my organization one team was very reluctant following any process so we tailored Scrum to their need.

I explained them what Scrum or Kanban or Drum Rope etc process have to offer us. Advantages and disadvantaged of each of them. Then we discussed our issues which we have presently and things my team is good at.

We all agreed that we need something which will let us keep our goodness and will fix our short comings . We designed our own process and my team is loving the process around their need vs. making them process slaves.

I know, I will upset few scrum gurus but my team is happy. To me this is bring agility to process.


No comments:

Post a Comment