Interaction at CapitalVia

Recently while visiting Indore, India I got a chance to interact with IT team of CapitalVia. The experience was awesome. I was amazed with the enthusiasm of team and management in moving towards Agile way of working.

CapitalVia is a financial market research and consulting company which provides trading recommendations in equities, commodities & forex based on technical research. It is located in Indore, India. It has in house IT team of 30 dedicated, enthusiastic and collocated technical and business savvy people.

CapitalVia has organized its IT team into following roles

•  Product Owner ( although CampitalVia call them Business Analysts) – Three in number
• Technical Lead – Three in number
•  Developer – Twenty in number
•  QA – Three in number
•  Program Manager ( CapitalVia  defines as General Manager) – One in number

 

     CapitalVia is mostly PHP shop and customers for IT team are internal to organization which is focused more on functionality, ease of use, and adaptability of applications. IT team manages existing systems as well as develops new ones as requirements arise. There is no separate maintenance team; one who develops the application becomes responsible for its maintenance which encourages maintainability and bug free applications.

     

     After interaction with them I got privilege to recommend ScrumBan as basic operating model to start with. I hope team will experiment with recommendations.

The Agile Manifesto in English - 17

Principles

Agile principles are concretization of agile values.  Agile manifesto lists 12 principles. These principles are iterated in the form of assertive statements.

12.     At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Do I know everything? Do you know everything? I am sure answer is NO. Even for a small subject, hardly anyone can claim that he know it all. We are learning beings.  

In any dynamic environment, we commit mistakes and learn from it and next time tries to do it better. In reality we all do small experiments. Most of the experiments fail; we learn from them and get ready for next one.

The main thing is learning from the failures. To learn from failures, we need to reflect as individual and team.  This is an ongoing exercise of improving self, to become more effective and efficient over time period.

Learning from mistake is not only true for devTeam but of stakeholders as well.

But before doing experiment, we need to analyses and understand the probable blast radius of failure. The consequences of failure should be analyzed well. To keep the impact of failure small, we do smaller experiments. Organization should also provide the support the teams and individuals for failed experiments.

Also reflecting should be a learning endeavor not the find the punching bag exercise. 

In scrum, kanban, and devOps frameworks, this principle is reflected in following practices:

• Daily Standup
• Retrospect meeting

 

The Agile Manifesto in English - 16

Principles

Agile principles are concretization of agile values.  Agile manifesto lists 12 principles. These principles are iterated in the form of assertive statements.

11.     The best architectures, requirements, and designs emerge from self-organizing teams.

In traditional command and control hieratical management, boss knows the best and he know who can do what and when even how. But in agile way of working, those who would do the work are responsible for organizing the work as well how to do it.

This might be heresy for traditional management gurus but here you may have to consider few things in context to software development and maintenance:

• Software development & maintenance is mostly devoid of repetitive tasks. In most of the cases as soon some repetitive task is discovered, team automates it.
• In software development and maintenance interactions are mostly among individuals instead among machines and/or machines & human as in manufacturing and assembly line jobs.
• The general level of education of persons working in software industry is significantly higher than working in manufacturing and assembly line.
• Software development and maintenance  is in very nascent state of becoming engineering (if it can ever become!), it is still largely a craft
• Technologies underlying software development are changing very rapidly. 

Keeping these factors in consideration, it is observed that Taylorism does not work with software development and maintenance teams. Also do not forget that in Maslow’s Hierarchy of Needs software professionals are striving for top three. 

In “Drive – The Surprising Truth About What Motivates Us “Daniel Pink says that people are motivated by autonomy, mastery and purpose. In my experience, I find Pink is saying true and these factors are by product of any self-organizing team.

To create great software (so the different aspects of software like – architecture, design, and design), provide autonomy to software teams so it can self-organize.

A self-organizing team:

•  sets direction for itself;
• design performing units for its work;
• manages (allocation, reallocation, estimation, re-estimation, delivery, rework) and monitors its work;
• executes the work;
• sets its rules and norms to achieve goal;
• has feeling of ownership and commitment;
• is self-driven, pull out work for itself to meet goal;
• requires mentoring and coaching;
• asks lot of questions to understand not only requirements but to understand reasons;
• gives lot of suggestions;
• intra team communication is spread across formal and informal channels;
• continuously enhance skill set;
• has high level of trust among team members; and
• sticks together for long time.

In scrum, kanban, and devOps frameworks, this principle is reflected in following practices:

• Sprint backlog
• Retrospect meeting
• Estimation of work by devTeam
• Daily standup
• Visual information radiators