If you need to whip up a simple bar graph, you don’t need to know about version control, sprints, development lifecycles, etc. With your chart making tool, you can bang out the bar graph in a couple of minutes. If you’re building chart for someone else and after you show it to them they need a bunch of changes? That’s another few minutes.

But as the tools and the work power users are taking on gets more sophisticated, just throwing together “products” can get you into trouble. Over time, it’s easy to end up accidentally creating a snarled rats nest that is prone to mistakes, brittle, and unsustainable.

When programming first took off, “cowboy coders” learned that lesson the hard way. Organizations overcompensated, adopting the waterfall approach in an attempt to rein in all that chaos. But too much control turned out to be as unsustainable as too much chaos. So over the years, more and more organizations have moved to Agile methods that strike a better balance.

As power users gain more power, they are also going to need to figure out how to find that balance. But they can’t just adopt the same Agile methods used by software developers. For example:

  • Scrum assumes you have 3 or more developers creating a product. Although many power users are members of a team, most of time they work solo on their projects. It’s hard to have a meaningful Daily Scrum if you’re an army of one.
  • Many power users work on projects where sprints would be useful, but usually they’re also juggling enough work whose duration is too short to use sprints. As a result, measuring Sprint velocity for their larger projects isn’t helpful.
  • With most power user tools and frameworks, using test-driven development would create an inordinate amount of overhead without producing enough bang for the buck. There aren’t a lot of people who use pandas for analysis, for example, who practice test-driven development (although developers who create libraries on top of pandas often use TDD).

But that doesn’t mean power users can’t benefit from Agile. Sprints, MVPs, prioritized backlog lists, regularly reflecting on how to be more effective, replacing status meetings with something more effective, power users’ managers having a role more like scrum masters, groups of power users operating as self organizing teams – all of this could be extremely useful. The key is to adapt Agile methods to the circumstances facing power users. After all, that’s how many Agile methods are created: people were frustrated with how their work was organized, so they started experimenting until they found an approach that fit the reality they faced.

In doing so, power users might help spark a transformation in how their organization’s developers and/or vendor’s developers work. Too many organizations practice “Checkbox Agile”: they check all the boxes, but they throw away the spirit of Agile. As organizations wrestle with what it means to use Agile for their power users, they may also end up rethinking what it means to use Agile for software development.