You Aren’t Really Agile If You Aren’t Doing These 9 Things

Maybe you can relate to this. If you asked anyone at your company if they think your engineering teams are “Agile,” they would say “yes, they certainly are.” Then, if you asked them what they mean by “Agile,” you would get as many different answers as the number of people you asked. Clearly, we’re not all on the same page here.

Leadership claims we’re “doing Agile.” Meanwhile, noticeable changes in the organization are slow to take shape. The supposed benefits of this whole “Agile” thing still seem always to be just around the corner, but never quite here yet. Everyone is working really hard to transform the way they work, but for some reason nothing seems to be getting much better.

Here’s why Agile is not working for you despite everyone’s rampant enthusiasm for it. And I am sorry to say, it’s a far more simple and obvious an answer than you want to admit to yourself, your boss, or your team.

You aren’t doing the Agile basics right—or at all, perhaps.

The following 9 items are, in my view, the first principles of any Agile program. If you are actually doing all of these things, you will start seeing real change in a relatively short time. And if you are not doing all of these things, or only doing some of them, you simply won’t see much real change at all. And if you do, it’s probably a coincidence.

The Technical Practices

1. Your engineers practice test-driven development (TDD) like their lives depend on it. TDD has three major benefits, and I’ll list them in reverse order of importance.

First, it prevents regression errors from being introduced by adding new code. The test suite once developed checks known functionality each and every time a new line of code is written. It’s like bug insurance. Second, it helps keep your code modular and organized. Tests help to define clean and simple interfaces for each new module, component, or function.

But most importantly, The practice of TDD—writing a test first, then filling in the code to pass the test, then repeating with the next increment and so on—puts the developers in a “flow state.” A flow state, my friends, is the magical place where all your best work happens.

OK, if you are not a software engineer, this principle may be hard for you to grasp. But let me see if I can explain it anyway.

Say you order a wall hanging cabinet from IKEA. You open the box, lay out all of the pieces, and you notice a paper template along with the instructions. That’s the template you use to mark the place on the wall where you want to drill holes, and hammer in the drywall screws.

When engineers fail to write code using the practice of TDD, what they are doing is essentially holding up the 40lb cabinet with one arm, while trying to guesstimate where to drill the hole with the other shaky arm. You inevitably get a ton of holes in the wall and a cabinet that’s slightly off center. Make any sense when putting up cabinetry? Nope. Well, it doesn’t for writing code either.

And now, for the engineers in the audience, I’ll direct this straight to you. You don’t think you need to write tests first, eh? Stop fooling yourself. If you’ve never done it before, maybe you have a thin excuse. But there is nothing wrong with just admitting you don’t know how, and just asking for help.

If you’ve experienced the pure joy of being “in a flow state” doing TDD, and you’ve given up trying to do it in your current environment…

Well, there is no one else to blame for the sub-standard code, mountains of bugs in production, and constantly failing builds than that person you see in the mirror each morning. Get with the program, because you’re making the rest of us look bad to the non-engineering crowd.

2. You set up continuous integration properly, and you’re actually using it to integrate. Agile engineering teams leverage continuous integration to, well, continuously integrate new code into the last stable version. The logic here is that the longer new code is developed separately from the last version, the more out of sync it can get, especially with several developers constantly merging in new features. So, integrating new code more often makes it less likely you’ll introduce unexpected behaviors into the application.

Here is how it works:

A developer (obviously doing TDD, but I digress) completes a new feature on her local environment. That feature includes the, let’s call it “business” code to make it function, plus a set of tests that verify that it works as she intended. She commits all of that code into a version control system.

As soon as the commit is registered in version control, the CI tool “wakes up” and pulls the freshly merged latest version from the version control system. It then executes the entire current test suite to make sure that, first, all of the previously written tests still pass, and second, that the developers’ new tests for the new code also pass. If everything is “green”, work continues as planned. If any of the tests fail, old or new, the developer is immediately alerted, and she’ll start working on fixing that failing test right away. No one goes home on a broken build, so it’s best not to merge your code 15 minutes before you have to run and catch the bus home.

Now, I have worked with teams that use a continuous integration tool, Jenkins in most cases, simply to move code from one place to another. The commit to version control triggers activity, but there are no tests to run. That’s not “integration.” No new information about the health of the code is generated from the build, so you’re not really getting the benefits of CI at all.

3. Your environments are configured automatically. The best single test of both the quality of a team’s code and the quality of their engineering culture is the time it takes to get a new developer up and running on their local machine. In an ideal world, a new developer would get access to the version control system, pull a copy down to their machine, execute a single command, and everything would be configured automatically for the local copy of the application to run and be ready for development. Sadly, this is still not often the case, even in 2018.

For the non-engineers, here is why this matters. In the old days, we had to do a lot of manual configuration of software every time we deployed it to a new location. You’d get the code on your machine, and then have to edit a file or set of files to tell the software what kind of machine it’s on, what it’s domain name is, where the database is, what passwords it needs, anything funky about it’s file structure it needs to know. This process was slow and error prone. In the worst cases, it would take a new engineer a few days just to get the application working locally so that they could start adding value.

Then we invented configuration management. These are automated tools for managing all of this configuration data, and often the packages of other software that our application depends on (dependencies, we call them). Smart and capable teams have invested energy up front in making sure their application can be downloaded and automatically configured in minutes (or maybe hours if it’s a really complex system).

If your teams are not managing their environment configurations with automation, you are introducing a huge amount of risk into your system. So get that under control—today!

PS: not to get too technical, but this is also where the benefits of things like containers come into play. If your engineers are babbling about “Docker” or “kubernetes”, that’s what they are talking about.

The Basic Process Stuff

4. You put the customer first. Why are you building software anyway? Who is the customer and what pain are you solving for them by building a digital tool or system. Is that customer always top of mind when your teams are working or is it a vague after thought that only crops up once a month or quarter?

Agile teams are servants of the customer. They are not building anything for its own sake. They don’t get caught up in the “shiny” new tools or programming languages. They only add features that are absolutely necessary. They value getting more value out the door with less code. They ruthlessly eliminate both unused code and unused features from the application.

Everything in your product backlog should be focused entirely around a customer need or outcome. The feature definition should include a metric by which you can measure whether that outcome was achieved once the feature is live in customers’ hands. Every discussion about new features should include the question, “are we sure that customers really need this feature?”

5. Your teams are actually teams. Still today, most Agile teams I encounter are not really teams at all. They are people who work next to each other. What makes you a team is that everyone on the team shares a common goal, can easily and simply articulate that goal to any outsider who inquires, and—most importantly—will subjugate their own interests for the interests of the team.

This selfless teamwork manifests in many places. It shows up in collective code ownership. It materializes whenever a developer drops what they’re doing to help a tester get some completed work tested and shipped. When a designer learns JavaScript so that they can have a better understanding of the impact of their designs on the front-end developers, they are thinking as a team member.

And remember, if you’re on more than one team, you’re not on any team at all. Agile teams are dedicated teams.

6. You limit your Work-in-Process (WIP). This simple rule is perhaps the biggest secret in what makes Agile awesome; maybe second to TDD above, but a strong contender for second place. WIP limits, which you may recognize from the Kanban method, refer to constraining the number of work items any team is working on at a time. There is science behind it, which you can get into by reading Don Reinertsen’s fantastic book, “Flow.” But if you’re in a hurry, the basics is that the more “multitasking” you try to do, either as an individual or as a team, the slower the overall throughput of the product process become. It’s related to the drag introduced by context switching, information degradation over time, and increased overhead of switching and communication costs.

Agile teams try to work on as close to “one thing at a time” as possible. If you have a team of 8 developers, and you’re pair-programming (which, of course, you are), then your team’s WIP limit might be 4 items, where each pair is only ever working on one thing at a time.

The Leadership Posture

7. The business goals of every task are crystal clear. If you don’t know the business value of the thing you’re working on right now, stop doing it. And I am not talking about “makes customers happy” or some bullshit vague metric like that. I mean what unit of measure are you going to use to evaluate success? A conversion rate? A change in revenue? A particular user behavior? If you don’t know, you shouldn’t be adding it to the code base.

A solid Agile leadership will make sure that everyone knows precisely what the business objectives are for the company, what strategy leaders have agreed to leverage in order to achieve those objectives, and how exactly the product will enable that strategy.

8. You measure and evaluate teams not individuals. I am pretty tired of arguing this point, but it just never seems to go away. You can’t measure individuals in a group project that produces knowledge systems. W E Deming knew it and wrote about it extensively. Taiichi Ohno knew it and built it directly into the Toyota Production System. Eli Goldratt talks about it ad nauseum in the famous business novel that introduced us to the Theory of Constraints, “The Goal.” And every major Agile book that’s worth the paper it is printed on has at least some reinforcement of this idea.

So, why then, are you still so intent on measuring individuals and their utilization? Do you have any evidence whatsoever that where all others have failed, you can somehow magically find the way to measure individual engineers and their impact on the quality of your organization’s output? I seriously doubt it, friend.

Teams are measured by their ability to solve problems as a unit. Smart Agile leaders use teams as the primary unit of organization, not individuals. Teams are given clear objectives, a set of resources to leverage and a set of constraints to work within, and then sent on their merry way. There is no place for individual performance reviews in Agile.

9. You have a culture that encourages risk-taking and experimentation. Agile is designed to enable teams to build under conditions of uncertainty. At its core, the Agile philosophy is all about reducing large risks into a series of smaller risks that can be addressed independently.

Experimentation has always been part of the Agile mindset. Experiments might focus on the product and the market, they might address an area of technical uncertainty, or they may address a particular process issue.

The best Agile teams embrace experimentation as a core tenant of the product development process, and not simply an afterthought. Are your teams encouraged to be curious, to take small and reasonable risks, to embrace failure as a learning opportunity?

How Is Your Self-Assessment?

So, how many of the above principles are your Agile teams successfully implementing? All of them? A few? None?

If the answer is 3 out of 9, or less, you are not really doing anything that can truthfully be called Agile. If none of the 3 that you’re actually doing are in the Technical Practices category, you are even further behind than you think, and it will be very hard to catch up with your competitors without outside help.

Please notice that nowhere above did I use the term “sprint”, “backlog”, or “standup”—or even “retrospective”. These are all good things. But they are only the rituals that reflect an intention to work in an Agile way. They are not the thing itself.

But no matter how bad your situation looks, you can do something about it. You can train your engineers in the technical practices (my organization and many others offer this), you can implement process improvements, and you can retain an executive or leadership coach to help level up your organization (we offer this too).

But don’t call yourselves Agile if you’re not. The first step to improvement is admitting you don’t have all of the answers and reaching out for help.

Go ahead, reach out. I’ll be here when you need me.

—

Be a better technology leader

Check out the Startup Patterns Mindful Leadership Accelerator. We cover topics like how to discover and pursue your purpose, effective communication, how to manage up to executives, and how to lead change in an organization using influence rather than authority. Grab a spot now!