Agile

My Agile Life: Be Your Own Best Boss

by

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

(My continuing “Agile Life” column, where I use Scrum for a more balanced and productive life continues).

One of the better bosses I had, when seeing a report I had created, noted “Now I understand where we are and I’m worried.”

Why do I say he was a better boss? Because his reaction to seeing disturbing data was to then figure out what to do. He didn’t kill the messenger (me) or berate the team (everyone else).  So, solve the problem.

This provided what’s known as Psychological Safety (https://en.wikipedia.org/wiki/Psychological_safety), feeling I and we could take risks.  Ironically I was laid off a few months later – as was he – due to other reason.  I felt so bad for him being laid off I forgot my own feelings of annoyance.

Psychological Safety is crucial for good management and good Agile.  Agile philosophy and methods depend on feedback and authenticity so people can respond, communicate, and improve.  Without that it will fail -and trust me, I’ve seen some doozies.

In personal Agile, you’re everyone – the boss, the product owner, the scrum master, the team, the analyst, etc.  Psychological Safety seems to be a bit irrelevant here.

But I realized it’s not.

Ever berate yourself for mistakes?  Ever beaten yourself up over missing something?  Hard on yourself?  You probably have done all of this – you haven’t provided yourself with psychological safety.  You’re being the Bad Boss to yourself.

This is very common.  This is probably near-universal.  I’ve encountered many people who beat themselves up constantly, and worse of all excuse it.  They’re their own battered spouse, their own abusive parent, their own tormentor.

Honestly, a lot more of us probably need to be in therapy.  But back to Agile before this gets too depressing.

To be productive, you need Psychological Safety, even in your own personal life.  How can you achieve that?  A few things I’ve found:

  • * Honesty.  Be honest with yourself self, admit your mistakes and flaws and issues.
  • * Cooperation.  Work with yourself to improve.  Coach yourself.  “You” are on the same team.
  • * Enablement.  Help yourself get better so you don’t repeat mistakes and can improve.
  • * Review.  Review what you do to improve what you do.  It becomes regular, it becomes habit.
  • * Empathy.  Let yourself “feel” what you feel, its like having empathy for others but you’re taking a look at yourself.
  • * Humor and fun.  Learn to have fun, let yourself have fun, enjoy things.

It’s not easy.  But it’s better than the alternative.

Being your own worst enemy is, well, the worst.  This is because you can never get away from yourself.  How about being a good manager to yourself instead?

(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: Overwork

by

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

(My continuing “Agile Life” column, where I use Scrum for a more balanced and productive life continues).

Uhg.  So as you know from my blogging about agile techniques, I’ve been getting overloaded.  I’m trying to fix this with some success.  So here’s what I’ve been trying.

  • Velocity.  Velocity, the measure of work done in a timeframe, is a big part of Scrum.  One reason to measure it is to see what you can do – but another is to make sure you’re not overloaded.  I can tell my usual workload doesn’t quite work out, so I’m trying to reduce it a bit here and there.  EXAMPLE: Restructuring how much I put into a given project a month.
  • Effectiveness.  Do things better.  I’ve found you can also save time just by doing stuff better.  EXAMPLE: I made graphic templates for upcoming graphic work.
  • Letting go of the schedule.  Work done on time doesn’t matter if it’s poorly done.  You have to re-evaluate and re-assess your schedules and in some cases dispose of them entirely.  EXAMPLE: I had some library donations to make that kept getting interrupted, so I had to accept “it gets done when it gets done.”
  • Iterativeness.  The flipside of efficiency is to not try to be perfect.  Some things are iterative, things you do over and over or regularly.  These can be improved, or mistakes compensated for.  EXAMPLE: Cleaning.  If I miss a hard water stain in the shower it won’t kill me as I’ll fix that next week.
  • Capture.  Be sure to capture any big blocks of time you want to use for something.  EXAMPLE: I have some convention speaking coming up so I literally put it in my schedule as a big block of time to note “I will be doing nothing else then.”
  • Sizing.  I’m sticking with the Fibonacci numbers for sizing my work – in hours – as it seems to produce better estimates.

I’ve also looked at things that mess up my planning and scheduling and productivity.  The Antipatterns.  They are

  • Loading Up.  When you find your maximum velocity of work, it doesn’t mean it’s what you should do.  It’s what you’re capable of when you push yourself.  What is you sustainable rate?
  • Lumping.  When possible break things down so you can calculate your workload – and because it lets you adapt better.
  • Missing lumps.  Some things are just purely about a time commitment, like “setting aside X hours to relax.”  Some things are better lumped together just so you’re not micromanaging.
  • Not looking at value.  When you do something ask what makes it useful – believe me there’s some surprises in there.
  • Bad Deadlines.  Again, deadlines should serve quality, not the other way around.
  • No goals.  When you don’t have goals, you can’t plan.  We often substitute panic, deadlines, etc. for goals – those aren’t goals.  Goals are positive.
  • Done over quality.  Doing something fast poorly can be worthless.
  • Rigidity.  Agile methods are about embracing change, and if you have to keep things rigid, you’re not Agile.  You need to find ways to be adaptable.

Hope these help you out.  Something to look out for in your own life – and anyone you manage.

(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: The Line Isn’t So Dead

by

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

(My continuing “Agile Life” column, where I use Scrum for a more balanced and productive life continues).

Right now I’m doing Agile methods in my own life, specifically Scrum.  This has been very successful, both in terms of becoming productive, but also in truly understanding good process and productivity.  However, I often felt (and feel) odd bits of discomfort, concerns over things being late, and so on even though I had a great grasp of how things were going.

Why am I worrying despite having such visibility into my own work?  I literally know my plans for a month, I can adjust on the fly, I have a backlog/roadmap fusion?  Why am I worrying?

This article on Kanban made it clear –  http://www.personalkanban.com/pk/primers/how-to-limit-your-work-in-progress-1calm-down-and-finish/.  I was still focused on deadlines.  Wait, deadlines as bad?  Sometimes.

Think of it this way.  Agile methods are about adaptability and doing things right – a lot of good productivity methods are the same way.  The thing is if you focus on the deadline, you often forget about doing things right – and you stress yourself out.

For example, my fiction book.  I have a “deadline” for this that’s set purely in my head for very little good reason.  This deadline has smaller deadlines.  When I stepped back I realized that these deadlines were arbitrary and affected my productivity and work breakdown.  Getting back into the swing of fiction was a bit of a challenge, and arbitrary constraints kept me from focusing on my craftsmanship.

Instead I had to ask not just when things had to be done, but what’s the most productive way to approach my work – all work.  Not just a book, or cleaning the bathroom, or anything else.  What’s the most important things to do and how do I do them effectively was more important than a given deadline in most cases.

Sure the deadline mattered, but unless the deadline was truly more important than doing it right, it wasn’t a worry.  By the way, the book may also be about a month later than I predicted.  You can guess why.

This is a subtle part of Agile methods, and one I missed.  Scrum may have it’s timeboxed sprints, but is always re-prioritizing.  Kanban focuses on Work In progress with priority in the background. Most agile methods are not compatible with our old ways of thinking where the deadline has to rule everything.

Sounds weird.  Ask yourself this – what if you had a choice to do a good job but it’d be late or done in parts, or delivering something bad on time?

As an example, let’s say something has to get done at the end of the month.  You of course rush this and do it early – but is it the best thing to do earlier that month?  Could it delay other work that backs up on you?  Could it be you need to do it in stages to get feedback to get it right?  What if making it a week late made it far better?  What if you did part of it and got feedback and did the second half the first week of the next month?

Also the focus on the deadline may make you miss doing things right.  Consider this – if you focus on doing something well, won’t you get it done quicker, especially over time?  Won’t it last longer?  Won’t focusing on quality and work first, ironically, mean you’ve got a better chance of hitting the deadline (or at least being more on time later)?

Now back to my writing.  I had gotten so focused on my deadline I hadn’t thought about the best way to do things – and as I improve/polish my fiction writing, I need a bit of “space.”  So I set aside a block of time a month to work on the novel, each task takes some of that allocated time.  I can adapt to tasks and needs of this highly chaotic effort. Now when I decide what task to do then I focus on quality and careful sizing, but I’m not overplanning around a deadline.

(Eventually, as I improve/polish/shake the rust off I probably can be more scheduled).

In all Agile methods, to one extent or another (less in Scrum, more in Kanban), you focus on the best ways to be productive first.  Letting old ways of thinking about when things are due or deadlines can, ironically, interfere with results.

I’m not going to knock deadlines.  They have their place.  But when they interfere with doing good work, you have to ask just how much value they have . . .

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

– Steve