
Sridharan Vembu
Head Engineering
CreditMantri
location_on India
Member since 6 years
Sridharan Vembu
Specialises In (based on submitted proposals)
I'm working for CreditMantri a Fintech startup based out of Chennai. I head the product engineering team.
I were with ThoughtWorks for ~5 years and played the role of Client Partner in the India Market.
Prior to ThoughtWorks, I was with Infosys for around 11 years, handling multiple large to complex portfolios in Telecom, Manufacturing domains.
As a seasoned project manager, with over 11 years of focus on managing various portfolios and programs, I strongly believe that People Management is the central and core aspect of being a successful manager. And your success as a manager relies on choosing the right team, play to the teams' strength, attention to the team dynamics and handle them carefully, among other key dimensions.
-
keyboard_arrow_down
Velocity or No Velocity?
45 Mins
Talk
Advanced
The boundary between product development and solutions development is shrinking, in the context of agile development. When you adopt and practice agile in it's true sense, right from coming up with a roadmap, creating a release plan, breaking the release plan into iterations / periodic releases to how you actually run an iteration or a release - there is actually not much of a different between a product development team and a solutions development team.
On this premise, I've been part of few discussions questioning the relevance and purpose of "Velocity" especially the usage of it, in the context of product development vs solution development. These discussions prompted me to take a step back and ponder over the very concept of "Velocity":
Purpose of velocity
- How long it would take for the product / solution to be completed and derive associated cost
- Raw velocity exercise is a common technique used during release planning
- How much work (in terms of story points) can be planned in an iteration
- Important metric that’s used as a continuous improvement measurement at team level
- Evaluate performance of the team / individual (or dev pair)
What happens in reality
- Teams normally fall short of planned velocity across different iterations - they either extend the release timeline or get into scope negotiations and / or prioritisation
- When used as a tool to evaluate performance, it’s normally used in negative connotation and teams tend to compromise quality or functionality to meet the planned velocity
How does the teams / management reacts if the planned velocity is not met
- Retrospectives and management meetings to discuss at length
- why team couldn’t achieve planned velocity
- how to improve velocity
- teams / individuals indulge in blame game, tries to find scape goats, how to protect one’s own interests in front of management and in effect it gets into a downward spiral and agile gets blamed in the end
Can we successfully manage a product / solution delivery without worrying about velocity?
#1: Self organised teams are expected deliver to its full potential every iteration; the collective output at the end of each iteration is the best the PO can get, without having the need to track the velocity.
- And it would only get better with time, given the team members stay longer and gain more in depth knowledge of the domain / product / solution
- Over time, the entire ecosystem of the project team, Product Owner and the management would work in tandem
#1.a: If the PO comes up with a minor change mid-iteration or a major change mid-release, he/she must provide the following critical inputs:
- business imperatives of the change
- critical business value that will be delivered by this new / change request (or lost opportunity by not picking up this change request)
- is there any major business impact due to change in release timeline
- finally, what other feature can be traded off or delayed, if timeline is a constraint
In this scenario, velocity really becomes secondary (please note: not necessarily irrelevant or insignificant) as it’s the business that’s really influencing the decision.
#2: On the contrary, a. if the team is in early stages of agile adoption and / or if the agile adoption is not by choice but by an organisational mandate OR b. agile adoption is by choice, but only in parts of the entire ecosystem, velocity becomes one of the important metrics to track and act upon.
In this talk, I plan to cover a. how to unlearn the wrong interpretations and usages of 'velocity' and make them understand and appreciate the right implementation of velocity through couple of examples.
- How long it would take for the product / solution to be completed and derive associated cost
-
keyboard_arrow_down
Velocity or No Velocity?
90 Mins
Workshop
Advanced
The boundary between product development and solutions development is shrinking, in the context of agile development. When you adopt and practice agile in it's true sense, right from coming up with a roadmap, creating a release plan, breaking the release plan into iterations / periodic releases to how you actually run an iteration or a release - there is actually not much of a different between a product development team and a solutions development team.
On this premise, I've been part of few discussions questioning the relevance and purpose of "Velocity" especially the usage of it, in the context of product development vs solution development. These discussions prompted me to take a step back and ponder over the very concept of "Velocity":
Purpose of velocity
- How long it would take for the product / solution to be completed and derive associated cost
- Raw velocity exercise is a common technique used during release planning
- How much work (in terms of story points) can be planned in an iteration
- Important metric that’s used as a continuous improvement measurement at team level
- Evaluate performance of the team / individual (or dev pair)
What happens in reality
- Teams normally fall short of planned velocity across different iterations - they either extend the release timeline or get into scope negotiations and / or prioritisation
- When used as a tool to evaluate performance, it’s normally used in negative connotation and teams tend to compromise quality or functionality to meet the planned velocity
How does the teams / management reacts if the planned velocity is not met
- Retrospectives and management meetings to discuss at length
- why team couldn’t achieve planned velocity
- how to improve velocity
- teams / individuals indulge in blame game, tries to find scape goats, how to protect one’s own interests in front of management and in effect it gets into a downward spiral and agile gets blamed in the end
Can we successfully manage a product / solution delivery without worrying about velocity?
#1: Self organised teams are expected deliver to its full potential every iteration; the collective output at the end of each iteration is the best the PO can get, without having the need to track the velocity.
- And it would only get better with time, given the team members stay longer and gain more in depth knowledge of the domain / product / solution
- Over time, the entire ecosystem of the project team, Product Owner and the management would work in tandem
#1.a: If the PO comes up with a minor change mid-iteration or a major change mid-release, he/she must provide the following critical inputs:
- business imperatives of the change
- critical business value that will be delivered by this new / change request (or lost opportunity by not picking up this change request)
- is there any major business impact due to change in release timeline
- finally, what other feature can be traded off or delayed, if timeline is a constraint
In this scenario, velocity really becomes secondary (please note: not necessarily irrelevant or insignificant) as it’s the business that’s really influencing the decision.
#2: On the contrary, a. if the team is in early stages of agile adoption and / or if the agile adoption is not by choice but by an organisational mandate OR b. agile adoption is by choice, but only in parts of the entire ecosystem, velocity becomes one of the important metrics to track and act upon.
The objective of this workshop is to make the participants first unlearn the wrong interpretations and usages of 'velocity' and make them understand and appreciate the right implementation of velocity through couple of group exercises.
- How long it would take for the product / solution to be completed and derive associated cost
-
keyboard_arrow_down
Over-selling the "Enterprise Agile Frameworks and Certifications"
45 Mins
Talk
Intermediate
Agile is only for smaller projects and/or startup organisations - Not Anymore. Taking my own and my organisation's experience, Agile is a proven methodology that is well suited for delivering complex, distributed, multi-year enterprise programs, for many years now.While this is really a great thing for agile enthusiasts and practitioners, it’s a bit of worrying sign for me the increased recognition and popularity the ‘Agile Certifications’ and ‘Agile Frameworks’ are receiving among individuals and organisations who would like to adopt Agile to stay relevant in current world.I would like to share my views on the adoption of these frameworks and certifications, why I feel they are not-so-agile and how am I and my organisation are solving similar problems without the need for any of these frameworks and certifications.I am planning to walk through the complete life cycle of the most recent program that I’m part of (from Inception to Initiation to on-going Execution to Post-Production Support) and bring out the relevant agile principles that we adopted, context based customizations we did and the best practices that we have come up with.- For instance, one should know the clear difference between hygienic practices vs context based practices - the first ones are not to be compromised at any cost, whereas the latter ones are to be applied based on the need, not because some framework prescribes it.
The typical life cycle stages that we follow in any program / project delivery is normally: Discovery - Inception - Initiation - Execution - Transition, whereas the actual set of practices within any of these stages and how they are being implemented could be very different from project to project, team to team.- For example, in the Execution Phase, doing pair programming and following TDD are hygienic practices for us. Having said that, it’s perfectly okay for a pair to split and work on a specific task on a case-to-case basis (we call this Pragmatic Programming) and the pair decides when and how long they would split and when to re-join.
To give an idea on the complexity, enterprise and distributed nature of the program, some key data points:- Started almost 3 years ago, on-going
- 10 quarterly planning workshops done so far
- 10+ teams, 7 timezones
- peak program size: 250+
- peak team size from my org.: 50+
- total no of systems: 10+
- geographical spread: plan: 100 countries, 132 locales launched so far: 53 countries, 56 locales
- 140 page-views / sec
- Av. response time: 1.3s
- Handling 100+K products in the catalog, 15+ K pages , 300+ K responsive images
- Blue-Green production deployment (zero downtime over 1.5 years)
- 3 weeks cycle of production releases
-
keyboard_arrow_down
Over-selling the "Enterprise Agile Frameworks and Certifications"
45 Mins
Talk
Intermediate
Agile is only for smaller projects and/or startup organisations - Not Anymore. Taking my own and my organisation's experience, Agile is a proven methodology that is well suited for delivering complex, distributed, multi-year enterprise programs, for many years now.While this is really a great thing for agile enthusiasts and practitioners, it’s a bit of worrying sign for me the increased recognition and popularity the ‘Agile Certifications’ and ‘Agile Frameworks’ are receiving among individuals and organisations who would like to adopt Agile to stay relevant in current world.I would like to share my views on the adoption of these frameworks and certifications, why I feel they are not-so-agile and how am I and my organisation are solving similar problems without the need for any of these frameworks and certifications.I am planning to walk through the complete life cycle of the most recent program that I’m part of (from Inception to Initiation to on-going Execution to Post-Production Support) and bring out the relevant agile principles that we adopted, context based customizations we did and the best practices that we have come up with.- For instance, one should know the clear difference between hygienic practices vs context based practices - the first ones are not to be compromised at any cost, whereas the latter ones are to be applied based on the need, not because some framework prescribes it.
The typical life cycle stages that we follow in any program / project delivery is normally: Discovery - Inception - Initiation - Execution - Transition, whereas the actual set of practices within any of these stages and how they are being implemented could be very different from project to project, team to team.- For example, in the Execution Phase, doing pair programming and following TDD are hygienic practices for us. Having said that, it’s perfectly okay for a pair to split and work on a specific task on a case-to-case basis (we call this Pragmatic Programming) and the pair decides when and how long they would split and when to re-join.
To give an idea on the complexity, enterprise and distributed nature of the program, some key data points:- Started almost 3 years ago, on-going
- 10 quarterly planning workshops done so far
- 10+ teams, 7 timezones
- peak program size: 250+
- peak team size from my org.: 50+
- total no of systems: 10+
- geographical spread: plan: 100 countries, 132 locales launched so far: 53 countries, 56 locales
- 140 page-views / sec
- Av. response time: 1.3s
- Handling 100+K products in the catalog, 15+ K pages , 300+ K responsive images
- Blue-Green production deployment (zero downtime over 1.5 years)
- 3 weeks cycle of production releases
-
keyboard_arrow_down
Over-selling the "Enterprise Agile Frameworks and Certifications"
45 Mins
Talk
Intermediate
Agile is only for smaller projects and/or startup organisations - Not Anymore. Taking my own and my organisation's experience, Agile is a proven methodology that is well suited for delivering complex, distributed, multi-year enterprise programs, for many years now.While this is really a great thing for agile enthusiasts and practitioners, it’s a bit of worrying sign for me the increased recognition and popularity the ‘Agile Certifications’ and ‘Agile Frameworks’ are receiving among individuals and organisations who would like to adopt Agile to stay relevant in current world.I would like to share my views on the adoption of these frameworks and certifications, why I feel they are not-so-agile and how am I and my organisation are solving similar problems without the need for any of these frameworks and certifications.I am planning to walk through the complete life cycle of the most recent program that I’m part of (from Inception to Initiation to on-going Execution to Post-Production Support) and bring out the relevant agile principles that we adopted, context based customizations we did and the best practices that we have come up with.- For instance, one should know the clear difference between hygienic practices vs context based practices - the first ones are not to be compromised at any cost, whereas the latter ones are to be applied based on the need, not because some framework prescribes it.
The typical life cycle stages that we follow in any program / project delivery is normally: Discovery - Inception - Initiation - Execution - Transition, whereas the actual set of practices within any of these stages and how they are being implemented could be very different from project to project, team to team.- For example, in the Execution Phase, doing pair programming and following TDD are hygienic practices for us. Having said that, it’s perfectly okay for a pair to split and work on a specific task on a case-to-case basis (we call this Pragmatic Programming) and the pair decides when and how long they would split and when to re-join.
To give an idea on the complexity, enterprise and distributed nature of the program, some key data points:- Started almost 3 years ago, on-going
- 10 quarterly planning workshops done so far
- 10+ teams, 7 timezones
- peak program size: 250+
- peak team size from my org.: 50+
- total no of systems: 10+
- geographical spread: plan: 100 countries, 132 locales launched so far: 53 countries, 56 locales
- 140 page-views / sec
- Av. response time: 1.3s
- Handling 100+K products in the catalog, 15+ K pages , 300+ K responsive images
- Blue-Green production deployment (zero downtime over 1.5 years)
- 3 weeks cycle of production releases
-
keyboard_arrow_down
Relevance of the '12 principles' through project lifecycle - A Practitioner's View
45 Mins
Case Study
Intermediate
This talk is about taking a closer look at how one or more of the 12 principles behind Agile Manifesto are closely connected to the different stages of the project lifecycle and how they impact the right choice of practices and tools at each stage.
Few sample scenarios:
1. Major change in the way iteration planning was done - common backlog for the platform (comprising of different application teams), think each 'iteration' as a 'release' - deployment of business features to production end of each iteration - resulted in greater collaboration, no separate integration/stabilization phase towards major commercial launch
Relevant Principle: Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale
2. Reflecting on team organization - one large team (or) multiple smaller teams and / or feature teams, concepts like Mountaineers-Divers, Navigators-Drivers -> effective and easy context sharing, no stepping-into-each-others-shoes, efficient balance between big picture view and attention to details and such.
Relevant Principle: At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly
3. Feature kick-offs, analysis volleyballs, need basis Dev/QA/BA huddles, vide calls with distributed teams, subject-specific-google-hangouts -> Effective communication and fewer email conversations
Relevant Principle: The most efficient and effective method of conveying information to and within a development team is face-to-face conversation
Experience clearly suggests that following the right principle at the right time for a specific situation ensures successful outcome, while ignoring one or many of these principles often results in failure.
4. Adverse effects of measuring the delivery team's efficiency of the team one-dimensionally based on the Story Points delivered
Relevant Principle: Working software is the primary measure of progress.
In this talk, through specific practical examples, I would be explaining
- identifying the right principles for each life cycle stage of the project/program
- deriving the right practices based on the principles and following them effectively to deliver value to customer
- business and delivery constraints that prevented us from adhering to some of these principles, resulting in not-so-desired outcomes
In summary, I would like to emphasis the importance and relevance of the 12 Agile Software Principles behind Agile Manifesto in everyday life of a Agile Practitioner.
-
keyboard_arrow_down
Turning around a twice-failed distributed enterprise program into success
45 Mins
Experience Report
Intermediate
The common myth about agile methodology is, it is suited for smaller, co-located teams, would not scale up for big enterprises and is best suited for smaller, less complex programs.
In this talk, I intend to share how we went about setting up, executing and successfully delivering probably one of the most complex and strategic programs for one of our customers. This program was the first ever successful adoption of the fully distributed agile implementations for the customer.
Context: The client is the leading Telecom Operator in the UK, having their captive and other strategic partners based out of India. The program was highly strategic for the client and the predicted ROI was high.
- The implementation was tried twice by different vendors for more than an year, but failed to deliver; root causes were not analyzed
- The Program Sponsor had one last chance to try and deliver the platform successfully, against a very tight schedule
- Continued Operational risk with the legacy system in place
Outcome of our engagement:
- Core functional application ready in pre-production by the end of first release cycle (4 months from engagement start); fully ready to functionally scale easily and quickly
- Adoption of the technical and execution approach to other related programs within the portfolio
Our Approach:
- Outcome of initial assessment of the existing codebase was to go with re-write from scratch; was a really hard sell, but was the RIGHT thing to do
- Re-define the release cycle: extend development period by embedding integration testing as part of development cycle and cut down on the low level design phase
- Need-basis colocation of functional SMEs with development team
- Direct access to Product Owners: weekly video calls, must-attend iteration show-cases, etc
- Remove unnecessary operational overheads, in terms of people as well as organizational processes
- Well-defined, pragmatic strategy for Integration testing (major constraints - lead time for test data preparation, limitation in re-usability of test data, lack of e2e functional understanding within team)
- Smart seeding of other vendor team members (with good functional/domain understanding) into the core team
- Zero compromise on basic hygienic practices: IPMs, Showcases, communicate negative-news-first with alternate solutions/workarounds, strict removal of wastes, inclusive decision making, highest degree of code coverage, sanity test suite, e2e basic automation suite
- Building trust between distributed teams: cross-pairing, align on core work hours across time zones, joint showcases and retrospectives (shared responsibility)
Challenges faced:
- Big push to release the core functional platform into production in 3 months (immediate next release)
- Working out of other vendor premises: seen as threat to their business, lack of cooperation and collaboration
- Product Owners based out of UK, no easy / frequent access
- Functional SMEs/designers based out of different location
- Release cycle that was in place: 8 weeks of design, 4 weeks of development and 8 weeks of testing!
- Distributed and isolated testing teams
- Highly manual and time-consuming E2E testing processes
- Multiple interfacing systems, both upstream and downstream
- Client development team based out of UK, different execution approach, lack of trust between the teams
In summary, I would like to share the unique aspects of the execution approach that made this program a real success for the customer, though some of the approaches might be tried out in different environments and project situations.
-
No more submissions exist.
-
No more submissions exist.