Most, if not all, teams I have worked with (in the capacity as the Agile Coach in The Lab) do not know what truly matters to their customers. Through numerous planning sessions with key stakeholders from ‘the business’, they gather requirements for their product development. These plans sound great until you start asking a few questions, for example: ‘What are the biggest problems facing your customers?’, ‘How have you validated the requirements with your customers?’, ‘Will the proposed solution actually work in their context?’. Upon asking these kinds of questions, they quickly understand that the proposed backlog of work is frequently what the business wants, not what their customers need. Using design thinking approach and applying techniques for user research and validation, the teams had the opportunities to understand the need of real customers. Talking to a real customer isn’t that hard, but the insights can be quite profound.
What all of those “unicorns” have in common are flat organizations with small teams that are responsible for a product or feature, including receiving feedback from their customers and guiding the future of the product. ING decided to transform its business to be more agile.
The arrangement doesn’t mean EV owners need to run out and add a Hubject account. All of this should be invisible to the end user—Hubject’s actual customers are the charging networks or utilities. Its platform provides an API that different charging networks can use to make that interoperability painless for drivers. “Our software is middleware that runs between network providers in a hub architecture,” Glenney explained.
“For example, an OEM who wants all to be able to display charging stations on their smartphone app and infotainment system would connect to Hubject, and the driver gets real-time dynamic point-of-information of where chargers are, services around there, pictures of the charging station, and so on,” he said. “It will also tell the user if the charger is available, being repaired, and so on. As you drive around, you can access different charging providers as long as they’re on the network.”
Protecting customers in times of duress is the basic purpose of insurance, and yet only 57% of US online adults feel confident that their insurance company will treat them fairly when they have a claim. Poor claims experiences have immediate business effect. In the UK, 71% of property & casualty insurance customers would consider switching providers if they had a bad claims experience.
When GDS started in 2011, mobile apps were that day’s special on the fad menu. Ministers all wanted their own. Top officials thought they sounded like a great idea. Delighted suppliers queued up to offer their services to government. We’ll talk about apps in more detail later. For now, all you need to know is that GDS blocked 99% of requests for them. Government wasn’t ready for apps, because the people asking for them didn’t really know what they were for. They just sounded good. The blogpost explaining the apps policy, written by Tom Loosemore in 2013, quickly became the digital team’s most widely read post. 16 We have seen too many chief executives and department heads proudly explain their organisation’s pioneering work on artificial intelligence, say, while in the same breath conceding their back office systems can’t reliably pay employees on time. Or running pilots with connected devices while thousands of their customers still post them cheques. This is not to say that preparing for the future isn’t right and good. Responsible leaders need to keep their eyes on the horizon. The successful leaders are those who can do this while remaining mindful their view will be ruined if they step in something disgusting lying on the floor.
from “Digital Transformation at Scale: Why the Strategy Is Delivery (Perspectives)” by Andrew Greenway, Ben Terrett, Mike Bracken, Tom Loosemore
The benefits of ditching the paper driving licence have been clear for a decade, but because of a fear of change, fear of failure and, yes, fear of digital, it hasn’t happened. We’ve forgotten the art of the possible.
Source: On policy and delivery
In such scenarios incumbents risk ending up as “dumb pipes”, holding bloated balance-sheets and originating products such as mortgages and loans that someone else sells to consumers. If they were to lose the ability to build a brand and the transaction data needed to understand their customers and cross-sell, their wares would become interchangeable. Margins would be driven down, even as they continued having to abide by onerous banking regulations and hold balance-sheet risk.
“There are a million solutions out there to your technical problems, but what we wanted was to solve the people and process problems,”
“It depends on Pivotal. If they add a common pattern in the future for deployment with Istio and Envoy through a cluster and platform-agnostic service mesh, then, yes, we will combine them,” said another senior engineer at the carrier.
As always, with Jon, this is a great conversation:
Demonstrating the value of software, how it contributes to revenue, is no easy feat. Staffing can be difficult, especially with an eye to sustaining teams over the years. Jon Osborn returns as a guest to discuss these and other transformation hurdles, plus successes they’ve had at the Great American Insurance Group.
Making the financial case:
“This is going to sound silly,” he says. “The hardest part isn’t necessarily the refactoring. The hardest part is convincing people to do this. Because, let’s be honest the upfront cost can be very scary, man. It can be frightening. The business is going to say, ‘We just put in X amount of dollars last year to support these kinds of environments.’ You kind of have to ask the question, what’s going to happen five years from now?”
While the legacy application may not be “broken,” forward-looking companies will consider the lost opportunity costs that are inherent when an existing system is not agile enough to support new opportunities and initiatives.
“You’re going to have to have the conversation where you can’t integrate with cloud at all, or you can’t integrate with data analytics, or you’ve failed to do cognitive system and your competitors are because RPG can’t support this stuff?” Kleyman says. “But just because it’s working doesn’t mean necessarily it’s bringing value back to the business.”
It’s easy for an executive to identify problems when servers are down, the application is throwing errors, and the day-to-day business is being impacted. It’s much harder for the executive to be able to identify the ways in which a legacy system could put hamper growth in the future.
“Honestly that’s one of the best approaches, when things aren’t on fire, to start asking some of these difficult questions,” Kleyman says. “It’s kind of like in a relationships. When everything’s going great, you don’t want to bring up any sore points. But realistically speaking, you don’t want to start arguing when everything’s wrong and you start bring up the pain points.”
“Don’t get excited about shipping a feature—get excited about when the feature turns into revenue and turns into profit.”
Usually we’re told that improving IT means changing the old organization. I’ve been re-reading The Art of Business Value, and re-came across this, to the contrary:
This way of thinking has always struck me as a little strange. Our goal is to deliver value, to figure out how to meet the needs that are determined by the organization, and yet we consider the organization to be the biggest impediment to doing so. The only explanation I can think of for this is that we are implicitly assuming that there is a stable, objective, preordained definition of business value, and we are determined to deliver on that definition despite the organization around us. In my experience, this arrogance is not warranted; in fact, the organization probably understands value in ways that the Agile team does not, and the obstacles to Agile adoption actually tell us something useful about business value in the organization.
Because, in fact, the organization knows the “business value,” the strategy, it’s in charge of reliving:
The organization has had to learn what business strategies, values, protocols, and behaviors work in its environment to support its ultimate aims, whether those are maximizing shareholder value or accomplishing mission objectives. That learning forms the basis of tacit assumptions and norms, the organization’s collected wisdom about what behaviors foster success. And if success means accomplishing the ultimate goals that serve as the sources of business value, then the Agile team must come to understand those values, strategies, goals, and operational modes that are embedded in the culture around it—that is, the business values that have been known to foster success.
Strategy involves determining the company’s intent. Strategy is expressed in an understanding of the environment, an expression of ambition, decisions regarding the allocation of resources and plan of execution. Strategy provides a perspective on where and how the company will win from the inside out.
Design entails understanding and expressing customer intent. Expressed in terms of persona’s, needs, journey maps, touchpoints and prototypes. Design provides a perspective on how and why customers win from the outside in.
Source: Digital, Strategy and Design
One of the global leading banks created about 30 platforms. One such platform was payments, which consisted of more than 60 applications that previously had been managed independently from each other. The top team decided to bring the 300-plus IT people working on development and maintenance of payments together with the corresponding people on the business side. Under joint business/IT leadership, this entity was empowered to move quickly on priority business initiatives, to modernize the IT structure, and to allocate the resources to make that happen.
The team shifted its working model and started running the payments platform as an internal business that served all the different parts of the bank (think payments as a service). This approach made it clear where to focus specific tech interventions: removal of nonstrategic IT applications; modernization and accelerated shift of the target applications into the cloud; connectivity to enable swapping solutions in or out easily; and, most important, a major step-up in feature/solution development for the internal business clients. This platform-based way of running the business was then progressively rolled out across the group. Prioritization is set by the top team (because empowerment does not mean anarchy), and all IT interventions are run the same way, to ensure consistency and replicability.
Their notion of a platform is more like the old API economy thing:
A platform-based company will have 20 to 40 platforms, each big enough to provide an important and discrete service but small enough to be manageable. To simplify platform management, it helps to group them into three broad areas: customer journeys, business capabilities, and core IT capabilities (Exhibit 1).
For example, in personal banking, the customer-journey platforms cover the customer experiences of searching, opening an account, getting a mortgage, and so on. The business-capability platforms deliver the banking solutions, such as payments and credit analytics, and the support capabilities, such as employee-pension management, visual dashboarding, and management information systems (MIS). Finally, the core IT platforms provide the shared technology on which the journeys and business capabilities run, such as the cloud platform, the data analytics environment, and the set of IT connectivity solutions.
1) Enterprise computering considered difficult.
2) Be careful what wish-contract for.
3) Agility is expensive if your budget cycle is on years.
4) Maybe hire your own people?
These low-ball estimates are sometimes provided by consultants working to get their foot in the door, or by executive sponsors working to gain approval for their programs. Excluding low-ball estimates, the primary cause of poor estimates tends to be a lack of experience and background of the leader.
To improve the way you do software, I recommend starting up a new organization. It’s not always the right tactic, but it probably is if you’re having problems changing the “culture” at your organization.
Duke Energy has had success with this approach over the years. In one of my recent Pivotal Conversations podcasts, I talked with John Mitchell, who’s been involved in their transformation over the years. They’d just opened a brand new (well, renovated from an old factory) office to host the existing teams (something like 4 or 5 if I recall) and the supporting teams.
Here’s a summary:
Duke Energy has been working on their software capabilities for some time now. They’ve recently reached a milestone by opening a brand new innovation center in Charlotte. Coté took a tour of it recently checking out the numerous product teams and their approach to exploring and building strategy, all the way from corporate strategy down to writing code. John also shares a couple of new examples of how lean product management and design in action. Also: gingham.
An IoT use case, for tracking cows, that actually helps out the business (in addition to the customers, the ranchers):
Rabobank’s network and financial support helped mOOvement enormously, says Van de Ven. The bank has also benefited from the product. Van de Ven: “Nowadays, you can use satellite images to determine the condition of the grass. Combining that data with precipitation patterns and the GPS data from the cows generates interesting insights for both the farmer and the bank, such as the cows’ condition and what the ideal number of cattle is to graze on the land during a particular period. Using up-to-date information means the bank can make better decisions about financing requests than if it were to use the annual figures from the previous year. MOOvement enables us to serve not only the farmer, but also the bank.”
I’m always trying to find a reference to Linda Rising’s cake law. Here it is!
Original source: Where there’s cake, there’s success