In 2012, the book "Lean Startup" suddenly became very popular. Established on the principles of lean thinking, the book advocates a lean approach to starting a business, so that entrepreneurship is a gradual and controllable thing. The essence of “Lean Startup” is a "building => measure => learn" cycle, i.e. take a small step forward and get fast feedback.
For innovative businesses, the same principles apply. Widely influential "big innovations" are built on a foundation of micro-innovations. In the process of development and promotion, a large number of micro-innovations will stop at a certain stage, creating value within a comparatively smaller scope, and will not evolve to “big”.
The innovation and the development process can be thought of as a funnel, which consists of the following stages: discovery of pain points => problem solving => experience sharing => generalization => promotion.
The innovation funnel
This funnel metaphor helps us understand some of the key points in creating innovative enterprises. First, ensure an abundance of source material, which will allow employees to explore innovative ideas. Second, ensure smooth flows and eliminate barriers between the various stages. The innovation funnel has five main stages, each with a different focus.
#1 Discovering Pain Points
Every project has its own set of problems and every team has members with complaints – this we take for granted. But from the perspective of innovation, every problem and every complaint can be seen as an opportunity to innovate. Rather than team members becoming downtrodden or bored by existing problems, they instead may see them as exciting possibilities.
Firstly, one must encourage team members to summarize their own existing pain points. Agile retrospectives are a good time to do this. In a typical retrospective meeting, team members recall what they have done well in order to improve the self-confidence of the whole. Then the team covers what they have done less well so that they may find opportunities for improvement. In these frequent “retros”, which are targeted at issues and not persons, members are willing to speak honestly in order to reveal problems and pain points.
Sometimes, team members are so caught up in their project that they fail to detect pain points. At times like these, communications between teams become even more important.
At Thoughtworks Chengdu, there are more than 10 independent projects. Team leads have a biweekly meeting to share what they have learned and to identify pain points. During one such meeting, a team lead shared his desire to speed up automated build. The leads discovered that this was a common wish across several teams.
However, some deep-seated, large-scale problems are difficult to detect due to limited scope and ability. For example, within Thoughtworks Chengdu, four teams were working on four different applications for the same brand. Because the teams paid little attention to each other’s products, the UI and UX among these applications were not consistent. Such inconsistency causes users to feel a disconnect when, in order to fulfill different business scenarios, they traverse through an application. To reveal these sorts of pain points, teams need an experienced external observer.
Thoughtworks Chengdu has a practice called a Technical Deep Dive. For this, members of the China Technical Council (CTC), composed of prominent technologists from Thoughtworks China, join a team for two weeks. During this period, the CTC members will interview team members, hold exploratory workshops and review current practices (architecture, code, workflow) to try to discover pain points.
#2 Problem Solving
After discovering pain points, team members must solve them in a timely manner to gain a sense of achievement. Otherwise, the acknowledgement of pain points will simply cause low morale amongst employees and will not become a source of innovation.
Time is a limited commodity, so how does a company, and in particular a professional service company like Thoughtworks that spends eight hours a day serving clients, find time to solve problems? The company, client and employee should trust each other, so that they can collectively create space for continuous improvement.
The first thing a project team will do in addressing pain points is to record technical debt within current system. The team discusses pain points with the client and identifies the root causes of the pain. The team records these causes in the form of technical debts, puts them into the backlog and manages them with stories. In this way, resolving debts become an integral part of the delivery plan. Technical debts reduce the velocity of delivering stories, so the team and client must come to agreement on how to balance the short-term yields (only deliver functions) and the long-term payoff (getting rid of technical debt).
Some pain points are not suited to a resolution within daily work as a regular task, and instead need a dedicated period of time in order to be resolved. An example would be developing a software tool in order to improve support. One approach to solving this problem is to buy beer and pizza and run a code jam on a weekend, developing an open-source piece of software to address this problem. Thoughtworks Chengdu’s client also holds an Innovation Day every quarter, encouraging employees to use two days’ working time to realize great ideas. Combining pain points with the opportunity to innovate usually brings achievements beyond expectations.
#3 Experience Sharing
No matter how seemingly trivial and rough the solution for a pain point, it is still worth sharing the solution among other teams within the company. This type of sharing has two benefits. First, it is a form of encouragement to the project team, letting them know that discovery of pain points and continuously looking for improvement are admirable traits. Second, other teams may have found the same problem in their projects and can re-use or even improve the solution.
A lot of technologists are introverts unwilling to share their experiences in public. To encourage them, Thoughtworks Chengdu organizes a Team Showcase every week. One team each week presents their recent achievements. Since delivering on time is a basic responsibility for Thoughtworkers, it is not considered an achievement. Teams instead focus on new approaches, tools or technologies that they have used to eliminate pain points. With 10 projects in the office, each team presents a showcase every three months. This pushes every team to make continual progress, lest they be caught with nothing to share.
Every week there is a project showcase to demonstrate achievements.
During the team showcase, you often hear, “We encounter the same issue.” Sometimes, the ready-made solution can be re-used. More often what you hear is, “We have a similar problem, but this solution doesn’t completely work for us.” This feedback is a signal, indicating the solution might be a good start but needs closer attention.
#4 Generalization
There’s a saying that “There’s nothing new under the sun.” Nobody is able to create a wholly original question. There may be thousands of people and teams who are suffering from the same problem you have suffered, but just like leaves, none are identical. Dedicated solutions usually do not work everywhere. Abstracted and generalized solutions have more power and can be more widely used.
The evolution of the Moco test tool is a great example of abstraction and generalization. Integration tests greatly frustrated Zheng Ye. They were slow to run, hard to prepare test data for and ran in unstable test environments. To simplify them, he developed a tool that at first could only be used via its API interface.
Through discussion with other project teams, Zheng Ye learned that not only integration tests written in JUnit had this problem. Functional tests written in Cucumber, Concordion and other testing tools were also pain points for other teams. Zheng Ye realized that these problems could be abstracted to “it’s difficult to test integration points”, and that led to a standalone model of Moco.
Beyond expectations, mobile developers began to use Moco to simulate server-side behavior for relieving workload, simplifying their daily development work. This is one example of an advance made possible by abstraction.
Whilst using Moco on another project, I discovered that the main obstacle to integration tests is actually test strategy itself rather than the testing tools, and that test strategy is affected by software design. The key to solving testing difficulties is to design integration points appropriately in order to plan a good test strategy. Through some practical project validation, I was able to summarize a set of integration points’ designs and test strategies, which greatly improved our integration tests. I wrote “A Test Strategy for Enterprise Integration Points” and published it on InfoQ. Since then, Moco has, from humble beginnings as a simple test tool, become an important part of the approach for design and test strategy for integration points.
Even in such a success story, we still cannot generally answer, “How to abstract solutions from pain points?” In my opinion, the ability to generate abstractions still relies on a mysterious spark of insight. Even so, there are still ways to promote occurrences of these sparks. In Thoughtworks Chengdu, micro-innovation owners and experienced colleagues (especially CTC members) are encouraged to communicate frequently with each other. The key to this communication is to make clear what the pain points are, what the root causes are, how to solve them and to what scenarios the solution can be applied. Mind maps and whiteboards are the best tools to convey this information. Inspiration may occur during this clash of minds.
#5 Promotion
When a micro-innovation has already been abstracted and generalized and is suitable for use by many people and teams, then it is time to promote it in order to gain greater influence. When promoting, it is important to consider channels and content.
In Thoughtworks Chengdu, there are three methods of distribution: intra-company promotion, client-side promotion and external promotion. Inside Thoughtworks, an innovation might not be applicable just to a particular project within a particular office, but also to projects in other offices in China and even globally. Thoughtworkers can easily introduce innovations to global colleagues via their internal forum, mailing list, the CTC, and more. Promotion amongst clients occurs similarly in clients’ internal forums and mailing lists and through recommendations via Client Principals. Thoughtworks’ clients expect to reap the fruits of creative thinking and so top managers are typically keen to hear of any new developments.
The above two channels are inner ones, where a clear email is enough to achieve the promoter’s goal. When promoting innovations to clients, the organization of content becomes of utmost importance. Common channels for external promotion are Weibo, blogs, public presentations, articles, books and more. There’s no need to describe every channel’s characteristics, and it is actually more valuable to point out their similarities. Organic use of these channels can help the author collect feedback and organize thoughts, resulting in better content.
When a content structure appears in my mind, I will quickly tweet about it. The 140-character limit helps me to pare a thought down to its core elements, allowing me to form a 30-second elevator pitch that I can use to introduce my idea to anyone. I then would use a mind map to sort out my content structure, and write a blog post under 2,000 words to describe its structure. This is the most basic introduction, without any lengthy expansion. A post like this is sufficient to the gain the sympathy of readers with similar pain points, at which point they often provide feedback to the author.
After this, authors can present this blog post to online and print media editors to gauge whether its contents are of interest. If a media outlet is willing to publish the article, the author can tailor his piece according to the characteristics of its format, add statements and examples and making it ready for publication. Using the same skeleton framework, the author can draft a speech, using the words from the article as speaker notes for their presentation slides. When the article is complete (and usually earlier), so is a well-organized speech. Now you can go ahead and deliver your speech at influential industry conferences such as InfoQ and QCon.
In the case of Moco, we did more than the above. After publishing in InfoQ China, two colleagues from Thoughtworks Chengdu translated the article into English in order to introduce Moco to our clients. We realized the English version could be published as well and contacted editors of the InfoQ global site. The English version was subsequently published on InfoQ global after a few modifications. We entered Moco for the Duke's Choice Award, held by Oracle, and duly won. Moco has, from an unknown internal innovation, become a highly influential open-source project.
#6 Leader Responsibilities
Organizations lack innovation not because their employees lack the capability, but because they have not provided a supportive environment. Creating an environment conducive to innovation and eliminating obstacles is the responsibility of the whole team, but especially of the leader.
Leaders have to make employees aware that innovation is encouraged. Nearly every organization claims to encourage innovation, and no leader will say, “No innovation, please.” We can conclude that the building of an innovative consciousness is done through deeds, not empty words.
Innovation means doing jobs in a different way and possibly making mistakes. If an organization cannot accept mistakes and punishes employees who make them, then no employee will innovate. In my daily work as an office principal, I keep asking every project: Is there anything you’re able to do better? What kind of new approaches do you want to use to deliver the project?
If a team does something wrong, the first question I ask is, “What have you learnt from this?” I want employees to know that making mistakes is allowed but making no attempt at progress is not.
Employees need to know as much as possible to produce innovation. An organization that wants to foster innovation should be a transparent organization whose employees can access all manner of information beyond what they need in their daily work context. Thoughtworks Chengdu holds a full office update every month with information relevant to business operations announced in the open to everyone. Traditional companies might consider much of this information to be sensitive: sales progress, customer feedback, staffing, financial data and more. A lot of management meetings are open to any employees who wish to attend. We are eager to have staff understand wider contexts in order to engender new thinking.
Even with information, employees may not have enough perspective to innovate. As a more senior employee, a leader needs to help inexperienced colleagues expand their horizons. A leader can help developers understand the impact of software for business, help on-the-floor staff understand the background to corporate operations, help internal staff learn to gain exposure within the industry through writing and public speaking – these are all methods a leader uses to expand an employee’s horizons.
When employees have good ideas, a leader should guarantee that they receive enough resources to implement them. When a micro-innovation has still not been realized, what an employee needs most is time: time to discover project pain points, to create a solution, to share experiences. All of these may take up work time. A leader must give their employee enough support so that the innovation can be pushed forward.
Take care to not provide too many resources too early. Doing so smothers the will to innovate. Just as every company claims to encourage innovation, so too does every individual claim to have innovative ideas. However, many endeavors are half-heartedly undertaken and put aside soon thereafter. A commitment is the standard by which to judge passion, and investment in new ideas should follow the principles of lean startup: when an innovator has created something from scratch and found a clear direction, invest necessary resources only when investing populates corresponding output quickly.
Why are innovators willing to start from scratch and even to spend spare time to implement their new ideas? Aside from the high brought about by the act of creation, another important reason is that their creation may help others. The desire to lend a helping hand is a key factor in the culture of innovative organizations. Employees who are happy to help others empathize with clients, colleagues, fellow IT professionals and even vulnerable groups within society, and will do their best to help. Such employees have a greater probability of finding meaningful new ideas and making them come to life. Leaders should assist these types of employees and these types of innovations. An atmosphere of helping others is what leaders should encourage and cultivate.
An excerpt from an article originally published on InfoQ here
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.