Limit your Holiday WIP with Personal Kanban

I'm asked on a regular basis how Agile or Lean practices can be applied during the holidays.  Let's face it, we have a limited amount of time and todo lists as long as our arms.  Truth be told, people have limited success using the ever-growing todo list.  You either forget your list at home, you take on too much at one time, or you forget why some of the items on your list just aren't getting done.  Several years ago, I found the answer to my "get stuff done" problem and it is known as Personal Kanban.

Personal Kanban borrows from several Lean principles and practices. With just two simple acts – visualizing work and limiting work in progress – Personal Kanban gives us clarity over our work and our goals, and the unprecedented ability to deal with distractions, manage expectations, make better decisions, and ultimately find a healthy balance between our professional, personal, and social lives. - See more

Using Personal Kanban

I've leveraged Kanban for Agile Teams with great success.  But I used a physical board, complete with sticky notes and painters tape. I also had a small board in my office, for personal stuff.  Unfortunately, the more I traveled for work, the less physical boards worked.  I always seem to have my laptop or phone with me but I didn't always have a wall to apply sticky notes. What is an Agile coach to do!?  Of course, in this digital age, there are several inexpensive solutions.  I use LeanKit.  It works on the web, phones, and tablets. Everything is synced all the time.  There are other solutions out there but this has worked for me (and my family) for quite a while.

Here is the 50,000 foot view of how it works.  On a surface that is in plain view all the time, visualize your workflow.  It could be as simple as ToDo, WIP (work in process), and Done.  Being this is personal, label the columns anything you want. Identify what you need to get done on cards. I like the title to be actionable (Call, Find, Do, Finish, Get...). I then color code the cards so I know if it is for work or not. Let's say you are traveling during the holidays: "Pack clothes, book hotel room, reserve rental car, get boarding pass". Use specific card colors and you'll know at a glance if you forgot to do something.  Limit the stuff you work on at any given time.  If you haven't discovered it yet, multitasking is a big lie.  You don't get more done! You just keep really busy.  Focus on getting stuff done, not starting more stuff. Don't exceed WIP limits in a column.  If there is no room for a card in a column without exceeding a self-imposed WIP limit, you do not pull a card into the column!  This is important. By limiting what we agree to start, we will in turn finish a lot more.

peronsal kanban

Kanban Cards

Here are the cards for my "Holiday" Personal Kanban.  My board doesn't go away after January 1. It just focuses on other stuff. The yellow cards are going to drop off after New Years. I left them on the board so you could see how we can have three groups on a board and it still have clarity.  Colors of cards are optional. I use every visual queue I can, including blocked and high priority indicators.

  • Red cards – Christmas and my birthday
  • Orange cards – LeadingAgile (work)
  • Yellow cards – Chanukah

Ready

I keep a backlog of stuff that isn't "ready" for me to work on so I don't even include those on my board. Even after having the highest priority cards appear at the top of the board, having too many cards on your board can paralyze you with choices.  I only add cards to my ready column, if they have limited dependencies and are ready to complete within the next few weeks.

WIP (Work in Process)

One of the secrets of a pull system is you only work on things you actually have capacity to work on. When you have capacity in the next step of your workflow, you can pull work into that step. Limit the amount of stuff that you're working on at any given time and I can pretty much guarantee you'll get more done.  Personally, I know that I can only deal with three things at a time before things start to get dropped. Know your personal limits and set them accordingly.  If you're working on something and you get blocked, don't pull in more work. Add a visual indicator that indicates the item is blocked. and continue pulling working through to done. Once you unblock the work, you can pull it the rest of the way through your system.

Focus

I'm a strange combination of a little OCD, a little ADHD, a lot of grit, and a lot of drive.  I need a focus column.  If I walk away from my desk, read an email, or get a cup of coffee, I can pretty much guaranteed to forget what I was working on.  The focus column is my visual reminder of that one thing I'm trying to focus on right now.  Notice the image of my personal kanban above that I'm trying to wrap up this blog post.  Everything else can wait. I need to get this done!

Done

Ah yes, the done column. It is where all work needs to go.  When I look at it, it makes me feel pretty darn good.  We all feel busy but we commonly ask ourselves if we've actually gotten anything done.  Well, this will show you.  I recommend you reflect on what you've accomplished, feel good about it, and clear the column on a periodic basis. I do it either once a week or every other week.

Summary

I know this is a lot to put into a single blog post.  But if you're wishing for a more productive and balanced 2014, I would recommend you give this a try. It's super simple to start and over time, if you're persistent, you'll see it will bring more clarity to your work and your goals.

If you want to learn more about Personal Kanban, I would recommend you read Personal Kanban by Jim Benson and Tonianne DeMaria Barry.  It's a great read and an awesome gift!

Barriers to Agile Adoption

We’ve all seen it happen. Though we try to show organizations the benefits of using a mature agile delivery framework, we still run into roadblocks. Though the status quo is killing their organization, some barriers to further Agile adoption happen way too often among organizations that need it most. I recently had a client ask me to introduce the elephant in the room. I was asked to actually list some common barriers others have dealt with. I want to thank our friends over a VersionOne for distributing an annual survey of the Agile space. One of the questions? What is preventing you from further agile adoption? Within the last published survey, 4048 people responded and they were able to vote for more than one barrier. The responses may sound familiar.Barriers to Adoption

Barriers of Agile Adoption

[table align="center" caption="" width="500" colwidth="25|25|450" colalign="center|center|left"] #,Percentage,Barrier 1,52%,Ability to change organizational culture 2,41%,General resistance to change 3,35%,Trying to fit agile elements into non-agile framework 4,33%,Availability of personnel with right skills 5,31%,Management support 6,26%,Customer collaboration 7,26%,Project complexity 8,22%,Confidence in the ability to scale 9,14%,Perceived time to scale 10,14%,Budget constraints [/table]

Did they miss any in the list?  How did you overcome your barrier?

 

Originally posted at LeadingAgile

Cheat Sheet for Backlog Refinement

Backlog Refinement Meeting

What is it?

The purpose of backlog refinement (grooming) is to make improvements to the product backlog.  Though there is no official ceremony detailed in the Scrum Guide, the activity of refining the Backlog is.

Who does it?

Backlog Refinement is a collaborative effort involving:

  • (Optional) facilitator – (like a ScrumMaster) keeps the session moving toward its intended goal
  • (Optional) representative(s) from the Management Team – clarify the high level priorities
  • (Mandatory) representative(s) from the Product Owner Team – clarify the details of the product backlog items
  • (Mandatory) representatives from the Agile Delivery Team – define the work and effort necessary to fulfill the completion of agreed upon product backlog items.  It is recommended to have at least one developer and one tester when refining the backlog, to ensure alternate viewpoints of the system are present.

When is it?

Before development of a user story in the current sprint (iteration), generally sometime during the previous 1 or 2 sprints, the team sits down to discuss the upcoming work. Do not wait too late to add details, because the delay will slow the team down. Do not refine your stories too far in advance, because the details might get stale. Depending on the delivery rate of your teams, you should be meeting once or twice a week to review the backlog.

Before You Begin

We need to ensure:

  • The product backlog is top-ordered to reflect the greatest needs of Management Team and the Product Owner Team
  • Candidates for grooming include stories identified as not ready to complete within the next sprint or will require multiple days of research
  • Epics, features or other items on the Management Team roadmap are reviewed periodically

The Backlog

The product backlog can address anything deemed valuable by the Product Owner Team. For the purpose of sprint planning, when using Scrum as the delivery framework, product backlog items must be small enough to be completed and accepted during the sprint and can be verified that they were implemented to the satisfaction of the Product Owner team. 

Estimate

Backlog items must be completed in a single sprint or split into multiple user stories. While refining, give stories an initial estimate to see if they are small enough. If not, split them. The best way to split product backlog items is by value and not by process.

Acceptance Criteria

All stories require acceptance criteria. Without it, you can not define the boundaries of a user story and confirm when a story is done and working as intended. Ensure acceptance criteria is testable.   This is what your testers should be writing tests against.

Rewrite Written Stories

Ensure the user story format is consistent, INVEST criteria is being met, and is written from a business not technical perspective.  Know who the customer is. It may not be an end user. Rather, the story may be for something like a service, to be consumed by another team.

Image Credit: Pictofigo

Originally Posted at LeadingAgile

Brain Teaser With a Hidden Lesson

parking lot I was on Google+ last night when I came across a brain teaser.  It took me about 20 seconds to figure it out.  On average, I'm finding others taking about 2 minutes. Others just gave up, getting angry with me for asking the question.

I have a theory for how long it will take you to figure it out.  The more empathetic you are, the less time it will take you. Counter to that, if you are more apathetic toward others, it will take you longer.

The question:

What is the number of the parking space containing the car?

So, how long did it take you?


A Lack of a Shared Understanding

I am so glad we all agreeEarlier this week, I facilitated a backlog refinement meeting.  In the past, the team was used to all of the requirements being completed (in advance) by the analysts. The delivery team would then execute on those requirements. The problem, of course, was no shared understanding. We came into the meeting with everyone agreeing they were on the same page.  That was true for about 15 minutes. The more we talked, the more they realized they were looking at things from individual perspectives.

At the beginning of the meeting, we had less than 10 user stories, from an analyst's perspective. By the end of the meeting, we had a prioritized backlog with over 100 user stories at different levels of granularity.  It's not perfect and it's never done.  But, it's a start.  For the first time, developers and testers were engaged at the beginning.  At LeadingAgile, we call this the Product Owner team.  When the highest priority stories get to a "ready" state, they will be pulled into a delivery team's queue.  Until then, we need to answer some of the more complicated questions, mitigate risk, and achieve that shared understanding.

Image Source: Based on hand drawn image from Pictofigo