Wednesday, June 29, 2016

Chasing the exit

I've only lived in San Francisco for two years, but I'm catching on that the mindset here is "chase the exit" not "delight the customer" (failing to realize how much more likely the latter makes the former). With that mindset the state of code quality is not surprising.

There are some seemingly practical outcomes from this. One of which is a bias toward fast features, leveraging frameworks, and little time spent "doing the dishes." Because, honestly, if 7/8 of your startups are going to fail, you only have to spend the time/money to clean up 1/8.

A problem with this "practical" mindset is that the skills required to remove complexity from a system are significantly more refined and harder to come by than the skills needed to keep a system simple in the first place.

I may expand on this later, but I'm interested in others thoughts and observations.

Saturday, June 11, 2016

On Leading Change

We talk a lot about leading change in the agile community. Some of us are even in positions where change is a major portion of our job description whether we are change agents, change artists, or just plain old coaches. We want to change practices, behaviors, mindsets, and often entire cultures. Unfortunately, I rarely hear about change in the context of changing ourselves.
"It's not my job to make them better.  It's my job to make me better."
One of the most profound things that's been said to me about leadership and change is the following koan: "It's not my job to make them better. It's my job to make me better." This short phrase holds so much wisdom. I've been unpacking it for years, yet I'm sure it will continue to provide insights for years to come.

If I can continually work to be a better engineer, a better manager, a better learner, a better person, if I strive for probity, then change will happen within me and around me. Because change leadership is not about making followers. It's not about instilling or inculcating or impressing upon others. Real change leadership is about being worthy of emulation.

Sunday, June 5, 2016

Fundamental Principles of Agility

I think a lot about fundamental principles. I've found that a solid understanding of principles allows me to derive understanding of more complicated things.  Within the Agile community I hear a lot of talk about culture, methods, frameworks, and spirited discussions around #hashtags. But, rarely a straight forward discussion of fundamental principles.

To begin, when I speak of principles here I am not talking about the principles behind the Agile Manifesto. These are statements of values which help you know right and wrong and that influence your actions (e.g. a person of principle).  Instead, I am using the term to mean a law or fact of nature that explains how something works or why something happens (e.g. a principle of chemistry).

In the article "Agile and Waterfall: More Different Than You Think" Tim Ottinger lays out an argument for why mixing and repurposing practices between waterfall and agile development leads to unsatisfactory results.  In the process I believe he uncovered several fundamental principles of agile in the form of certain axioms. I've since refined these axioms into the following set (given with a comparison to a more traditional view).


Mindset Axioms
Agile Traditional
We may be wrong in our assumptions, and even if we are currently right the world may change, therefore... We are right in our assumptions, and the world is fundamentally static and unchanging, therefore...
Changes are inevitable and needed for success Changes are an indication of error
More planning will give us a false sense of certainty and likely lead to errors in decision making More planning will allow us to reduce uncertainty and correct errors in decision making
Inspection is to learn about the current state of the world and correct the plan Inspection is to find deviance from the plan and control changes
Feedback is the primary signal for adjustment Milestones are the primary signal for adjustment

The first is the fundamental agile principal. We assume the future is unknowable and therefore our assumptions are possibly wrong. From this we can derive the rest; the limited usefulness of planning, the need to continuously inspect and adapt to understand the current state of the world, the value of feedback.

As an example we can use these fundamental principals to derive the purpose of different Scrum ceremonies.
  • Sprint planning provides an opportunity every iteration to adjust to a new state of the world.
  • Stand-up/Scrum provides a daily inspect and adapt cycle where team members sync up and and can adjust to changes based on what they've learned in the last 24 hours and broadcast that new understanding to others.
  • Sprint reviews allow an inspect and adapt step of the product every iteration. Stakeholders are able to experience working software in their hands which often leads to new lines of opportunity (see exaptation).
  • Retrospectives allow an inspect and adapt step of the teams process. They are able to adjust how they work based on knowledge of the world as it is today. 

We also see the centrality of the inspect and adapt cycle in agile technical practices

  • Continuous Deployment allows a faster feedback loop between customers and the team
  • Continuous Integration allows a faster feedback loop between parts of the system
  • Local automated tests allow a fast feedback loop before code is pushed to others
  • Writing a failing test then making it pass the simplest way possible allows a fast feedback loop showing that your codes does what you expect and allows the design to be adjusted based on what's learned as you work
  • Pair/mob programming provides a faster feedback loop from peers to help improve design, hold context, and correct errors
All of these practices are useful if we understand that we can't "do it right the first time" because the world changes. Better designs will emerge, new technologies will be created, we will find new opportunities to explore. We as individuals are constantly changing as we learn and find new and better ways to solve the problem at hand. We co-evolve with the projects and products we create.

There are other fundamental principles behind individual practices related to flow such as work-in-process limits and small batch sizes (principles of queuing theory) covered very well by Ken Rubin in Essential Scrum and  Donald Reinertsen in Principles of Product Development Flow. However, I think you'll find that they are more easily understood when approached from the perspective presented here.