Jana Werner, Tesco Bank – “Tesco Bank has embarked on a digital transformation journey, and at the heart of it lies a shift of culture and the adoption of modern product development practices. What could go wrong? Everything! Culture, leadership, bureaucracy, route to production, you name it. Yet, with the help of VMware Pivotal Labs, we delivered an amazing product during a time of great need for our customers: a digital gift card allowing volunteers to shop for self-isolating and vulnerable customers, while creating our very first cross-functional Product Team, now scaling out rapidly with enthusiastic people and full exec sponsorship. If you’d like to learn what it takes, what not to do, and how to fast-track your digital transformation, don’t miss this talk.”
BT wants to get better at how their do business, through software. Their strategies are, of course, operational excellence, but also getting software that improves the customer’s experience. This means they need to simplify how business is done, which they did by transforming the way they do software: IT underpins this corporate transformation, Rajesh says.
His approach to telling this story is to talk about how BT questioned some initial assumptions. On some of their initial plans, they pivoted (adapted) when they discovered new needs and realitis. On others, they persisted when they really needed the change. For example, at first, they thought that having a PaaS would be good enough for all development and app needs.
A pivot example: they discovered that more fine grained control was needed for some apps (esp. legacy ones), so they added in kuberntes. Here. PCF/TAS and TKG.
A persist example: security had to move from security by static IP. Because they were moving to AWS and microservices, things needed to be more dynamic. There was no way to achieve their tech-stack transformation otherwise. So, they persisted.
The third area he describes is their approach to removing ops toil from application developer’s agenda. As ever, they want apps developers to focus on…apps! And have time to explore and innovate making the apps better to deliver on customer service goals. (You see several example from Comcast on this with their new TV apps and improving customer service with ChatBots, and even in-home wifi coverage calibration, etc.) He also comments on a discovery, or validation of a predictable state, in my rewording: developers aren’t good at production ops and don’t really realize all the new tasks they’ll need to do – responisbilities they have! – in a DevOps model. So, they had pivot to training them and putting in place tech stuff to make it work better for them.
He has some fantastic framing: "instead of letting [developers] grapple with operating model choices, we adopted a more human-centric approach to educating teams."
He touches briefly on some portfolio modernization strategy. The benefits of doing, I think, were that they spent their time wisely, modernizing apps that were feasible and valuable to modernize instead of all of them. I could use more detail here, but I think the point is made – I mean it’s a five or six minute talk, so it’s fine. For a lot more, check out the ever excellent Rohit explaining this kind of portfolio app modernization analysis.
BT business – Fixed line, mobile TV, and networking.
Lead in converged activity by simplifying business.
Build scalable platforms for growth.
Creating leaner business models.
IT underpins this corporate transformation.
"The challenges arise from our ways of working, process, account policies, security postures, and even we inventory software assests."
Three challenges and how they worked with them:
A PaaS, PCF/TAS with Spring – time to deploy from 2 months to 2 minutes. Also, microservices.
But, people wanted kubernetes for finer grain control, and needs for non/fuzzy cloud-native apps. Used TKG for this.
Listening to devteam
Moved from static IP to static IP, public IP addresses.
AWS networking needs, i.e., elastic IPs and REST endpoints.
"They also were not fully aware of the [new] shared responsibilities of managing infrastructure as code, or how their roles changed when adopting the cloud."
E.g., with a more DevOps approach, "their responsibilities did not end with a cf push."
Enterprise architects looked through portfolio to bucket apps into legacy, strategic, SaaS, PaaS, and IaaS to plan out the way of working, priorities, app modernization tasks.
Drives concensous on "application treatment" and how to educate teams on their roles and new skills.
Also, this eliminates scope overlap in our budgets and app modernization plans, allowing the PaaS team to focus on executation, [instead of work that wasn’t applicable to the various apps strategies and bucketing].
Rajesh: "What really happens is you’ve got to tease out what is containerizable"
"To overcome this challenge, BT has established a platform team, dedicated to helping application teams identify these containerizable elements and find the best environment in which to host them, be it in the public cloud or on a platform-as-a-service (PaaS)."
Rajesh: "You have to handhold them, otherwise they will take the biggest unit they can handle, put that into a Docker container and then lo and behold you’ve got the same monster on better infrastructure — that doesn’t solve your business problem."
"This is a constant tussle," he admits, "where people want Kubernetes by default, but I think you’ve got to be a bit more prescriptive in the beginning to developers and then as you see them maturing, have them make those independent choices."
"the next task is to scale it out via documentation and word of mouth buzz, both for in-house engineers and with external partners."
Rajesh: "If you look at how standards are democratized, you’ve got enterprise architecture that looks at the overall architecture standards and policies, then you have solution architects, who are a level down and are specific to a product, and finally we have distinguished engineers — we call them expert engineers — who are also key influencers for other developers, who look up to them."
The report goes over how software development needs and programs should adapt to the urgency that COVID brings. Highlights:
Obviously, teams are working from home more now. This exposes all of the face-to-face, undocumented processes that were happening (“manual processes address handoffs across departmental boundaries”). If there were too many, work can’t happen as well anymore when everyone is working from home.
“The trend catapulted use of Zoom, a videoconference service, from 10 million average daily users to 200 million during March 2020 and introduced us to our coworkers’ tastes in home décor.1 But it also separated millions of workers from the paper files they require to complete their missions, breaking millions of business processes. Paper files are an obvious point of failure, but manual processes based on desktop tools like excel and email lack visibility and tracking that are vital to remote workers.”
Paperless efforts are really on the front-burner now: “any enterprise relying on paper to advance its processes needs to automate just to continue to function.”
Also: “Topping the list for most now are tracking and tracing applications: tracking of employees, people entering hospitals and other sensitive buildings, equipment, facilities, patients, tests, research results, and on and on. These applications are not throwaways; they’re business-critical. and in the public sector, throw in new apps to manage new support, recovery, and stimulus programs or support existing programs straining under unprecedented volumes. Then in financial services, you have new servicing apps: servicing debt, defaults, new rescue programs, moratoriums, etc. (rather than new customers and new products and services). and any enterprise relying on paper to advance its processes needs to automate just to continue to function.”
And, more app types:
This urgency is driving business people to (finally) start getting involved more in IT/software: “as organizations scramble to fix processes and rapidly automate to keep them running, it becomes clear that businesspeople are the primary source of operations insight…. Bringing businesspeople closer to the development process through iterative, rapid prototyping and sometimes allowing them to develop solutions on their own offers promise for much faster and more agile responses to business needs.”
With apps being used remotely (as a SaaS, over the internet), organizations will likely discover new scaling needs – when the apps run outside the corporate network, and are home grown. “Scale becomes a vital focus. Many development teams are getting their first glimpse at what massive scaling looks like for their applications.”
Companies are overworking staff: “a us hospital network made Java developers scramble 24×7 for 20 days to create a visitor registration application to extend its hospital administration system.” [This isn’t sustainable and if done too much will leave a bad taste in staff’s mouth about “agile” and “digital transformation.”]
The authors really like and recommend low-code stuff. This probably makes sense to get a lot of line-of-business people to start putting together wizards and UI-driven workflows around databases, Excel/CSV, and APIs to ERP systems.
I like to track CI/CD* surveys as an indication of far along organizations are doing at getting better at software: “digital transformation” where the main focus is using software to improve how you do business.
If you’re not doing CI, you’ll have a hard time getting better at doing software, or, really, doing good software at all. I
Anyhow, here’s one chart I put together based on the State of Agile surveys:
The data isn’t perfect, scientific, or whatever. But it’s a good rhetorical device. Also, it matches up with other surveys on this topic (from the likes of Gartner and Forrester).
The general take is: CI has plateaued, but it’s high; CD has been slow to catch on and still has only minor growth in adoption year over year.
So, if you think you’re doing agile, there’s a good chance you’re not. Go do a walk-about and see what’s actually happening and make putting CI/CD in place a priority if you’re not doing it. Otherwise, all your other efforts to get better at software will fail and be a waste.
Five self-checks executives should do to make sure they’re transforming how they’re managing. Check out the free books mentioned at cote.pizza. Come hear first accounts of THE_DIGITALS at Spring One, Sep 2nd & 3rd, all online, & all free. Register now!
So when you’re transforming your organization, it’s important not to lose sight of this. You’re transforming yourself, the manager and the executive, the people who are doing that organizational transformation. Here’s 5 things you should check on to kind of be a dipstick if you will. If you’re changing yourself one the format of your meeting should change. You’re not only getting status updates of what’s happening, but you’re learning how the product has changed new understandings of the customer.
An getting a sense of how the product is helping the business. You should also be changing the people you talk with. You’re not just talking with your direct reports, but you’re talking with product managers and other people. Maybe even audit people as you’re trying to clear the way for automating more of compliance. You should be thinking about how the things you measure change not only technical metrics. Time to close bugs and.
Time to deploy, but metrics about how your software is improving the way your business functions. Things like customer satisfaction, revenue, the time it takes to fill out a mortgage application, and the time it takes to refill a prescription. You should also be encountering customers a lot more end users having that same empathy for what people are doing with the software that you want your developer teams to be having.
And finally, you should be delegating a lot more. Instead of using your meetings and your managerial position to make all of the decisions or to make the crucial decisions. Many of the decisions are pushed down to the actual teams who have weekly, daily familiarity with the business in the software, and they’re the ones that should be more and more making decisions that you probably were more comfortable making in the past. So if you look at those.
Kind of go through those every now and then. Make sure that they’ve changed from your pre transformation time to see if you yourself are actually changing.
Transforming to a more agile way of doing software might be easier in times of crisis, and probably a better approach. For more, check out my book, The Business Bottleneck for more & hear tales of thriving at SpringOne Platform, this September 2nd and 3rd.
Whatever you want to call it, “legacy” software is a problem. In one of our recent surveys, 76% of executives said they are too invested in legacy applications to change how they do software. It can seem hard, but fixing that blocker is possible. As with all things in software, there is no quick fix, it just takes discipline, work, and time. In this episode, Coté talks with VMware Tanzu’s Rohit Kelapure who’s been working in application modernization for years. He goes over the initial portfolio analysis and thinking that the Pivotal Labs application modernization teams walk customers through.
Jana Werner and Barry O’Reilly have a great case study and commentary of transformation at a couple organizations, primarily a bank. I was lucky enough to get Jana on for an interview on Software Defined Talk, talking about the case, information theory, and Nietzche. It should be in the podcast feed next week.
Here’s some of my highlights:
“In one Financial Services organization we’ve been able to implement an increase to contactless card payment limits in days where the previous increase took months. We stood up a work from home solution for call centre staff, automated processes and relieved pressure on teams having to manually capture customer data over the phone in 3.5 weeks—a record for service delivery and a credit to the teams and individuals who made this possible.”
Focus on the outcome, not following the process, or working a lot: “The subtle yet powerful shift to outcome-based measures of success — reducing and resolving customer issues — over traditional output-based deliverables of being on time, budget and scope had a pronounced impact on productivity and employee satisfaction.”
When the meeting (the bureaucracy) becomes the product: “Slide decks, paper proposals and steering group sessions all take a significant investment to prepare, avoiding “difficult” conversations by socializing and re-socializing in advance of exec meetings, deferring decisions, requesting a raft of meeting minutes to document, correcting, amending and signing them off—the majority of which few people read.”
This effects how the entire organization runs, and, indeed the pace of delivery: “The speed of these cycles determines the heartbeat of the organization.”
Management starts asking different questions: “Responses can now shift post-release from ‘How could you have got this wrong?’ to ‘What is our next best action?’ Seeing how shipping smaller slices allows us to iterate, also means leaders can set direction and monitor metrics over setting targets and failing anything but perfect results.”
Often, management has failed to build a system (vision, strategy, norms, “culture,” etc.) that makes staff’s job clear. That’s a problem! “Test your strategy cascade methods to maintain the clear purpose, problems and outcomes teams are working towards. Ask teams if there’s a clear line of sight between the objectives, and how their work contributes to achieve your shared success. If they can’t see it, fix it. Maximising both organizational alignment and autonomy can be the biggest accelerant for sustainable pace, employee engagement and amazing customers experiences.”
And: “The biggest hurdle to change is people not believing it’s possible.”
Developers often know what’s slowing them down better than executives. So, like, if you’re a manager, don’t let that happen. Go check on what’s actually going on in the organization instead of just what’s going on in your status meetings. Get the more details and free books mentioned at cote.pizza.
The bank will create agile teams where “product owners in business and infrastructure divisions will lead teams of technologists, using agile principles, to continuously work on products and ensure progress meets their expectations”.
It will also increase the proportion of software engineers in the workforce and better support and motivate them, as well as “reduce the burdens that slow them down.”
The vast majority of CIOs expect to deploy new technology stacks in the next 12 months. Most CIOs said they are already using or are planning to deploy microservices (88%), containers (86%), serverless computing (85%), PaaS (89%), SaaS (94%), IaaS (91%) and private cloud (95%) in the next 12 months.
CIO responses captured in the 2019 research indicate that lost revenue (49%) and reputational damage (52%) are among the biggest concerns as businesses transform into software businesses and move to the cloud.
“The goal is to continue building the engineering team to focus on building technology that allows restaurants to operate at a higher efficiency,” he said.
Most of the technology focuses on back-of-house operations, though Newlin declined to share details about that technology. On the front end, customers place orders using kiosks or its mobile app. A large screen then displays the customer’s name next to a countdown, which indicates exactly when an order will be ready.
“The general idea is figuring out how to run a restaurant based on statistics,” he said. “In the long term, we’re going to be running every piece of technology that touches on the customer and employee experience. We’re building a technology platform that will be the entire Birdcall ecosystem.”
Take-up was as we had expected – at peak times better than we’d expected – and it’s clear that not all our customers are ready for a totally till-free store. Some customers preferred to pay with cash and card, which sometimes meant they were queuing to use the helpdesk, particularly at peak times of day. This is why we’ve added a manned till and two self-checkouts back into the store so those looking to pay by cash and card can do so quickly and conveniently. We want to be the most inclusive retailer where people love to work and shop, so it’s really important to us that our customers can pay how they want to…. We’ll take the learnings from this experiment to develop our technology even further to help make shopping easier and more convenient for all our customers.
A competitive arena, as opposed to an industry, is used as a primary lens through which to understand the world and therefore what the effects of a potential inflection point might be. Think of an arena as a definition of the setting where customer need connects with company solution to create value. An arena can be seen as super sized and strategic use cases that enable an organization to concentrate on what is really going on. It provides a tool with sufficient scope for meaningful change without falling into strategic paralysis. This is one idea that make the book worth the read.
.As they mature, digital startups are now turning their attention from customer acquisition to becoming profitable. With no branch networks and legacy IT systems, digital challengers have a substantially lower cost-to-serve than incumbents of £20-£50 per account compared to £170. Meanwhile, deposit balances for challengers have increased from £70 to £350 per customer. However, this is still dwarfed by the £9000 average for incumbents.However, the majority of new entrants are still not profitable, with the average digital bank losing £9 per customer