Autonomy: Not Just the Good Parts

It's a common lament from management that development teams don't take ownership of the product they're developing.

This may mean:

• Caring about the quality of the product
• Proactively implementing improvements to the product
• Not waiting to be told what to do

The Agile Manifesto talks about self-organizing teams:

The best architectures, requirements, and designs emerge from self-organizing teams.

It's a beautiful concept: teams that rally around a product, nurturing it like it was their own child. Why is it so hard to find people like that?

Actually, those people are everywhere. They've probably just had their hand slapped or their heart broken too many times.

Let's think: What is it that makes a development team want to take ownership of a product? It's probably because they like creating something in their own image, in their own way.

Who wants to own an ugly product that has been foisted on them by the decisions of people whose command always takes precedence over their own?

This isn't the team's baby anymore, it's yours. No one is going to raise your child.

Perhaps this goes without saying, but micromanagement and autonomy are incompatible. If you want the team to own the product, then they own the details, too.

If you want the team to take ownership, then the product has to look like them, warts and all. You don't just get the good parts.

Does this feel sustainable?

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

- The Principles of the Agile Manifesto

I'm kind of obsessed with the idea of sustainability. In fact, you could say it's a major theme of my writing on this very blog.

Below are some unsustainable practices I've covered in the last few years, with links to my writing on them.

---

We've been collecting paychecks for several months without delivering a valuable feature to a real user.

• Maximize the Amount of Work Not Done
• Breaking Work Into Chunks That Users Care About
• Continuous Delivery and Management Pathologies

We complain often about the need for improvement in our processes, but we don't make time for the work or hold anyone accountable.

• Retro Grade

We're paying highly-trained technical experts to do tedious, manual tasks that a computer could do.

• Discipline Is a Limited Resource
• My Job Went to the Cloud
• Be the Automator

We're pulling our hair out trying to forecast release dates, and working overtime to fit in all the work.

• How Do I Convert Story Points to Hours?
• The Psychology of Story Points

The QA people never have enough time to test all the code the developers are writing by the end of the sprint.

• Quality Assistance

We're rushing to meet deadlines, and we insist on getting every detail right the first time.

• Don't Trap Your Clients in the Bikeshed
• Opportunistic Programming

We're slowing down the delivery of features to do code reviews of every commit, but the code quality is still low and we have tons of bugs.

• Small Diffs and Code Reviews
• Keep Code Reviews Focused on the Code

Maximize the Amount of Work Not Done

My favorite principle of the Agile Manifesto addresses simplicity, or as they describe it...

the art of maximizing the amount of work not done

This principle is so core to the way I approach my work as a software developer, that I often take it for granted.

"Maximizing the amount of work not done" almost sounds like a definition for laziness, right? No, it's not about laziness--we just don't want to work on things that no one will care about.

Software is such a pain in the ass to describe, develop, test, budget for, maintain, operate in production, etc. I can stomach all these things because I think about the people who will use the software and how it will save them time and make their lives easier.

It's hard to get motivated to work on things I don't feel confident any real user will value.

In fact, I'd say a thread that is woven throughout the Agile Manifesto is this idea of never drifting too far away from what we know will be valuable to real people.

Let's examine a few more of the principles of the Agile Manifesto...

Principles:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Translation: At every stage, let's make sure that the customer sees exactly what we're building for them, so that we don't waste time building things they don't like.

Principle:

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

Translation: We don't want to keep building something the customer doesn't like just because the requirements say so.

Principle:

Business people and developers must work together daily throughout the project.

Translation: Let's make sure the people who will actually use the software we're building actually like what we're building for them and find it useful.

Principle:

Working software is the primary measure of progress.

Translation: The people we're building the software for only know that we've built something valuable for them when they have real software at their fingertips. Until then, they must take it on faith that we're building something valuable.

Maximize the amount of work not done. The customer gets the most bang for their buck, and the team stays motivated. Everyone wins.

Does this feel agile?

This is how Merriam-Webster defines agile:

1. marked by ready ability to move with quick, easy grace
2. having a quick, resourceful, and adaptable character

It's common for software development teams to get lost in the artifacts and ceremonies associated with "Agile" methodologies. You know--standups, backlogs, sprints, etc. They can lose sight of the very basic idea of what agility means.

I've always thought of agility as being fundamentally about change--how well you deal with change.

The Agile Manifesto talks about change explicitly:

Responding to change over following a plan

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

It doesn't matter how well you're following "the process" if you're not responding well to change. If you're not responding well to change, then you're not agile.

How well do we handle changing requirements, for example? Do we grumble and complain, or do we take it in stride?

If we're grumbling, why are we grumbling? Maybe it's one of these reasons:

• We wrote very detailed user stories or acceptance criteria that we have to change now
• The QA people have test cases they have to rewrite now
• We're mid-sprint and we've already committed to a certain scope of work

In the spirit of responding well to change, we could examine those pain points:

• Are the user stories or acceptance criteria written at the level of value an end user would recognize, or do they include low-level implementation details?
• Are the QA people focused on testing business value delivered, or following a rote checklist focused on implementation details?
• Why don't we deliver the business value that we committed to at the beginning of the sprint and capture the new requirements as an item/items for a future sprint (which is at most 2 weeks away)?

Software is soft. If we're working with a process and artifacts that we experience as hardened, ossified concretions, then we might stop and ask: what would it take to get back to our software being soft? What would it take to get to a place where it felt easy to respond to change. What would it take to be agile again?

Keep Code Reviews Focused on the Code

Hopefully we're all doing code reviews, right? Whether it's part of a pull request process, or something else, it's important to get another set of eyes on one's code.

There are a million checklists and blog posts out there on what to look for and how to give constructive feedback.



The thing I don't see discussed enough is how to appropriately scope a code review. When I'm reviewing commits, what should I leave out?

Here are some things I believe are out of scope for code reviews:

- Hypothetical business requirements

"What if the business wants X as well?" Then let them ask for it. That's what the product backlog is for.

- Broad architectural debates

"Should we change the way that we're doing X in general?" Maybe we should. Let's put an item in the backlog to find a new approach. If we adopt a new pattern for similar functionality, we can revisit this code and refactor.

- Fear of change

The perspective that the code under review must represent the last word on a particular topic. If the code under review is high quality, well-tested, and meets a known requirement, then it represents no danger to master. There's no shame in changing or even deleting the code in question with a future pull request if requirements shift.


As with so many aspects of software engineering, setting the appropriate scope is key. For code reviews, stay focused.

"Environmental Issue"

I really like a post I read recently from Paul Osman called Production Oriented Development.

He touches on a lot of topics near and dear to my heart, but the section on non-production environments stood out:

Environments like staging or pre-prod are a lie. When you’re starting, they make a little sense, but as you grow, changes happen more frequently and you experience drift. Also, by definition, your non-prod environments aren’t getting traffic, which makes them fundamentally different. The amount of effort required to maintain non-prod environments grows very quickly. You’ll never prioritize work on non-prod like you will on prod, because customers don’t directly touch non-prod. Eventually, you’ll be scrambling to keep this popsicle sticks and duct tape environment up and running so you can test changes in it, lying to yourself, pretending it bears any resemblance to production.

I've heard the heartbreaking phrase "environmental issue" too many times in my career. You know, like when a developer spends days investigating a bug reported by QA only for the team to decide it was due to a configuration drift between a lower environment and production.

With modern infrastructure-as-code tools like Puppet and Terraform, at least there's a chance of preventing the pitfalls with using non-production environments. Even then, only prod is prod. ¯\_(ツ)_/¯

Process Bikeshedding

Hopefully we’re all familiar with Parkinson’s law of triviality:

Parkinson observed that a committee whose job is to approve plans for a nuclear power plant may spend the majority of its time on relatively unimportant but easy-to-grasp issues, such as what materials to use for the staff bikeshed, while neglecting the design of the power plant itself, which is far more important but also far more difficult to criticize constructively.

One anti-pattern to watch out for in retrospectives is what I would call process bikeshedding.

Topics like these tend to get a disproportionate amount of coverage in retrospectives:

• The length of sprints (2 weeks or 3 weeks?)
• On which day to start the sprints (Monday or Wednesday?)
• On which day to have the sprint planning meeting (first day of this sprint or last day of previous sprint?)

They come up over and over because they’re simple, easy to have an opinion on, and no one’s feelings will be hurt by discussing them. Unfortunately, this also means they’re trivial—i.e., not impactful to the delivery of working software to production (the purpose of a sprint).

So how does a team get beyond the trivial to discuss the real stuff? That’s the tough part. But I believe it comes down to trust and scope.

People need to trust each other in order to discuss deep concerns. There’s no magic to building trust. It just takes time.

In Parkinson’s example of the nuclear power plant, why are people so focused on the bikeshed while ignoring the design of the plant itself? I’d say it's an issue of scope. Luckily on a Scrum team we’re not approving designs for a nuclear power plant (hopefully); we’re just trying to improve the next two weeks on our software project.

In this video on Scrum retrospectives, Jeff Sutherland cuts the scope:

You only want to fix one thing at a time.

What is the one thing, that if we fixed it, would have the biggest impact on making this team go fast? And then commit to fix it.

Certainly the color of the bikeshed is not that one thing.