Agile

Can You Imagine Starting?

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)

I was going to do a post on media forms and what we can learn about today’s media from the Dada art movement, but Serdar had to go and get all brilliant and discuss how people can’t and shouldn’t wait for the right conditions to start something. It deserves it’s own blogpost, so me discussing art movements has to wait.

Serdar points out how people wait for the right conditions and how you can always find advice, from Doris Lessing to Buddhism that the time is never right, never perfect. The problem of course is helping people understand it’s time to get off their butts and do it. If you’ve ever tried to get someone – or yourself – “going” you know what I mean.

Now I work with Agile methodologies, as anyone who’s known me for five minutes is aware. Agile is about breaking work down, doing it in order of importance, and very importantly getting going. Just start and take feedback later – in fact doing something means you at least get feedback so you can do better (or even just quit). Agile isn’t “move fast, break things” it’s “move fast, make things.”

Thus as you can imagine I have to help people “get started” and “just get going.” Which should be easy as I have a lot of experience, a lot of certifications, and a very irritatingly effective attitude of “just do it.” Should be easy with a person like me, right?

Of course you know the answer is that it’s not, which irritates me at an irrational level. Sometime I “buddy up” with “just give it a try.” Sometimes I “Agile harder.” Sometimes I end up a therapist. But Serdar’s post made me realize in some cases what people lack is the ability to imagine starting. It’s easy to look at a big project or some ambitious idea and be so overwhelmed you can’t imagine starting – and in some cases it’s easier to imagine failing.

It’s easy to imagine not starting. I’ve realized as I mull offer Serdar’s writings that people like me are trained imagining how to start, other people have that imagination of how to start and we have to help others develop that capacity.

Of course easier said than done, and each person or group is an individual case. Maybe we have to inspire. Maybe we have to (in some cases literally) draw a picture. Maybe we encourage a prototype. Maybe we just “give it a shot.” But we need people to be able to see starting despite “imperfect” conditions.

Which means when we’re trying to help someone overcome a fear of imperfect conditions, our first job might be to help them see what’s possible. But the next job is helping them develop that imagination.

Steven Savage

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

Evil Agile

by

We wonder how people can get away with so much horrible stuff.  I’d like to talk Evil and Agile productivity, and yes, I am completely sober as far as you know.

For those of you who are in no way familiar with me, I’m a Project Manager, a professional help-stuff-get-done-guy.  While I’m being paid to be the most anal-retentive person in the room, I prefer to use Agile Methodologies, which are all about rapid, adaptable, approaches to getting things done.  It doesn’t sound Evil, but stick with whatever journey I’m soberly on because I think Evil people are actually pretty good at a kind of Agile.

Many Evil people have A Goal.  It may be (more) money and power, it may be dealing with their childhood traumas, and usually, it’s a dangerously pathetic combination of things like that.  Agile is all about Goals because when you set them, they direct your actions more than any single plan.  You gotta know where you want to go to get there.

Then, simply, Evil people set out to achieve their Goal by whatever means they can.  They don’t care if they lie, cheat, steal, burn books, burn people, and so on – the Goal is what matters.  Agile is also about making sure that your actions direct you toward your Goal so you’re focused and efficient – it just doesn’t involve Evil.

But what if Evil people hurt others, get caught, etc.?  Simple, they lie or do something else because they don’t care – they adapt.  Agile emphasizes constant adaptability and analysis as well, just with an emphasis on truth and honesty.  Evil people are pretty adaptable, even if that adaptability is staying the course and lying about it until others give up.

Agile emphasizes goals, directing yourself towards them, and adaptability.  Evil people do the exact same thing.  The only difference is that Agile emphasizes helping people and being honest, and Evil people are just Evil.

And this is why we’re so often confused by Evil people.

We expect elaborate plans from Evil people – and there may be some – but they’re focused on their Goals and how to get there.  We expect Evil people to be derailed by getting caught in lies or hurting people, but as we’ve seen they don’t care.  They want something and they’ll adapt no matter the price played by other people.

It’s the banality of Evil all over again.  Evil isn’t even interesting in how it gets things done.

Steven Savage