Deep Roots – Surviving Disruptions

Articles: Customers aren’t buying, they are deciding what to cut: Focus your dev teams well

Thu, 19 Mar 2020 00:00:00 +0000

As consumer confidence has plummeted, wooing new customers with exciting new features is less likely. However, engendering loyalty among your customers as they look through their subscriptions and decide what to cut seems a very wise plan.

Not only do your customers not really care about snazzy new features, but it’s the kind of work that does not flourish within the remote environment. Well done feature development requires communication across many different roles that is good, frequent, and fast. You need the product owner, sales, development team, and customer all bouncing with quick iterations.

But if we’re not shipping features, what should we develop?

From Snazzy to Loyalty

While we don’t know how long the quarantine effect will last, we know it’s not forever. We have x months to perform work that is suited well for remote teams and increases customer loyalty.

What is the best way to build loyalty as a technical team?

Loyalty does not come from things going well. It comes from things going wrong and having an excellent experience of it getting fixed - fast!

Improve capabilities for faster response
Work down the technical waste for faster response
Eliminate frustrating bugs (clean the complaint backlog!)

These are in order. Fixing bugs requires reducing tech debt, which requires specific technical capabilities.

Where to start? Cleaning technical waste is like saying we need to clean the ocean.

One Plastic Bag at a Time

Quite simply, it’s the everyday habits. The product you deliver is a direct reflection of developer habits.

A classic response to technical waste is to try to shift process and culture. However, while culture is hard to change, specific coding behaviors and habits on the micro level are not. Getting different business results is easy when these habits can be changed and aligned to the business needs.

So how do we change those habits?

Awareness is the first step towards change. This begins in workshops that introduce the habits.
Experiencing the new state helps the brain start recognizing new patterns. This begins in the mobbing experience within those workshops.
Practicing the new state helps the brain build the neural pathways that build new patterns for the long term. This begins in the daily practice that focuses on one micro-behavioral shift at a time.

Whether your ocean, I mean tech waste, cleaning needs are about improving quality or legacy code, Deep Roots offers habits that fit the needs for each team uniquely. And our workshops and coaching have always been virtual, so this may be the best time to spend the next x months developing the ability to quickly and effectively respond.

Articles: Using Talent Well during Disruption

Fri, 27 Mar 2020 00:00:00 +0000

It’s safe to say that the world is in a state of disruption that organizations are navigating all at the same time. The book Zone to Win describes how to organize in times of disruption.

Moore’s premise is that during stable times every company plays in three of the four zones. However, when disruption happens, a fourth zone comes into play … the transformation zone.

Companies die when they transition poorly from stability to disruption. In terms of the book, we can say that the company killer is when the organization fails to add the fourth zone well.

So what exactly are these magical four zones?

The Four Zones of Play

Performance - money generating zone
Productivity - cost and risk reducing zone
Incubation - market tester zone
Transformation - disruption zone

Augmented by Wildcat Venture Partners to visualization provided in Zone to Win

Many organizations need to play what Moore calls Zone Defense. They need to add the fourth transformation zone or die. For example, let’s say a company writes software for the logistics supply chain serving hospitals. Previously the market valued long term stability and foresight. The essential feature was tight automation integration between hospitals and suppliers. Now the market demands adaptive responsiveness. The biggest feature is now the biggest market impediment because it requires a two-week set up time for every new supplier. The winning product will be whoever shows the administrator the problem they are going to have between 12-24 hours from now.

When the transformation zone comes into the mix, it takes resources from the other three zones. At the same time, executive function redirects to the new transformation zone.

Each of the three always-active zones have to do a different job with less resources. To do that well, it’s essential to re-align who’s working on what.

Getting Rid of Unimportant Products

In the productivity zone, you have products that simply aren’t generating enough money. Any product that makes the cut should be contributing at least 10% of the company’s revenue, according to Moore. Products that don’t meet this criteria either need to be cut or merged.

Meanwhile, the incubation zone products are trying to prove a market before transitioning to performance. However, transitioning takes more than time, it takes organizational disruptions. There’s only so much disruption a company can handle. Limit your disruptions to ONE.

As such, the window of opportunity is now closed for incubation projects to transition. Everything in the incubation zone needs to find an alternate exit. Such exits include cancellation, sell-off, or stripping for technology to enhance the performance zone.

Making Important Products Efficient

There have been inefficiencies in the performance zone up to now, and that’s been all right. After all, consumer demand has given enough revenue to cover these inefficiencies. Now revenue is dropping. At the same time, the transformation is taking resources.

Significant resources are trapped in the performance zone. Each important product includes some less-important parts. The performance zone needs to vigorously find and eliminate efforts on those less-important parts. The transformation gives more important things for these people to do.

The purpose of the productivity zone is to make the performance zone more efficient. The resources are now diminished for all three common zones, and the productivity zone provides the solution. This is one of the most important areas to focus on in a disruption.

A powerful example are bugs. Bugs are one of the most pervasive problems in the performance zone. They cost customer loyalty. Hint: this is not the time to lose loyalty! Bugs cost you significant manpower in customer support, operations, and data recovery. As such, moving your now limited talent and resources to a bug prevention mindset is now a top priority for the productivity zone.

Creating a bug prevention mindset is challenging even when everything’s going well. How do you initiate a cultural change during high disruption?

Making Culture Change Easy

Culture change is hard. However, changing behaviours is easy one habit at a time. The good news is that enough of those habits adopted sustainably do change the culture.

But which behaviours? Which habits? Answering this question incorrectly can be too costly for the productivity zone. However, Arlo Belshee’s (@arlobelshee) twenty years of intentional testing lets you skip the testing stage and go straight to increasing your efficiency.

When he started Deep Roots, we created three guarantees for delivering technical excellence through habits.

These guarantees provide the assurance to organizations for making their products efficient from the code up. Our habits increase developer productivity so that you can free developers for your transformation. They prevent bugs to improve loyalty and free up your operational staff for your transformation. Additionally, the new habits allow you to reduce the cost of retrofitting technology so that you can mine your innovation zone for technology to help your performance zone.

Articles: Why Technical Waste Blocks your Pivot Speed

Wed, 08 Apr 2020 00:00:00 +0000

Imposed change on a global scale shifts how the world works. For example, the industrial revolution eventually replaced cottage industries with at-scale manufacturing. Similarly, the rise of the Internet shifted the meaning of expertise from what-you-know to what-you-can-find-and-apply. And now we are watching another global shift, from tolerating remote work to embracing it as a value. We are seeing the first glimmers of a new reality.

Last week we wrote about mindshifts that are necessary to prepare your technical teams for the ways of working required by COVID-19. Now we examine how organizations pivot to those new mindsets, and what blocks us from pivoting quickly.

Looking at the Pivot Reality

Any pivot is started by a change in needed outcome. Right now, Zoom is likely pivoting to scale for supporting business subscriptions driven by the coronavirus, while customers of products like Salesforce see cost centers worth reducing. Either way, the critical aspect is recognizing the shift that coronavirus is causing. The pivot sequence then starts by then changing what choices the organization makes. Once people are aligned to the new way of thinking, the pivot finishes by changing the actions people take as a result of new choices.

Friction Makes Pivot Difficult

Friction, anything that slows down your ability to pivot, falls into two categories. The first common type of friction is organizational inertia, or people and processes that drive the organization’s current way of thinking. The second common type of friction is technical waste, or anything that makes it hard to take different actions than you currently do.

Organizational inertia slows down the first phase of the pivot, where we change minds and processes. Meanwhile, technical waste slows the second phase, when we all think differently yet keep enacting our old patterns.

Organizational Inertia

Effective transformational change is required when an organization needs to change minds and processes. This requires intentional process and system changes. However, its root is strong, articulated leadership. Shared visioning provides everybody the direction necessary to explore and adopt new mindsets.

Technical Waste

Initially we immediately think of the obvious time wasters, such as more reviews and process meetings that add painful hours to implementation.

Meanwhile, we are referencing a more sinister form of technical waste. This kind of technical waste is invisible to most people and lays there like a dormant disease. Pre-pivot actions do not overly change legacy or low-quality code, and the disease stays dormant. However, new directions will require changing legacy or poor quality code, activating its full potential to block action.

This invisible disease in the code will add multi-week “refactoring” stories to each decision’s implementation. These stories feel inevitable, but there are ways to eliminate them.

Fixing the Friction

Establishing any pivot requires funding of the Productivity Zone, as we discussed in our article on using talent well during disruption. Productivity Zone programs and systems improve your business agility. In particular, they alter systems to reduce each kind of friction and speed up whatever pivot will come your way next.

The Productivity Zone runs transformational change efforts to reduce the cost in changing how we think. Simultaneously, the zone executes architectural improvements to reduce the cost to enact new potential directions.

But Wait! We have an Emergency Pivot!

There are pivots that organizations must eventually make to survive, such as Kodak and digital technology. However, there are pivots that demand immediate pivot or obvious doom. This is the kind of pivot we were discussing for organizations with customers looking to what gets cut during this economic shrinkage caused by the global pandemic.

However, the good news is that emergencies provide natural alignment as everybody involved accepts the pivot inevitability much more readily. Unfortunately the bad news is that emergencies do not tolerate risk nearly as much even though the work product is likely going to need to be changed even more quickly.

Lead through Organizational Inertia

The time dedicated during a “normal” pivot to change minds and processes is greatly reduced by an emergency. While good leadership transforms this uncertainty into clarity, the external factors that have convinced people cut down half the resistance. Emergencies decrease the time required to change minds and culture.

Incrementally Improve Technical Waste

Meanwhile, the time dedicated to making it easy to enact the new decisions just got longer. Decreased risk tolerance makes it harder to fix the underlying disease. Not only does the Productivity Zone need to make bigger changes with less staff, but the reduced risk tolerance removes many of their standard approaches. Mitigating technical waste during an emergency requires new, lower-risk techniques.

We Help you Fix the Technical Waste

Deep Roots has a deep focus on resolving technical waste, or in other words, shrinking the time it takes for you to enact the new decisions you made for your organization’s survival. Our techniques allow your teams to provide extremely high consistency guarantees. They will fix the code disease well within even the low risk tolerance required by today’s business environment.

Deep Roots trained technical teams can change code with near-zero risk and in tiny chunks that don’t disrupt delivery. Then they can safely cure the technical waste, speeding up the slowest part of your next pivot.

Articles: Technical Excellence: Now Required

Wed, 25 Mar 2020 00:00:00 +0000

Our world is in a state of emergency. Today’s uncertainty and ambiguity means we can’t assume everybody can be back in the office shortly.

And truthfully, this is an opportunity. In the office, informal technical communications covered for many weaknesses. Technical skills that were good enough in the office won’t work well in remote work, where informal communication is limited. Excellent technical skills, however, allow developers to communicate informally through the code.

Beneficial? Yes, but not strictly necessary. At least when we were in the office. Now it is very necessary.

Easy Problems are Now Hard

Many problems that developers recognized and solved everyday were natural to do in the face to face environment. However, now we are working with the coronavirus lockdown, thus remotely. Now those easily solved problems have become challenging in the remote environment. Here are just a few examples.

Design Syncing

In the office, design collaborations come together organically, normally in front of a whiteboard. Additionally, the discussion by two people gets overheard by other developers. Consensus develops for the design techniques and approaches for that code.

Remotely, your team needs to find a way to accomplish with intention something that was organically natural to them before.

Bug Syncing

In the office, code reviews, stand-ups, and conversation drive the discoveries of the most common bug mistakes.

Remotely, your team needs this conversation thread to be intentionally developed in stand-ups. While it is possible to mention in Slack a common bug, that is also an intentional decision and action. This has a much different way of thinking than an organic conversation.

**Domain Insights **In the office, individual epiphanies often drive domain insights, sparking more epiphanies. Also, domain insights frequently happen from conversations with stakeholders outside the development team, such as the customer, managers, customer support, and sales.

Remotely, your team needs a way to have the space necessary to have the epiphanies. The remote setting increases pressure and expectation to simply produce. Coffee conversation or the whiteboard wandering at the office naturally occurred, but at home it’s now a point of “waste”. This leaves little space to even have the insights, much less share them. The results are different parts of the code being written in different ways.

Additionally, the team and the business need to establish new norms for between-team communication. Normally solved by hallways and lunches before, now everybody is in their own silo.

Slow Down to Go Faster

The key takeaway from these once-easy problems now becoming hard is the lack of organic time and space that is naturally present in the office. Remember that 2.5 hour of office time equates to 1 hour of remote time. Many of us breathe a sigh of relief to lose the interruptions and get focus time. However, developers rely on those natural collaborations to ensure quality production. The great trap for them is staying so busy cranking out code individually that they don’t even see the round wheel.

So what can developers do to get that time and space to solve those problems?

Learn, Solve, and Code Simultaneously

There are lots of ways to slow down, but only some will help you go faster. One of those ways is to create coding habits that give developers a structure for every tiny decision they are making. If they use the habits that Deep Roots offers, they will additionally learn how to code better with each of those decisions.

Below are examples of how tiny habit shifts can make those now-difficult problems easy again.

Design Syncing

Simply tagging commits according to the level of risk communicates design intent with the team and simplifies those commits. This reduces the number of code reviews required to keep the design on the same page. Below is an example of the final shift in Deep Roots’ Refactoring Safely habit that gives a key for reliable tagging.

The visual reminder of tags for increasing safety.

Tagging also slows a developer down to think about what exactly is in the commit. Now the developer is thinking about the risk within a small commit. This provides the opportunity to notice a team level systemic problem that impacts design, and gives an interrupt where it is natural to get others involved.

Bug Syncing

Practicing the safeguarding techniques (as described by Llewellyn Falco and Jay Bazuzi and that we offer in habit form) help find common risks that cause the team to write bugs. Once the team finds what safeguarding calls hazards, then the they can learn how to safely eliminate those hazards in the code. Deep Roots offers habits that solve common hazards, with some examples including Fix God Classes, Advanced Testing, and Prevent Non-Local Interaction Bugs.

Domain Insights

This is not solved in the codebase or coding technique, which is the focus of Deep Roots. However, while the process side of the business is working to pivot, we can offer developers the opportunity to improve their craft and solve the design and bug syncing issues.

While Deep Roots stays focused on technical excellence, not process, we offer very viable technical solutions to two of the problems that developers are used to solving face to face but are now quite difficult. This provides time and space for the process side of the business to solve the communication challenges.

Articles: Transitioning to a Marathon of Change

Thu, 02 Apr 2020 00:00:00 +0000

In the United States we are a month into the quarantine, give or take a little depending on your geographic location. Dr. Fauci, Director of National Institute of Allergy and Infectious Diseases, informs us that the infection rates will not truly curb until a vaccine is created. While J&J and other companies are working to deliver a vaccine, we know this is not a quick fix. Regardless of how many safety protocols they are ignoring to speed delivery.

This is not to be scary, simply realistic. We are no longer in sprint and recover mode. We must gear up for a marathon.

Mindshifts for this Marathon

In this sprint we have had to think differently about how we communicate and prioritize. In the marathon we will have to rethink about those for the long term. We are focused on the technical development arm of any organization, so through that lens, there is a mindset shift to adopt for both communication and strategy at the team level.

Mindshift #1: Code + Commit Communication Channel

Developers best communicate organically. Last week we discussed how certain small problems in the workplace are hard to solve in remote working environments. That article discusses solutions for those specific problems, however, let’s step back to the bigger picture and consider ways to simply communicate better … through the code.

Commits (see Design Syncing section) and Names (see how-to blog series) are the lifeblood of tacit communication if we use them with intention. Names convey what developers think the code does or should do. Commits convey developers’ intention in changing the code. Together these provide a powerful communications channel for detailed, relevant, asynchronous communications about the product.

Mindshift #2: Increasing Loyalty through Zero Bugs

As we discussed a couple weeks ago, the customer base is no longer interested in snazzy new features. In fact, they are looking to see what subscriptions they can no longer afford. As a result, you need to shift your energy from customer acquisition to customer retention. Customers buy because of new features; they leave because of frustrations. This causes a 180 degree prioritization flip from features before bugs to bugs before features.

In addition to the clean-up of old bugs we recommended in the section One Plastic Bag at a Time, new bug creations need to stop. Bug cleanup can be done for a sprint, but a marathon requires bug prevention habits.

Training for the Marathon

The challenge for any organization is making techniques for improving communication and preventing bugs systemic and sticky. Actually, the real first challenge is identifying what those techniques even are. THEN they have to scale it sustainably.

The good news is that Deep Roots not only knows the techniques, such as our structured commit tags, naming process, and spooky action disentanglement process, we also know how to scale those habits to stick over time and across multiple teams quickly.

As a final note, not only does this prepare for the emergency marathon, but it also builds systems that improve efficiency and customer loyalty in any economic situation. This provides the organization with a huge corporate asset that creates competitive advantage for the long term.

Articles: Don't Lose Productivity when Transitioning to Remote Development

Tue, 17 Mar 2020 00:00:00 +0000

Are you prepared to lose 120 hours a week for each development team?

As a manager, I would assume that sending development teams home for remote work, as we must right now, would still achieve productivity. After all, so many developers work remotely very easily and they seem to do well in quiet alone spaces. Of all the quarantine disruptions, this one seems minor, right?

Mmmmmm…not so minor.

Technical development frequently requires tacit knowledge that is shared in close verbal quarters. Coding requires unique decisions every hour - finds unique problems every hour - collaborates to solve problems every hour.

In fact, one of the reasons that mobbing gives such a productivity improvement is because innovation and collaboration are faster with everyone thinking about the same thing at the same time.

Don’t developers live on Slack? Can’t they simply set up working meetings on Zoom and zip off difficult questions to handle on Slack? Theoretically. But that’s not how it plays out in the real world.

Consider the psychological difference between asking for written help versus leaning back to ask “hey Sue, what do you think about this code?” While informal discussion creates a shared comradery and collaboration, requesting written help feels slow, intrusive, and suggests incompetence. Thus developers will first take “a few minutes” to try to figure it out first before burdening their peers.

Let’s break down those numbers. Developers often need to discuss a quick problem a couple times per hour. Trying to solve each of those by themselves costs about 15 minutes each. That’s 16 problem explorations per person each day. We just added four hours of work per developer to their day in order to produce the same output.

While 4 hours per developer doesn’t seem like an overwhelming loss, remember that’s per day making it 20 hours per week. With 6 developers on the team, that’s 120 hours per team-week. Of course, developers don’t add those extra 4 hours a day. They just get less stuff done.

Reducing the Cost

There are two possible solutions for reducing this productivity loss. You can reduce the cost of getting each answer, or reduce the number of answers we need.

Reduce cost of getting each answer

Remote mobbing (podcast by Mob Mentality Show) can reduce the cost of getting answers that they used to easily get in the office. While this is an effective strategy to get back your productivity, you can also do more by simply reducing the number of answers they need, whether developers are remote or not.

Reduce the number of answers we need

Most team discussions exist to puzzle out difficult-to-read code. The more difficult the code is to read, the more answers they will need.

Teams that don’t need those discussions already use a powerful communication channel: the code itself. Those teams use names in the code to communicate insights and intent to the other developers.

Great names make communication work; bad names necessitate team discussions.

Getting Good Names Remotely

Traditional naming processes fail as communication deteriorates. Good names arise from team-shared metaphors and concepts. Poor names slow down remote development and remote development creates poor names.

You can improve your names without a productivity disruption. Deep Root’s Naming as a Process allows teams to use their code to incrementally develop shared concepts and names, whether remote or not. This approach allows good naming with less verbal communication.

In the wake of this difficult global disruption, you can create opportunities to actually improve productivity, decrease bugs, and clean code … all while working on the day to day code! Check out how Deep Roots provides this through a remotely facilitated mobbing workshop and series of follow-up habit shifts that are also remotely coached.