Every year, people talk about the future of IT, which is shorthand for, "Some big changes may be in the works." In the last year, we've had to revise that sentence to read, "Some big changes are definitely in the works." Agile practices will be a critical tool for making this transition successfully, but not because of velocity. At least, that won't be the primary virtue of Agile that helps with the transition.
One of the Founding Fathers of Agile, Jim Highsmith, recently commented on his blog about an MIT study that surveyed one face of this mountain of change:
The implications of these changes in emphasis could be significant in terms of mindset and capabilities in and out of IT departments. From a focus on standardization, optimization, and cost control, the focus shifts to innovative uses of emerging technologies such as social media, cloud computing, and mobile devices; speed to market; flexibility to follow changing opportunities, and building new products and services.
We've been talking about the next stage of application life-cycle management (ALM) for several years now. As my colleague Dave West argued, the vision of ALM 2.0 is clear, compelling, and comprehensible. While ALM tools might have a ways to go to fulfill this vision, they have made significant strides in one particular area: integration among tools, whether or not they come from the same vendor. The momentum for ALM integration isn't unique, propelled by the same forces that make integration the killer app in other segments of the software market (CRM, content management, collaboration, etc. etc.). Tools provide potentially valuable capabilities, but these capabilities don't map exactly to the way people work.
The Work Defines The Tool, Not The Other Way Around
The primacy of work over tools explains why ALM 1.0 died quickly from its own success. Having convinced app dev teams of the value of point solutions for task management, planning testing, requirements, release management, and other functions, the obvious question on practically every customer's mind was, "What other tools might help us?" We should be careful about how we understand that question, which is not synonymous with, "What other activities might we make easier or more successful?" The tools are, more often than not, part of the same activity. Planning, for example, should identify risks that shape what requirements you write and what tests you build.
They say "content is king." But, "context is kingier" when it comes to designing great smartphone and tablet mobile apps. Don't make the mistake of thinking that mobile app design is just about a smaller screen size or choosing the right development technology. Content and context are both important to designing great user experiences, but mobile amplifies context on five critical dimensions: location, locomotion, immediacy, intimacy, and device. Understand each dimension of Forrester's mobile context to design mobile apps that will make your users say "I love this app!"
Forrester LLIID: Location, Locomotion, Immediacy, Intimacy, And Device
Location. People use apps in an unlimited number of locations. And not all places are the same. A user may be in a quiet movie theater, at home in the kitchen, on a train, or in the White Mountain National Forest. Contrast this with desktop computers, stuck in places such as an office cubicle, home office, or kitchen. Laptops provide some mobility but are larger and less able to provide the immediate access of instant-on mobile devices such as smartphones, eReaders, and tablets. Location is a key dimension of context, driving different needs for users depending on where they are. Fortunately, GPS-equipped smartphones can use a geodatabase such as Google Maps to determine precise location.
Following the Charles Darwin's statement “To change is difficult. Not to change is fatal,” application development professionals always seem to be in the process of change. Changing technology, adopting new practices and methods, and introducing new organizations are just a few of the things that most application delivery shops are changing at any time. But how is that change being undertaken? How do these change programs get managed? And more importantly, how does all this change fit together? During 2010, Diego Lo Giudice and I asked these very questions and have recently published a report describing our findings. This blog describes our findings at a high level:
Where does change come from?
Having interviewed 75 companies that were in the midst of change, we found that, perhaps not surprisingly, change was being driven from a multitude of sources. Bottom-up change was coming from practitioners. Technology Populism seems to be rampant in most companies, with individuals bringing in their favorite technology or practice. In parallel with this grass-roots adoption model is top-down, executive-driven change. The majority of organizations we interviewed had executive-driven change programs around process, organization, or technology. Rarely did we see the bottom-up change being integrated with the funded, top-down approaches. The result was often confusing, with ideas clashing and change initiatives running against each other. At best, the practitioners ignored the top-down ideas; at worst, they blatantly undermined these ideas because they were different from their own ideas.
Both Agile and Lean have an ethos that, at least on paper, acknowledges the noble failure. "Fail fast" is part of the Agile credo. Although it sounds as though it contradicts the "fail fast" approach, Lean's admonition to delay decisions for as long as possible is actually very complementary. The first draft of anything, from automotive design to software architecture to student papers, always contains elements that could be improved or that are just flat-out wrong. Practices that sit beneath the banner of Agile or Lean, such as set-based development, provide further ways to make mistakes and overcome them.
To a large extent, these practices deal with the easier varieties of failure. Prototyping a feature quickly, so that you can invite feedback when you actually have enough time to respond to it, is an extremely valuable technique for lowering the risk that you build something the wrong way. You need a different approach to identifying the features that you should not build, period.
I visited a client recently, a large company with global operations and a large application delivery organization. A senior VP in charge of a large part of that organization told me an interesting story about its experience with a change in the way it approaches EA over the past few years. In brief, he said:
“A few years ago our architects were mostly dispersed into various parts of the delivery organization; we didn’t have an EA group.
“Then we recognized that we needed an EA group to better manage our use of technology, so we pulled those people out of delivery and formed them into an EA group.
“Since then EA has spent a lot of time understanding our business, building capability maps, and focusing on a more strategic level.
“But now I’m hearing cries of anguish from the delivery teams that they don’t have enough direct engagement and support from the architects in their delivery efforts. The delivery teams are concerned that EA has moved too far away from the actual delivery of business value, that EAs are not helping enough, and that it’s harming the effectiveness of the delivery organization.”
Are you under increasing pressure from your business colleagues and sponsors to deliver more business value, faster, with higher quality? Have you been experimenting with new processes like Agile and new technologies like cloud as ways of meeting those objectives? Are you looking to transform your delivery capability, whether top-down or bottom-up?
If you answered yes to any of these questions, then you should pursue this special opportunity, which is open to all: next Tuesday, April 12, at 11 a.m. Eastern, I'll be delivering a webinar on Transforming Application Delivery, together with my colleague Diego Lo Giudice. Diego is one of the authors of our recent report on this topic, together with Dave West. I edited this report. I hope you can join us!
The right knowledge, delivered to the customer or the customer service agent at the right time in the service resolution process, is critical to a successful interaction. When done correctly, knowledge personalizes an interaction, increases customer satisfaction, reduces call handle time, and leads to operational efficiencies.
Embarking on a knowledge management project is hard. Concerns include:
Worries about cultural readiness and adoption. Many executives don’t understand how activities done by a knowledge team translate into real business outcomes and don’t support these programs with the adequate resources for success.
Concerns about making content findable. The best content is useless if it can’t be found when needed. “Findability” has to do with search technology, a solid information architecture, and giving users alternate methods to search for retrieving knowledge.
Questions about keeping content timely. Knowledge must be kept current, and new knowledge must be published in a timely manner so that it can be used to answer new questions as they arise.
Forrester published its most recent evaluation of B2B service providers in October 2009. At that time, the market was dominated by three large providers: GXS, Sterling Commerce, and Inovis. Shortly after this report was published, the consolidation began, with GXS and Inovis consummating a merger in December 2009. In June 2010, IBM announced that it had acquired Sterling Commerce, which was at that time the #2 provider of EDI VAN and B2B managed services. And last week, Liaison announced that it had acquired nuBridges (including its VAN, managed services, MFT, and hosted security capabilities). Bottom line, the market landscape looks significantly different than it did just 18 months ago.
What does this mean for clients who have significant EDI and B2B needs?
For starters, there is obviously less competition than there used to be, and this could lead to higher prices over the long haul (though the current economic problems are having a dampening effect on this so far).
Secondly, clients with a long-standing relationship with a particular provider may experience some service issues during the transition to the new organization, and we have heard some reports of problems in this area. Clients need to be diligent in holding new providers responsible for delivering the same level of service (or higher) than what they were receiving previously.
Clients should pay close attention to B2B service provider contracts that may be expiring in the next year and make sure to leave enough time for effective analysis of alternatives in support of contract renewal negotiations.
Hockey god Wayne Gretzky said, "I skate to where the puck is going to be, not where it has been." For application development professionals, three megatrends show you where to skate to be more successful:
Megatrend 1: Get faster. The recession that started in December 2007 created a hunker-down mentality. The sentiment for IT became: "We need to do more with less." As we emerge from the recession, albeit in an unresounding way, the new sentiment is: "We need to get faster." The pace of business change continues to accelerate, and that in turn has intensified the need for application development professionals to deliver and change applications faster. The industrialization of application development has failed. Scrap it. You must get faster, and that means changing your process, changing your technology, and changing your organization. Software development is more akin to making a movie than to making widgets on an assembly line.