Doc Norton
Doc is a software delivery professional working to make the world of software development a better place. His experience covers a wide range of development topics. Doc declares expertise in no single language or methodology and is immediately suspicious of anyone who declares such expertise.
A frequent and well-rated international speaker, Doc is passionate about helping others become better developers, working with teams to improve delivery, and building great organizations. In his role at OnBelay, Doc is provided opportunities to realize his passion every day.
You can learn more about Doc's presentations or feel free to peruse around and read his latest articles on agile, leadership, and culture.
If you want Doc to come speak at your event, let him know.
Featured Articles
This article focuses on using Chain of Command as a means of reducing cyclomatic complexity in our code. Along the way, we also create better adherence to SRP.
I recently worked with a team on a fairly significant refactoring. I paired with different team members each day over a three day period as we moved code around, pushing responsibility into other classes, reducing complexity, and make the code more expressive. On the fourth day, I put together some notes on the things we saw and general guidelines for the team to keep in mind. Nothing herein is new to the community, but it might be new to you.
Collaboration Contracts are a way of identifying who is involved in a decision and what level of decision-making authority each participant has. This isn't a delegation model where some individual is empowered and imparts unto others some fraction of their authority for a limited period of time. This is a collaboration model where all participants are equally empowered, but find consensus on all topics to be a suboptimal approach.
I often find myself talking to people who are in the midst of a switch to agile and who find the change very difficult to get used to. They may be strong advocates, but their team just "doesn't get it". Through discussion, I find that many of them are attempting what I refer to as "Shock and Awe" agile. If you couldn't tell by the name, I consider this another agile coaching anti-pattern.
Some time in mid-January, I was thinking about various organizational patterns and how companies run. I was thinking, in particular, about the idea of a "leadership team". I tweeted that leadership teams may be an indication of dysfunction.
I got a few different responses, all of which amounted to "please say more about this."
I think I saw Daniel Pink's TED Talk on "The Puzzle of Motivation" for the first time in 2011. I'd been reading some about leadership, management, and organizational psychology up to that point, but Pink's talk and his distillation of these complex concepts into a simple framework (Autonomy, Connection, and Excellence) inspired me to read more on the topics. Over the course of the next couple of years, I consumed a decent amount of material. You can view my Goodreads account to see what books I was reading. Unfortunately, there is no easy way to share all of the scientific articles and other sources I also consumed.
I've worked for essentially two types of companies - those that have clearly defined job ladders and those that don't.
A clearly defined job ladder provides people a clear picture of what they need to accomplish and what skills they need to display in order to move into a new role. A clearly defined job ladder provides a baseline for performance appraisals. Everyone in the organization knows what is expected of people in each role. Are you displaying these attributes with a level of proficiency requisite for the role, or are you not? Job ladders make the expectations of progress and the opportunity for advancement clear and consistent.
About 15 years ago, I started a simple practice with my fellow co-workers and employees. Every so often, we'd meet to discuss stuff and things. Nothing too formal, just a touch-point to make sure we were staying connected. I called the sessions "touch-point meetings". Over time, I made adjustments to the format of the meeting as various structures proved more or less valuable.
I like to practice my craft. I enjoy participating in Code Retreats. I enjoy facilitating Code Retreats. I like working on kata and koans. And a lot of what I talk about includes references to these practices. We at LeanDog are always on the lookout for people who are passionate about improving their own craft. I thought I'd start a blog entry where I catalog resources that might be of interest to others looking for ways to sharpen their saw.
Over the past several years, as I’ve been helping teams and organizations improve their ability to deliver software products that are desirable, viable, and feasible, I have been experimenting with a Behavior Framework that has proven to be rather effective. And I’d like to share it with you in hopes that you find it useful and that you provide me feedback on your experiences with it.
My plan is to write a series of blog posts all related to the behaviors framework. Some of them will be about a specific behavior. Some of them will be about tools or techniques that help teams express one or more of the behaviors. Some of them will be my own experiences. And some will be damn near complete fiction.
Parallel Thinking seeks to reduce the influence of things such as hierarchy and rhetoric. Parallel Thinking encourages everyone to see the subject from the same perspective at the same time - building a shared view over contrasting different views.
In this excerpt from Escape Velocity, we take a more in-depth look at Velocity and try to answer (at least in part) the question, “What Is Velocity”?