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:
- 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.
- 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.
- 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:
- 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.
- 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.
- 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.
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?
Been really freaking busy the last few months, so I haven’t had the chance to share the news of a few upcoming presentations:
On October 10, I’ll be presenting at the Orlando SQLSaturday, doing my session on a DBA’s guide to Hadoop.Â I’ll be representing that session at theÂ Professional Association for SQL ServerÂ Summit in Seattle (October 27-30).
Brief service announcement is over; now I can say I’ve blogged recently.
“A good man brings good things out of the good stored up in his heart, and an evil man brings evil things out of the evil stored up in his heart. For the mouth speaks what the heart is full of.” â€“ Luke 6:45
Been doing a lot of reflecting lately on my goals in life, and I realized that I complain. A lot. Complaining is good when it leads to change (i.e. complaining about your sibling to your mom MAY cause their behavior to change), but complaints without action just lead to bitterness. I don’t want to be bitter, so I’ve recently started getting rid of these three phrases.
“I didn’t have enough time.”
Variants of this include “I didn’t get everything done I wanted to do”, “I’m not blogging enough”, “my career’s not as far along as it should be”, and “I didn’t make MVP again? Bummer”. Don’t get me wrong, I’m not making excuses for not completing things; I’m just trying to figure out ways to not complain about it. There’s never enough time in the day to do everything, and I completed what I spent time on. If I’m not satisfied with the outcome, it’s because I made the wrong choice, not that I didn’t have enough time. The trick is to figure out what I want and choose the right path.
My clothes don’t fit right, and I’m sitting here at a table writing this blog and polishing off a bag of Doritos. To me, exercise is waddling my way from the fridge to my chair, and I wonder why I struggle with my weight? Again, complaints without action do nothing but make you bitter. I’m reading on Facebook about how several of my friends are turning to activity to drop weight and become healthy, happy, people. Maybe the first step is to quit reading Facebook.
Variant of phrase two, but not quite the same thing. To me, fatigue has become a synonym for boredom. Instead of enjoying the moment, I spend 15 minutes complaining about how much work it was to get involved in the moment, and I miss half of the fun. It’s natural to be tired, but it should never stand in the way of getting the most out of life.
Again, I’m not necessarily to the point of taking action to correct all of the deficiencies in my life; I am, however, just about done with griping and moaning. Life is what you make of it, and I want to make more out of mine.
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:
- Spend some time making your board match your processes (at least 30 days).
- Define your goals (metrics for improvements)
- 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.
Recently, my friend Joe Webb has posted some great resources on Personal Kanban on his Facebook timeline.Â Joeâ€™s an influential guy in the tech community (particularly the #SQLFamily), so Iâ€™ve been excited about the flurry of emails and comments regarding the adoption of Kanban techniques.Â Iâ€™ve been using Kanban boards for a while now at work, and itâ€™s interesting to see the differences between Personal Kanban and â€śindustrialâ€ť Kanban.Â Â The significant distinction between the two appears to be the impetus to â€śget things doneâ€ť in Personal Kanban by using a very simple abstraction; in other words, start with a simple board of â€śTo Doâ€ť, â€śDoingâ€ť, and â€śDoneâ€ť and attack your task list.
I think this is a great way to get started with Kanban, but I also think that itâ€™s easy to forget about some critical components of Lean thinking.Â After observing a couple of email chains from friends (and comments on Joeâ€™s Facebook thread), I thought Iâ€™d blog about some common misconceptions of Kanban, starting with:
Myth 1: Kanban is a process to manage my task list.
This is probably the biggest trap that most people fall into when they decide to get started.Â The simplicity of Kanban is so appealing; just throw up a board and start moving cards left to right. Â Getting things done; Kanban helps you do that, right?
Sort of.Â Kanban is not a process; itâ€™s a visualization of your process.Â The distinction may appear to be subtle, but itâ€™s important.Â A simple board showing three columns (i.e., â€śTo Doâ€ť, â€śDoingâ€ť, and â€śDone) assumes that your method of handling tasks is equally simple.Â Your process should drive your board, not the other way around. Â While the act of defining tasks will yield some immediate benefits, oversimplifying the visualization has some costs.
As a concrete example, letâ€™s assume that one of your tasks is to call and make an appointment with your doctor.Â You move the card to the Doing pile, call your doctor, and then get informed that theyâ€™ll have to call you back.Â Can you move the card to Done?Â You havenâ€™t made the appointment.Â Do you leave the card in Doing?Â Are you doing anything with it besides waiting?Â Do you move it back to To Do?Â Youâ€™ve already started working.Â Â If your board is driving your process, the temptation is to leave the board alone and struggle with task movement.Â If your process is driving your board, you change the board.Â Add a column for waiting tasks, move the card, and then revisit that pile as needed.
Donâ€™t get me wrong; starting with a simple board is a GREAT way to get started with the fundamentals of visualizing workflow, especially if you donâ€™t know what your process is yet.Â However, as you discover more about the way you work, donâ€™t try to change the process (at first); make sure that you spend some time developing your board so that it matches the way you do work.Â Improvement will come later.
Just got my email this morning stating that I’ve been accepted again as a Friend of Redgate for 2015; very honored to be a part of this program again, and excited to continue contributing to the community in this way.
Very honored to be today’s guest blogger at Pinal Dave’s blog Journey to SQL Authority; check out my post here:
Finally finding some time to sit down and write this post; of course I’m squeezing it in after work, and before my wife and son come home, so there’s no telling how far I’ll get. This post is probably best treated as a stream of consciousness effort, rather than my usual agonizing over every word. 2014 was a mixed bag of a year; lots of good stuff, and lots of not-so-good stuff; I’ll try to start with the good:
2014 Professional Highs
As I’ve mentioned before, I was promoted to management in my day job a few years ago; in October of 2014, my kingdom expanded. Instead of managing a team of SQL Server DBA’s, my department was consolidated with another small group, and I now manage the IT infrastructure for our Product Group. It’s not a huge jump, but it is an opportunity for me to get involved with more than just SQL Server and databases; I’m now managing a team of sysadmins as well, so I’m getting a crash course on virtualization, server administration, and networking. It’s been fun, but a bit challenging.
I haven’t neglected my SQL Server roots, however; I presented to over a dozen user groups & SQL Saturdays last year (which is a lot for full-time desk jockey). I ultimately delivered two killer presentations at Summit in November, which boosted my confidence tremendously after 2013’s less-than-stellar performance. Blogging was steady for me (23 posts on my blog), but I did have a chance to write a piece on Pinal Dave’s blog (Journey to SQL Authority); that was a great opportunity, and one I hope to explore more. In addition to blogging and community activity, I also finally passed the second test in the MCSA: SQL Server 2012 series (Administration; 70-462). I’m studying for the last test (Data Warehouse; 70-463), and then I need to start getting some virtualization certs under my belt.
Finally, a big professional step forward for me was that I became a Linchpin (part-time); I’ve had a great deal of respect for this team of SQL Server professionals over the years, and I was very blessed to be able to step in and help on a few projects this year. I’m hoping for more. It’s a great way to test the waters, even if I’m not ready to dive into full-time consulting yet.
2014 Professional Lows
I got nominated for Microsoft MVP (twice); I didn’t get it (twice).
2014 Personal Highs
Big year for travel for my wife and I; we went to Jamaica and Vancouver, as well as Nashville, Chattanooga, St. Louis, Charlotte, Seattle, Hilton Head, Myrtle Beach, and Ponte Vedra. We saw two killer shows: George Strait and Fleetwood Mac; I also got to see one of my favorite bands, The Old 97’s. Our son turned a year old, and it’s been a lot of fun watching him grown and discover new things. 2014 was a year of joy in a lot of waysâ€¦.
2014 Personal Lows
2014 was also a year of sorrow for me; if you follow me on Facebook, you know how proud I am of my son. What became less well-known is that I have two teenage daughters from my previous marriage; they turned 17 and 15 this year. In September of 2013, my daughters decided that they didn’t want to spend as much time with me and their stepmother. Over the last year, I’ve had to come to terms with the fact that my daughters aren’t planning on changing that any time soon, and they have no desire to have a relationship with their brother. That’s a pain that I’ll never get over; I love all of my children, and all I can do is pray that someday things will change. The only reason I feel compelled to mention it publically is that I don’t want them to become invisible; I have three children, even if I don’t get to see two of them very often. I also feel like I’ve reached a turning point; I was VERY depressed last year because of this situation, and I’m ready to move forward in 2015.
For Christmas, I got a neat little tablet hybrid (Lenovo Yoga Tablet 10 w/Windows), and I’m trying to use it as a laptop replacement; I’ll try to give an honest review of it by the end of the month, but for now, I’ve been trying to replace Windows Live Writer with some other tool (since support for Writer may be ending). Someone suggested that I give Word a try, so I’m giving it a fair shake with this blog post. Not much to add (other than I have a few ideas brewing); this is just a work in progress to see if Microsoft Word can handle things like:
- Image upload
- Formatting issues
- Tags and categories
I’m hoping to get a year in review post up soon (while it’s still relevant); stay tuned.
I was recently contacted by Webucator, an online training services provider, and asked if they could turn a recent post of mine (#SQLServer â€“ Where does my index live?) into a video. They are promoting their SQL Server classes by doing a free series called SQL Server Solutions from the Web using (with permission) different blog posts from around the web. Wish Iâ€™d thought of this sooner; enjoy!