Getting PMI Agile PDUs Early

Let's say you're interested in the upcoming Agile Project Professional (APP) certification from PMI.  You look to see the eligibility requirements and notice you'll need 21 hours of Agile Project Management Training.  If you're determined to get the PMI APP and looking to do this on the cheap, start watching webinars now. I can guarantee there will be a lot of training opportunities in the near future.  Check out a future location to find upcoming Agile PDUs. Once it is fully rolled out, it should be an excellent resource to find PDUs to meet your PMI needs. So back to the intent of getting the training.  After I read (and recently reread) Dan Pink’s book, Drive: The Surprising Truth About What Motivates Us, it made me stop and question why people wanted to get the PMP or APP.  Are we trying to discover better ways to deliver value to customers or just trying to get a piece of paper and a few extra letters after our names?  Dan breaks it down to pursuing the mastery of performance-based objectives versus learning-based objectives (ie. getting a passing score on a certification exam versus learning new approaches to deliver value to customers).

Regardless, information is information and I want to do what I can to help people discover it.

One of the approaches I really enjoy using is Kanban.  Today I stumbled upon a free Kanban webinar.  Though you do have to enter some contact information, it's free.  You have the option of downloading it or viewing a playback.  So, regardless if you're looking to bank those PMI Agile PDUs or not, enjoy 1 free hour of training.  By the way, I am in no way affiliated with the provider.   I just like free webinars.

HT: ASPE Events HT: Agile PDUs

Link to Drive is an Amazon affiliate link Drawing by Pictofigo

Reading about Process Improvement

Over the weekend, I found myself trying to read a physical book about systems analysis while listening to a book on operational process improvement.  I'm not going to go into the physical book because I am so impressed with the audio book.  I guess it wouldn't matter if it was physical, digital, or audio.  It's just a really really good book! It's titled: The Goal: A Process of Ongoing Improvement by Eliyahu M. Goldratt (yes, if someone clicks on that link and buys a book, I would get credit)

Though the story reads like fiction, in its introduction of characters and story, it does an amazing job of introducing concepts to the reader.  The main character manages a production plant, where everything is always behind schedule and things are looking pretty bad. (Sound like any projects you know?)  The production plant is doing so poorly, the company has given the main character an ultimatum.   With a threat of closure, the plant has three months to turn operations from being unprofitable and chronically late on deliveries to being profitable and successful.  In the book, we are introduced to the Socratic method. Throughout the book, a character poses questions to another or a member of a team, which in turn causes them to talk amongst themselves to come up with a solution to their problem.

Because the book revolves around manufacturing and not application development or project management, there are a few dotted lines that need to be drawn.  But, overall, it really got my wheels spinning.  It doesn't matter if you're using Kanban or if you're in any type of management position, I would recommend this book.

One quote really stuck with me

Intuitive conclusions (common sense) are commonly masked by common practice

Process Improvement

The following lists some of the ways that processes can be improved.

• Reduce work-in-process (WIP) inventory to reduce lead time
• Add additional resources to increase capacity of the bottleneck
• Improve the efficiency of the bottleneck activity to increase process capacity
• Move work away from bottleneck resources where possible to increase process capacity
• Increase availability of bottleneck resources to increase process capacity
• Minimize non-value adding activities to decrease cost and reduce lead time

Like the drawing? Get it free from Pictofigo

PMI and Kanban

How are you? My name is [author] and I'm a writer for PM Network magazine, the official publication of PMI. I'm doing a piece about e-kanban systems and their role in Enterprise Resource Planning (ERP). Would you be interested in doing a quick interview?

So begins my hope of spreading the positive impacts of Kanban in a PMI publication, only to feel betrayed.

Let's go back a few years

Back in 2009, when I was first learning about Kanban, I saw both David Anderson and Jim Benson write about AgileZen on their blogs.  That's when, in addition to using a physical Kanban, I started using AgileZen to manage my personal work.

Fast forward to June 2010

After reading David Bland's blog post about creating virtual story boards with Google Docs, it inspired me to create a DIY virtual Kanban. What I discovered was, yes, you can do it.  But, why would you do it when a physical Kanban works so much better?  For me, it's all about visualization and simplicity.  If you're dealing with distributed teams, in addition to a physical Kanban at each location, I would recommend using AgileZen to bridge the 2 physical boards.  AgileZen is my personal preference.  It's clean, it's easy to use, and it's free if you only have 1 project.  I never used my Google Docs hack because it was too easy to use a physical Kanban and AgileZen.

Now fast forward to just 2 months ago

A writer for PM Network magazine writes me, asking to interview me.  I agree and we spoke at length by telephone two times.  During the first interview, I got the impression that he had not used Kanban before.  He didn't get visualizing workflow. He didn't get limiting your work in progress.  So, I threw out my L.A. Freeway analogy and related it to activities at work.  The author had done research about JIT lean manufacturing but I got the impression he was unable to bridge the gap on how he could apply it to his world.  I couldn't understand why he kept pushing the virtual Kanban.  Because I wanted to answer his questions, I said he could go so far as to do it in Google Docs.

A few weeks passed and I was contacted by a research editor.  She said she was fact checking and also wanted a high resolution headshot and introduction to include in the article.  Her "facts" surprised me.  What the author had written was sending the wrong message!  He was pushing the Google Docs (hack) and not AgileZen.  He clearly had not even tried the Google Docs hack, based on what he wrote.  The last sentence made me cringe.

...but you have to see if this will work with your culture before you try implementing it, even for yourself.

No, what I said was, you can leverage Kanban on an enterprise level, like for portfolio management, but you need to verify if this approach will be accepted by the organizational culture.  It doesn't even make sense to say "...even for yourself".

I sent back edits to what she provided.  The following is my additional responses to them.

Is there a way I can proof the entire article?  I've been leveraging Kanban for several years now.  Based on a few of the edits I made, I have a few concerns.  Though I don't want to take anything away from [Author], I want to ensure your readers get the highest quality and most accurate information possible.   To be clear, I recommended AgileZen, hands down as the virtual Kanban of choice.  But, IF you wanted a (very limited) DIY virtual Kanban, then you could do it with Google Docs.

I finally picked up the phone and called them.  I stated, if I could not proof the entire article or could not be assured my changes would be incorporated in full, I did not want to be associated with the piece.

Yesterday

I received my March copy of the magazine.  On the front cover, I read "Kanban goes digital".  On page 66 and 67, I find that I am quoted but with no introduction as a technical contributor or headshot.  To set the record straight, I didn't choose the images used in their article nor did I write it.  I am merely quoted.

...and this is why I write my own blog and tweet.

One of My Resolutions

When PM Bistro asked if I would write a blog post for them, I was happy to oblige.  You can read the original post here.  For a little background, I was asked to write about a particular work-related goal I have for 2011.  I actually have several (goal) resolutions for 2011.  I keep them on my Personal Kanban so I can be reminded of them daily.  Because they are so big, I consider them Epics.  I then break them down into "actionable" stories.  Anyway, here is the blog post.  I hope you enjoy.

---

When asked to think about a particular work-related goal I made for 2011, I knew it would be easy to list but harder to explain. It’s common to say “how” or “what” you’re going to do. It’s a whole other thing to say “why” you’re doing it.

The goal I have is: To articulate the values, principles, and methods of the agile community to the traditional project management community.

Why: I’ve been working in the Industry for some 15 years. I’ve seen and been involved in the best of projects and the worst of projects. Over time, I’ve seen more and more methods defined and practiced. I’ve seen people in our profession leverage these methods in the hopes their projects would be successful. It is my fundamental belief that all project managers and leaders should know all of the options available to increase the probability of project success.

How: About 5 years ago, I read the Agile Manifesto. Though it was written for software development, I discovered I could leverage some of the principles it defined in other areas. I then discovered the agile community. These progressive thinkers spoke less of maintaining the status quo and more of introducing new ways of doing things or refinement of the old. Though there are “agile” processes to follow and disciplines to uphold, many in the traditional project management community seem to be unaware of them.Some still think agile lacks both process or discipline. I hope to change that. I plan to tweet, blog, publish, speak, and mentor at every opportunity.

What: I had the pleasure of attending the PMI North American Congress in Washington DC this last year. Though I saw a very strong visual representation from the Agile Community of Practice, when I spoke to the random attendee, they had no idea what Agile was about. As I interact with both new and seasoned professionals of our Industry, I want them to know how agile can work in concert with their traditional methods. I want to see more projects succeed.

Like the image? Find it at Pictofigo

Using Stories on my Personal Kanban

A colleague on Twitter asked how do I break down my stories, acceptance criteria etc?  As a reference point, "stories" refer to my use of User Stories on a task board or Kanban.  It's a method of representing requirements or scope.  In upcoming posts, I'll also write about acceptance criteria, size, blocks... Let's say you have some work that needs to be completed or delivered (scope).  Rather than the old fashioned shall statements to define the scope or requirement (system shall do this; system shall not do that), we're going to write a little self-contained story on an index card, post-it note, or something similar.  When we're done, we're going to add the story card to our kanban board.  Our user stories are written from the perspective of the user.  In the case of the personal kanban, that's me.  What you put in your user story may vary. But, for me, the stories have to be self-contained and they have to pass my "why" test.  Though I don't write it in the user story or on the card, I map work I do back to higher level goals.  If the work can't be mapped back to previously defined goals, I'm just wasting time.  Let's try not to do that.

When writing a user story, this is the format I follow

As a <type of user>, I want <goal> so <reason>.

Here it is in action

As a blogger, I want to write a blog post about user stories, so people will understand how I use them.

Now I ask myself "why". What is my predefined goal that it maps back to?

Spend more time writing, speaking, and mentoring and less time directly managing or leading projects.

So, there you have it!  Because I use both an electronic kanban and a physical one, I keep all of the details in the electronic version and use the physical one a visual reference.  It is a constant reminder to myself and others of what I am committed to do, work in progress, work that is blocked, and work recently completed.

Have any question?  Feel free to leave a comment.

The Funnel Effect and My Kanban

GuyKawasaki tweeted about a really cool infographic on Alltop titled Why freeways come to a stop. I checked it out and what most interested me was the graphic The funnel effect (I circled it in red).

WIP

The funnel effect is a really good analogy of why you should limit your work in progress, like I do on my Personal Kanban.  In the analogy, just the right amount of water can go through as fast as it's put into the funnel.  But add extra water to the funnel, and the whole thing backs up.

Personal Kanban

In reality, keeping focus on just the right amount of work can allow you to finish more than if you didn't. Personally, I limit my work in progress to 3 items. I never thought it would have such a positive impact. So, what do you have to lose? Do you have a long list of to-do's, doing a little here and doing a little there?  Do you ever feel like you're not actually getting anything done?  Today, rather than trying to multitask, focus on just a few tasks until they are DONE. If you complete one task, you can add another to your focus list. Remember, 99% done is still not done.  At the end of the day, you'll feel a sense of accomplishment, preventing a traffic jam of work and actually getting stuff done.

My Personal Kanban 2.0

I commonly get asked what I personally use to manage my work. The answer is almost too simple. I use a Personal Kanban. Now, I'm no efficiency guru. I'm no expert on Kanban. I just need a simple system that satisfies a few requirements and makes sense to me.

Personal Kanban

Requirements

1. I need something visual to combat my ADD.

2. It must visually capture all of my Backlog of work.

3. I will help me visualize what Work is In Progress.

4. It allows me (and others) to see what got Done this week.

Now, I've been using task boards for probably half a decade now. When you have that one stakeholder who cruises by your office or cube (constantly) and asks what you're working on, you can point at the wall and not even look up from your monitor. The board proves its worth just by cutting down on those people interrupting your day.  After a while, people get used to knowing what's going on and appreciate the transparency.  It's strange that I need to point that out.  Who benefits by not embracing transparency?  That may be a question left to the comments.

The key difference between a Kanban board and a regular task board is a column limiting your work in progress.  My first exposure to this was from a Scrum Master training session being led by Sanjiv Augustine. Sanjiv displayed a PowerPoint slide of what appeared to be a Los Angeles freeway.  During rush-hour, the number of vehicles coming onto the freeway is limited (by on-ramp lights).  This attempt to control the volume of traffic flow onto the freeway allows vehicles already on the freeway to move at a faster pace and in turn exit the freeway.  This visual freeway analogy was like a light bulb moment for me.  When I got back to the office and began limiting my Work In Progress (WIP), I did indeed increase my delivery rate.  The days of multitasking are now in my past!

Jim Benson

Soon after I started using a Kanban, I met Jim Benson of Modus Cooperandi.  I would describe Jim as a Kanban Sensei.  If you ever want to know more about Kanbans, Jim's your man.  Go check out the  Personal Kanban website.  Though Kanban is kind of a background business process to me, I still check out the site from time to time to see how others are using Kanban.

Tool

To wrap this up, there's only one "tech" tool I use to bridge the gap between my home and office.  It's call AgileZen.  AgileZen is a Kanban web application.  Though I have all of my work  work on my Kanban board at the office, my wife would frown on seeing a wall of post-it notes next to my desk at home.  So, I use AgileZen to manage both my personal and work tasks while away from the office.  Some people may choose to just use the electronic version.  I just can't let go of the satisfaction of moving a post-it note from WIP to Done.

Graphic: Pictofigo

The Pepsi Challenge of Waterfall, Agile, or Kanban

I kind of enjoy it when people get all in a huff over which soda is the best.  It's bad enough they can't even decide what to call it. Is it soda, pop, or soda-pop?  I've even heard a few refer to any brown carbonated non-alcoholic beverages as a "Coke".  I don't get that at all.  I'm going to assume these people just don't care.  All they want is a brown carbonated non-alcoholic beverage that will satisfy their thirst.  As far as soda-pop, I am the complete extreme opposite.  I drink Coca-Cola.  I don't drink Coke; I don't drink Pepsi.  If I ask you for a Coca-Cola and you ask me if Pepsi is OK, I'm going to respond with a stern but polite "No".  But, at the end of the day, I am also just looking for something to satisfy my thirst.  But, I digress. Since the Pepsi Challenge in the mid-70's, there has been another battle raging.  Let's call it the Delivery Challenge.  Regardless of what facts may be reports, detailing which approach lowers risk the most, which approach delivers the most value up front, or which approach leaves the stakeholders feeling the most satisfied, we all have our favorite.  If delivery approaches were soda-pop (yes, soda-pop) in a blind taste test, chances are we'd stick with our favorite regardless of what we may have picked.

From my own perspective, I don't believe we should be so blind to these opportunities.  We should be open to the idea that formulas can be improved and we should be open to the idea that processes can as well.

When I'm dealing with the government client on a particular contract, I use Waterfall.  We're talking Waterfall the size of Niagara Falls.  It's not that I choose this approach (drink).  It's all that is currently offered. When I'm managing my own personal projects and deliverables, I use Agile and Kanban.  I'm not saying one is better than the other!  But, when the choice is mine, I know what I like from each.  I ala carte the way I do things, so (as the customer) I get the most value while not bastardizing the original processes.

I know there are those out there who are cursing me.  They are strict Coke, Pepsi, and Dr. Pepper zealots.  Think of me as that kid down at the local Kwik-E-Mart who takes his cup and adds a little of each soda-pop in his 64 ounce cup.  It may look nasty but it sure tastes good.

...and at the end of the day, isn't it important that I just satisfy my thirst?

Image source: USAGeorge