Transitioning Product teams to agile – Key considerations

How do we enable the product team for agile product development and delivery?

 Let us first understand the links between a engineers and customers

Coder -Product Manager-Tester-IT Infrastructure-Project Manager-(execs)-Marketing-Sales-Sales Engineers-Account Managers-Product Technical Support- Customers

To enable continuous and incremental software delivery we have to navigate the above chain with maximum efficiency. (i.e. quickly and easily)

In this post I will focus on the product team (product managers and engineers). Given below are the key considerations for maximizing efficiency in delivering continuous product releases.


Engineering Team
Product delivery methodologies and tools do not deliver products; Software engineers do. The technical team needs to have the the correct composition of technical leadership, technology skills and maturity to deliver successful product releases to customer requirements and system (performance & scale) requirements, in effectively crafted product increments.
Lack of technical leadership will result in complete failure of product or releases, irrespective of the product delivery methodology of the organization.
If majority of members in the engineering team have never previously worked on software products with the level of complexity (user experience or architecture or performance & scale) expected in the product to be worked upon, it points to lack of experience and maturity in the engineering team. The engineering team might also lack experience or awareness to lean and agile engineering or collaboration practices or tools. This can result in delayed product releases through over engineering of solutions or initial optimistic commitments in a product release or inefficient collaboration and decision making during release execution.
The ability of an Organization's leadership team to effectively set-up the right engineering team is the most critical factor for the success or failure of product delivery.


Product architecture
Product architectures needs to be adequately modular to enable automated software updates to production deployments. The goal is to ensure the highest uptime for the product and a hassle free product update and maintenance experience for customers.
In the case of pure SAAS products, the organization owns and maintains product deployment in its own data centres or through PAAS providers like Amazon Web services, Rackspace or Microsoft Azure. This fact makes it relatively easier to update product production deployments with no intervention from customers.
In the case of products that either exclusively deploy in customer environments or partly deploy component in customer environments, the components deploying in customer environments have to have the architecture and capability to be able to download and deploy product updates with minimal down time and ensure minimal intervention from customers i.e. Minimize or avoid expensive product resets or restarts and consequent change management process workflows in customer environments.


Customer engagement
Engineering team have to be in a position to engage customers to get direct customer feedback on functionality being built in the product at regular intervals.

• The product team has to select a right sized and representative customer sample set to get maximum validation of product functionality being built, before the newer functionality in the product is available to all customers.
• Customers have to be able to use the product functionality being built and give concrete feedback based on their experience, at the earliest possible point in the product release cycle.
• The product has to capture the right amount of information to effectively understanding customer behaviour patterns from the customers use of the product.
• Product components deployed in customer environments and interacting with the customer environments are in a position to gather valuable information on customer environments to enable software engineers to effectively understand IT environment characteristics across customers.

Continuous Integration (CI) engineering systems
Product engineering teams have to have continuous integration engineering systems in place for continuous development, testing and delivery;

Code review tools, continuous build integration, unit testing & integration testing, software security testing, test automation, test environments, staging (production replica) environments.

The goal is to minimize the time cycle between the point at which new code is added to the point at which the new code is published to be deployed in production environments to deliver net new value to customers. As an important consideration, automation in engineering systems has to ensure that, on a day to day basis, engineers spend maximum time in writing or debugging code (creating value), and minimal time on all other activities like building, packaging, test deployments, regression tests etc.

Process & collaboration mechanisms
Information, actions and decisions have to flow effectively between every department or function involved in the value chain between the coder and customers.
Within the product team (Product Owner, and Engineering team), effective collaboration could involve daily stand-up meetings, tools for capturing arising issues (impediments), technical decisions, risks, unanticipated work items, as well as sequence diagrams,whiteboard diagrams, test results etc. that precisely convey the right state of the feature/product as implemented in an iteration on a daily basis.


Project management tools
Agile tools for tracking project scope (product backlog), iterations (sprints), regular progress on features & sub features (user stories), work that could not complete in an iteration (spillovers), in a manner highly visible and transparent to project stakeholders.


Its very typical for Organizations adopting agile to first adopt agile collaboration practices, or project management tools in isolation, to claim success at adopting agile product delivery. As a first step such an Organization would first request development managers, testing managers or project managers to undergo agile or scrum master trainings, define a new process around agile collaboration mechanisms, perhaps invite an agile coach as a consultant, and quickly get to adopting agile in the next release. This is a classic top down or management driven approach that adds tremendous burden on engineers. They have to continue with existing engineering practices, or product architectures or customer engagement practices, and now have to additionally take on additional complexity of a new process, take responsibility to be self organizing and share updates on their progress through the newer tools etc.


Agile speaks of the need for the engineering team to be self organizing. This very principle requires the organization to, as a first step, empower the engineers and technical leaders and involve them and ideally have them decide the best path to moving to an agile product delivery model. This might in-turn require bringing in upfront training to engineers on agile product delivery model to have them understand the benefits and implications of agile. This is the true agile and empowered approach to adopting agile in an engineering organization.