When should customize open source? As Coté says in this episode, if you have to ask, the answer is no. Rick Clark and he discuss strategic considerations for going beyond just using and embedding open source software.
Coté goes through his opening talk for “round tables” and “fireside” chats. Also, he answers the age old work-form-home question: are cucumbers good enough to transform seven month olds into good office mates?
In this episode, Coté is joined by Rick Clark and Sophie Seiwald to discuss management challenges of remote working. You know the drill: everyone has been working from home since the spring, taking away all the advantages and habits of working face-to-face. What’s new in this conversation is some advice for doing strategy communication, something that’s especially important when you’re relying on autonomous developer teams. We also discuss keeping people’s spirits up and making casual conversations with the boss more like running into each other in the hallway instead of an ominous “we need to talk” meeting.
You don’t have to make an A on everything, try for more B’s and C’s, even F’s. Doing perfect on every project is a path to failure, if not misery. So, why not be OK doing less than perfect on some projects, and completely failing on others? This is howI’m getting gets comfortable saying “no” more often, which so far has worked out.
When it comes to digital transformation, kubernetes, and app development, executives are always stressed about skills gaps. They don’t think staff people are up to the tasks and they don’t have the budget to hire new people with that occult knowledge. However, this might be more about the lack of training and strategic learning methods in those organizations. What if the problem wasn’t a lack of skills, but a lack of learning? In this episode, Coté goes an analyst report that looks at this situation and walks through some tactics to address the (supposed) skills gap.
00:00 – Skills gaps. 00:40 – Survey says: people worry about skills. 05:37 – The types of skills that are missing. 09:19 – Three ways to get the skills your org. needs. 16:31 – Learning how you learn – don’t forget to measure. 17:14 – CTA – http://kube.academy, http://tanzu.vmware.com/developer 19:23 – Bonus: get free training from deal-hungry ‘vendors.
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.
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.
But there’s still confusion about the term. A survey of 1,000 developers and IT decision-makers by software maker Lightbend found that a plurality of respondents (41.7%) ranked writing applications that specifically leverage underlying cloud infrastructure as the most important aspect of cloud native, but a majority picked the other two options: utilizing Kubernetes and containers (34.5%) or moving to a cloud infrastructure provider (23.8%). In other words, most respondents still prioritize where applications run over how they’re built.
The typical disciplines of analyst relations, field marketing support, product marketing are still important in B2D. But they need to be complemented with consumer marketing techniques to be successful.
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.
The company infamously rose to prominence as a scofflaw taxi-killer and later added delivery services and freight as substantial sidelines that in Q3 2019 delivered $863m compared to the $2.9bn won by ride-sharing services.
One year and one pandemic later, delivery and freight delivered a combined $1.74bn of revenue compared to ride-sharing’s $1.37bn.
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.