Speed up with Test-driven Development

Doing test-driven development is the best way to maintain software release speed and avoid “legacy” software slowing you down. Coté lays out what TDD is, why it helps you avoid legacy slow-downs, and shows that most people don’t actually do it.

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.

Mentioned

CTA

Three things for more Tanzu

Don’t forget to measure

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.

Outline

  • 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:
    1. Awareness – do people even use your new feature?
    2. Completion rate – buying a thing, signing up for an account, going all the way through a workflow.
    3. Time spend on workflow.
    4. Accuracy – generic, but whatever.
    5. Churn rate/retention; lowering operating costs; growth; doing loose-causation activities (loyalty programs, educating self on banking activities).
  • Loose example: Home Depot buying washing machines (shows that you need to focus on end outcome, not just app itself).

CTA

Three things for more Tanzu

Better, more decisive meetings

Most meetings should result in a decision. However, most meetings are not run well enough to get a decision. Today, I summarize the method Pivotal Labs uses to find The One Thing to Work On. It’s from the book Radically Collaborative Patterns for Software Makers – you can download it for free.

Chapters

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.

CTA

Three things for more Tanzu

The mayonnaise measuring epiphany – better software with discovery and framing

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.

Mentioned

CTA

Three things for more Tanzu

How COVID changed IT priorities & spending, with Rita Manachi

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.

Mentioned

Chapters

00:00:00 – Gartner IT Symposium.
02:59:29 – COVID surveys for IT priorities, before & after.
05:31:00 – Are people actually going to change, this time?
11:00:11 – Let’s look at the survey results – charts!
12:37:05 – Demographics.
12:45:15 – Lead time/release frequency.
13:29:29 – Speeding up innovation.
14:11:11 – Business priorities.
14:38:01 – Reducing costs vs. innovation.
19:04:05 – Budget changes, per Gartner.
22:42:07 – Sustaining the positive change.
25:01:21 – Prioritizing applications to modernize.
26:38:28 – Blockers & challenges.
27:36:23 – Reducing costs, automation, etc.
32:14:28 – Staffing.
34:14:26 – Hiring freezes.
35:24:20 – Business/IT alignment.
38:25:18 – What does “digital transformation” mean here?
45:03:19 – Bye, Bye!

CTA

Three things for more Tanzu

Colophon

Everything I know about platform operations, platform as a product

I don’t know. The title is pretty comprehensive.

Nevertheless: What platform operations and “platform as a product” means, how it differs from existing ops, and why it’s so. Also, some “therefore, do these things” tactics.

Mentioned

Chapters

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!

CTA

Three things for more Tanzu

Colophon

Getting good at messing up, negotiating SRE error budgets, and small talk topics

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.

Topics

  1. Skidding on my bike, that is, getting good at messing up. Also: don’t learn to surf if you can’t swim.
  2. Small talk – “what’s that like?”

Mentioned

Chapters

00:00 – Agenda.
03:22 – Getting good at messing up.
13:25 – CTA for developers.
18:55 – Small talk and ripe melons.
25:48 – free consulting and kubernetes training.
27:18 – Bye, bye!

CTA

Three things for more Tanzu

Colophon

6 ways that pair programming makes development better

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.

Mentioned

Chapters

00:00 – I’m eating.
00:27 – Pairing
23:43 – Podcast recommendation.
21:03 – Bye, bye!

CTA

Three things for more Tanzu

Colophon

Build alliances for The Big Meeting

Pre-wiring and cross-business alliance building for The Big Meeting. Also: the surprising uplift from regular check-in meetings.

Topics

  1. Pre-wiring, meetings for meetings, and other nonsense for The Big Meeting. Build alliances with peers ahead of time.
  2. Check-in meetings are always good and nicely compassionate…even a cynical person like me gets inspired.

Mentioned

Chapters

00:00 – Agenda
00:32 – Pre-wiring and consensus building.
10:00 – CTA!
12:17 – Just checking in meetings.
16:05 – Bye, bye!

CTA

Three things for more Tanzu

Colophon

Kubernetes for VI admins – VMs fit to the app/apps fit to k8s

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?

Topics

  1. Check out Boskey’s courses on kube.academy.
  2. What VI admins do, traditionally.
  3. Kubernetes is a set of interfaces, APIs, and architectural norms.
  4. How admining kubernetes is different than VI admins: roles change a little bit.
  5. The VM fits to the app, but the app fits to k8s.
  6. Kubernetes is built into vSphere 7 – see Boskey’s blog post on this.

Also, check out her session from SpringOne 2020, “Crafting a New Enterprise App Platform with Cloud Foundry, Kubernetes, Istio, and More.”

Chapters

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!

CTA

Three things for more Tanzu

Colophon

It’s not about breaking the rules, it’s about almost breaking the rules

When you want to change, you need to find out what the new rules are, or start following the ones you’ve been neglecting. Also, stop trying to find who’s in charge: it’s probably you!

Topics

  1. It’s not about breaking the rules, it’s about almost breaking them. Remember: you wanted to change, not stay the same.
  2. “We’re the only ones” – Matt Wolken, Nnamdi, and Shafer.

Chapters

0:00 – Agenda.
00:20 – Everyone is good at saying “no.”
01:58 – Don’t break the rules, almost break the rules.
07:20 – It’s you! There’s no one else to ask.
12:31 – Your CTA.
16:42 – Bye, bye!

CTA

Three things for more Tanzu

Colophon

Less leadership, more technocracy

Getting good at leadership is always good, but make sure to mind the technocracy as well – someone’s actually gotta do the work! Also: plan for needing gadgets for your gadgets.

Topics

  1. Less leadership, more technocracy.
    • Go beyond high-level “why,” seeking out the “why of how.”:
      • >“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.”
    • E.g., Seek out “patterns.”
    • Tanzu whitepapers, e.g., on ROBO, chargebacks, and TEI for business case modeling.
    • Haven’t read this one yet: Radically Collaborative Patterns for Software Makers.
    • And, of course: my two books on transformation!
  2. Now you have two problems
    • I don’t dislike my dog, I dislike the work and responsiblty that comes with her. I often confuse this.
    • Pets for your pets, work for your hobbies.
    • When the process becomes the product.
    • Be aware of this distinction in your thinking.

Mentioned

Chapters

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!

CTA

Three things for more Tanzu

Colophon

The drunk under a lamppost app modernization anti-pattern

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.

Chapters

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!

Topics

“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.”

  1. 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.
  2. Saying “no” as prioritization. All these execs saying no to things to focus on other customer and prospect engagement.
  3. Follow-up on strategy: check out Gartner’s “Winning in the Turns: A CIO Action Guide,” July, 2019. Good list of types of “turns” and advice on how to change the way you do strategy. In particular, as TD Ameritrade went over at s1p 2020, change “ROI” to “payoff.”

Mentioned

CTA

Three things for more Tanzu

Colophon

Shift right to improve corporate strategy

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.”

Mentioned

Chapters

0:00 – The agenda.

02:51 – kube.academy.

4:00 – Remove bottlenecks to get better at software, always.

22:06 – Amsterdam art nouveau.

24:06 – Shift right to improve corporate strategy.

35:45 – Discovery workshops.

38:07 – Policy is made by humans.

43:33 – Bye, bye!

CTA

Three things for more Tanzu

Colophon

Doing something works better than doing nothing

Summary

Doing something works better than doing nothing

When you put a new process, like agile, in place, you often realize there was very little process in the first place. Also, kubernetes at the edge, T-Mobile, and as architecture.

Mentioned:

Also

Programming notes

Chapters

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!

CTA

Three things for more Tanzu

Colophon

The right mindset for starting application modernization

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?

Colophon

De-risking software

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.

Topics, mentions, etc.

CTA

Three things for more Tanzu

Colophon