Agile Design and Development

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

The Agile founders had it right, one size doesn't fit all. What the founders perhaps didn’t foresee, or couldn’t agree on, is that in order for the world to scale and consume their wisdom, it had to be packaged as concrete practices, not as abstract classes with virtual methods to be defined in context. And to the proponents of Agile Scrum, give them their due, for their part, they made it concrete – Agile Scrum has been packaged and delivered. Yet much work remains to realize the promise of Agile, which in summary is, the realization of wise use of lightweight development practices and workflows that flexibly adapt to the changing and evolving needs of customers.

What happens when you apply date pressure to software engineers working on high value software projects? The engineers will focus on delivering Something™ by the Date™! This fatal flaw results in delivery of a Something™ full of chaos and features that nobody really wants or needs.

The Lean Portfolio Management function that controls funding, are given sole authority to approve which Portfolio Epics move into each stream. Epics are not explanations about a problem that needs to be solved. They are pre-formed ideas about how best to solve those problems.

Right away we can see signs of the old-school mindset of viewing teams as a “delivery” function instead of a strategic one. The high level thinkers come up with ideas, and the low level doers execute on those ideas. Ignored is the possibility that those closest to the work might be best equipped to make decisions about it. Escaping from this misguided mindset is a core goal of Agile thinking that SAFe fails to remotely accomplish.

I’ve come to the conclusion that “enterprise web development” is just regular web development, only stripped of any joy or creativity or autonomy. It’s plugging a bunch of smart people into the matrix and forcing them to crank out widgets and move the little cards to the right.

In these structures, people are stripped of their humanity as they’re fed into the machine. It becomes “a developer resource is needed” rather than “Oh, Samantha would be a great fit for this project.” And the effect of all this on individuals is depressing. When people’s primary motivation is to move tickets over a column, their ability to be creative or serve a higher purpose are almost completely quashed. Interaction with other humans seems to be relegated to yelling at others to tell them they’re blocked.

Reading “AS PER THE REQUIREMENTS” in tickets makes me dry heave. How did such sterile, shitty language seep into my everyday work?

The mandate from above is clear, just get it done! Avoid everything that's in the way: all advice, all expertise, all discovery efforts that detract from hitting the Date™!

What these organizations don't realize is that all software change can be modeled as three components: Value, Filler and Chaos. Chaos destroys Value and Filler is just functionality that nobody wants. When date pressure is applied to software projects, the work needed to remove Chaos is subtly placed on the chopping block. Work like error handling, clear logging, chaos & load testing and other quality work is quietly deferred in favor of hitting the Date™.

The word “agile” has been subverted to the point where it is effectively meaningless, and what passes for an agile community seems to be largely an arena for consultants and vendors to hawk services and products.

…Let’s abandon the word agile to the people who don’t do things. Instead, let’s use a word that describes what we do. Let’s develop with agility.

• You aren’t an agile programmer—you’re a programmer who programs with agility.
• You don’t work on an agile team—your team exhibits agility.
• You don’t use agile tools—you use tools that enhance your agility.

/

Individuals and Interactions over Processes and Tools
Working Software over Comprehensive Documentation
Customer Collaboration over Contract Negotiation, and
Responding to Change over Following a Plan

Innovation is messy, and frankly Anti-Steve [Jobs] can’t figure out why you wouldn’t just tell people the right thing to build and skip all the trial and error that comes with innovation. Anti-Steve and his board of directors that keep him in place fundamentally believe that they know what needs to be built. Or at least that they can hire the messiah that will come down off the mountain and tell everyone what to build. There is no such messiah.

The Scrum process says to break down stories into tasks to make estimation easier, encourage collaboration and to be able to show more granular progress during a sprint.

But after a few sprints, we decided to do the next sprint without creating tasks. As a result we drastically increased our velocity and never went back. Here I'll jot down some of the reasons we decided to do this:

1. Breaking down stories into tasks is time consuming
2. The tasks we came up with invariably would change as we worked on the stories
3. Tasks are repetitive
4. Tasks were often carried out in parallel
5. Our estimates didn't improve
6. It decluttered our task board
7. It encouraged collaboration throughout the sprint

While we started our process by following Scrum to the letter, we soon realised that breaking down stories into tasks was something that wasn’t worthwhile for us. In the end we realised that it was overplanning and poor use of our time. In the end we used that time to get on with the work and deliver at a significantly faster pace.

Yesterday I worked on the widget.
Today I will work on the widget.
I have no blockers.

Are you asleep yet? The developers are. You promise them an intellectually stimulating work environment and what they end up with is drudgery.

What value can be had from these meetings anyway? Using “alignment” for justification is so nebulous that it is essentially meaningless. Engineers align themselves. They talk. Especially if you hire good ones (which, you know, you’ll struggle to if you have a culture of coercing them into this kind of busywork). Where does the real discussion happen? It’s written down.

What just happened is a new software product/feature was created that no customer wanted. This happens way too often. In fact, most hyper important software projects that must be done by date certain or else, have deep flaws that cause some variation of this phenomenon, flaws that include:

• Not wanted - Company specified a solution to a problem that customers don't actually have
• No Rarity - Company is pursuing an iKnockoff of existing products. The market already has two scaled competitors with working solutions, customers naturally spend budget on products that are already successful to avoid risk
• Incorrect Packaging - Customers need a website, but the company created an iOS app instead
• Incorrect Pricing - Customers need SaaS pricing, but the company created a shrink wrapped, on-premise solution with CapEx and maintenance agreements instead

Doing it right requires a different pace of working and a much broader thought process than “ok, let’s get this thing out the door.” Which is super tough because most workplaces place a huge emphasis on getting things out the door, and fast. Little agile tickets that are expected to be completed in micro sprints to me seem to be antithetical to doing it right.

My own time in a Silicon Valley startup has proved this much to be true; planning doesn’t make for better software. In fact today our design systems team doesn’t have sprints, we don’t have tickets or a daily standup. Each day we come to work, figure out what’s the most important thing that we could be doing, and then we—gasp!—actually do it.

Watching so many other teams slowly flail about whilst they plan for quarter 3.2 of subplan A, whilst our team produces more work in a week than they all do combined in a quarter has been shocking to me.

After four years of working in a large startup, I know what I always assumed was true: you don’t need a plan to make a beautiful thing. You really don’t. In fact, there’s a point where overplanning can be a signal of inexperience and fear and bullshit. The scrum board and the sprints and the inane meetings each and every day are not how you build another Super Mario 64.

Instead all you have to do is hire smart people, trust them to do their best work, and then get the hell out of their way.

The Agile Manifesto is an immune response on the part of programmers to bad management.

Yagni originally is an acronym that stands for "You Aren't Gonna Need It". It is a mantra from Extreme Programming that's often used generally in agile software teams. It's a statement that some capability we presume our software needs in the future should not be built now because "you aren't gonna need it".

On the surface, the world of agile software development is bright, since it is now mainstream. But the reality is troubling, because much of what is done is faux-agile, disregarding agile's values and principles. The three main challenges we should focus on are: fighting the Agile Industrial Complex and its habit of imposing process upon teams, raising the importance of technical excellence, and organizing our teams around products (rather than projects).

This article is certain to upset many people.