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

How does the teams / management reacts if the planned velocity is not met 

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. 

#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:

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.

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

How does the teams / management reacts if the planned velocity is not met 

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. 

#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:

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.  

• 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.

• 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.

• 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

• 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.

• 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.

• 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

• 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.

• 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.

• 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

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.

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.