Tom Grant serves Application Development & Delivery Professionals. See the full Analyst bio. Visit Forrester.com to learn how we make Application Development & Delivery Professionals successful every day.
When you were a child, you may have played with a paper fortune teller (a.k.a. cootie catcher). By folding and unfolding this origami-like construct, you produced answers for questions you posed.
The topic of technical debt is a lot like the paper fortune teller: the more you unfold the topic, the more interesting observations emerge. Israel Gat wrote two recent posts (click here and here) at his blog, The Agile Executive, that illustrate the sort of costs that technical debt imposes. His second post focuses on the most conspicuous cost: The more you develop, heedless of the technical debt you create, the harder and harder it becomes to make further changes. While this may seem like an obvious conclusion, it's not one that has the impact on software development that it should. In their rush into the future, building code that is supposed to expand choices, many teams are actually constraining their choices.
For ISVs, technical debt has a lot of important ramifications. Here are just a few:
For startups, aggressive product road maps can be counterproductive. The more you develop, the more competitive your product, right? That formula seems obvious to most insurgent vendors, but there's definitely a point of diminishing marginal returns, when the cost of maintaining all that aggressively-developed code exceeds the company's ability to continue developing and supporting it.
IBM recently launched CityOne, a serious game that poses the kinds of questions about water, power, finance, and retail that city planners face daily. It's a powerful tool for a B2B company like IBM to market its products and services in a way that engages the customer more deeply, making the company's value proposition more clear and compelling.
IBM has been making a serious investment in serious games for quite a while. Here's a short interview with IBM's serious games program manager Phaedra Boinodiris, in which she lists some of the business applications of serious games. Here's a brief overview of the work IBM has done with USC to incorporate a serious game about business process management (BPM) into the USC business school's curriculum.
The BPM game, INNOV8, demonstrated that a serious game can translate a dry and complex subject like BPM into something more interesting and vivid. It appeals to human psychology in a way that even the best white paper can't. Humans are visual creatures, so it's often more effective to show us a principle in action rather than talk about it. A serious game like INNOV8 pushes other buttons in our brains, too. For example, there's a higher probability that someone will finish playing a game than reading a white paper. If the game succeeds at keeping your attention, you want to see it through its conclusion.
Obviously, as a regular blogger, I think social media are the cat's meow. However, when I use social media, I don't lapse into that blissed-out state that cats enjoy when they bust open a jar of catnip. Your experience may be different:
If you believe that Twitter is of net-benefit for the world, and only someone who hasn't used it much would say otherwise, then what's good for Twitter is good for the rest of us, too. Costolo's adventures with the last world-changing messaging system he [led] may have worked out better for himself than for the rest of us in the long run, but his work at Twitter so far has been key at building staying power for this new, more accessible way for people around the world to speak with each other.
That's the concluding paragraph from a ReadWriteWeb story about Twitter's new CEO. It's just the sort of gushy, overblown statement that plays well in the pocket universe of people with a vested interested in social media using social media to sign hosannas on the highest about social media. Outside the pocket universe, it's just the sort of hyperbolic prose that makes people who are on the fence about Twitter, who don't necessarily see it as good for the rest of us, nervous that anything sold that hard must not be as good as advertised. For people who still look at their email inbox with despair, Twitter may be one more channel of communication that they don't need.
Our first application of Agile principles to the research process, which occurred during our study of thought leadership in the tech industry, was a very Agile-esque journey into the unknown. We learned a great deal that applies to future applications of Agile Research Development, so here's my retrospective.
You Can Be Agile Up To The Boundaries Of What You Control
Ultimately, you control only part of the value stream. This maxim holds true wherever you apply Agile, and software developers learn this principle right away. You can be the most disciplined developer imaginable, never checking in code that doesn't work, always building in tests, and still be at the mercy of your own QA team. And even if the larger team, including testers, works in blissful harmony, someone needs to deploy the code on a live system. (Which is why dev ops is receiving a lot of attention from within the Agile community these days. See Jez Humble's recent book for a good example.)
If a stream is an appropriate metaphor for value creation and delivery, then this stream always takes many twists and turns, frequently encountering dams and obstructions. The success of Agile, therefore, depends to a great extent on eliminating these kinks, navigating around them, or learning to accept them as part of the value stream's trajectory.
Believe it or not, that was a piece of "advice" that I discovered while trying to fix a problem with Google Chrome. The question was about a browser, but the answer was about an operating system. It was clearly not helpful, at least in dealing with my immediate problem.
On the other hand, pseudo-advice like that is very useful if you want to understand the state of the technology industry in 2010. It's the subject of this autobiographical psychodrama that I might entitle, Personal Computers Are Not Appliances. If you decide to read on, let me warn you: it's a terrifying tale of reasonable people at the mercy of unreasonable levels of complexity and unreliability. During this exposition, you'll encounter interesting characters like the Apple iPad, Google's business plan (of sorts), Marc Benioff, and our evil cat Kelly.
When Chrome Lost Its Shine
Yesterday morning was crunch time at stately Grant Manor. The quarter was coming to a swift end, which meant all kinds of deadlines for research documents, expense reports, client projects, and a variety of other tasks. Regular activities, such as phone calls with technology companies about their latest product and service offerings, still happen during these hyper-busy periods, when time becomes so compressed that it fails to serve its basic purpose of, in the words of Richard Feynman, preventing everything from happening all at once.
Now that we've posted the outline for our study of thought leadership in the technology industry, it's a good time to take stock of our success so far. It's important to start the retrospection process, even if we're not completely done with the project yet, because we're using this study to pilot a different way of doing research. As we said in the document explaining this approach, Agile Research Development, we set the following goals (shown in order of priority):
For those of you who have been following our thought leadership research project, we're now in the final stages of this project. I've posted the proposed outline here for your comments. If you're not familiar with this project, here's the development document that summarizes the topic, working hypothesis, and research method. Also worth reading is this blog post, which explains why we're using this piece of research to pilot an Agile, community-based approach.
Realistically, comments will have an impact on the final document if you post them by the end of the week. After that, I'll be writing the actual document.
Also worth mention: in drafting the outline, I realized that some of our earlier work on B2B evaluation, selection, and adoption is applicable here. Expect to see a cameo appearance from some of that interesting research in this document.
In the last couple of years, an increasing number of technology companies have discovered, or rediscovered, or redefined their own portfolio. Here are a few examples of where you can see this new appreciation of portfolios:
Using the portfolio to define alignment. Recently, I wrote a profile of Sterling Commerce's efforts to deal with the inevitable misalignments that occur in any company with lots of products, particularly after making acquisitions. Their decision to use the portfolio as the instrument of realignment is by no means unique, but it wasn't as common several years ago as it is now. (And it's still not as common as it should be.) Vendors like Sterling have to take two steps for realignment to succeed: (1) define the portfolio clearly, in a way that suggests measures of misalignment; (2) enforce this standard on people who would otherwise continue moving in the same direction unless acted upon by an outside force. Not everyone has succeeded at both, or even understood that both were necessary.
As someone who has worked in development teams, I take it for granted that not everyone on the team has the same needs and interests. A twenty-something Java developer, fresh out of college, is interested in questions like, "Which emerging framework might be worth learning?" The architect on the team may be interested in the same frameworks, but for entirely different reasons. Unlike the rank-and-file developer, the architect has decision-making power over which framework to adopt. The architect bears responsibility for the long-term consequences of this decision, while the rank-and-file developer is primarily concerned about delivering components written for whatever framework the team selects. Meanwhile, the development manager has to oversee the work of both the developer and architect, ensuring that, collectively, the developers and architects and testers and everyone else deliver their work product on time, at an acceptable level of quality.
Different roles, different questions -- not a hard principle to understand. When applied to developer support, it means that developer conferences, discussion forums, and other resources must tailor their content to a specific audience. Not surprisingly, the material interesting to developers might not be as interesting for architects, and vice-versa. (And if you're still not convinced that the two roles have different needs, take a look at the chart in this earlier blog post, which shows the sources of information and advice to which developers and architects turn.)
At this link, Dave West and I exchange observations about the Agile 2010 conference earlier this month. For some earlier notes from the event, click here.
. Your experience may be different:
"Or you could just install Linux. ;-)"
Different roles, different questions -- not a hard principle to understand. When applied to developer support, it means that developer conferences, discussion forums, and other resources must tailor their content to a specific audience. Not surprisingly, the material interesting to developers might not be as interesting for architects, and vice-versa. (And if you're still not convinced that the two roles have different needs, 