Thursday, July 30, 2015
Friday, July 24, 2015
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
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
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.
Saturday, July 4, 2015
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.
Have a nice weekend.
Thursday, July 2, 2015
Wednesday, July 1, 2015
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