Agile

Steve’s Update 5/21/2017

by

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

It’s my weekly Scrum style standup for the audience.

Well bluntly this week also was nuts, with assorted work events, a friend having health concerns (resolved) and of course occasional allergies.  It’s not been the greatest week – but Agile method are about adapting.  So where are we?

So what have I done the last week?

  • Way With Worlds Minibook #5: Still going good and on schedule – I might even get a bit ahead of the game.
  • Seventh Sanctum Spotlight: That’s on hold.  This is due to the interruptions I’ve been having from allergies to events, and now convention time might cut into the results for me and other people.  So I’ll do it in June if it seems viable.
  • Professional: Attended that professional event – they’re running out of space so I found my apartment complex can host them!  A great way to network and meet people.
  • Social: Girlfriend’s birthday and book club went well.
  • “A Bridge To The Quiet Planet:” The latest plot outlines and character arcs are plotted.  Looks good again, and I think the book is taking on a more personal tone; for instance, there’s two minor characters (one extremely minor as in he’s in one scene) that by exploring I really did a  lot with the story.  This is a good lesson from the late Sir Terry Pratchett – you tell a lot more by having it personal, even if that person is gone after a scene.
  • Newsletter: The newsletter is out.  Which you probably saw.

What am I going to do this week:

  • Way With Worlds Minibook #5:  More writing.  Let’s just assume that’s the norm (and book #6 is next).  I’m thinking these books are best written in one or two big lumps not spread out.
  • Social: Fanime is going to consume a lot of time this week, as will events there.  I’ll be preparing presentations.
  • Speaking: I’m speaking twice at Fanime.
  • Cosplay: I’ll be Doctor Oobleck from RWBY at least one day.
  • Her Eternal Moonlight: A sale is coming, so pay attention . . .
  • “A Bridge To The Quiet Planet:” Next step is fleshing out the plot so it’s ready to be scene-for-scene outlined, as well as some character details.e

Challenges and blockers:

  • The Allergies are better, but I’m keeping an eye on them.  These were bad and hit a lot of people hard.

– Steve

Steve’s Agile Life: Work Complete

by

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

So more on my “Agile Life” experiment where I use the Agile techniques in Scrum for a more productive, less-stressful life.  This is all about getting things done – so let’s talk about something we don’t often think of, limiting how much we complete in a day or a time period.

Remember when I talked about WIP, work in progress? That’s measuring “what’s not yet done,” and reducing it usually helps productivity and reveals problems.  But I found something related you want to pay attention to.

How much work gets completed in a day and over time.

I began noticing sometimes I’d deliver regular amounts of work, sometimes huge lumps. I came to realize that monitoring how much you get done in a time period – often a day – helps you improve your agility and your work.

Here’s what it can reveal:

 

It Can Reveal Overload

I’m going Agile and it means I’m getting more done.  That makes sense; I’m clear on what to do and what’s next, I can adapt to change, and because of all this I feel less pressure.  Yet, at times, I’m feeling kind of stressed despite improvements.

I realize now that this is because I kept looking for the next thing to do.  The productivity had become habitual and addictive, and I kept trying to move more to “done” – bringing more stress back to a process that’s supposed to reduce it.

This can be worse if you have well-defined stories and tasks. You can blaze through them relatively easily. You can get them to “done” pretty quick. I had a day “off” where I got a lot of work done as I had it broken down well – and then realized “hey, I am tired.” That spike in my cumulative flow was a reminder to go play some Overwatch.

It Can Reveal Bottlenecks

Those sudden droughts and onslaughts of completed work can reveal bottlenecks in your work and your plans.  This is usually heralded by a block of Work In Progress, but isn’t always.

Let’s say you’ve had to write three articles for three websites, sending them each out to editors, each at a different time. You’re getting work done while you wait, maybe keeping your Work In Progress from getting too high – then bang, all the articles come back at once.  Turns out they’re all great, you just have to sign off, but that’s stressful.  It shows your editors may be a bottleneck and you need consistent response time.

Also that sudden onslaught of “done” can be disruptive and jarring – context switching.

It Can Reveal Poor Breakdown

You’re working on all sorts of tasks, from painting a table to writing a book, but it seems they get done in huge lumps.  This might be a sign of poor breakdown – you’re delivering enormous “chunks” of work as you’ve got it set up to be worked on in enormous chunks.  Maybe your stories can be broken down into smaller pieces of value to do.

This can happen in “Agile Life” pretty easy as we may not think of breaking down tasks we’re used to – or lump similar ones into one pile.

It Can Reveal Forgotten Work

This happened to me a great deal in my first “Month Sprint” of April 2017. I noticed some of my erratic delivery and then, when asking myself what I did that day, realizing I’d done a lot of tasks that probably should have been in my backlog. If you see erratic delivery of work, it may mean you should be capturing more work.

This was a real revelation to me – because once I started capturing this work (a mix of social events, obligations, and my cooking schedule), my stress dropped. I was more aware of my goals and time commitment and could plan better and be more agile.

 

So beyond workload and work in progress, keep an eye on how much is getting “done” each day. It may reveal some problems in your plans and give you new ways to improve.

This recalls The 8th Agile Principle the value of a good, sustainable, pace of work.

– 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