As Forrester has pointed out in past research, to move forward in a product-centric way, you must establish a number of capabilities in your organization in a product-centric operating model:
I used to make a living doing product management and running product management organizations, as did a number of people at Forrester. My perspective on product management is somewhat distinct because I started out on the product engineering side, leading product development organizations. But between my first ISV and my second, I saw the contrast between weak, ineffective product management and strong, effective product management. When strong product management is in balance with an effective engineering group, well aligned, it’s a beautiful thing to see. The weak option? You don’t want to know – it was too painful to remember.
Is it hard to focus your software delivery organization on the right things? Do you sometimes deliver the wrong features or give too little priority to the most important features? Are you drowning in the cost of too much redundant software, because stakeholders can’t get on one page about what the business really needs? Do you struggle to make the case for investments you know are essential to your long-term survival but that deliver few short-term benefits? If so, consider the benefits of running your shop more like a business by reorganizing to deliver products (or value streams, in Lean lingo).
It’s been more than two years since we last surveyed software delivery leaders about their increasing tendency to organize to deliver software as products (rather than projects or application functional areas), but even then this trend was well under way:
I have only anecdotal evidence that this trend is continuing to grow, but I’m convinced by hundreds of interactions with top software delivery leaders since we did this survey that it is, especially for people who deliver customer-facing websites and mobile apps. Customer-facing dynamics are also driving this trend for the “Internet of things” among firms focused on Smart Grid and other similar domains that depend on customer adoption to drive success. What are the factors driving this growth?
Just over 3 months ago, I made note of three things I'd tell your CIO, all of which focused on your need to build a software development competency to help your firm thrive in this age of software-fueled, consumer-led disruption. Since then, we've heard from a number of clients stating that they're having a tough time convincing their executives, from COOs and CFOs through to CIOs, that they need to stop looking at software and app development as a commodity.
Vendors you work with aren't helping. System integrators and consultancies continue to tell your CFO and CEO to outsource your software development work to them, that they can deliver more quickly, and more cheaply, than you can. Software application vendors build their marketing around needing no customization, even "no software." This helps fuel the perception and myths many executives hold that software development, especially app dev, is a commodity.
Recent research published by Phil Murphy and survey data we recently collected in our Forrsights Software Survey, Q4 2011 can help you bust those perceptions and myths and help you show your executives the importance of software development.
The story of Agile is more than just one chapter in the history of software development. It's also an extremely valuable case study in innovation, an elusive and often humbling process that doesn't work in quite the way that we instinctively think it should.
The trajectory of Agile points toward increasing the value of the software delivered. However, it started with no metric of value and almost no notion of what happened outside the development team. Instead, the first phase of Agile, as I describe in the recent publication "Navigating The Future Of Agile And Lean," focused primarily on changing the behavior and world view of developers working together in a team. Therefore, you won't find anything in Scrum or XP that says, "This is how you know your software is better." Instead, these methodologies told you how to work more effectively as a team. Presumably, better results would follow.
Engineering methodologies have been around for a long time. They've not been noticeable for being terribly successful. They are even less noted for being popular. The most frequent criticism of these methodologies is that they are bureaucratic. There's so much stuff to do to follow the methodology that the whole pace of development slows down.
Think of a medieval fortress: It was originally used for a small army, it has walls nine meters thick, and it’s surrounded by buildings hundreds of years old. Upon entering, you are confronted with the concept of eternity.
This fortress is located in the smallest state on earth — though it is also perhaps the best-known state in the world. The business housed within the fortress is what many might classify as a SME but with with complexity of a large enterprise, holy but busy, centralized but truly global — its work spans hundreds of countries with hundreds of currencies and hundreds of languages — and it serves very special and demanding clients.
Have a clue yet of where we are?
Zoom on Italy, then zoom on Rome, then zoom on Vatican City, and you can’t miss the round tower (Torrione Sisto V) where the Vatican Bank, or Istituto per le Opere di Religione (IOR ), is located. You won’t be allowed in if you are not a client, an employee, or part of a religious congregation. Change comes hard to institutions this steeped in tradition. To give you a clue, IOR’s previous managing director spent his entire career at IOR — 60 years — and retired at the age of 80. We all know it’s the soft and cultural aspects of transformation that are the hardest part for any organization.
Nevertheless, IOR has been going through a major change since 2008, working to replace its legacy IT system with a modern BT one. The new BT system brings more flexibility for the business, richer business functionality, and greater integration and development capabilities. Enabling fast change is the key driver for IOR’s IT transformation program from IT into BT.
In talking with nearly 30 organizations, consulting companies, and solution vendors, I found that instead of deploying slow-to-change packaged applications or building difficult-to-change custom solutions, leading organizations are embracing business process methodologies — supported by process-centric IT platforms. They are striving to drive rapid process change, increased business engagement in IT projects, and achieve dramatic improvements in worker productivity.
In my new report, I define more than 30 best practices that organizations can use to support their transition to process-centric customer CRM. Here are few of them:
What are the key trends that CRM trends that business and IT professionals need to pay attention to in setting their plans during 2012? Here are the top trends that I am tracking. My full report that spotlights our latest research and recommendations for how to compete in The Age of the Customer will be published in late January.
1. Customer experience management will move beyond aspiration to strategy. More organizations will move beyond empty goals like becoming “customer-obsessed” to define clear and actionable customer experience strategies. The strategy must meet three tests: 1) It defines the intended experience; 2) it directs employee activities and decision-making; and 3) it guides funding decisions and project prioritization.
2. Brands will embrace the experience ecosystem. Firms will move to break free from their organizational silos, invest in understanding customer moments of truth through journey-mapping, and embrace the concept of the “customer experience ecosystem” — one that considers the influence of every single employee and external partner on every single customer interaction.
3. Experience management will emerge as a management discipline. There is increasing acceptance of the idea that customer experience management can be thought of as a discipline — a set of sound, repeatable practices such as those are defined in Forrester’s Customer Experience Maturity Framework.
Ultimately, customers don't judge you based on how well you gather business requirements, choose development technologies, manage projects, or march through the development process — they judge you based on how they feel before, during, and after they use your software. This is the digital experience. If you get the customer experience wrong, then nothing else matters. And expectation inflation is sky-high thanks to the Apple-led smartphone revolution. To succeed in the new age of digital experience, application development professionals must collaborate with their business partners and customers to create experiences that customers love. You need a new approach represented by these five axioms:
Software is not code; it creates experience.
Development teams are not coders; they are experience creators.
Technical talent is table stakes; great developers must be design and domain experts.
Process is bankrupt without design; you get what you design, so you had better get the design right.
Software is a creative endeavor, not an industrial process like building automobiles. Structure your methodology to empower your creative talent.
From: Forrester Analysts Tom Grant and Diego Lo Giudice To: App dev and delivery practitioners, especially ones with Agile experience Re: It’s time for us to take another look at the value adoption, and we’re inviting you to join our survey
For example, Scrum is far and away the most widely adopted flavor of Agile. Scrum focuses on how teams organize themselves and how they organize their work. For teams that have struggled to make accurate estimates or adapt to changes to the backlog, the attraction of Scrum isn’t just velocity.
My colleague and friend Mike Gualtieri wrote a really interesting blog the other day titled "Agile Software Is A Cop-Out; Here's What's Next." While I am not going to discuss the great conclusions and "next practices" of software (SW) development Mike suggests in that blog, I do want to focus on the assumption he makes about using working SW as a measurement of Agile.
I am currently researching that area and investigating how organizations actually measure the value of Agile SW development (business and IT value). And I am finding that, while organizations aim to deliver working SW, they also define value metrics to measure progress and much more:
Cycle time (e.g., from concept to production);
Business value (from number of times a feature is used by clients to impact on sales revenue, etc.);
Productivity metrics (such as burndown velocity, number of features deployed versus estimated); and last but not least
Quality metrics (such as defects per sprint/release, etc.).