Role of Agile in Building New Products in Companies

 The need for Agility while building new products cannot be overstated. Positioning the product with laser focus for a specific segment with the right business model goes hand-in-hand with the flexibility to change direction or pivot when needed. However, agility goes far more deeper than just product focus. In order to fully understand the customer, question our assumptions, define and target the ever shifting and evolving market needs, product teams have to be truly agile as well. Before we understand why Agile is important we have to understand why the traditional control & command structure put companies at a disadvantage for creating disruptive technology products or Business Models

Let us look at some characteristics of a company. What is company? A product or service that has reached market-fit and is well in growth stage. This means that it has a steady stream of customers or clients. In order to continuously serve and achieve quality there are predefined processes starting with hiring, creating teams, to executing projects. Processes and hierarchies serve to reinforce the established way of doing things. There is not a lot of room for experimentation and change since there is a fear that it can affect the quality and impact company reputation. The organization is built around obeying rules and doing ones job since it creates a constant output similar to a factory. Hiring is done for this culture fit – Obeying and mostly not questioning. Highest paid person tells the next person who in turn cascades it down the chain. Everyone gets paid for doing just their role and everyone is looking forward for Friday, well.....actually Thursday.

Creating a rigid assembly line of personnel and process for projects and expecting to to miraculously adapt itself to fearlessly think and solve complex product challenges is futile. It doesn’t matter if the leadership is open-minded and encourages everyone to embrace Agile and contribute since the original purpose was something else.

So what are those important characteristics of a new product that are the Achilles heel for most companies?

Speed and Thoroughness

Any one involved in Product Development is well aware that launching a market-fit product or feature is truly a challenge. The process has to be fast as well as thorough. Because, the sooner we know there is no market for our product or feature the quicker we can shift to building something more valuable. This means that the overall process from making decisions to building and validating the product have to be quick. With decisions stacked at the top, every time there is a challenge with the team that may affect scope, cost and schedule the decision has to go through the leadership. With their limited time, the decision analysis and the problem context have to be conveyed as accurately as possible. Not only can it delay the product building process and lead to incorrect decision making it can also result in teams waiting unnecessarily with the potential to lose focus as well as trust in the decision making process itself.

How Agile Solves this –

• Trusting individuals to take the right decision
• Collective Ownership of the Product
• Sustainable development with a constant pace

With teams fully responsible for making their own decisions in order to move forward there is no waiting for leadership to make each and every decision. Only the big decisions can be reserved for them such as Pivots, Strategy changes and others. This doesn’t mean that the decision analysis isn’t rigorous. It only means that decision making is honed at the team level collectively rather than with a single leader. When ownership is on the team there is a sense of passion about making sure that the Product is successful for every individual rather than the Project Manager creating the momentum to move the work forward. This naturally creates a sustainable software delivery cycle with a constant indefinite pace since there is no waiting. However, this requires a great amount of trust in the calibre of the team individuals i.e. they are committed to building a successful product rather than just getting the job done. This is where creating the right culture, hiring for it’s fit and ensuring it’s continuity are the key.

Selecting the Right Idea

Let us face it. Building and maintaining a quality software product is a very tough job. With pipelines of features and ideas that one would like to push to the customer along with an intuitive user experience development teams have to deliver big. However, the best ideas are not the ones that come from top executives but rather those that are well-debated for their business value to a specific customer. Hierarchy creates a natural barrier to bringing out well researched, thoroughly evaluated and refined ideas. When leadership is entrusted with decisions while product teams are relegated to development it becomes normal for decision-makers to vouch for pet projects without true business value. Moreover, with resources at their disposal, unlike a startup and less accountability, there is lot of room for influencing and propagating ones own wishes and vested interests while shielding them from scrutiny and keeping other alternative opinions/views at bay. Additionally, every fanciful thought becomes an indispensable feature that should be implemented. Even with the best of the intentions this may happen inadvertently or behind the scenes.

How Agile solves this –

1. Highest priority is for customer through early and continuous release of software in short timescale
2. Working software is the primary measure of progress
3. Simplicity and the art of maximizing the work not done.
4. Welcoming change late in the requirements

In the most popular framework for Agile called Scrum there are only 3 roles – Products Owner, Development Team and Scrum Master with the last role only aiding in understanding and implementing the rules of scrum. In fact there are only two power camps to develop a product but even they do not have an absolute authority over each other. The Product Owner (PO) has to prioritize the list of features judiciously aiming to deliver highest value first to customer. The development team has the choice to implement the way they seem fit. If the PO is not satisfied the development team can propose other options that are feasible but the PO cannot force development team in a particular manner. If the PO chooses big fanciful ideas they will take too long to implement and will be against Agile Principles. Since release iterations have to be short it will result in faster feedback for any short fanciful ideas which will clearly lose out among customer without real business value. Similarly by consciously maximizing the work not done (rather than work being done) a rigorous prioritization occurs. In fact it will assist teams to effectively think in order to optimize for delivery rather than deliver first and then try to optimize.

Creating and maintaining a competitive product is a tough job. Not only should the building process encourage lots of thoughts or ideas but also include rigour, verification and questioning to determine those ideas are worthy of being developed. Unless ideas and thoughts are thoroughly substantiated with Data for business value and vetted by the team they shouldn’t be allowed into a product. In one of the most popular moonshot project factories “Google X” 7 out of 10 ideas are rejected in the first stage with only 1% of all ideas reaching implementation. This automatically ensures the survival of the most robust and fittest ideas for delivery.

Building the Right Team

Incubation and launch of new Products is a marathon. Starting with Market Research, Identifying the Customer Segments and Personas, Understanding the current Products and Business Models, Creating realistic Business strategies and Target Metrics, Envisioning the Product and the Roadmap, Assembling the right teams from Development to Marketing, Consciously ensuring the right culture is no easy task. There are lot of focus areas as in wrote in the other post – Product Building by Companies. And most importantly, it requires everyone to work with passion just like a sports team, which is much easier said than done.

In the traditional company structure not only does the leadership team work intermittently with development but it is common for multiple teams to be working on multiple projects in order to maximize for productivity. Hence a deep chemistry is never formed between all the individuals that work on a product. Especially with Products where focus and scope can shift rapidly and multiple decisions can be made in short span distributed teams can easily lose context and rationale. This naturally leads to a mismatch in understanding and expectations which in turn deteriorates trust. I was often witness to one team being frustrated with another simply due to the lack of involvement and empathy because at that given moment one team was more closely involved in the product/project than the other team. In fact teams became reluctant to communicate with each other simply because they never saw each other even in the same office or when working remote in spite of having laptops/smartphones with HD cameras. When team collaborated there would be lot of tension and anxiety since the expectations about each other were always unclear. It would clearly manifest on the Product.

How Agile solves this –

1. Business people and development team must work together daily
2. Preference for Face to face communication
3. Better products come from self-organizing teams
4. Teams work at regular intervals on how to become more effective and adapt accordingly

Putting together the right mix of self-organizing, self-critical, cross-functional teams that closely work together and have a genuine empathy for each other and the customer is an extremely crucial aspect. Facebook organizes teams such that they are co-located minimizing to work across different locations or timezone even for shorter duration. This is probably the most challenging aspect for companies since resources are optimized for Projects and budgets rather than solving Product challenges. Working face to face builds an atmosphere of trust and friendship as well as an interest to actively collaborate. When individuals work together without inhibitions and anxiety it naturally leads to passion and a fearless questioning attitude. This is where creating the right nucleus of individuals and the supporting project framework is critical to product success. One cannot bring a mule and expect it to work like a horse. Similarly, an individual needs to be hired for an Agile culture fit, experience and passion.

One of the simplest ways to jeopardize a Product team is to include a senior leader on the team that can quickly establish hierarchy and infuse fear while destabilizing the trust. Since the command and control structure is efficient for doing routine work without much questioning it cannot be a natural fit to an Agile Culture. Hence, companies either operate separate work locations called Labs where Agile teams are created independent of the regular workforce which focuses on serving established product/service lines. Also, they invest and acquire startups instead of building these Product Teams within the regular workforce which can be a huge anti-fit to their existing culture and purpose.

Conclusion

No wonder the best products come from Startups and Product Companies that have software development life cycles built to solve problems and challenges over completing projects. In addition to big tech companies there are lot of Development & Design Studios which have ensured Agility from the beginning or have actively incorporated Agile principles to build amazing products.

Lean UI/UX, Faster software release cycles, Collaboration focused Work Spaces and Communication Tools, Devops, Test Automation and Living Documentation are some of the popular solutions being adopted by companies at a rapid pace to foster Agility. However, I believe that at every stage, as one of the Agile principles advocates, teams need to regularly introspect to understand if these solutions have truly brought in Agility or whether it is something else – perhaps a mindset change, that is hampering building a successful Product.