Is Santa Agile?

Tony Askey of Post-it Projects asked  "[Are] Santa's elves using Kanban in the toy shop!!?? I can see it happening.  But doesn't it sound a little disturbing hearing about Santa controlling his WIP?  What are the elf labor laws like at the North Pole?

Brian Bozzuto at Big Visible asks, does Santa draft his "naughty and nice" list up front and implement change control or is he Agile?

I hummed a few bars and thought "Making a List, Checking It Twice..."  My answer: Santa isn't necessarily using any kind of Agile process for this.  I do think it's a draft.  He created the (draft) list, it's tested.  Since the song says he does it twice, perhaps he is doing both a unit test & acceptance test.  Once the list is baselined, I bet he does use change control.

Brian's response was then: If he's checking his list twice, why doesn't he automate?

Oh man, I think Brian has just stumbled onto something.  If Santa isn't using automated tests, I bet he's delivering a lot more presents to kids who should be getting coal.  I think the automated test scripts should be ran daily, right up to deployment.  Even if Santa is not doing automated testing, he should be leveraging some kind of automated deployment. Seriously, you think Santa should delpoy all of those toys around the world in one night without some kind of automation?

Though you don't think "Lean" when you think Santa, the guy has be to be leveraging some kind of Agile processes.

Building on failure and action versus motion

I just listened to the 37signals podcast.  It was a playback of some of the brainstorming sessions leading up to the release of the book REWORK.  For those who don't know me, I'm a complete 37signals fanboy.  They just "get it".  I don't know if it's their no BS approach to business or that they have great products.  But, I've found many of the things they created, do, and say helpful in multiple areas.  It doesn't matter if you're an entrepreneur or a project manager.  They have something for everyone. There were two things from the book I wanted to note today.  First, they talked about building on failure versus building on success.  My takeaway is if you want to reach a goal (insert your project or product here), it is easier for you to build upon small successes than to fail and start over. Example: When you're [creating] an [product] for a customer, wouldn't you rather deliver small chucks and get acceptance from the customer along the way, rather than offer a big reveal at the end and risk delivering something they don't want?  If you fail, you have to start all over.  Out of a million possibilities, you've narrowed it down by ONE.  I agree with the PDCA approach (Deming cycle). You should refine, deliver, refine, deliver.  Don't forget to deliver.  If you get something 99% done, you still have nothing.  Deliver something (regardless how small), get acceptance, and repeat.

The Second thing I wanted to note from the podcast was the mention of an Ernest Hemingway quote

Never mistake motion for action

Things don't have to be hard.  If your business [process] requires you to do wasteful (time or money) things, don't do them!  You should be doing things because they provide value (save time/money or make money).  The rest is just fat and you need to trim the fat from every business [process].  Make your [processes or products] as lean as you can without hitting the bone.  Only then can you have a good baseline.  Only then can you build on top of something.  Anything beyond that and you may be wasting time and money compensating.

Do something because you need to do it.  Don't do it because you feel obligated.  Do you need to go to that next meeting because there is valuable information being communicated?  Or rather, if you don't go it will give the impression that you're being antisocial?  Meetings are perfect examples of an crime perpetrated by people that don't have enough actual work to do or those to feel obligated by people that don't have enough real work to do.

You know why I don't check my email every 5 minutes?  Because I have things I need to get done for the customer!  Sending me pictures of LOLcats is not going to help me get that work done.  Equally, expecting me to respond to that email within an hour of you sending it just reinforces the fact that you have more time on your hands than me.

Image courtesy Flikr: Travis S.

And The Best Methodology Is

The question is always asked, which Methodology is best?  It is interesting to see or read the responses from people and their reasoning behind their opinion.  I actually don't like to use the term Methodology. I would prefer to use the term Approach.  Merriam-Webster defines methodology as a body of methods, rules, and postulates employed by a discipline; a particular procedure or set of procedures.  An approach is the taking of preliminary steps toward a particular purpose.  THAT is what people do.  If you review the PMBoK or the Agile Manifesto, neither are going to say in the event of A-B-C, in this sequence, do D-E-F.  Life, application development, and project management are complicated enough.  You don't need to write an algorithm to know the next step needed to accomplish goals. There is a pain point in the industry that I've seen ongoing for several years now.  In this post, I'm not going to say which approach I think is better and why.  It's really kind of irrelevant.  I think what is important is we ask ourselves and our stakeholder. What IS important?

A while ago, commented on two blogs that address similar topics.  Jesse Fewell wants to empower teams to succeed, equip managers to lead, and enable executives to unlock the secrets of high performing organizations.  Jesse wrote a blog post offering the real reasons behind the methodology wars.  It's an insightful post and I would recommend you go and read it.

The other blog post was from Mike Cottmeyer, someone I turn to on a regular basis to find inspiration and wisdom within the industry.  Mike wrote a blog post asking Why is Agile so hard to sell? Again, it is a very good read and you should set aside some time to read some of his writings.

My bridge to both blog posts is identifying Wants and Needs.  Both drive motivations.  Once you understand the motivation, you can answer the question "why?"

Before analyzing why one team likes one approach or has disdain for another, you have to question their motivations. We assume we all desire the delivery of value. That’s not necessarily true. Some are more motivated at protecting the status quo or their position in the program.

The hierarchy of wants, not needs, will commonly differ between teams, if we want to admit it or not.

Image courtesy of quickandirty

My Merge of GTD and Kanban

I'm not going sit here an boast of being some kind of expert on Kanban or guru of personal productivity.  I'm just a Project Manager/Leader who is always keeping his eyes and ears open for newer or better ways to manage time or work.  I believe you should always try to eliminate non-value-added processes, resulting in a positive impact of customer satisfaction, while reducing support costs.  How do you do that?  You get it done as effectively and efficiently as possible. I recently completed Getting Things Done by David Allen.  It was an interesting book.  Though I use paperless processes to "get things done", David offered one bit of advice that resonated with me.  To advance a task or activity to more of an actionable conclusion, he said to ask "What's the next action?"

This parallels what I do with my Kanban (task) board.  I currently have 4 columns:  Backlog, Work In Progress (WIP), Blocked, Done.  When a prioritized task can not be worked, I put the task card (user story) in the "blocked" column.  I then ask myself the question.  What's the next action? Without asking yourself that simple question, your task may be blocked longer than necessary.  You have to understand there may be 3 or 4 steps you need to complete before you can unblock your task and get it back to WIP.  So, ask the question.

As to not ignore the obvious, I recommend you write your tasks in a standard user story format.As a [perspective], I want to [activity], so I can [desired outcome]

It doesn't matter if you use a physical or virtual Kanban (task) board.  I recommend following 3 simple rules:

1. Keep your tasks visible

2. Keep your tasks limited

3. Keep your tasks actionable

Kanban for Lean Project Management

For those out there using Kanban for Lean Project Management, let me sing the praises of Zen.  Zen is a tool that applies the ideas of the Toyota Production System (commonly known as "lean" principles) to project management. Whether you already practice lean in your organization, you want to set up a lean process, or you just want an easy and effective way to manage your process, Zen will work for you.

Since I started using Zen back in July, my productivity increases has been astounding.  I used to think multi-tasking was the best way to deliver value.  I couldn't have been more wrong.  Instead, I now limit my Work In Progress to only 3 and only focus on 1 at a time.

Though I wrote about this product back in August, I wanted to give a formal product endorsement.  Getting started is free of charge. Once you begin using it on your projects, the cost is reasonable and scalable.  The Zen creators focused on what really matters, and designed an open-ended and easy to customize product.  They don't overwhelm you with metrics and force you to try to figure out what matters.  Instead, they track just a few high-value indicators such as cycle time and lead time.

If you've already implemented lean ideas in your organization, Zen can easily be used to replace a manual kanban board and spreadsheets, and has all the features you would expect to find in a lean project management tool.  If you think I'm a fanboy, you'd be right!  I love this product.  Check out www.agilezen.com

My Personal Kanban Story

Personal Kanban

A little over a month ago, Agile Zen started following me on Twitter.  They are creators of a very clean web-based kanban solution.  Around the same time, I connected with Jim Benson.  Jim is a collaborative management consultant.  He is the CEO of Modus Cooperandi, a consultancy which combines Lean, Agile Management and Social Media principles to develop sustainable teams.

Though I've used information radiators like kanbans in the past, I've been working in a non-Agile PMO for the last six months and it's all very foreign to them.  Thanks to reading the works of David Anderson, Jim Benson, and AgileZen, I'm back in the game.  I'm using AgileZen on a daily basis for everything from business deliverables, to an entrepreneurial project, to my wife's honey-do list.

My actual task completion velocity has noticeably increased in the last month.  I attribute that to AgileZen having a very easy to use product, Jim musing on a daily basis on the topic, and most importantly limiting what I'm working or focused on.

I wish I could thank all of the kanban supporters out there that I follow on a daily basis.  These 3 really have to be mentioned.  If you're interested in Kanban, look them up.