Three types of Value can be looked into in a scrum set-up- Business Value, Customer Value and User Value. Typically customer is the one who pays for the value or service and users are the ones who ultimately work on the software. In a general sense, Business value is treated as equal to revenue or profits. Users represent the end-users. Depending on whether who pays for it is the one who uses it, these 3 roles will differ.

In any Agile system development context, understanding how these three types of Value play out is critical to formulating it for the product / application at hand and translating it into PBIs for translating into working software.

This session will examine how these three types of Values play out in differing contexts with real-life examples.

A similar session was presented in 2018 APGI conference in Pune in May. This is an enhancement over the same with more real life examples and delving deep into Product development and internal application development contexts.

Objective of teams in agile is to deliver business value, under the guidance from the Product Owner. While what teams do is supposed to revolve around Business Value, do we know what it means?

This session, with practical contexts emanating from the presenter's professional experience will delve into defining / formulating business value, what it means in differing contexts, markets & industries. For instance, How would it look for a Fintech start-up or a Financial institution in B2B or a company building Core banking product.

Intent is not to prescribe or provide a singular definition of Business Value but to discuss and deliberate on the different dimensions and considerations. Often beyond cost of delay or Return on investment.

Implementing agile at scale is contextually different when compared to Agile at team level. In this session, I intend to delve into pre-requisites or underlying conditions needed for scaling - immaterial of the scaling methodology adopted. As they say, agile practices are not fractal, the principles are.

This session is based on the scaling experiences I have had as a practitioner and a coach in Product Development and Enterprise Application development set-ups in Utilities, Building Technologies, Enterprise security and Automotive domains.

Session will start with the context of Agile @ scale. Complexity in factors like platform, integration needs, domain complexity, departmental interactions all multiply manifold.

There are typical constraints which come into play when we scale. The typical patterns are:

- High degree of departmentalisation

The team for large programs is typically composed with people from the line department plus those from horizontal departments (like DB,testing, technology centers of excellence, tools, Configuration Management) etc., While such a composition (with people from horizontals) is to be generally expected in a large program, things may become a challenge if the team is largely staffed by those from support services. More so, if the departmental goals do not align with team goals & departmental processes do not align with agile team's processes.

Typical patterns seen are, code promotion policies can vary as per technology, departmental focus on specialization versus multi-skilling needs of agile teams, frequent shuffling of staff from horizontal teams, horizontals using ticket based systems (also are SLA based) to address requests.

- Inflexibility of existing development processes

Typical impediment seen is that milestone definition, project tracking metrics are waterfall based and largely rigid. This will affect project tracking and funding for large agile programs.

- Harmonization of technical infrastructure

Large programs are typically developed out of multiple locations. This requires that facilities to integrate the systems are in place. Typical challenges are seen where test set-ups do not communicate accross locations or there is a network or a tool limitation to access the set-up at remote locations.

It would pertinent to note that many of these factors also discussed in the context of Enterprise transformation as well.