Thursday, July 30, 2015

Thank you Sir, for igniting our minds

Mr. Abdul Kalam Sir, is some one who taught India to dream big. He is the one who taught me to take pride in India. Due to centuries of colonization and exploitation, an average Indian who has not witnessed the elite state of India before colonization was programmed to believe that everything foreign is better. And that trend continued, and still continues in the form of certifications. If a person takes pains to gain knowledge and is smart enough to translate that knowledge as superior skills at work, do we need these foreign certifications, which are overly priced. If we get certified by leveraging the brain dumps, just to impress those abroad, does it really translate to better productivity?. There was a time when the Indian I.T firms could not qualify into the vendor lists of foreign agencies, without the CMM level 5. So, we wanted to comply with it at any cost, because business was at stake. To make hay while the sun shines, the assessment bodies went to the extent of having different pricing for the several capability maturity levels. It was as stupid as someone having variable pricing for blood sugar check, based on the sugar levels. They made their money, and we were very happy to pay them because business was at stake. To make this happen we hired the quality staff from manufacturing companies, or we used those who are already non-technical. They recommended the metrics from the manufacturing (operations) to projects, ignoring the fact that each project is unique, and must be treated uniquely. The core of all the borrowed stuff from manufacturing was standardization. Companies like Infosys, Wipro, Cognizant, HCL etc was driving the CMM initiative within India. When we standardize everything, what happens to Innovation?. Recently I came across a video of Mr. Narayanamurthy, co-founder of the Indian I.T giant Infosys, complaining about lack of innovation from the Indian technical community. It was a kind of a paradox. 



Now another transformation is happening in the Indian I.T community. More and more teams are getting into the product space. Many are start ups, and some project based organizations. Start ups are already lean, and all they need to take care of is to remain lean consciously. The bigger challenge is for those large project based organizations, moving towards the product space. They will have to shed their traditional project based ways of working to make faster releases with quality. This time, in the product space, there is no compulsion from anyone outside to comply to something. The compulsion is from within. Just because we have been doing things in a particular way do not make it the best way. The ability to question everything non value adding without any fear, and the organizational climate without the compliance raj is the basis for innovation. We must consciously break away from the traditional stuff and embrace the new, to be the leader in the product space. Else, we will miss the bus to product leadership. The sports and apps will have to move to those locations where there are subscribers, and that is to our advantage.  If Abdul Kalam Sir was bound by the compliance raj, he would not have carried the rocket on a bicycle to Sriharikotta to launch it, which marked the beginning of the space age for India.  Thank you Sir for igniting our minds. 

Friday, July 24, 2015

10 points for those who are transitioning from project to product environments

Here are 10 key points to help those who are transitioning from projects to products

1) In projects, we deliver to one client, where as products get delivered to a market segment.

2) Inorder to build great products, we need people of the highest technical capabilities, where as in projects, the technical capabilities of people may not be the highest. This difference is very clear when we compare product companies to project delivery organizations.

3) Product teams, very often have to deal with millions of lines of legacy code, if they are working in very large established products. In startups, the challenges are different.

4)  In project based organizations, very often the teams may be following waterfall model for software development, where as most of the product companies have either transitioned or transitioning to agile.

5) In waterfall models, the predominant managerial style is command and control, and at the same time the desired managerial style in product based organizations is that of a servant leader. Some product companies promote 'manager as a host' styles, where everyone else is trated as a guest, and the manager ensures that they are comfortable. A variant of servant leadership.

6) Since the quality of engineering talent is the best in product companies, it is absurd to tell tell them how to do things. Explain the scope of work, and give them the freedom to choose the best approach to accomplish it. It is a kind of leading from behind, whereas in project based organizations, the predominant style is leading from the front.

7) In product companies, the requirements evolve over a peiod of time. Requirements are allowed to grow. In project based organizations, the focus is on freezing the requirements.

8) In majority of the product based organizations, test automation is in a higly matured state. Without test automation it is very difficult to achieve the desired quality levels, especially with voluminous code base.

9) In project based organizations, it is very difficult to justify the investment on test automation, becuase projects are unique and very often sigle time assignments. The predominant testing style is manual testing.

10) In product teams, the manager is only as good as his team. In project based organizations, the managers tend to position them as better than the rest.

Monday, July 13, 2015

Kill the planned vs actual data tracking at the individual level

When we try to fit in agile project management in environments created for traditional project management, some of the metrics must be either modified or abandaoned. The first one is the planned Vs actual effort metrics, which is used to measure the productivity of the team / members. Here the inherrent assumption is estimates are right, and the actual effort must be within the planned effort. Agile estimation comes from the premises that all estimates are wrong, so do not spend too much time to have accurate estimates. Agile promotes some amount of risk taking while encouraging to start with abstract estimates which gets refined as the sprints advances. Team members are encouraged to revise the balance effort required to complete the task at hand, on a daily basis. By bringing in unwritten conventions like the actual effort must be within the planned effort, the risk taking, and the self organizing qualities of self organizing teams will be curtailed. Ability to revise the balance effort based on the actual hands on experience on the task is the hallmark of empowered, self organizing teams which thrives on work volunteering. If one has to get the agile teaming right, the planned vs actual data can be collected, for analysis puposes alone, and must not be used for performance evaluation of the team members. In one organization I worked, time accounting systems were in place, and the managers did not have access to the individuals data, they could see only aggregated data at the team level. If agile has to thrive, organizations must not use the planned Vs actual effort data for tracking individual team member performance as it contradicts with;

Promotion of abstract estimates in agile teams
Promotion of eight hour working days, for maintaining sustained productivity
Promotion of risk taking
Promotion of work volunteering of work, estimated by someone else
The basic forward looking nature of the agile models.

Will blog about the other metrics that needs correction in my subsequent posts.

Sunday, July 5, 2015

Meditation for the Agilist


Iam proud to be from a spiritual nation, which contributed yoga to the rest of the world. Unfortunately we  are not practising yoga. In fact I went for yoga classes a couple of decades back, and then on, it was more of a on and off business. I wish I could do it every day. The benefits are phenomenal,  yet it remains as an important and not urgent activity. I have not given up on that yet.
In the meanwhile I got interested in Osho's dynamic meditation which comprises of five stages and in its original form and takes around an hour to complete. I did not have the time or patience for that, so started doing it in twenty to thirty  minutes. At the end, Iam relaxed and positive. The search for information about Oshos dynamic meditation lead me to the videos of zen meditation, which can be practiced from anywhere. Ever since I came across zen meditation, waiting in a que is no more a problem for me. Whenever and wherever I get free time, I do zen. I wish if everyone could meditate at the end of the day and get rid of all that garbage accumulated during the day, and have a peaceful seven hour sleep before going for next day's work, the quality of work and life will be better. After all what is the essence of Agile. It is about throwing away everything which are not value adding, and then concentrating on those stuff that really matters.

Thanks to that unknown Indian software engineer who was sleeping at the breakfast table on a Monday morning, who triggered this blogpost. I must thank our prime minister also for his efforts to promote yoga.


Saturday, July 4, 2015

What is the best advantage of agile to the engineer?

If you have to highlight one best advantage of agile to the development team member, what is that?. That was a wonderful question that made me think for a while before answering. It is the freedom of the engineer to choose the work he/she wants to do.

In self organizing teams, there is nobody to allocate work, the team members have to choose it by themselves. That is a great opportunity for the engineer to liberate herself from the clutches of the positive or negative halos, perceptions formed in teams where work allocation exists based on the manager's judgment of the potential of team members.  Even for good managers, it takes a great deal of professionalism to give everyone equal opportunity to restart their career without any biases after the performance appraisals. People get perceived as performers and non performers, and this reflects in the work allocation and has a cascading effect.

Many traditional managers believe that excellence is linked to experience. They think that experienced people must handle complex work.  Excellence is never linked to experience. In a fast changing world, sometimes experience is a burden. In a society which thrives on Matha (Mother), Pitha (Father), Guru (Teacher), Boss Daivam (God); it takes a paradigm shift to thrash the myth that excellence is linked to experience. Agile provides the opportunity for people with potential to demonstrate their mettle to the rest of the world by grabbing these complex work and completing them successfully. In the agile world, stars are born in no time. It does not take years for a star to surface. Even a sprint/iteration can create champions. At least every sprint adds to the reputation of the contributor based on sheer performance. 

In teams where work is allocated by the boss, based on the perceived capabilities of the team members, the tendency to cast the members to specific types of work is higher. 'I know who can do this' is something we hear everyday in the corporate world. That is okay, if one does not reach the extent of  believing  that others in the team cannot do it. Take it from me, perceptions are very often very wrong. On day 1 of my agile workshops, I tend to form opinions about each participant based on their interaction, dressing etc. At the fag end of the training, I am terribly wrong. Participants surprises me, and that is the best positive kick I get out of my work as a coach. In fact I am waiting for these moments, and the agile way of working have amble opportunities for these kind of surprises, that keeps me moving forward professionally. Agile is the opportunity for people with potential. Since it is highly empirical, the room for error in judgment based on  perceptions is minimal. Grab it, dear engineer, else till you retire others will be telling you what to do and how to do it. Liberate yourself. Agile is the opportunity. 

Have a nice weekend. 

Wednesday, July 1, 2015

Infy Hyderabad

#cricket #mymobileclicks

A photo posted by Abrachan Pudussery (@abrachan) on


A staged approach to agility enhancement

Without a focused, time boxed road map for the agile implementation, the agile implementation may not provide the real strategic business advantage to the organization. Based on my experience with agile teams from various organizations, I have coined the agile maturity model for implementing agile within organizations. The only objective of this staged approach is to provide a road map for organizations to mature their agility in the right path.




Level - 0

An aspiring organization, which is very new to agile project management practices. Most of the work happens in an ad hoc manner, or are based on waterfall, CMM, ISO etc.

Level-1 (Agile project management partial)

General awareness on the right agile management methodology is imparted to some teams, and they have started implementing tailored agile in their respective teams. Mindset still remains waterfall. Definition of done is ready for testing. Testing teams still work in the independent testing mode. Work allocation and tracking happens as in the traditional project management teams. Still they get some benefits.

Level-2 (Agile project management fully implemented)

At this stage, all the key agile project management practices given below are implemented.
• Product backlog
• User stories and estimation using story points
• Estimation using poker
• Acceptance test cases are written and documented before the sprint
• Sprint planning
• Work volunteering
• Daily stand up meetings
• Tracking Sprint board and burn down charts
• Sprint review meetings
• Lessons learned exercises
• Velocity calculations
• Role clarities scrum master, product owner, team members
• Tool usage for multi-location collaboration

Level-3 (Agile engineering practices implemented, Scaled)

At this stage the core engineering practices given below are adopted;
• Adherence to coding standards
• Create the unit test first
• Pair programming
• Integrate code at a time
• Integrate often
• Acceptance test automation

Level -4 (Agile HR practice implemented)

• Alignment of the HR practices to the agile values like commitment, focus, openness, respect and courage.


My agile journey 

  • Designed and developed ‘Agile project management using Scrum’ program based on the Scrum guide and delivered the same for major multinational product companies as well as medium and small sized start ups.
  • Worked very closely with large and medium sized organizations to transition their teams from waterfall to agile.
    • At a healthcare product company we transitioned a team of around 100 professionals from waterfall to agile. I was in charge of the agile transition for their Bangalore and Chennai offices, reporting to their Global agile transition head. Was involved in strategy, training and on the job coaching.

    • At a telecom product multinational corporation, I was instrumental in transitioning a team of around 60 engineers from ad-hoc agile implementation to good agile. Was involved in training and on the job coaching.
    • Implemented agile project management and execution at a start up projects based organization, which has grown to a 400+ member organization subsequently.
    • Implemented agile project management and execution at another start up, which has grown to a 100+ member organization subsequently.
    • Implemented agile project management and execution for a team at another start up who are into data analytics.
    • Implemented agile project management and execution for another project mased team of a medium sized org.
    • Implemented agile project management and execution for another organization, a medium sized project based company

Delivered agile training to a large number of organizations, both large and small.

My Agile journey continues with my clients. If there are opportunities I am interested to associate with everyone who want to improve their agility. email abrachan@gmail.com