This is a roll-up of all Forrester blogs written for . Role-specific blogs are listed below. Visit Forrester.com to learn how we make successful every day.
Never has a new trend annoyed me as much as Agile. Right from the get-go, the Agile Manifesto revealed the weaknesses and immaturity of the founding principles. The two most disturbing: “Working software is the primary measure of progress” and “Business people and developers must work together daily throughout the project.” These are
Most Forrester readers certainly understand the importance of empowering their employees to contend with highly informed and increasingly demanding customers. But I’m often asked just how to overcome the process and data integrity challenges of apps or services that empower employees and/or drive continuity of experience for consumers across channels. With the rise of mobile as well as web and call center interactions and with a proliferation of new tools for managing distributed processes and data, most application development and delivery professionals as well as their business process and applications colleagues have to absorb all the arguments before they make decisions that could be critical to their firms’ futures – to say nothing of their own careers.
One pioneer whom I interviewed was immensely proud of his lightning rollout of a guerilla app to support his firm’s front office in advising clients on complex product choices. I asked him about future plans and sheepishly he admitted they would be starting again from scratch because the guerilla app was unable to leverage enterprise services exposing critical data about product offerings. He remarked ruefully that sometimes you do have to follow the IT standards “yellow brick road” rather than just head for the hills, but wouldn’t it be great to have the best of both worlds, with both agile deployment and full advantage taken of enterprise assets and data?
If you need a deeper understanding of the issues and options, then I’d like to invite you to join us at Forrester's Application Development & Delivery Forum, where my colleague Clay Richardson and I will discuss in practical terms how to deliver integrated experiences across multiple touchpoints.
Marketing planning has changed little in the past century. It's essentially a linear process built on the development of rigid 12-month plans built around brand and channel metrics. This approach is coming increasingly under strain as the combined effects of the growth of digital marketing platforms and a volatile economy demand marketing plans that deliver clear business outcomes and can adapt and improve to meet evolving market dynamics.
Over the past 12-18 months, we have come across several marketing organizations that have decided to do something about this situation and look for new ways to improve their approach to marketing planning by adopting some principles borrowed from a relatively new methodology originally conceived for software development efforts: agile development.
From the interviews that we did with marketers that are experimenting with this new approach, several of the key principles of "agile" development looked particularly relevant to innovating their approach to marketing planning:
A clear definition of business outcomes and associated business metrics
Complexity is the nemesis of application developers everywhere. While software products' complexity may be, to a great extent, unavoidable, we don't have to complicate software development to match it.
That's the conclusion driving many of the new approaches that app dev teams are embracing. For example, Agile breaks down humongous, complex projects into incremental deliverables that are far easier to scope, build, test, and deliver. Lean practices simplify processes, making it easier for teams to achieve a state of flow. DevOps advocates are trying to eliminate the needless complexities that result from throwing software over the wall from one team to the next.
But there's more to Agile, Lean, and DevOps than just a common enemy. It's no accident that practitioners often speak of this trio in practically the same breath. The Kanban board is the symbol of this convergence of practices. Here's an increasingly common use case: an Agile teams uses a Kanban board to manage work with other groups, including the DevOps team.
The evidence for this convergence is more than just anecdotal. When we survey app dev professionals, they report that they're mixing methodologies all the time, including Agile and Waterfall. For a variety of reasons, Agile teams have made the adjustments necessary to accommodate Waterfall. Not every planning activity at the beginning of a project can be handled in a strictly Agile fashion, and not everyone involved at the end of the project (release management, operations, and business users) is necessarily sold on the idea of rapid, continuous delivery. If you work in a regulated environment, you're required to take extra steps at the beginning and end of a project.
Fiction writers I've met have said that the hardest section of a novel to write is not the beginning or ending but everything that happens in between. The middle chapters trace the course of the protagonist's struggle in way that must be both engaging and credible. The story of how people adopt Agile successfully also has a beginning, middle, and end. The middle part here, too, poses some of the most difficult challenges. The first chapter is a grabber, with teams energetically and fervently doing daily stand-ups, blazing through sprints, christening a product owner, prioritizing their backlogs, and living through all the other exciting events that happen at the very beginning.
And then the plot takes a different turn. Success at the small team level is fantastic, but how do you fit into a development organization? What if you need to work with an offshore team? How do you maintain velocity when builds take several hours or maybe even a full day? Is it possible to deal with compliance requirements without a significant amount of automation? How do you work better with the ops team so that the speed of deployment matches the speed of development?
Since Agile went mainstream, the number of teams reaching the difficult middle chapters of Agile adoption has increased markedly. Both I and my colleague Dave West answer questions about the middle phases every day. Many of these questions also arise during the yearly conference that the Agile Alliance holds in the US. (This year, it's in Salt Lake City to mark the tenth anniversary of the signing of the Agile Manifesto in nearby Snowbird.)
In my previous post about Agile practices and compliance requirements, I described the first of two big surprises encountered while doing the research. Compliance, as it turns out, is not quite as high a barrier to Agile as we thought. The second surprise has to do with the approach teams have developed to getting over or around that wall.
Leaving Scrum, Sarbanes-Oxley, and related concerns aside for the moment, a hot topic these days in app dev circles is product-oriented development. While teams in IT departments might have different motives than ISVs, systems engineers, or people in other situations, they're all interested in roughly the same thing. What it takes to qualify as a product may not be altogether clear, and there may be no definitive way of measuring whether your team's thinking and behaviors have shifted from project-centric to product-centric. As rough-hewn as the concept of product-oriented development might be, it's still an attractive destination for people coming at it from multiple directions. (Not coincidentally, this is the topic of a soon-to-be-published doc.)
In an unexpected way, many of the app dev teams that have been most successful at dealing with compliance are, as it turns out, acolytes of the product-oriented approach. They may not realize it, as their work output may not be any more productized than it was before. Instead, compliance is what turns into a product.
Now that Agile has moved into the mainstream, it is encountering a whole new raft of challenges, including compliance. The word on the street for at least the past couple of years is that trying to be Agile and satisfy regulatory requirements is a lot like juggling chainsaws and machetes: theoretically possible but certainly not advised.
Fortunately, the word on the street is nearly always wrong. When I started interviewing people who had made Agile succeed in highly regulated environments, I expected to hear a lot of handy best practices that I could synthesize into a research document — essentially, a tactical guide to compliance. If you're a medical device company and you need to document six ways from Sunday how you validated and verified the software embedded in a new device, here's what you might do. If you need to deal with the auditors, here's where an investment in an application life-cycle management (ALM) tool might help.
Although this type of research depends on interviews, it's worth taking a peek at the available survey data to see if it has any additional insights. And boy howdy, am I glad I did. Sifting through the data collected in the survey that Forrester did in conjunction with Dr. Dobb's Journal, I found the first of two big surprises about Agile and compliance:
Agile adoption in the most regulated industries is not significantly different from the adoption rate everywhere else.
With the increasing richness and complexity that digital channels and social media bring to the marketing equation, senior marketers increasingly realize that, to be relevant in shaping their brands’ interaction with customers, their teams need to embrace new technologies with the help of the IT group.
In my latest joint research effort with my fellow analyst Nigel Fenwick from Forrester’s CIO role, I explore how marketing and IT can successfully work together in enabling organizations to master the customer data flow.
Our early findings were not very promising . . . What clearly emerged from our interviews with CMOs and CIOs was how deeply ingrained the stereotypes about the two teams are. We heard that:
IT is the department of “no” and does not care about customers or what’s happening in the market.
Marketing is having all of the fun and spending money without rhyme or reason.
It feels as though the word "value" has appeared in more discussions about software development and delivery than in the previous two decades. We see this increased demand for immediate, tangible value across the entire range of technology producers and consumers. The dubious value of legacy applications, which have grown like kudzu, is the impetus for many painfully difficult cutting and pruning jobs within IT departments. Faster realization of value is driving more applications and infrastructure into the cloud. Software vendors are realizing that, while revenue is vital, the long-term relationship with the customer depends on the mutual value that both parties think they're getting from the relationship.
If we measure software by value, instead of cost, revenue, completeness, or other possible measures, we have to measure the software development process in a complementary way. What characteristic of software development is most likely to generate a valuable result? If your answer is "speed," think again. Predictability is a much better measure.
At the IBM Innovate conference last month, Walker Royce made a very plausible case for valuing predictability over velocity. Here's his keynote address, which is definitely worth watching.
Recently two colleagues of mine, Patti Freeman Evans and Martin Gill, put their respective cities’ shopping meccas to the multichannel test. The question: To what extent were bricks and mortar retailers on Fifth Ave in New York and Oxford Street in London using their physical stores to advertise and promote their digital channels?
Eager not to be left out...and curious to see how my city of Chicago would fare…I paid a visit to our world famous “Magnificent Mile” to see if/how bricks and mortar retailers promoted a connection to their own digital channels.
As I walked both sides of Michigan Ave (home to retailers such as Northface, Macys and Gap…as well as high-end retailers such as Tiffanys, Louis Vuitton, and Chanel)…I thought to myself, would Chicago be different from London and New York? Would America’s heartland have a better feel for a large and growing number of shoppers today who may physically “be” in stores but whose shopping “attention” may reside elsewhere?
Some findings:
Traditional Brands Disappointed. Count among this grouphigh-end/luxury brands and more established brands (e.g. Louis Vuitton, Macys). Which is not to say that all youth-oriented brands excelled (e.g. Zara, Disney)…in fact, a surprising number of them failed to show their multichannel chops (e.g. no URLS in store, no discernable mobile presence). For example, The Disney Store was heavily promoting the “Cars 2” movie on monitors in its store, but I could not find any links anywhere to their content-rich website.
Complexity is the nemesis of application developers everywhere. While software products' complexity may be, to a great extent, unavoidable, we don't have to complicate software development to match it.
Fiction writers I've met have said that the hardest section of a novel to write is not the beginning or ending but everything that happens in between. The middle chapters trace the course of the protagonist's struggle in way that must be both engaging and credible. The story of how people adopt Agile successfully also has a beginning, middle, and end. The middle part here, too, poses some of the most difficult challenges. The first chapter is a grabber, with teams energetically and fervently doing daily stand-ups, blazing through sprints, christening a product owner, prioritizing their backlogs, and living through all the other exciting events that happen at the very beginning.
In my previous post about Agile practices and compliance requirements
