Values in an Agile/Lean/Innovative company

This is part of my Lean Disruption Series where I’m looking at Lean, Agile, Innovation, and Lean Startup.

None of these methodologies can be adopted for free. They require a great deal of firm introspection. Understanding how processes interaction with people and values is vital to adopting any of these approaches let alone a combination of these approaches.

Metrics are one of the best examples of how there can be conflicts between stated values, values in making decisions, how resources are handled and how processes are structured. The famous saying “You manage what you measure” is right in a lot of ways. Many companies claim that they value customer satisfaction, however many of these companies do not actually do anything with the satisfaction surveys they do get. Comcast is the most obvious example of this. Comcast doesn’t really value customer satisfaction because they measure their customer support on how much they can upsell to the customer anytime they are on the phone. This changes the processes their customer support must use, rather than designing processes to enable single call resolution, their processes are designed to enable selling more products. Their employees, the resources, are rated based on this and if they don’t meet those goals they are unlikely to do well. Considering the Verge’s Comcast Confessions series most of the resources at Comcast do not feel valued. This all points to the true values for Comcast being retention at all costs and more revenue per user measured in Churn and ARPU (Average Revenue per User) respectfully.

Agile Manifesto from ITIL’s blog

For a company to adopt an Agile approach to developing software, the paradigm of what the organization values must radically change to align to the Agile Manifesto. In most software development the concepts on the right are what are valued through a Project Management Office. The concepts on the left are typically considered only at the beginning or the end of the project or not at all. Working product is the goal of a project, while customer collaboration inclusive only in the beginning getting requirements.

Switching from the right to the left creates massive cultural upheaval at an organization, where power is shifted down and out. It is shifted down to the team level, where managers in the past made all the important decisions Product Owners, Scrum Masters, and developers make the decision now with the customers. Power is shifted out through increased collaboration with the customer. Customer centricity forces the company to understand what the customer really wants and more quickly respond to changes in their understanding of their needs. This does mean that the “requirements” change, however, in many cases due to the uncertainty in a technology, interface, or some other aspect it was impossible to properly articulate the actual need until there was an example in front of the customer.

With these value changes there must be process changes to that properly reflect the change in the way the values require work to be completed. In the case where Single Call resolution is the most important metric reflecting the value of true customer satisfaction, processes must be built to enable that – such as training, information repositories, and authority to truly address customer needs at a single point of contact. In software development rapid iteration with continual feedback is a process that must be built to enable that.

This changes are not free and require true commitment from leaders across the organization. Without their commitment any adoption of these frameworks is doomed to failure.

Customers Don’t Know What They Want, But You Don’t Know What They Want Either

This is part of my ongoing series on Lean, Lean Startup, Agile, Innovation, and Disruption.

This topic always gets a lot of press and it is truly covered in just about any business book these days. In fact the Disruption perspective offers the suggestion that a product is hired to do a given job, so you need to understand what the customer is trying to do and then start figuring out what how to best solve that problem.

Typically, people start with the solution. Engineers, designers, programmers have an idea for a solution a product that they think people will like because they find the solution to be a cool idea. So without consulting true customers through interviews they do other “market” research which may or may not really ask the right questions because they might not truly understand the problem that they are truly trying to solve. A solution might sound good and people might say they are interested in it, but if it truly doesn’t address their problem. This is why the Lean Canvas is powerful, because if forces you to truly confront the problem your solution is trying to attack.

The point isn’t that you or anyone else know better than your customers, you truly don’t. You might have an idea that could be something that your customers could use. You don’t truly know. Having confidence if vital for success, but you truly need to test that through interviews and planned conversations.

The iPhone wasn’t successful because it was truly novel It really wasn’t, the phone wasn’t able to handle 3G, it didn’t have copy and paste and many other features that Blackberries had for years. Things that standard businessmen needed. However, that wasn’t the market Apple was going after initially. They were going after high value customers that were not having their needs met with existing smart phones. They knew their customers would be willing to pay a premium because of the more and more advanced iPods the company was selling. Apple was able to look at the competition and see what was working well, what was not working well, and what features customers truly needed. The first iPhone was truly an MVP, but the problem Apple was trying to solve was different than Blackberry or what Nokia was thinking of solving. This is why they were successful. They understood the problems their customers had. They didn’t have the most innovative phone on the market from the hardware perspective. They figured out how to attract customers through an easy to use UI. The problem people had with with Smart Phones was that it was terrible to use. Solve that simply and elegantly, you can rapidly expand into different customer segments. Then quickly move into those other segments as businessmen bought the iPhone as a personal phone and wanted to replace their Blackberry.

Assuming arrogantly that you know what the customer wants will likely lead to failure as much as asking the customer what they want/need. Identifying a viable problem and validating through experimentation is the best way to determine if it’s truly something your customer wants.

The Power of Kanban

This is part of my ongoing series on Lean, Innovation, Lean Startup, Agile, and disruption.

Kanban is a tool in Lean which is used to help send messages downstream without needing to actually talk to each other. Which is powerful in a manufacturing setting as communication might be difficult depending on the environment. Kanban translate as card from Japanese and typically has information related to the number of items that need to be in a bin and what the item is that needs to be in a bin.

Example of a Kanban board on Trello

Example of a Kanban board on Trello

Some Agile practitioners have adopted Kanban to be a set of steps in the process for developing software. This could be as simple as Ideas, To Do, Doing, Completed, or as complicated as Backlog, Wireframe, Coding, QA, Testing, Integration, Complete. Ideally, simpler is better, because more bins make management of the lists much more complicated than if there are that many phases in the Kanban board, but this is really up to the preference of the team and whatever works best based on the Build measure Learn approach.

Even developing a Kanban system for software development the team should view it as another possible to learn how to work with each other better. This includes the information that’s required for a piece of work to be started. For example, determining what information is the minimum for a User Story is something that must be agreed upon by the team. Furthermore, the Acceptance Criteria can help reduce the number of steps on the Kanban board as these may simply be part of the acceptance criteria for a complete story.

Using stories and Kanban board can help with Innovation through creating bite size pieces of work that can be designed to reduce the environment of uncertainty the product is being developed in. Since uncertainty is the greatest risk to the project it is vital to write user stories and use the kanban board to maximize efficiencies with developing a new product.

The Kanban board is also extremely effective for ensuring that startups keep their energy focused on the most important thing. No work should be done on an item if the work is not on the Kanban board. If the work is vital to the startup, then it needs to be recorded and validated that it’s the right thing to be doing. Yes, it might slow things now, but the Kanban board is an effective tool to help people understand who is working on what and how those interact with other problems out there. This doesn’t meant that immediate issues shouldn’t be resolved immediately, but for development purposes no new work should be done without having an item on the Kanban board.

How to manage those Innovations?

This is part of my ongoing series exploring Innovation, Lean, Lean Startup, and Agile.

A few days ago I wrote about how the Lean Product Development method at Toyota essentially builds a Skunk Works around a new technology. This concept was popularized by the Lockheed Martin Skunk Works, which produced some of the most amazing aircrafts ever created, including the fastest plane ever made, the SR-71 Blackbird, which was designed in the mid 70’s.

In a similar fashion to Toyota, Lockheed relied heavily on existing technologies to drive down the cost of a new break through innovation. This allowed the Engineers to focus more energy on the few systems that truly required breakthrough engineering and thinking. Existing components for the bulk of the design also significantly reduced costs as the engineers did not have to design everything from scratch and could rely on standardized or consistent components at interfaces. This means the cost was lower using an already designed part, the part could be purchased at economies of scale, and the engineering work on new components was reduced because of they didn’t need to design interfaces.

This approach is seen as a best practice not just by Toyota and Lockheed, but Christensen argues this approach should be applied for any sort of disruptive innovation at a large company. This is required because of the risk of cannibalization of existing sales, lack of alignment with the needs of existing customers (doesn’t meet performance needs), and wins that might be small for the overall organization are huge for the new team. The alignment between wins and team help cement the team as successful and continue to shelter it from unrealistic demands from the broader organization.

In the Innovation Machine the author argues this is the approach that the most successful companies at innovation use. It helps companies become serial innovators and continually disrupt their markets and industries. Furthermore, the small wins for a new team doesn’t mean that these companies can’t have extremely aggressive goals for these internal startups. In fact, it’s likely many of them have billion dollar goals within 5 years for them, such as IBM has for their internal startups. However, the funding and the organizational structure is sheltered for a short amount of time and protected from the normal funding cycle that other portions of the organization are subject to. This is to ensure investment in future innovations that have a great deal of uncertainty.

The added benefit of these internal ventures is that the leadership of the entire organization can decide to use them as a means to change how the organization operates. For example, in the case of the Macintosh, re-integrating the Mac mini-company back into Apple forced massive changes in the way everyone worked. If the work processes are more efficient in the Skunk Works it is key that those processes are adopted by the business unit that will eventually house that new innovation. If the Skunk Works is using Lean processes and Lean startup practices integrating into the rest of the organization is going to be difficult unless those leaders are helped to get on board with the methodological approaches. This will take time but will certainly be worth it.

This is the approach that GE is taking for their new engine development. They essentially used the Lean Startup to develop an MVP by using a Skunk Works/Lean approach where they leveraged an existing engine to move the technology in a new direction with customer feedback the whole way.

For companies to be successful in deploying these approaches it will be key to to develop a safe place for them to experiment. Learn and grow away from the unrealistic expectations of a mature idea, when the idea is living in a space of extreme uncertainty.

Lean canvas, Lean Development, the Theory of Disruption

In yesterday’s article I talked about how you can use a product development approach called Set Based Concurrent Design (SBCD) to avoid some of the risks associated with developing a disruptive design regardless of how integrated or modular a given technology and its platforms are. Before that I had written about a concept called Lean Canvas to include questions associated with disruption to help push the initial design into a more disruptive place to maximize the likelihood of success.

In “Running Lean” the author, either knowingly or unknowingly emulated the benefits of SBCD whenever he fully described his approach for creating Lean Canvases. Ash Maurya recommended that for any given startup to initially start with multiple different views of the initial Lean Canvas which could represent different solutions, problems, customer sets, and metrics. Each one of these is to be discussed with potential customers in interviews.

However, once you understand your customer, you’ll need to begin developing your solution. In the case of a piece of software it may be easiest to simply caret multiple wireframe mock ups that emulate the SBCD. While with physical products, you’ll need to start with several mock ups and ideally multiple different specifications for components within the design. This is important as you may need to mix and match components of your physical design based on the niche customer set that you are targeting. The best result may end up forcing you to create a product that might be difficult to make if you don’t plan for the different specification interactions from the beginning.

While building your product as  you look at each different iteration it is important to continue asking if the actual solution continues to be disruptive or if it has slid into a less disruptive niche in the market. It is also vital that you still are aware if the interaction between the changes in your product and how it impacts your customers. If your potential customer decide that there are too many features you may have pushed yourself out of the initial niches  you were striving for. This will also mean you’re moving into a market space that will force you to compete head on with your competitors.

Using these three tools, questions for disruptions, lean canvas, and setbased concurrent design, will help speed the decision to continue pursuing a specific product, problem, and customer set. The point of this early process is to speed learning as quickly as possible and the B-M-L approach coupled with a set of Lean Cavnases and Products will help rapidly increase that knowledge set. Especially when using tools to help determine the trade-offs between your choices.

Finally, with continual engagement with your customers and products that are narrowing down towards a completed solution, you may find that your sets of products could become a family of products. This means that your learning may even be more valuable than before.