Agile Life

Steve’s Agile Life: Size Affects Pursuit Of Value

by

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

Let’s talk Sprints and organization. If you’re new to my whole “Agile Life” thing, this is me using Agile (specifically Scrum) to make my life more productive and less stressful. Sprints are periods in Scrum used to choose – and do – work. It’s not linear planning, more “I can get X done in Y period.”

So I’m doing Scrum for my life, and my sprint is a month, not the traditional two weeks. I do this because my life has a monthly cadence, with monthly meetings, events, and the like. This also means I focus on value differently than if, say, I used two week sprints or the even more (insanely) daring one week sprint.

I have a larger timeframe, so I focus on more kinds of work (stories that deliver value) because I both can do more and have more to do. Thus where a two-week sprint might have me focusing on a generator, a monthly sprint may bring in more projects and work.

Because of my sprint size, I focus on value differently. I deliver multiple, unrelated kinds of value – where a smaller sprint may mean I focus on fewer kinds of value, and those are probably related. I’ve wondered if this dilutes my ability to focus, but also see some advantages.

Here’s an example:

  • In the first two weeks of every month I have three professional meetups – maybe four. These meetups each take up an evening.
  • If I have a monthly cadence then these big blocks aren’t as big a deal as I can fit tasks around them or just do some later. I have adaptability, but work might be diluted.
  • If I have a two-week sprint, then I have to think more of what to accomplish in that time, working with those “block.” of time. I’ve got a bit of a tighter backlog, but the focus is on specific value. For instance maybe I’d make these two weeks even more “business” and do studying, etc.

So smaller sprints means a narrower focus on value – and an opportunity to focus. Why not, I wonder, go by two-week sprints, and these “business blocks” could be enhanced if I also used that time to do studying for certifications, etc. However . . .

. .. this is also my life. That has a few complications:

  • Some work is very hard to “block” like writing. That’s intellectually exhausting, and though I’d like to try, I’m not sure I’m going to, say, write an entire book in a two week block.
  • This big picture lets me adapt easier because there’s more room to shift around. Because of the monthly cadence, I tend to “step on my own toes” less.
  • My “life” commitments are a bit more variable than work. When’s the last time your boss suddenly visited and slept at your place?  OK, don’t answer that.

Your life may be different, so you’ll have to find the sprint cadence that works for you. However, you might be surprised.

If you’re a Scrum Master or Coach, these “life Scrum” and “life Agile” experiences are valuable to develop empathy. By using these techniques in your life, you literally live them and live the roles of all members – Scrum Master, Team Member, Product Owner. Because of that, these experiences are burned into your brain in a visceral manner – next time your team debates value and sprint size, you’ll remember what it was like.

– Steve

Steve’s Agile Life

by

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

You’re going to want to read this; yes it’s on time management, and yes it’s worth it.  I’m going to talk about management but in a non-boring way.

Remember how I moved to Agile techniques and started those weekly reports?  Here’s what happened.

In March I felt my time management could be better; I felt overworked, fell into multitasking, and knew I could do more.  Sound familiar?

I had organized myself by a mix of Getting Things Done (GTG) and Scrum/Agile, but it was casual.  Since I’m a a pro Project Manager and Scrum Master moving towards coaching and process improvement, I know a lot of techniques and processes and coaching tools.  So I coached myself towards more productivity and less stress.

It makes sense; my life is more like a business with my books, and so on.  So what I did was use the Agile practice of Scrum, combined with some GTG (which if you want to really argue, is kind of Kanban, but let’s hold off on that).

To help, here’s a quick refresher about Agile/Scrum – and trust me, you’ll also want to read this.

Agile is a management philosophy that evolved from software development.  To sum it up it’s “A focus on delivering results regularly by working directly with others and responding to change.”  Here’s the 4 parts of the manifesto and 12 principles that will give you an idea.  You really want to read this stuff.

Agile is a MINDSET with a focus on delivery and adaption.  It’s important to keep this in mind – literally.

Scrum is the most well-known Agile Method.  Take a priority-ranked backlog of what you want to do, figure out how much stuff on the top you can do in a given timeframe (called a sprint, usually 2 weeks).  Do the stuff, deliver, evaluate how you did, then do it all again.  The goal is to get something done and learn – that something could be bad or not ready for prime-time, but it’s done.

Make sense?  As I like to put it (sarcastically) if you deliver value often and re-evaluate, you get benefits fast, but also there’s only so much you can screw up in short bursts.

So time to adopt an Agile mindset, and Scrum was the best method to do it.  Here’s what I did.

  1. I made an Agile Backlog (from my GTG Incubator).  This is basically a list of things I want to do ranked in order of value.  I re-evaluate this regularly – this is not a random repository of ideas (I have separate documents for that).
  2. I have a Project List (a GTG artifact) of active initiatives.  This is basically the top of the backlog for what I focus on, and have some plans or outlines.  I’m probably going to merge this into the Backlog.
  3. I have a flight plan (a separate artifact) that lists my general goals per quarter and month for up to two years.  I revise this as I change plans.  This is a quick way to look ahead and look for any schedule collisions. It’s not quite a roadmap, more a projection.
  4. I do monthly sprints, and the above help me decide what to do.  The Projects get priority, the Backlog feeds new projects or smaller initiatives.  The Flight plan lets me evaluate my goals and look for bottlenecks.  Yeah, this could be the classic 2 week sprint, but my life seems to have a monthly cadence.
  5. Work gets broken into stories that provide actual value, like a completed essay or a clean bathroom.  Learning to describe stories and figure value is part of the learning process, and an area of intense discussion in Scrum/Agile.  Short form is think of your target audience what they want and why – “As X I want Y so Z.”
  6. I break stories into distinct tasks used to get the story done.  A good rule is a task is something you can do in a day or less (and if you’re really good, 1-2 hours).  A story may be so distinct and so simple it has only one task – “As a gamer I want a Playstation so I can play Persona 5” doesn’t need any more breakdown unless you REALLY want to block out the drive there, the purchase, the drive back, etc.
  7. I estimate tasks in terms of person-hours so I can look at my workload.  There’s endless discussion in Agile and practices like Scrum on how to “size” tasks, but I find in the end hours always win because eventually whatever you do is going to affect, be measured in, or be communicated in time.

There.  I got a Sprint Backlog of work to do.  how did I use it?

  1. I review my backlog daily to see what I want to do.  I also do a weekly overview of my schedule, work, etc. to get an idea of what’s up.
  2. When I take a task I focus on getting it complete (ready to validate) if not done.  In a few cases complete is done: “Hey, the kitchen floor is no longer disgusting”
  3. If something is not immediately done, in that it continues or needs testing, I get it done in a short time.
  4. If things have to change – so be it.  I know what I’m adding and what I’m taking out.  A lack of change should be due to good foresight – resisting change isn’t inherently a virtue.
  5. I chart my tasks in the categories of Backlog (not started), In Progress, Testing (making sure it’s done), and Done (complete, finished, off my hands).  I do what’s called a Cumulative flow, charting it by task hours in the categories (more on that in the future).
  6. At the end of month do a retrospective- review how things went, decide what to improve.
  7. Plan the next sprint (month).
  8. I might keep my quarterly review (which is part of GTG and other techniques), but am honestly debating how necessary it is.  Probably good to keep it though as I’ve got a lot going on.

This worked great for April – a busy month, yet I got a lot done. It also lets me seriously crawl inside of Scrum and Agile because I’m doing the work, managing myself (Scrum Master), figuring the product (Product Owner), and more.

I’ll be sharing other findings in separate posts, but a few here:

  • You won’t see a lot of “do X by Y.” There’s some obviously, but in general I leave it open – because my daily and weekly reviews let me figure out the best time to do things.
  • I measured completion with Tasks not Stories – which I consider improper as stories deliver value. I did this originally because many of my “life” stories were one task, but it didn’t measure completion of my few multitask stories, which really did affect my time management and sense of completion.  I’m moving to stories next sprint.
  • I’m already keeping a “next sprint” list as I get ideas of what I want to do next; I realized I can easily apply lessons to the next month.  This is a good example of iterative improvement and time-saving – and “backlog polishing.”
  • I keep a “regular” tasks list I can now copy over from sprint to sprint as some tasks for my “Agile Life” keep repeating.
  • This may sound like a radical restructuring – it sort of was and wasn’t.  If you try something like this you don’t have to do it all at once, but add things iteratively, over time.  I’ve got more to add myself.
  • I’m going to be making changes to how I manage the backlog and projects.  To not overwhelm you with technique, I’ll probably post that later after I share some other insights.

Look for more posts on this – a lot more.

– Steve