All Articles
Friday, March 27, 2020 in Surviving Disruptions
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.Wednesday, March 25, 2020 in Surviving Disruptions
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.Thursday, March 19, 2020 in Surviving Disruptions
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.Tuesday, March 17, 2020 in Surviving Disruptions
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.
Developers Need to Share Tacit Knowledge Technical development frequently requires tacit knowledge that is shared in close verbal quarters.Wednesday, February 19, 2020 in DevOps Concepts
You are responsible product manager. You carefully hone your multiple ideas. You split test (A-B test) to refine and pick the best ones to invest. You build out the winner. You make your big release … and it flopped.
What happened!? You put in all the effort to make sure this won’t happen, and yet it did.
Getting the right data. What you didn’t know was that several of your tests had a small cosmetic bug on one treatment.Monday, February 03, 2020 in DevOps Concepts
Releases had been delayed, slow, and buggy. You fought that for awhile and then adopted the magic of DevOps, which promised automated pipelines to get fast feedback. This also was supposed to give the developers the ability to easily fix production problems when they happened.
After all of that, you find yourself rushing to make quick fixes while the system keeps telling you that it’s still broken. This churn wastes development time, promises 2am work on live-site issues, and inures people to the red light.Friday, December 06, 2019 in Articles
You schedule sprints that do nothing but clean up the previous sprint. You are told that features you feel are critical to the product “simply can’t happen”. You watch feature after feature ship late and then get long bug reports.
However, you have not been idle. You’ve contracted process and technical consultants. They gave you answers and you got the green light to implement them. Things did improve, but your bottom line issue of buggy and late deliveries continue to happen.Wednesday, November 13, 2019 in Articles
Executive Summary In trying to improve productivity and reduce waste there are 3 important concepts. These often get confused, which makes it difficult to align and fix the problem. The key concepts are:
Technical Debt — a way your system has not yet incorporated new information.
Technical Waste — technical friction that does one of 3 things:
puts existing business at risk, or
causes delays and increases costs to respond to new information when it appears (aka, manage technical debt), orMonday, October 28, 2019 in Articles
Our background and experiences inform our instincts … and your instincts tell you that productivity is low because technical waste is in the way. How can teams possibly be effective working through the maze of quality issues they face?
You have instituted process changes to help them reduce WIP. You have established the roles recommended to make communication clearer and faster. You have embraced the recommendations you’ve heard at conferences or from consultants.Thursday, October 17, 2019 in Naming as a Process
We all know naming is a pain in the ass and you can’t trust the names in your code. But it doesn’t have to be that way.
Many people try to come up with a great name all at once. This is hard and rarely works well. The problem is that naming is design. Here are the things you are typically trying to do all at once while naming:
Deciding the things the code should do Deciding which things go together Deciding which abstractions best represent those clusters Picking a name that clarifies intent Picking a name that distinguishes from all the other similar intents Describing the side effects of the code Keeping your name under 15 characters This is why naming is hard.