My colleagueJohn McCarthyjust published anexcellent report sizing the "app Internet," a phenomenon Forrester defines as "specialized local apps running in conjunction with cloud-based services" across smartphones, tablets, and other devices.Forrester estimates that the revenue from paid applications on smartphones and tablets was $2.2 billion worldwide for 2010 with a CAGR of 82% through 2015.We're witnessing the rebirth of the rich client in real time, on the mobile device instead of the laptop or desktop. Developing applications using native application technologies like Objective-C, Java, or Silverlight is clearly how the majority of developers are reaching these mobile platforms today (see figure).
Last week Agile reached the milestone of 10 years. Ten years ago a group of 17 thought leaders met to draw up the original guiding principles and manifesto for Agility. These principles not only define the approach of many Agile methods but are the line in the sand when discussing if something is Agile or not. There is little doubt in my mind that the creation of these principles set in motion one of the most important transformations that the software development industry has seen ― focusing development teams on the things that really matter and challenging ideas of work, processes, and practices that make no sense in the development of software. But the question is, after 10 years, should the guiding principles be updated?
Reviewing the principles
When working with organizations that are introducing Agile methods, conflict sometimes occurs when reviewing the principles in the following areas:
Individuals and interactions over processes and tools. The words individuals and tools usually cause the most concern when adopting Agile. Software development is a team sport, but this principle focuses on individuals. And as Agile grows in use, increasingly tools play a key role.
Working software over comprehensive documentation. The challenge of documentation is often discussed when talking about this principle. As the adoption of Agile grows, so does its use in industries where documentation is crucial and legislated.
Customer collaboration over contract negotiation. This is very true with internal development teams, but when external vendors enter the mix, contracts are important and will form the basis of the engagement.
Responding to change over following a plan. Implementation of this principle often results in lack of upfront planning, which is contrary to most organizations' funding processes.
You have to admit that knowledge management (KM) is hard — it’s hard to explain, hard to implement, hard to do right. It’s not just technology. It is a combination of organizational realignment, process change, and technology combined in the right recipe that is needed to make KM successful. And when it is successful, it delivers real results — reduced handle times, increased agent productivity and first closure rates, better agent consistency, increased customer satisfaction. Check out the case studies on any of the KM vendors' sites to see real statistics. Yet despite these success stories, and despite there being commercially viable KM solutions on the market for over 10 years, I am unsure whether KM really ever crossed the chasm.
Why is it then that we are seeing renewed interest in KM in 2011? I believe it’s attributed to listening (and acting on) the voice of agents and customers, coupled with loosening the strings of tightly controlled content that has breathed new life into KM. Most common trends include:
Using more flexible authoring workflows. In the past, knowledge was authored by editors who were not on the frontlines of customer service, who foreshadowed questions that they thought customers would ask, and who used language that was not consistent with customer-speak. Authored content would go through a review cycle, finally being published days after it was initially authored. Today, many companies are implementing “just-in-time” authoring where agents fielding questions from customers, not backroom editors, create content that is immediately available in draft form to other agents. Content is then evolved based on usage, and most frequently, used content is published to a customer site, making knowledge leaner and more relevant to real-life situations.
A while back, I had a spirited exchange with someone who took a rather extreme position about the role of product management in software as a service companies. The less polite version: He staked out a silly position – just poll your customers about what to build, and eliminate the PM role altogether – so I felt obliged to refute it. With two additional years of research into SaaS and PM, it's worth returning to that contretemps for a moment.
Then, I argued that PM was necessary in SaaS ventures.
Now, it's clear that PM is not merely necessary but essential.
Product Managers Are Really Innovation Managers
If the sole responsibility of PM were requirements, as my foil assumed, a poll might replace a person, but only if you had no interest in the long-term success of your company. Polls are extremely useful tools, and it's far better to use them than not to. However, polls have their limitations: most obviously, as a tool for taking the temperature of the customers you have, they tell you absolutely nothing about the customers you don't have yet.
Seriously. I recently spoke with a client who swears that software quality improved once they got rid of the QA team. Instead of making QA responsible for quality, they put the responsibility squarely on the backs of the developers producing the software. This seems to go against conventional wisdom about quality software and developers: Don't trust developers. Or, borrowing from Ronald Reagan, trust but verify.
This client is no slouch, either. The applications provide real-time market data for financial markets, and the client does more than 40 software releases per year. If the market data produced by an application were unavailable or inaccurate, then the financial market it serves would crumble. Availability and accuracy of information are absolute. This app can't go down, and it can't be wrong.
Why Does This Work?
The client said that this works because the developers know that they have 100% responsibility for the application. If it doesn't work, the developers can't say that "QA didn't catch the problem." There is no QA team to blame. The buck stops with the application development team. They better get it right, or heads will roll.
As British author Samuel Johnson famously put it, "The prospect of being hanged focuses the mind wonderfully."
Recently, the city of San Jose used a serious game, Buy A Feature, to address some tough budgetary challenges. Since serious games have relevance across a wide range of contexts, including application development and delivery, it's worth relating one anecdote from San Jose's exercise that demonstrates the importance of having a shared vision.
I was a "facilitator" for this exercise, which involved more than 100 members of the community, plus a couple dozen city officials, including Mayor Chuck Reed. According to the ground rules of this exercise, organized by Innovation Games, each group of several community members had to decide which municipal projects (libraries, parks, school programs, fire, police, etc.) to fund and which not to. These "wish list" items formed List A. A complementary List B included other projects that the participants could decide to cut and then shift the money into projects from List A.
Every participant had a small amount of money, but not enough to buy anything from List A outright. Funding anyone's favored project, therefore, required investment from more than one person. Money from any List B project was available only if everyone at the table agreed to cut it.
This article on consumerinnovation that appeared in The New York Times over the weekend was fascinating. It points to a new study conducted in the UK on the role customers play in innovation in consumer markets. A key finding was that:
“6.2% of UK consumers — 2.9 million individuals — have engaged in consumer product innovation during the prior 3 years. In aggregate, consumers’ annual product development expenditures are 2.3 times larger than the annual consumer product R&D expenditures of all firms in the UK combined.”
Study author Eric A. Von Hippell, of the MIT Sloan School of Management, said, “We’ve been missing the dark matter of innovation. This is a new pattern for how innovations come about.”
Well, maybe not so new. The NYT journalist, Patricia Cohen, goes on to point out that “The very study of collaborative user innovation is a relatively new phenomenon that began only in the mid-1990s when advocates for open-source software began to argue that computer code should be freely available for thousands of independent minds to play with and improve.” “They overturned the widely held model,” Ms. Cohen quoted Carliss Y. Baldwin, a business administration professor at the Harvard Business School, adding: “What makes Eric’s work so significant is that it is unprecedented to try to measure the extent of user innovation. He shows that we’ve had on a set of mental blinders.”
Some of the most joyful technical challenges I experienced as a developer were solving application performance problems. Isn't it fun. You are Sherlock Holmes - examining the architecture, diving into the code for clues, and scouring through logs files to find the bottlenecks that are responsible for snail's pace. However, this job is a lot harder than Sherlock Holmes or CSI. It is more like Dr. Gregory House, because you are racing against the clock. For every minute of sluggish performance, you could be losing eyeballs and therefore revenue. Worst case: the patient, i.e., your website, dies.
Performance Problems Are Usually Elevated Because Of A Crisis
Your business just launched a Super Bowl commercial that confidently directed people to your website - #fail. More likely, a new release of software performs like a dog (with apologies to Greyhounds) because of lame coding and nonexistent performance testing.
Cosmopolitan magazine certainly doesn't publish articles such as "Seven Hairstyles That Will Make Your Man Yawn." Wildly desirable is more like it. And so too, is it with great software. If you want your applications to be successful, you better make them wildly desirable.
My latest published research has identified seven key qualities that all applications must exhibit to be wildly desirable, with our choices based on research and inquiries on software design and architecture; assessment advisories with clients; and interviews with leading experts, including both practitioners and academics.
Forrester defines the seven qualities of software as:
The common requirements that all software applications must satisfy to be successful: user experience, availability, performance, scalability, adaptability, security, and economy.
All seven qualities are important, but if you get the user experience (UX) wrong, nothing else matters.
The UX is the part of your application that your employees and/or customers see and use daily. You can do an exceptional job on project management, requirements gathering, data management, testing, and coding, but if the user experience is poor, your results still be mediocre — or even a complete failure.
Ever hear about the "First Rule of Holes"? It's pretty simple — if you find yourself in a hole with a shovel, the first thing to do is.... stop digging!
That's kind of what it's like in app dev when it comes to release management: We've dug ourselves a pretty deep hole, and it's impacting our overall ability to ship software on time. We recently ran a survey of app dev professionals that confirms what we hear in our client inquiries: Most development leaders are frustrated with slow software delivery and their release management process (see Figure). While Agile speeds software design and development, it doesn't do much to speed up release and deployment — creating a flash point where frequent releases collide with slower release practices.
But some organizations have stopped digging themselves in deeper. They are working with their peers in operations to streamline release management and cutting steps into the side wall of their hole so that they can climb out, step by step. Here are five steps that they are taking:
Investing in improving their pre-build processes. Many problems that occur during a release cycle have their root cause in inadequate pre-build tasks and activities.
Expanding release management throughput. Projects that have large code bases or extensive testing cycles are using parallelism and intelligent testing processes to speed up the early stages of the release cycle.
Optimizing their release pipeline. After taking care of the early stages of the release pipeline, advanced teams are implementing virtualization, parallel testing, and developer self service to further compress their release cycles.