agile life

My Agile Life: Fix A Few Things

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).

Many Agile methods use some kind of retrospective to review and improve. I adore them but find they can drag for two reasons: sometimes people hate them and sometimes people go overboard.  It can become a venting session or it can become a case of people shutting down.

Personal retrospectives can be a drag as well for the same reasons, though I find it tends towards the “overboard.”

I find that the “overboard” and the “underboard” are part of the same problem – that retrospectives can be overwhelming.  If you want to discuss what went wrong on a sprint or on a project, you can probably easily find tend or even hundreds of things.  This can lead to people endlessly listing off problems – and people trying to ignore then because there’s so many (and their egos feel threatened).

A retrospective needs you to both focus and not be afraid.

What I’ve learned both as an Agilist and in my own life (where I can’t escape any of this) is that you need to limit what you try to improve. When you focus on one or two or a few things to get right, you can get them done – focus on every problem and you’ll never start, or you just won’t try and review your work.

Besides, as you focus on a limited amount of improvements you can also reinforce the issue that many of the problems that came up were already taken care of.  All those hundreds of problems got taken care of by reasonably mature people or a reasonably mature person and it’s probably not worth going over.  Focus on what needs to be improved.

On top of that, the focus on a limited number of issues can take your ego out of it.  You ignore the vast amount of things you can complain about to focus on things you can and want to fix.  It tones down the fear you may feel of going over the many things that did go wrong, dealt with or not.

I’ve found the “power of Few” to be very helpful in that I can focus on getting better in specific ways – ways that have real value.  Plus it doesn’t’ trigger any insecurities

As an addendum, you should always seek to improve outside of reviews and goals. Good opportunities to get better abound all the time, and seizing on them is a big part of an Agile Mindset. It also helps you get used to facing and fixing problems on the fly – so they don’t gum up your retrospectives (and your self-esteem).

(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: Eat Failure, Not Your Peace Of Mind

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).

Doing Agile in my personal life taught me how to fail. You’d think at my age I’d have plenty of practice failing, but there’s always something to learn.

Ever obsess over a problem or mistake? Of course you have. We make mistakes then play with them in our heads over and over even while we fix them, berating ourselves as we do so. Even when the mistake is fixed, the self-flagellation may continue afterwards.

This is terrible for our peace of mind. Every minute spent in worry is a minute not spent doing something else. Worry can eat up so much time that we get less done – which only makes us worry more.

In business, we’re familiar with the equivalent of this worry; blame game and paralysis through analysis. A department or group becomes so locked up by blame-flinging and over-analyzing nothing gets done. Such a department is as trapped just like person locked in an endless cycle of self-loathing. In fact, I’d say it’s pretty much the same thing

In doing Agile for my personal life as well as work, I came up with the term “Eat Your Failure.” Agile methods use failure to fuel improvement. Failure’s not just part of the process – failure powers it. Failure is actually not bad (well, not entirely).

This has helped change my attitude towards failure in a very short time, and am finding it fear of it starts to diminish. I’m far more aware of when fear of failure or annoyance with it drains my time. I’m less upset with it because I take an “eat your failure approach.” By treating failure differently, I have much more peace of mind and get more done.

(Trust me, on the novel I’m working on, that’s such a change of pace I get lots of fear of failure.)

In large organizations, this “eat your failure” mindset is as important if not moreso. If I get obsessed with failure and don’t think in Agile methods, I can slam a beer or go to therapy. In an organization, bad attitudes towards failure can become part of culture and outlast the people there (and their supplies of beer and therapy). Worry can become institutionalized.

Taking a positive or at least progressive view of Failure doesn’t just bring efficiency. It brings peace of mind.

Of course in our lives or in our jobs, we have to make sure that’s part of our culture, be it just us or an entire company. It’s up to us to make that change and encourage the change in others.

But honestly, how many people or businesses would be much happier if they just said “Let’s live with failure and improve” over obsession and guilt and denial?

Yeah, we know the answer.

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

– Steve

Eat Your Failure: Agile is Failure Absorbent

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).
So let’s be honest, May was not my greatest month. Sure, I got things done but plotting my first novel took over twice the time expected and isn’t done yet. I only wrote 84% of what I wanted for the minibooks. I had to hold off many small project due to time an illness, business, and allergies.

I honestly felt bad. I had failed. That was bad, right?

Wrong. Agile methods are about responding to change and learning. They are not failure avoidant, they are failure absorbent; failure is expected, learned from, and worked into the process.

OK I still feel bad, but I don’t have to – that’s not Agile – it’s just my own neuroses. I’m not used to absorbing failure – nor are many other people or groups.

Most organizations are failure avoidant – and because of that they fail even more. Nothing ensures learning slowly, having neurotic relations, continuing the blame game, and adapting poorly than being failure avoidant. I’m sure you’ve been in failure avoidant situations – it’s bad at work and worse with yourself.

Failure absorbency is a major part of Agile philosophy and methods. The goal of Agile is to be able to respond quickly, using communication and responsiveness to change to allow you to deliver work faster and better. Agile expects failure. Agile practices eat failure and use it to become stronger.

The only thing to feel bad about is not responding to failure appropriately. Though I suppose that’s a separate failure you can then respond appropriately too.

When you fail in Agile you should review, learn, and figure out how to adapt and do better. It’s not what you did wrong, it’s what you learned and how you adapt. Eat your failure.

So what did I learn:

  • TOO MANY ANKLEBITERS: I assigned too many small tasks that I didn’t need or I should have done to “clear the plate.”
  • TIMESHIFTING:Some of these tasks could have been timeshifted better – there’ a few cases where I just figured I’d get to them.
  • TOO PACKED: I had no room for disruption baked into my plans despite having so much going on yet having so much free time.
  • POOR PLANNING DUE TO OVERCONFIDENCE: I didn’t plan out the novel plotting well at all as noted; it may be this novel is going to be far less timebound and far more about iteration.
  • OVERCOMMITMENT: The Novel didn’t just take longer, I had to literally “back my mind out” of work that held up my imagination. It’s like writing code before the design research is done – an then you don’t want to change the code.

Now how do I deal with this?

  • Review tasks better to make sure I really need to do them – success if often measured in what’s not done or needed.
  • For truly new project, like my novel, watch my time estimates on early stages and give myself space to do them write. Also, don’t overdesign/overdetail or not back out.
  • Get a better sense of my velocity so I don’t overload myself (which I think I’ll have end of this month).
  • Better pace myself, which is part of velocity.
  • It’s probably better to find I have spare time in a sprint then to overload myself – If I have spare time I can start taking items out of my backlog. Again focus on what’s needed.
  • I’ll review going to two week sprints in July – it’d make me much more adaptable.  However I think long term my life will evolve from Agile to Kanban.
  • I still run too many projects at once – the Minibooks being a classic example of trying to do them over time, and that writing can just turn into a distraction.

So that’s how I adsorb failure – getting better.

This has made me even rethink how I’ve handled failure in my life. I tend to avoid it – then embrace it when it happens. Maybe I could just be a bit less avoidant early on.

– Steve