Agile Life

My Personal Agile: End Of Sprint

by

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

The sprint is done. The Retrospective is done. So now what?

You start over again.  Your sprint ended but another one begins right after.  You apply what you learned and move forward.  Agile is about moving forward; its a vehicle not a destination.

Here’s what I do in my Personal Agile when a sprint ends:

  • Look at the Incubator. Add or subtract things as you need.  Re-order them to fit the priorities you have – which probably changed.  I actually do this during the Sprint now, having gotten better at incorporating my lessons.
  • With the Incubator re-ordered, I then look at the Backlog and see what I should add to it from the Incubator, subtract (and maybe even move back to the Incubator), or re-prioritize.  I may also see ways to break down the work in there as well.  Much like the Incubator, in time I’ve come to modify it during the Sprint as I learn.
  • I put any undone work back into the Backlog, and rerank it. A surprising amount of time you’ll find undone work isn’t the highest priority. Sometimes you even decide not to do it and just drop it.
  • I review the Regular Tasks list to see if I need to change it. In time you’ll probably not need to do it because you’ll change it during the sprint and in the Retrospective.
  • I plan a new Sprint – Copying the Regular Tasks and then adding as much of the Backlog as I can do for a month.
  • I start the sprint.

That’s it. It’s back to the beginning. You’re done and you restart.

Now a few bits of advice:

  • A lot of the review at the start and end of sprint will eventually work into your regular work. You’ll just get ideas or discover re-prioritizing you need to do as you go.  It’s possible you will need less retrospective and planning time – but don’t change those times until you seriously review them.
  • You’ll get better at review and planning over time. It’s a real skillset you can develop – that may be useful in life in general.
  • Don’t try to get review and planning perfect. Agile is about adaptability, you do your best and keep getting better.
  • Don’t overload yourself. Its very very easy to do that, especially on the second or third sprint when you really get going.

So there you go, my personal Agile. I hope that’s going to help you out.  I’m going to try to bundle this advice up into a free ebook at some point.

– Steve

 

My Personal Agile: The End-Of-Sprint Retrospective

by

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

So your sprint is done. Congrats. Now it’s time for the Retrospective!

The Retrospective is a big part of Scrum, and there are variants of it in a variety of Agile practices. It’s simply sitting down and asking yourself “how did it go,” finding things to improve, and improving them.

It sounds simple, and it is. That’s the point. It’s an obvious, common sense thing to do is regularly review and improve. It’s just not common enough in practice.

Think of it this way, it’s great to stop now and then and decide how to get better. You just gotta make room to review and improve, and Scrum – and my personal-life implementation of it – make it explicit.

So here’s what you do.

The Retrospective

First, set aside time for the Retrospective.  It should always be timeboxed, and I use an hour.  If it doesn’t take an hour, fine – if it does, well you stop anyway.

Here’s how I review in a Retrospective:

  • First, ask yourself what worked. What kept you moving forward, getting things done, and what did you do right? It’s good to focus on the positive here, because if you do enough stuff right you’ll do less wrong.
  • Secondly, ask yourself what went wrong. Focus on specific things that went wrong that are improvable. There will be stuff, trust me.
  • Third, ask yourself what work you couldn’t get done and why. Note that’s not necessarily a wrong – maybe something wasn’t needed. But it let’s you figure out specifics.
  • Fourth, ask yourself what work you discovered you had to do that you didn’t realize. Always good to keep yourself aware of surprises.

You probably have a lot of stuff. But now you gotta make it actionable. What I usually do is list down all the items above, prioritize them, and work in addressing what I learned (good and bad) in actionable items.  Don’t just “not” do something, focus on doing better.  Take a good thing and find ways to repeat it.

As you come up with actionable items, there’s a few ways to record them so they get done:

  • New tasks in the Regular Tasks list. Often undiscovered work in my Personal Agile is something that reguarly occupies time at specific intervals.
  • New things in your backlog or incubator – say if you want to edit better, set aside a few hours to read up on it.
  • Habits you need to improve. I keep a list of what to improve and review it every few days.

Sounds overwhelming? It can be. So focus on the important things that you know you can address.  Don’t overload yourself.

You’ll catch it next time.

Velocity

Velocity is a measure of how much work you got done in a Sprint.  As you examine Velocity over time, you learn how much work you can take – maybe.  There’s a few arguments about how to apply Velocity in Agile, so I’m going to give you my opinions.

Here’s how to get and use Velocity:

  • Measure how much work you got done in that sprint. As noted I use hours of work.
  • Keep a record of these hours per sprint (month). I keep a list in the same spreadsheet as my tracking lists. This lets me compare month to month and make notes.
  • This gives you a rough idea over time of how much work you can get done at a given time.
  • * As you plan sprints, look at your past Velocities to help you decide how much work you can do. This keeps you from overloading – or underloading – yourself.
  • It helps you keep a reasonable amount of work, creating smooth, regular productivity.  Note that’s helps because . . .

Here’s the thing, you can’t be sure the numbers are always perfect.  Velocity is a guide, but each month is different, from holidays to illness to vacation.  Each task is different, and sometimes things that take the same time can be mentally taxing or better done in different situations.

So I use Velocity as a a check, a suggestion, and a way to catch me overloading myself.  But each sprint I also do a gut-check if I can really handle the workload I want to do, for those given tasks.  Velocity is just one tool – but a good one.

What’s Next?

What’s next? Your retrospective is done. Time to end the sprint and start a new one!

– Steve

 

My Personal Agile: Visualization

by

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

So you’ve just started your own sprint.  You’ve got a nice big spreadsheet.  You may like that (I do) but if you’ve done any agile research you may ask:

“Why the heck are we doing this in a Spreadsheet?”

There are a lot of tools for organization and time management: Trello, Smartsheets, and my beloved Rally.  Why aren’t I using them here?

A few reasons – none admittedly all that noble.

  1. I am deliberately avoiding more sophisticated tools right NOW because I want to perfect my process.
  2. Spreadsheets give me a lot of control and I can read them with multiple kinds of software.
  3. There’s a lot of choices for tools, but none quite my style – or that I want to pay for.
  4. I track things down to very fine levels – these tools might overdo my breakdowns or it’d take more work to use them.
  5. I am used to operating out of spreadsheets.
  6. I compensate for the limitation with some other methods, some of which I list below.

But some of us don’t work out of spreadsheets.  Why?  We need visuals.  I’ll present you some ideas, but a note:

In “professional” practice of Scrum, I use the big visible boards either automated or printed out, and track to the task level on most teams, the story level on teams of specialists.  What works here may work for you and not work for a team or vice versa.

For instance, one tool may work for a team and not you.  My spreadsheet method would be a disaster for a team in most cases.

Anyway, let’s talk about ways to visualize your work if, like most people, you don’t love spreadsheets like I do:

Solution #1: Use One Of the Tools I mentioned

Trello, Rally, and so on.  Really requires you to learn and adapt to one of them.  It could work, but you’d have to learn a new tool.

The plus side is it may work and you learn a tool to use elsewhere.

Solution #2: Pivot Tables

Since all my work is in a spreadsheet, I use pivot tables and quick calculations to see where I am story wise, figure how much work is done, etc.  After doing this for nearly a year I had pretty good instinctive sense of where things are.

As a note, I do create a rough “guess” every week as to what I can, will, and have to do and look at that separately.

Solution #3: Print Out Your Sprint Backlog

This is a cheesy but surprisingly effective way to track work – Print the backlog out.  Tape it on a wall or something.  As work moves, fill in the spreadsheet cells, using them to track progress.  If you use it well, you might not even need to update the original spreadsheet (though I do as I like to run a lot of statistics)

I did this for awhile, by the way.  It helped, but really as I was always in the Spreadsheet I didn’t need it eventually.

Solution #4: The Big Visible Board

A lot of Agile methods – especially Scrum and Kanban, use a Big Visible Board.  You take some board, divide it into columns for the different categories (Backlog, Defining, Developing, Review, Done), and then stick notes or cards up for each task or story, and move those around.  Yeah, it’s nothing more than cards or sticky notes on a board that you move around.  But it’s fast, easy, and in-your face so you’re aware of what’s going on.  It also helps teams coordinate because they get to see what’s up at a glance.

Now you’re not a team, but these Big Visible Boards help you stay focused – you see it all the time, you’re aware of it.  If you find operating out of a spreadsheet doesn’t work I recommend trying this method.

However, my guess is that if you look at your Sprint Backlog there’s a lot there.  A few Projects, a good amount of Stories, and a lot of Tasks.  Wouldn’t the board get overwhelming?

Well first, if it’s overwhelming maybe you’re overloaded.  But if you’re not, here’s a few recommendations:

  1. Only have Defining, Developing, Review, And Done on the board.  Put your print-out Sprint Backlog on the left.  As you take tasks, make sticky notes for them on the board and see them through.  Sure you get a pile of sticky notes at the end, but that gives you a sense of progress.  By the way, you probably won’t need to update the original spreadsheet much if you do this.
  2. Track by stories.  This is a bit more challenging, but if you’re REAL focused on doing each story all the way through before you take on another, then you can just track on the story level.  Put the tasks on the story and check them off as you do them.  By the way, if you have good story/task breakdown you may have to combine it with method #1.
  3. Two-board solution. On the top are the stories in progress.  On the board below, active tasks.  Might get confusing, but it could help you get “both” levels.

Again, see what works for you.  but that’s the point – what works for you.

– Steve