Most development teams forget to do a key activity: measuring the success of new features. Teams need to create metrics that will validate or invalidate the assumptions behind the feature and also alternate implementations. But it starts with creating measurements!
In this episode, I discuss the importance of measuring your software, some types of measurements, and an example of measurements in action at The Home Depot. As with other episodes this week, this one builds on one of the ideas in the book Radically Collaborative Patterns for Software Makers, which you can get for free – check out the links in the episode or the link at the end of the episode.
Don’t forget to measure things.
You often assume someone else will be measuring.
This means you can’t use it as feedback – only focus on project metrics (budget, schedule, QA, delivered features) for feedback – plus negative bug reports!
Some starter metrics:
Awareness – do people even use your new feature?
Completion rate – buying a thing, signing up for an account, going all the way through a workflow.
00:00:00 – The agenda. 03:27:00 – The point of a meeting is to make a decision. 04:30:05 – An example of a decision. 05:51:28 – The facilitator. 07:36:12 – Examples of decisions made, esp. application modernization. 10:04:13 – From many to one – finding the ONE thing, ignoring the others. 13:04:02 – Getting people to write down all their ideas. 14:37:20 – Rip up five ideas. 17:22:08 – Go over the ideas on a wall. 18:52:20 – Several passes at prioritizing, by easy/valuable. 21:07:09 – Ranking what’s left. 22:37:26 – Mind-tricks to encourage collaboration. 24:27:12 – Mind-trick: Just start, even if it’s dumb.
More than likely, your initial ideas for your apps will be wrong. You’re probably not even solving the most important problems. Pivotal Lab’s “Discovery and Framing” process is built around making sure you’re working on the right apps and features to meet your original goals. In today’s episode, I cover the discovery and framing idea as, er, framed up by Matt Parker in his book Radically Collaborative Patterns for Software Makers. Also, I go over a case study of this from the food services industry.
Off in analyst land, they’re always checking on IT priorities. In this discussion, Rita Manachi (@ritam) goes over some recent surveys about how COVID has changed IT priorities. It’s some good before/after stuff to see what CIOs and such are looking to do.
00:00:00 – Why “platform operations” is a new idea, how things are different. 02:03:07 – Benefits/drivers for platform operations: (1.) centralizing and standardizing is more efficient, better , and, (2.) fits with cloud native development desires. 04:00:09 – Surveys say platform operations works well. 06:18:07 – What the team does, their primary goals. 09:15:23 – When to start at platform ops team. 10:18:13 – What does the team “own.” 12:50:21 – Product management for developers. 16:42:11 – Starter platform product management questions. 19:53:06 – Long term commitments. 23:36:08 – Own the dev tools infrastructure. 26:42:15 – Scaling to the rest of the (large) organization: start small. 26:42:15 – Progress metrics, esp. financial/budget metrics. 28:43:02 – Plan for lots of consulting with developers 31:49:15 – Sidebar: Americans are cheap. 32:36:18 – Metrics: platform ROI. 34:02:07 – Metrics: business improvement & time-to-market. 36:00:16 – Attributes of platform ops staff. 36:30:26 – Skills gaps, you must train people. 38:14:25 – CTA. 40:44:25 – Bye, bye!
As with life, much of DIGITAL TRANSFORMATION is getting good at messing things up on a regular basis. There’s also a footnote on negotiating error budgets in SRE think and some small pointers on small talk.
Skidding on my bike, that is, getting good at messing up. Also: don’t learn to surf if you can’t swim.
Just one topic today: once you have your value stream (or whatever you want to call it) mapped, it’s time to eliminate bottlenecks. Here are five common bottlenecks in the software lifecycle to work on.
Pair programming might seem ridiculous at first, but it’s a proven, better way to program and do related work. In this episode, I go over six ways it makes things all better: quality, learning, team resilience, happiness, productivity, scaling change.
I had a great conversation with Boskey Savla (@boskey) goes over kubernetes for VI admins. We discuss what VI admins traditionally do, how that maps to kubernetes, and the new tasks and roles admins have when managing kubernetes. Also: what does “kubernetes in vSphere,” like, actually mean?
00:00 – Boskey Savla 01:06 – Her two courses at kube.academy. 01:56 – What is a “VI admin”? 05:57 – How kubernetes changes the role of VI admins. 10:00 – The “API”/interface differences between traditional VMs and kubernetes. 15:20 – Getting started with kubernetes: start with what you have. 19:54 – Putting together video training. 23:57 – kubernetes is in vSphere – wut? 30:46 – Bye, bye!
Robbie Clutton joins me again to talk more agile-think. First, we discuss how you can nudge people to actually follow priorities. How do you get people to do what they’re supposed to? Then, we discuss how to think about and use cost of delay in business case thinking. Cost of delay is also a good tool for prioritizing work as well.
>“I think some of my best conversations came through finding ways to respectfully ask those whys and trying to learn more about the process and why we were doing certain things, and really just diving into some of those uncomfortable situations,” said Liberty Mutual’s LeBlanc about her Pivotal Labs engagement. “But respectfully pushing back and sharing my perspectives, as well, ended up helping us learn so much more because we weren’t just taking it all in. We were really trying to understand the whole process.”
00:00 – The agenda. 02:14 – Less leadership, more technocracy. 20:38 – kube.academy. 21:54 – tanzu.vmware.com/developer 23:01 – Pets for your pets. 28:34 – Geting started with your transformation strategy. 30:35 – Bye, bye!
If you’re starting your app modernization plans with the biggest, most critical app you can find, you’re probably stumbling through the drunk under the lamppost app modernization anti-pattern. Chances are, you’ll also encounter a lot of resistance and excuses to avoid changing. Also, I discuss saying “no” more as a way to think about prioritization. Bonus topic: deep-fried bread in The Netherlands.
00:00 – Agenda. 01:49 – The drunk under the lamppost anti-pattern. 15:09 – Start planning your app modernization journey. 18:07 – Saying “no.” 25:12 – “Too many salads.” 30:23 – Learn kubernetes, free! 32:07 – Gartner on IT strategy “turns.” 35:51 – Free developer education & bye, bye!
“With in-house development and acquisitions, FedEx would bolt on technologies resulting in an ‘accidental architecture,'”” Carter said. Through its renewal program, FedEx began to “build out the core services and microservices that represent the less complex, more flexible, faster-to-market capabilities that we have today.” From “How FedEx’s CIO led a decade of modernization.”
Don’t get obsessed with the lamppost of pain: focusing on the difficult, critical things and concluding you can’t transform. Use a type of Disruption: work on lesser, cheaper things to creep up to the critical. Mobile apps, store finder, etc.
Saying “no” as prioritization. All these execs saying no to things to focus on other customer and prospect engagement.
Corporate strategy could be improved by shifting right, moving closer to the week-to-week software cycle to get more familiar with customers and changes in the market. See more on corporate strategy in The Business Bottleneck.
Plus, I discuss bottleneck removal and thinking about policy and governance as human system, not static “laws.”
00:00 – Staycation.
01:32 – Doing something works better than doing nothing
04:36 – BMC case study
09:03 – ending zombie process
11:21 – lack of management tools
13:59 – example of a management tool
15:09 – three small things on kubernetes
28:31 – Your CTA!
Marc Zottner talks with Coté about large scale application modernization. Also, they discuss the value of starting small and constraining yourself to short time lines. Also: what does the American-speaking French accent sound like?
IT, let alone software development has a poor track record for success in large organizations. And yet: we’ll told software is not critical for enterprise survival. We’ve got to figure out how to de-risk software, then. That’s the topic today.
Platforms are often represented in enterprise architectures, “marchitectures,” or as I like to call them, “burgers.” Today, I walk through some past, great burgers, from CORBA, to J2EE, to Cloud Foundry, and more. In doing so, I over some advice about how to find and care for your burger, especially when it comes to keeping your burger fresh.
Planned on topics
All the great burgers.
We’re talking about distributed applications – an application and the services (“backend,” “middleware,” database, ERP-system, etc.) run as their own application, accessed over an API (usually over a network, but could be on the same box, too).
What is it in service of? Software for large organizations: enterprise architectures.