process

Yellow Sticky Notes And Operating Costs

by

(This column is posted at www.StevenSavage.com, Steve’s Tumblr, and Pillowfort.  Find out more at my newsletter, and all my social media at my linktr.ee)

Once, many years ago (I think in the 2010s?) I interviewed at a video editing software company to be a Project Manager. When I asked what tools they used to track work, they pointed at a glass divider covered in sticky notes. That was it, that’s how they wrote video editing software which, as you may guess, is not exactly a simple process.

If you’re familiar with Agile methods, it may not seem entirely unusual. If you’re not familiar, then I’ll summarize all-too-simply: Agile is about breaking work into small, easy, tested chunks as you go through a larger list of work. It’s basically quick, evaluated development of software in order of importance.

So sticky notes were, in theory, all you needed for Agile, especially if the Product Owner (person with The Big List Of Stuff To Do) had their act together. I’m going to assume this company had one that did since, hey, sticky notes.

This experience stuck with me. Now, some 15+ years later, having used many project management tools, having seem many technical innovations, being friends with people in tech for decades, a lot of us seem to want the sticky notes back.

We’re beset by enormous choices of tools and the tools have choices. You can buy this software package or that and integrate them. All of them have their own workflow which you have to learn, but you can also customize your workflow so you can confuse yourself your own way. Plus you have to work with everyone else’s tools together in some half-baked integration.

But when all of that doesn’t work, does the tool fix it? Nope you get to! So soon you’re downloading a spreadsheet from one tool, to load into another tool, then you have to correct the issues. That’s if you can think like the people that designed the tools or the workflow, and those people weren’t you.

Past a certain point all our new helpful tools require so much learning and reconciliation, we might want to use sticky notes. And yes, I have met people who still use sticky notes in otherwise high-tech organizations.

I’ve begun to wonder if we’ve entered an era where we’re so awash in tools that the price of learning them, customizing them, and integrating them outweighs their value. This is amplified by the latest updates and changes from vendors, companies being bought out, or regulation and policy changes. There’s a lot of change and adaption that we have to put time into so we theoretically become efficient in the time left.

And that’s before there’s a software outage somewhere in the Rube Goldberg world of ours that brings it all to a halt. I’m looking at you, Crowdstrike, I still have trauma as I write this.

I’m finding a great test of good software is to ask how it would work if it wasn’t software. What if was, I don’t know – done by yellow sticky notes? What if the software wasn’t software but a human recorded, human run physical process. Would it still make sense?

This is something I noticed working with certain medical and research software. Some of it may have old-school looks, or be specialized, but it works (and has to or people get hurt). I once took a training course on medical software and it was both insanely complex because of medical processes, but in review everything I learned made perfect sense and I could see how it’d be done on yellow sticky notes. Even I, some IT nerd who shouldn’t be allowed anywhere near a patient could figure out how this all came together – and had decades before the software existed.

Sometimes it’s worth asking “what if we did this old school” to see what the software should do and how much cost there would be in changing everything or making it incoherent.

And, hey, maybe you’ll just go back to the sticky notes. Maybe you should.

Steven Savage

My Agile Life: Trust

by

(This column is posted at www.StevenSavage.com, Steve’s LinkedIn, and Steve’s Tumblr)

More on my use of “Agile” and Scrum in my life! This one actually gets into my writing – and someone else’s writing.  And work.  Let’s get to it.

So last week I wrote about how the Second Agile Principle helped me deal with changes to my book.  Short form, I learned how to better embrace change and my writing is better for it (despite my resistance).

This got my friend Serdar thinking about his next book, Always Outnumbered, Never Outgunned, and he did his own post on change.  Here’s where he hits on something very important to Agile – personal and professional:

To wit: At one point when writing Flight of the Vajra — in the first draft, mind you — I abandoned several thousand words and backed up a fair distance in the story so that I could explore what seemed a far more fruitful plotline than the one I had cul-de-sac’d in. Better to turn around than to keep fighting against odds I hadn’t a chance of bucking. It meant losing several days worth of work, but when you put faith in the process rather than the resulting artifacts, those hard decisions aren’t so hard anymore.

Agile relies on a lot of trust.  Without trust, Agile falls apart (which I’ve seen plenty of times).  Think about it:

  • You have to trust your Product Owner that they know what they’re doing with their directions.
  • You have to trust your teammates to do their work.
  • You have to trust the Scrum Master to have your back.
  • You have to trust the processes to help you get the job done.
  • You have to trust yourself to do things right.

In personal agile it’s the same thing.  You have to trust yourself, build processes you trust, and keep improving things so you trust they get better.  Personal agile like I use will very quickly show you places in your mind where you don’t trust yourself.

But here’s the funny thing – you trust a lot of things.  But you don’t trust the product or even the product backlog as some kind of perfect result or guide.  Serdar rightly says the artifacts of writing aren’t to be trusted, and I’d add even the artifacts that lead to writing – or any other actions – aren’t to be trusted.  Be it plans for software or a book, they will change.

In fact, trusting your current plans on anything is going to trap you.  Change is inevitable.  The most trustworthy plan will fall apart because the world shifted around it.

Instead you have to trust the processes that keep you going forward. Your sprint standups, backlog planning, the act of writing or coding or whatever.  You trust in them to do good work, get feedback, and set direction.  Good direction – in the forms of backlogs, plans, user stories, etc. – is the result of trustworthy people and processes.  But it is not as important – or as reliable – as they are.

It’s not the map, it’s the confidence of the person giving you directions to help you get to your destination.

In your life, in your own projects, in your Agile (at home and at work) – are you trusting the people and the methods?  Can you?

If not, my guess is you’re none too happy.

(By the way I do plenty of books for coaching people to improve in various areas, which may also help you out!)

– Steve