Agile Development Without The Bullshit

It is a thing of human nature to kill the meaning behind valuable phrases. While there may good intent behind phrases such as "SEO Optimization" and "Social Media Marketing," these terms become insignificant in substance. Boardroom buzzwords hold little merit to those in the trenches of building products from scratch, and "Agile Development" is no exception. The term 'agile' as it is currently used may as well be synonymous with 'development.'

The other day somebody asked me if I had any advice for an aspiring product manager. Without a moment of hesitation, I said the first thing to c ome to mind...

If a PM ever speaks to you in a way you don't understand, they're probably bullshitting you.

What I'd like to achieve is a separation of fluff from reality. It doesn't take much real-world experience to understand the extent to which the Agile Manifesto is misunderstood.

Even as we dig graves for our terminologies, it is important to remember the concepts they had come to stand for. Let's detox and salute good development practices, yet unapologetically call out bullshit that puts the integrity of our practice at risk. We'll start positive.

For the sake of simplicity let's say the implementation of agile has 3 parts: Iterative Development, Scrum processes, and Workflows.

1. Iterative Development

Obvious statement: good product development means constantly iterating. We'll almost never get it right the first time, and the best way to recognize that is by failing and adapting. This is handled with sprints.

Sprints refer to Developing in relatively short increments ensures frequent releases, typically over a few weeks or less.

Sprints are only useful if they end with a form of deliverable: failing to test what is built at the end of a sprint, against either end users or stakeholders, is the first failure to be made in agile adoption. Without feedback, sprints are simply arbitrary dates.

Pre-MVP Sprints: Sprint completions leading up to an initial release should mark internal demonstrations. Even if we can't test against our audience, we can see how we ourselves shift when seeing delivered code.

Post-launch Sprints: Iterations are key once a product is available to end users. This is the data we're after, because this is how our product grows.

Aside from sticking to a frequent release schedule, enforcing sprint dates has a number of other benefits:

For enterprise products, it is important to limit releases to a time frame, in effort to ease pressure on a team. This protects software development from top-down "get it done now" attitudes. Rushed hot-fixes to live products can put an entire corporation at risk.

Small shops have no problem frequently releasing to live products, as the risk of disaster is low. However, it becomes difficult to measure what is working and what is not when deployments are haphazardly constant. Over time, releases should follow a schedule for sanity as well as effective data analysis.

2. Scrum Processes

Where iterative development is what we hope to achieve, Scrum processes are the means to that end.

Scrums: Frequent scheduled check-ins are of course critical to keep members of a team moving. These facilitate conversations which may not have happened, or otherwise happen too late.

Backlog Maintenance: The product manager must build a backlog of features, while also treating backlogs as living entities. Even if products have roadmaps, these roadmaps change as we learn. The very definition of a product should remain dynamic.

Estimates, Velocity, and Burndown: A concession we all make is that software development is unpredictable. Estimates are ballparks; these numbers mean nothing unless we can gauge the pace at which a team moves. This is accomplished visually via usage of burndown charts.

All of these processes empower teams to adapt. As circumstances change, we have the power to adjust by modifying Scope, Timeline, and Resources.

3. Kanban

Kanban boards are synonymous with agile, but should really be standard for all development. Nearly all of us adopt this form of issue tracking... I hope. Issue boards are immune from being labeled as 'bullshit' as they're simply common sense. However, be wary of those who overcomplicate something this simple: the only reasoning behind a verbose explanation of Kanban is likely intentional confusion (read: somebody is bullshitting you).

'Kanban' seems like an overly flavorful word, considering it represents "moving stuff into columns." This originates from its Japanese origin as Toyota's famous efficiency brainchild; more of a tip-of-the-hat to agile pioneers than intentionally confusing.

The Bullshit

Let's call a spade a spade. In my humble opinion, the following tendencies within agile are bullshit:

Mandatory Daily Standups: Strict implementations of daily stand ups have lost my faith. Overly frequent stand-ups hold diminishing returns, which frustrate developers (why am I not working right now?). A project lead with an ego can justify these meetings with a delusion of power, usually evident to the team, thus causing a morale disaster. Stand-ups should only occur as frequently as they are useful, and the literal "standing up" aspect needs to die immediately. Slack and/or Hangouts were designed for these.

Scrum Masters: The idea that a product owner does not have the capacity to run their own scrums is laughable. If you can not manage the day-to-day execution of your product, what do you do?

The Term "Product Lifecycle": To this day I have not heard this phrase uttered by a respectable professional.

Implementing Processes Haphazardly: While I might personally timebox my own time, I would never enforce process like this upon others at my current workplace. Knowing what fits your organization culturally should take precedence over following rules.

How We "Teach Agile": If you're a PM, take some time online to find resources for improving your tangible skills, such as learning workflow schemes or improving your requirements documentation. Good luck. It feels impossible to find a constructive article on how to correctly write a User Story, but back-and-forth nonsense about 'team dynamics' is everywhere.

Purely by chance, I stumbled on this link, which is Smartsheet's attempt at explaining agile development.
Check out their list of "topics:"

"Agile vs Scrum?" "Kanban vs Agile?" These are not comparable things. This is the equivalent of comparing wheels to a bicycle.

Smartsheet is an industry leader and a tool which I use, no less. This page is, however, meaningless dribble. If the creators of our own tools can't explain their purpose, does anybody actually know what they're doing?

Cleaning Up

I want to instill confidence in our methodologies as opposed to diminishing it. Proper agile implementation is something that can only be achieved with an understanding of development, and an understanding of the people you're working with.

Those who can, do; those who can't, teach. It's time we start ignoring preachers while elevating those who tangibly succeed in product deliveries. Good practices exist, but process adapts to teams as much as vice versa.

We often attribute our inability to follow along as a personal lack of understanding. Instead, consider the fact that the words coming your way are well-crafted nonsense.

To heighten our craft, we must make our own conclusions as to what actually works to achieve our end goal: to create the best product possible.