Internal conference this week at Grainger, and I’m presenting two lightning talks. Excited to see my team again, but traveling is hard (especially without the family).
Two separate Kanban talks: an overview and one focused on two different styles of boards (time versus project based).
When I started my new gig a little over a month ago, one of the first problems I wanted to tackle was the flow of work. My team does a lot, and some of the work is very structured and repetitive, whereas other work is much more fluid. It’s really two teams with different foci; they run different sync meetings, and had different work intake processes but they were sharing a board.
The board was a typical software-development style kanban board; board columns included things like:
For a fluid SRE team where the project work can be ambiguous, a flow like this is OK (with some caveats that I’ll explain below); In Progress is a “squishy” state for work; you don’t know what the steps are, or how long it’s going to take at a glance. However, SRE work can be “squishy”; you don’t know if you’re going to be writing a script to automate a technical process or helping coordinate a large scale project to implement SLO’s for a new service. Having a card sitting In Progress is just a visual reminder of a task list.
For structured, repeatable work, though, this style of board has limitations; if the steps of being In Progress are known, then you can highlight obstacles in your process by teasing them out. The regulated work team doesn’t know how often projects come in, but when they do, they followed a series of steps for every project (no matter how much data was involved. There was also a lot of regular back-and-forth between this team and client teams early in the process; using the old board, cards were constantly moving back and forth between In Progress and On Hold. It made WIP limits on the board very difficult to track.
We spun up a new board to better represent the flow, focusing on replacing the concept of In Progress with more specific states tailored to the flow. We also identified the primary constraint(s) for each state, be it Client, Team Member, or Systems:
Note that WIP can now be defined for multiple states (Prep, Produce, and Analysis); each of these states are governed by a limited number of resources; team members can only have 1 project in the Analysis state at a time, for example. Note also that the cards represent the entire project, not just a task inside a project. It’s an assembly line mentality, and allows us to quickly see where constraints are acting as a bottleneck.
With the regulated workflow removed from the original board, it let us focus on some rules for the fluid SRE work (the caveats referenced above). One of the basic decisions needed for a kanban flow is what does a card represent? For assembly lines, a unit of work could be the whole project, but for fluid software development efforts, it gets really soft.
We decided to go with a timebox method; a unit of work should take no more than a day of focused work. A card could be really small or reasonably large, but if you think a project will take more than a day, then split the work out. This has psychological advantages; it’s far better to see things getting marked as “done” than to just watch a card sit in the In Progress column for weeks.
Another rule we implemented was transferring ownership of the card in the Validate phases back to the original requester. We then started a clock; if a card sat in the Validate phase for more than 7 days, we flipped the ownership back to the team member, and closed the card.
So far, the team seems to be working well with the two new improvements; after 30 days, we should have enough data to see where we can continue to improve the flow.
As I posted last time, I’ve been using Trello as a Kanban board to help with my job search. The default functionality for Trello is effective, but there are some free components you can add to minimize the time managing the workflow (so you can focus on the work itself). In Trello, these are broken up into two broad classes:
Adding a Power-Up to an existing board is easy; just push the menu button near the top right of the board and click on the add power-ups button. As you can see in the screenshot, I have two power-ups that I use in my job search board.
Card Age Badge – this puts a colored icon on each card that shows how old that card is. This allows me to track individual job submissions or leads and follow-up on older cards. At this point, I’m mostly using it to indicate when a job has “ghosted” me, and I no longer consider them active applications.
List Limits – an important component of kanban is WIP, and Trello does not capture that by default. This Power-Up lets you set a limit per column (and tracks the number of work items in each column). I use it as Reverse WIP measurement; I want to keep at least 15 applications in progress. List Limits will color the background of a column when you exceed the limit, so for my Applied column I set a limit of 15, and as long as the background is colored, I can focus on other things.
To access automation, click the Automation menu item next to the Power-Ups button. Because my needs are simple, I only use the Rules feature for my setup. Trello’s implementation of rules is very nice in that it creates natural language statements to show what is to be done and when. I have the following rules:
when a comment is posted to a card by me, move the card to the top of the list
when the red "Rejected" label is added to a card by me, move the card to the top of list "Dead Lead"
when the dark black "Ghost" label is added to a card by me, move the card to the top of list "Dead Lead"
The interface is very easy to set up; each rule is simply a trigger (something that happens) and an action (something that gets done). The three rules above do two things; they allow me to move a card to the top of the stack by simply adding a comment to the card (this helps me to remember to follow up on it), and to move a card to the Dead Lead list when I either get rejected or I think the posting has ghosted me (no response after 14 days).
Here’s what my board looks like today; as always, there’s room for improvement, but this allows me to focus on the job of finding a job while minimizing the overhead of managing the job search.
Good luck out there! And as always, if you want to see what kinds of roles I’m interested in, check out my LinkedIn profile! Stuart Ainsworth | LinkedIn
As I’m working through the process of dealing with my layoff from Salesforce, the biggest focus is on managing the process of applying for a job. I’m casting a wide net, and I figured I should approach this process like I would approach any project; break the work down into reasonable chunks, define a state for the workflow, and work the backlog. In essence, kanban.
I’m using Trello to manage this process. Trello is a very flexible list tracking tool that can be used as a lightweight kanban tool right away (although I plan on describing additional Power-Ups and Automation in another post).
For my job search, I visualized the workflow as 5 basics steps; this may change over time, but a week in, here’s where I am:
I work the board. In the afternoons or evenings while watching TV, I do my job searches and save prospective opportunities in an email, or bookmark, or whatever. Evey morning, I start pulling those opportunities, double-checking them to see if they’re still interesting, and then go through the mechanics of applying (and BTW, some job sites are PAINFUL to use when applying).
The job opportunity card is simple right now; I don’t want to overcomplicate this, and the goal is to provide minimal information to track what I’ve applied for and provide context when scheduling follow-up calls. I use the following notations:
So far, it’s been helpful. I’ve only screwed up once in the last week and applied to the same job twice, but that was my fault (I didn’t check the list).
Good luck out there! If you’re hiring, or have a job lead for me, please feel free to reach out to me at Twitter: @codegumbo or on LinkedIn: Stuart Ainsworth
As I’ve previously posted, I recently made a job switch. Frankly, it feels like I’m drowning most days. There’s a lot of processes and procedures to learn, as well as getting intimate with a new technology stack, and it’s been tough to maintain good workflow hygiene both personally and professionally. Part of that stems from a shift from Microsoft Office to Google Workspaces; I lost touch with many tools that I was using to capture to-do items.
I started using Google Tasks again, but the visualization is limited; it’s a checklist, and that’s ok for most tasks, but I love Kanban and the organization of workflow to help structure future items as well as current items. However, I haven’t had much success with mobile Kanban apps. They’re usually hard to work with on the smaller screen space.
Enter Kanbanly. It’s a Chrome Web app which transforms Google Tasks into a Kanban board by adding metadata. This allows me to use a Kanban interface on the desktop, and the Google Task client on my iPhone. It’s clunky at times (the metadata tags in the iPhone app can be distracting), but so far it seems to be working; it even has WIP limits per column for visual reminders when I’m overcommitted.
Trying to stay in the habit of writing, and this seemed like a quick post, so here goes; I’m not really in the habit of writing product reviews, but I’ve found this one to be useful, so I thought I’d share.
Task management is something I’ve always struggled with; I’ve tried various systems from Trello to LeanKit to Kanbanflow, and they’re hard for me to use consistently. At work, I use a homegrown SSRS report connected to our helpdesk system as a kanban board, but it’s clunky for ad-hoc requests. It takes way too many clicks to create a ticket for a simple to-do item like “set up a meeting”.
I recently got an Amazon Echo Dot (and later a Tap), and I was intrigued by the to-do list functionality; suddenly it became quite easy to jot down a quick task for either business or personal work. I just shouted out “Alexa! Add do something awesome to my to-do list”, and was immediately gratified with a task appearing in the Alexa app on my iPhone. Excellent. Except for when I was away from my desk (and my Echo Dot). I could open the Alexa app and add a task item manually, but typing seems so old school. And then I remember, Siri could do reminders too. Guess what? Integration with Any.Do.
Long story short, I can now manage nearly all of my to-do items by voice. If I have a brilliant idea while sitting at my desk, I ask Alexa to note it for me. In the car? Siri’s my friend. The beauty is that they both go to the same repository in Any Do, and I can mark them as completed as I knock them out. The only downside is that the app places them in different lists, but I can view them in one combined list (see screenshots below).
Visibility is only part of the battle; organization is equally important. One of the features that I really like about this product is the “Plan My Day” option. Basically, if you have several tasks scheduled for today, you can run a little wizard to cycle through all of them and decide if they’re really going to get done today (or not), and schedule them accordingly:
I try to keep it to 3 tasks a day; this gives me the flexibility of responding to issues as they come up, and still feeling like I’m getting somewhere. I usually add more tasks as I work, but if I finish with a clean slate (three planned + x unplanned), it’s a good day. Lots more features to explore, including calendar integration, subtasks, and task assignments, but I try to keep it simple. I’ve been pleased with how well the voice integration works, and how natural it is to manage my to-do list now.
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:
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:
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:
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.
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!
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.
So, as usual, I’m struggling to sit down and write; I know I should (it’s good for the soul), but frankly, I’m struggling to put words to web page. As a method of jumpstarting my brain, I thought I would write about something simple and relevant to what I’m doing these days in my primary capacity: management.
When I took over the reins of a newly formed department of DBA’s, I knew that I needed to do something quick to demonstrate the value of our department to our recently re-organized company. We’re a small division in our company, but we manage some relatively large databases (17 TB of data, with a relatively high daily change rate; approximately 10 TB of data change daily). My team was comprised of senior DBA’s who were inundated with support requests (from “I need to know this information” to “I need help cleaning up this client’s data”); while they had monitoring structures in place, it wasn’t uncommon for things to go unnoticed (unplanned database growth, poor performing queries, etc.). One of my first acts as a manager was to put in a system of classification I called MARS; all of our work as DBA’s needed to be categorized into one of four broad groups.
The premise is simple; by categorizing efforts, we could measure where the focus of our department was, and begin to allocate resources into the proper arenas. I defined each of the four areas of work as such:
After about a year of data gathering, I went back and thought about the categories a bit more, and realized that I could associate some descriptive adjectives with the workload to demonstrate where the heart of our efforts lies. I took my cues from the JoHari window, and came up with the two axes: Actions: Proactive – Reactive, and Results: Delayed-Immediate. I then arranged my four categories along those lines, like so:
In other words, Maintenance was Proactive, but had Delayed results (you need to monitor your system for a while before you grasp the full impact of changes). Research was more Reactive, because we tend to research issues that are spawned by some stimulus (“what’s the best way to implement Analysis Services in a clustered environment?” came up as a Research topic because we have a pending BI project).
Immediate results came from Architectural changes; adding more spindles to our SAN changed our performance quickly, but there was Proactive planning involved before we made the change. Support is Reactive, but has Immediate results; the expectation is that support issues get prioritized, so we try to resolve those quickly as part of our Operational Level Agreements with other departments.
After a couple of months looking at our work load (using Kanban), I see that we still spend a lot of time in Support, but that effort is trending downward; I continue to push Maintenance, Architecture, and Research over Support, and we’re becoming much more proactive in our approaches. I’m not sure if this quadrant approach is the best way to represent workload, but it does give me a general rule-of thumb in helping guide our efforts.