The agile company

I'm writing a series of articles on company culture and how it can affect the quality of your product and service. Checkout my previous articles on company culture:

• Don't waste time looking for culprits
• War
• The fallacy of the internal customer
• Air, food and profit
• Open-book management
• Clóvis Bojikian, former Semco's HR director, on how to implement organizational democracy

Here's the 7th article of this series. This article was originally posted in May/2011.

What does it mean to be agile?

Being agile means being able to respond adequately to changes.

Why is it important to respond adequately to changes?

Because the environment we live in changes all time and it has been changing faster over the years. If we don’t respond adequately to those changes we may end up doing things inadequately, i.e., things that won’t get us to our objectives.

Agile software development

The agile software development provides some suggestions on how to respond adequately to changes in a software development project. The main idea is to deliver software frequently so we get feedback on what is being delivered and adapt accordingly. In agile software management, adequate response to changes are possible due to:

1. frequent delivery of value to customers
2. feedback on what is being delivered
3. adapting accordingly

As a consequence, from agile software development derived:

• continuous delivery which means the frequent delivery of software in production so we can have feedback as early as possible.
• feature teams which means collocating on the same team everybody needed to develop and deliver the system, including software developers, QAs, BAs, product managers, sysadmins, interface developers, interface designers, interactions designers, customer support, etc.
• agile product management practices which come in many different flavors, including product discovery, customer discovery, customer development, inception, sprint 0, business model generation, etc. I’ll probably write a separate post on this topic.

However, all of this seems to be limited to the IT world, more specifically to the software design, development and operations groups. The problem with this limitation is that even though those groups are agile, i.e., are able to respond adequately to changes, the rest of the company may not be as able as those groups.

Different cycles in different groups

On a company level we normally have big annual – or even multi-annual – cycles of planning and forecasting. Those cycles are normally very painful. Jim Highsmith wrote an interesting post on the many cycles companies pass through and how they tend to be not synchronized. At the end of the article, Jim suggests that:

When companies get serious about Enterprise Agility, one area that will require major change is moving from financial cycles being the driver to focus on a product-driven (deliverables) “Short-horizon” model (that does deliver the required financial information but is not driven by that financial cycles) that is more adaptable to changing conditions.

Another suggestion for companies interested in Enterprise Agility is moving the planning and forecast process to a more agile fashion such as the “rolling forecasts”. The idea is quite simple. Instead of going through the budget process every year and make it a huge yearly event, we should review and adjust our budget every month or quarter, continuously planning and budgeting “the next 12-18 months to reflect real time changes in planning assumptions, both outside (competition and economy) and inside the company. Rolling forecasts make the budget process more agile, relevant, and useful. Rolling forecasts get managers more focused on the future and less on the past. The more practice people have with forecasting and planning the better they become.”

Agile means continuous improvement

Being able to respond adequately to changes means that we need to continuously improve the way we do things based on the feedback we gather. Even though the Agile Manifesto is 10 years old, the agile ideas has been around for longer than that. The idea of continuous improvement is part of the basis of the Lean Manufacturing System, which has been around since mid 1980s. In the early 1990s the term Agile Manufacturing was formulated as “a term applied to an organization that has created the processes, tools, and training to enable it to respond quickly to customer needs and market changes while still controlling costs and quality”.

So the ability to respond adequately to changes in customer needs or market environment came originally from the manufacturing world.

The agile company

Peter Weill, director of the Center for Information Systems Research at the Massachusetts Institute of Technology (MIT), presented “The Agile Paradox” during the MIT CIO Summit in June, 2006. This presentation was based on a survey done by Weill and his team with a group of 649 companies and it brings quite interesting facts. Slide 4 shows the that agile companies perceive a 37% increase in their profit growth while staid companies perceive a 13% decrease.

Is your firm agile or staid?

The Economist Intelligence Unit made a report sponsored by EMC in 2009 called “Organizational agility: How business can survive and thrive in turbulent times“. The report is based on a survey with 349 executives around the world on the benefits, challenges and risks associated with creating a more agile organization.The major findings are:

• Organizational agility is a core differentiator in today’s rapidly changing business environment. Nearly 90% of executives surveyed by the Economist Intelligence Unit believe that organisational agility is critical for business success.
• Yet most companies admit they are not flexible enough to compete successfully. More than one-quarter (27%) of respondents say that their organisation is at a competitive disadvantage because it is not agile enough to anticipate fundamental marketplace shifts.
• Internal barriers stall agile change efforts. More than 80% of survey respondents have undertaken one or more change initiatives to improve agility over the past three years, yet 34% say they have failed to deliver the desired benefits. The main obstacles to improved business responsiveness are slow decision-making, conflicting departmental goals and priorities, risk-averse cultures and silo-based information.
• Technology can play an important supporting role in enabling organisations to become more agile. Technology should function as a change agent in the use and adoption of best-in-class knowledge- sharing processes, so companies can improve their use of critical data.

Also in this report there’s a quote from Weill where he explains why agility is important: “When I was a kid, the most successful companies were monopolies or duopolies, but in today’s globalised, free-market environment, the ability to satisfy customer expectations is core to profitability. If you’re not agile, you can’t do it, because customer expectations are never static.”

Wrapping up

So maybe it’s time to think not only in terms of agile software development or agile manufacturing but in terms of agile company, a company able to respond adequately to changes in customer needs as well as changes in the market. This will be achieved if the company:

1. frequently delivers value to customers, employees and shareholders.
2. proactively gathers frequent feedback on what is being delivered and reviews this feedback.
3. adapts accordingly and improves how it delivers value.

It is a continuous improvement cycle, so it’s never too late to start! 

Product Management: how to increase the success chances of your software

In 2015 I wrote a book on Software Product Management in Portuguese. In the beginning of 2016, Paulo Caroli talked to me about how he enjoyed the book and how this book could be useful to people in the software industry not only in Brazil but anywhere in the world. For this reason, we decided to create an English version of my book.

The book is organized in 5 sections:

• Definitions and requirements
• Life cycle of a software product
• Relationship with other areas
• Product portfolio management
• Where to use software product management

This book is suitable for anyone working with software. Even companies that do not have software as its core business use software in their day to day and often have developed some software that interfaces with its customers such as a website or a mobile application. It is important for these companies to understand the software product management role and responsibilities, so they can better manage this software and increase its chances of success.

We are working on the translation but as we progress we are already releasing the content. If you want to see the work in progress, please visit the book page at LeanPub. Still in beta but already with valuable content. Feedbacks are not only welcome, but needed!