Agile

My Agile Life: Multitasking. Sort Of.

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!

Agile methods tend to discourage multitasking as well as having a lot on your plate.  The goal is to avoid distractions (with less multitasking) and avoid having a lot on your mind (by limiting work in progress).  Of course, as we always get interrupted, we tend to multitask a bit.  Sometime things almost have to be done together or require such long delays (like a chat) that multitasking is almost needed.

Let me note that I do think you should avoid multitasking.  I do believe in limiting work in progress.  But there are times multitasking is fine or even good.

What I’ve found that in my own life, what helps is to identify what you can do while doing other things.  Preemptive multitasking as it were.

You know what I mean:

  • You’d like to watch some tv, but friends want to chat online – you can do both.
  • You’d like to come up with a shopping list which you can do while watching tv as it’s not a rush.
  • You want to do some online research, so you do it while chatting or on the phone – heck, the other person may have ideas.
  • And so on . . .

You’ll note a lot of this is recreational/social.  This is where I often multitask when doing things that are “gruntwork-like.” Not something requiring intense effort, nor intense focus, but things that have a lot of “bite sized” tasks so I can watch TV or chat to take the edge off.  Sometimes it even helps to have others around.

This has helped me timeshift a lot lately, as well as get more done.  Yes, it’s multitasking, but only when appropriate.

As  a note I will be the first to say that you should avoid multitasking when it reduces your ability to focus, get things done, or do them your best.  I usually do it when the multitasking is something more fun, or social, and so on.  Be careful when you do this until you learn what works for you.

However, if you make multitasking conscious, you can do it right.  You can also choose when not to do it because you’re more aware.

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

– Steve

My Agile Life: Meetings

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 is another one inspired by my personal agile, but a bit more focused on business.

Meetings are why we can’t reduce meetings.

I find my personal practice of Agile – with a one-man team – informing me about my work in the business world. Since I do all roles, since all information flows to and through me, I actually have a decent feel of what productivity is like because of personal Agile. Thanks to this experience, I can better see when things are messed up in the business world.

Lately, this reasonably decent personal workflow has made me see just how crazy meetings can make us. Trying to schedule them in my own life is tough enough; and then when you look at the job world . . .

We’re drowning in meetings. Sure we complain, but we keep doing them over and over again. We know they waste time. We know people don’t want to be there. We know the people on either side of us are checking Facebook.

We KEEP DOING MEETINGS.

Meetings are terribly inefficient, at least in the way they’re run. If you invite 20 people to a meeting that’s an hour long and each person gets 10 minutes of benefit out of it, then you spend 1200 minutes so people get 200 minutes of benefit. Sure, they may multitask and do other things, but they won’t do it well as if they were focused.

But we KEEP DOING MEETINGS.

I could list any number of reasons why pointless meetings are held, but I want to share a realization of why we don’t stop this insanity.

There are clear solutions to reducing, avoiding, or improving meetings. I’m sure three or four spring to mind as you read this, such as information radiators and quick check-ins. Despite having these clear solutions, we do not use them, and we’re back to 20 people in a room hating it.

Frustrating, isn’t it? I’m sure you’ve tried.

Having worked to transform teams, improve process, and so on, I’m painfully aware that any attempts to change how people work takes time and effort. It also takes meetings, because you have to coordinate, plan, normalize, and so on. Getting rid of meetings . . . may take meetings.

That’s the bogeyman under the bed of meeting-reduction. If we want to get rid of meetings, we have to make an up-front effort to do so, and that effort may require meetings. People don’t want to do these meetings, and might not even have time for them.

We can’t reduce meetings because of all the meetings we have.

Really, it’s enough to drive one to drink. I recommend Licor 43.

What’s the way forward here? In the past, I resorted to either incremental changes or just barreling ahead. My personal Agile work helps as it provides me a lot of gut-level explanations and insights (like this) to share with people, which helps the situation. I’m hoping this personal insight helps people get around meeting-phobia.

But at some point, you’re gonna have to have that meeting. To stop meetings.

Yeah, I know.

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

– Steve

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