my agile life

My Agile Life: The Project Doesn’t Matter

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!

So this is going to sound weird, but one thing I realized in Agile practice, and my own use of the Agile technique of Scrum (with a touch of Kanban), is that the Project isn’t the most important thing.

Yes, I know, heresy. Projects are books, right? Projects are art, true? Projects are games, correct? I talk Projects all the time.

No. A book, a piece of art, a game is a product. Products deliver value to the customer and that’s what matters.

Projects are ways to get things done, to produce products, a useful conceptual tool, but that’s it.  The idea of a Project helps you complete a Product that has value.

Yeah, let that sink in. All your planning, all your schemes, everything are secondary to the result. Think it’s hard for you? I’m a guy with a ton of certifications on the subject of Project Management. In short, I actually have certifications on the second most important thing.

Except this is liberating. I don’t have to take Projects seriously or any other organizational tool.  All that matters is if this concept, this idea, this tool, this idea helps deliver value.  That’s it.

This is where Agile as a mindset shines. It’s outright saying that your goal is a result.  That’s it.  Everything else is just a tool on the way to the result.  You only have to care so much.

This is where Agile techniques shine, they’re tools to help you find blockages and get to the results – but like any tool you don’t have to be attached to them. Scrum this year becomes Kanban. This level of Project Breakdown is replaced by another.

I still use the term Project.  It’s useful.  I just don’t have to get invested in it.  It’s all about results.

By the way if you’re focused on Projects and not results – why?  Are the results even worth seeking?

(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

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