Agile

Agile Perspectives: Fixed or Variable Length Iterations

Got into a deep discussion with a colleague tonight over different approaches to Agile development (yes, I’m a geek; why do you ask?).  I’m a Fixed Length Iteration kind of guy, particularly since I’ve spent most of time on the Operational side of the house recently.  He’s a Variable Length Iteration fan, and I thought the arguments on both sides of the fence were compelling enough that I wanted to blog about them.

Really, I’m doing this for my adoring fans.

Actually, I’m doing this because I feel guilty about not blogging, and thought this was at least SOMETHING to warrant paying for a domain year after year.

Anyway, here’s the breakdown of the two arguments; let me start by spelling out some common assumptions.  I’m assuming that you’re reading this because you have some interest in development, and more specifically, some interest in agile development.  If you have those interests, then I’m also assuming that you know what an iteration is.  If not, the hyperlinks in the previous statements should help educate you and steer you clear away from this blog to more fascinating subjects.

The Argument for a Fixed Length Iteration

There’s a couple different versions of the Fixed Length Iteration, based on either a calendar (January, February, etc.) or a cycle (every four weeks); the goal is to commit to a ship date, and stick to it time after time.  I’m more of a fan of a calendar-based Fixed Length Iteration; the actual length of the iteration varies (February is short), but development is consistently wrapping up every month, and every month code is being shipped out the door.  My reasons for supporting this model are as follows:

  1. People are cyclical creatures. We live from paycheck to paycheck; we hate Mondays and work for the weekend.  Having a fixed length cycle (with some minor variation if you based that cycle on a calendar) helps in estimating and planning what gets done and when.
  2. A fixed cycle forces developers to think in terms of components. If you’re expected to ship working code at the end of each month, you start writing code that is bite-size, so that you can leave out pieces that aren’t finished (rather than waiting until the whole thing is done).  Bite-sized code is easier to test and deploy with reduced risk.
  3. A fixed cycle means that it’s easy to change directions without stopping development efforts. Sometimes business priorities change; a fixed length cycle allows developers to continue moving forward until the end of the iteration and change gears there.  The start of a new iteration is never far away, so most businesses can wait until the next month rather than waiting till an unknown end of a sprint.

The Argument for a Variable Length Iteration

I’m trying to give this perspective a fair shake, even though I don’t subscribe to it; in a variable length iteration model allows business and development to scope out work at the beginning of an iteration and estimate a ship date regardless of the cycle or the calendar; the goal is to allow code to mature and be more stable.  My friend subscribes to this model because:

  1. Variable length iterations resemble traditional projects. There’s a scope estimate, requirements gathering, and work estimates (and traditional slippage).  Most agile purists immediately scream “WATERFALL”, and there’s some truth to that, but a variable length iteration is comfortable to business.  It’s like Mr. Roger’s house shoes.
  2. They lend themselves to continual shipment of code. If the iterations are variable, developers can focus on one task from start to end, and begin to operate on separate iterative cycles; if you have a development staff of 5, you could theoretically have up to 5 separate iterations going on at the same time; when a developer finishes, they ship their contribution without waiting on the sprint to end.
  3. This fragmentation of the iteration allows for sudden, non-disruptive change. If there are multiple iterations occurring for each independent block of code, and business needs change for one line, then only that line has to shift gears.  There’s no impetus to wait; you stop where you are on the one piece, and move on to the next piece.

Your Choice?

I’d love feedback on this; as I’ve stated from the outset, I’m a fixed length iteration guy.  What did I miss?  Are there other benefits to the Variable Length model that I’m missing?

2015-08-11 by Blogging is FUN! Development SQLServerPedia Syndication 5

(Personal) Kanban Myths: The Myth of The Important Task

Continuing in my efforts to chronicle myths of kanban utilization, I thought I would tackle the second biggest misconception I see surrounding kanban boards.  As I discussed in my previous post, many people mistake kanban to be a process for task management, when in reality, it’s a visualization of some other process.  The key takeaway is that you should spend some time making your board match your process; a kanban board should emulate your workflow, not the other way around.

So you’ve invested the time, and you now have a complex board that accurately reflects how you do work.  You’re humming along, getting things done.  Life is good, right?

Almost.  If you’re just using a kanban board to visualize a process, there’s a temptation to accept the following:

Myth 2: Kanban is a visualization tool primarily focused on (important) task management.

This is partially true; in industrial kanban, workers may use a kanban board to keep track of individual issues as they move throughout the workflow.  Managers, however, should primarily use the tool to look for opportunities to continuously improve their processes.  Once your kanban board matches your process, it becomes easy to understand where bottlenecks occur (both resource allocation and/or unnecessary processes).   Tuning workflow is a critical part of kanban utilization.

For personal kanban, however, managing resource allocation becomes a bit of challenge; how do you manage yourself?  You’re already too busy working through your pile of stuff.  Unless you can recruit other friends or family members (the Tom Sawyer approach), it’s unlikely you’ll be able to adjust resource allocation.  You can, however, begin to look for opportunities to tune processes.  How?

This is where the conversation has to drift away from kanban a bit; as a tool, a board allows you to visualize workflow and primarily focus on improvement, but in and of itself the measure of improvement isn’t part of the board.  In other words, you can see how things work, but there’s no built in visualization for determining if something has room to improve.  You have to decide what that method of improvement will be.  To improve your processes, you must define the metrics for improvements.  Those metrics are known more commonly as goals.

Goals are a critical component of a successful kanban implementation.  For example, if you have a personal goal of “I want to lose 50 pounds in the next year”, that goal should influence your decision on which tasks to pursue (and what the priority of those tasks are).  In other words, if your kanban board shows that you’re getting a lot done, but no tasks are associated with the goal of losing weight, you’ve got some room to improve your processes.

So, in summary:

  1. Spend some time making your board match your processes (at least 30 days).
  2. Define your goals (metrics for improvements)
  3. Take some time to tweak your processes to align them with your goals.

Minor incremental adjustments are more likely to be adopted than sudden and swift changes (see my management notes about change curve).  Kanban is a long-term tool, but can be highly effective at improving workflow.

 

2015-03-10 by Blogging is FUN! Professional Development SQLServerPedia Syndication 0

Steel City SQL Users Group–March 18, 2014– @SteelCitySQL

Next Tuesday, I’m loading up Big Blue, and driving over to Birmingham to present at the Steel City SQL Users Group.  I’ll be talking about the Agile DBA.  Should be fun!

http://www.steelcitysql.org/

Featured Presentation

The Agile DBA: Managing your To-Do List

Speaker: Stuart Ainsworth

Summary: Agile development is all the rage, but how do the principles apply to database administrators? This presentation will introduce the basics of the Agile Manifesto, and explain how they can be applied to non-development IT work, such as database administration, maintenance, and support. We’ll cover scrum (one of the most popular development methodologies) and kanban, and identify some of the common struggles with implementing them in an organization. This is an interactive discussion; please bring your tales of success and your horror stories.

About Stuart: Stuart Ainsworth (MA, MEd) is a manager working in the realm of financial information security. Over the past 15 years, he’s worked as a research analyst, a report writer, a DBA, a programmer, and a public speaking professor. In his current role, he’s responsible for the maintenance of a data analysis operation that processes several hundred million rows of data per day.

2014-03-14 by Conferences Professional Development SQL SQLServerPedia Syndication User Groups 0