PICK Charts and Kaizen

I'll admit, I'm no Lean Six Sigma Black Belt.  But as I was sitting in a management meeting the other day, I was impressed by a vendor's Operations Manager, who was being touted as one.  The vendor has been running into some issues at the SOC (Systems Operations Center).  We asked the vendor to take a few weeks and do an analysis and then propose some improved processes.  I was apprehensive at first, being I've seen this vendor spend a lot of time and money to do an analysis, only to propose a solution similar to killing an ant with a sludge hammer.  That did not happen this time.  The Operations Manager offered a 15 minute presentation titled Kaizen. This caught my attention because Kaizen is Japanese for improvement or change for the better. I've heard the term used many times before, when referring to doing process improvement. A key component of this Kaizen presentation was a PICK chart.  What is a PICK chart you ask?  When faced with multiple improvement ideas, a PICK chart may be used to determine which ideas are the most benifitial. There are four categories on a 2x2 matrix; horizontal is scale of payoff (or benefits), vertical is ease or difficulty of implementation.    More expensive actions can be said to be more difficult to implement. By deciding where an idea falls on the PICK chart, four proposed project actions are given: Possible, Implement, Challenge and Kill (PICK).

Small Payoff, easy to implement - Possible Big Payoff, easy to implement - Implement Big Payoff, hard to implement - Challenge Small Payoff, hard to implement - Kill

You'll notice by my graphic below that we have 3 ideas to implement, 2 that are possible, 2 that are a challenge, and 1 to kill.  This was by far the best presentation I've seen in a while.  The entire executive team could visualize the recommendations on one screen.  All data supporting potential areas of improvement were on the other slides,  included assessments of cost (money or time).

All I can say is bravo!  When in doubt, use a visual aid.

PICK Chart

HT: Wikipedia

Social Norms at Work

I recently gave a talk in Michigan on the topic of servant-leadership.  Unfortunately, servant-leadership is something that is painfully absent in so many organizations.  Just a few years ago, it (servant-leadership) was not something I had even heard of.  Going back and reviewing the PMBOK made me realize two glaring omissions.  There is a lack of content on stakeholder or team engagement and there is a lack of content on leadership.  Fortunately, in the last few years, I have enjoyed books by authors like Clay Shirky, Seth Godin, Dan Pink, and Dan Ariely.  I've also met and interacted with some amazing people in the Agile community.  I now interact differently with my peers, as a result of these experiences.  I now apply my social norms at work.  What are social norms?  They are patterns of behavior in a particular group, community, or culture, accepted as normal and to which an individual is accepted to conform. We all go to work and we all get paid to do it.  Too many times, we take things for granted.  We don't question the things we do or the things that happen to us.  I'm pretty sure this is based on conditioning over a long period of time.  Perhaps we need to start treating those we work with more like those we socialize with.  Next time you interact with a fellow employee, ask yourself if your behavior is socially acceptable.

Social Norms

Within an organization, where we are working with other people, things can get twisted.  Some exhibit bad behavior and believe it's somehow forgivable because we're all getting paid.  Well, I don't think that's acceptable.  It's very interesting to see the same people behave differently, when not in the office environment.  Why is it some people forget basic manners or common courtesy, when in an office environment?

Case in point, I hold the door open for people, regardless if I know them or not.  I see this as socially expected behavior.  Socially, I expect a thank you.  To say I expect it is a slight embellishment.  Outside of the office, I still expect a thank you.  Unfortunately, at the office, I've started to accept not getting any reciprocation.  There are a few people in my building that I don't personally know but I still hold the door for them.  They won't make eye contact with me and they won't say thank you.  When the situation is reversed, these same people do not hold the door for anyone.  But, I refuse to accept their behavior.

We all need to strive to understand and empathize with others. People need to be accepted and recognized for their special and unique qualities.  Assume the good intentions of your coworkers and don't reject them as people, even while refusing to accept their behavior or performance.

Drawing:  Pictofigo

HT: Business Dictionary

30 Second Agile Pitch

I was just over at the AgileScout website and read an entertaining account of his trip to the supermarket.  It went a little something like this:

This past weekend, like every weekend, I go to Whole Foods with my wife for our weekly food run. While sampling some of the very good wine, I ran into an old neighbor that I hadn’t seen in years.

We ended up having a long conversation about his company doing this whole “Agile and Scrum thing.” I found myself saying things like the following to help clarify his questions:

“Yes, that is Agile.”“No, that’s not a Scrum principle.”“Yes, that’s part of iterative development.”“Well, that isn’t explicitly in Agile…”“Well, Scrum doesn’t prescribe you to do…“No, that would be waterfall…”“Can we… I… get back to drinking free wine?…”

This reminded me of a very similar experience I had when my wife and I met some friends for dinner. One of them asked what I did exactly.  When I offered a 30 second explanation and included Agile, I got a quick “we do that at work” response. I was pleasantly surprised so I asked in what ways they leveraged Agile principles and approaches. Now, I’m no dogmatic Agilist but the follow-up response had me shaking my head. I wasn’t going to outright argue with her but she correlated doing something as fast as possible as being Agile. No collaboration, no planning, monitoring, or adapting. To her, anarchy and Agile were pretty much synonymous.

For all of you project managers, project leaders, facilitators, ScrumMasters, coaches or whatever you may call yourself, what would be your 30 second pitch?  Do you think you could explain what you do (to a layman) in 30 seconds?  I'd love hear some of your pitches.

Image: Pictofigo HT: AgileScout

CSM & PMI Agile Certification Eligibility

Though PMI has published information about what is required to be eligible to take the upcoming PMI Agile Certification exam, I'm getting quite a few emails from people asking about the upcoming exam.  One of the most intriguing was from a Certified ScrumMaster (CSM) asking if (his or her) CSM training could be applied toward the required 21 PDUs. The question: Do Scrum Alliance® Certified ScrumMaster (CSM) courses qualify for the training eligibility requirement?

The answer: Yes, Scrum Alliance® courses qualify for the training eligibility requirements. Only hours in Agile training will meet the certification eligibility requirements. One hour of training equals one contact hour of education eligibility.

My GLSEC Talk on Slideshare

After my talk at GLSEC, I wanted to make my slide deck available for viewing by the general public.  I noted to the people attending that my presentation was going to be a little heavy on text, so the people reading it later could actually understand what I was talking about. The best talks I've seen have been those where the presenters only referenced their slides from time to time.  Of course, we're all thinking of a Steve Jobs keynote.  But imagine if you viewed his slide deck after the fact?  It would be pretty hard to get detailed information, unless you read a transcript of the event. After reviewing a few methods of distributing my presentation, I decided on slideshare. The original presentation lasted closed to 1 hour. We spent about 15 minutes of my talk playing two interactive games. (Simon Says and Red Light Green Light) Other than the games, the basis of the talk are all in the deck.

Breaking the Law of Bureaucracy

View more presentations from derekhuether

PMI Agile Exam Tools and Techniques

50 percent of the PMI Agile certification exam will be comprised of questions about tools and techniques.  The PMI Agile Certification team grouped the tools and techniques it 10 areas. The toolkits below are ranked in the order of their relative importance within the tools and techniques section of the exam.

1	Communications
2	Planning, monitoring, and adapting
3	Agile Estimation
4	Agile analysis and design
5	Product quality
6	Soft skills negotiation
7	Value-based prioritization
8	Risk management
9	Metrics
10	Value stream analysis

Want an example of what you will find within the Communications area? Some tools and techniques included but are not limited to information radiators, team space, agile tooling, osmotic communications for collocated and/or distributed teams, and daily stand-ups.

Remember, 50% of the exam will be dedicated to Tools and Techniques and 50% will be dedicated to Knowledge and Skills.

HT: PMI Agile Certification Examination Content Outline

Mapping the PMI-ACP Exam

So, word on the street is the PMI Agile (Project Professional Certified Practitioner) Certification pilot will begin in just a few weeks.  For those interested in participating in the pilot or taking the exam in a few more months, PMI was kind enough to provide an examination content outline.  Though it's only 16 pages in length, I started to reorganize the data so people can see what they're up against.  Download the PMI-ACP Exam Matrix.

Here is a breakdown of the exam

Agile Tools and Techniques (50% of Exam) I'll write another post about that later

Agile Knowledge and Skills (50% of Exam) Percentage of Knowledge and Skill Content / % of Exam Level 1 (65% / 33%)  (18 knowledge/skills) Level 2 (25% / 12%) (12 knowledge/skills) Level 3 (10% / 5%) (13 knowledge/skills)

HT: PMI Agile Certification Examination Content Outline

Judgement Day

Last night (April 19, 2011) at precisely 8.11pm, Skynet, the giant computer network that controls most of the U.S. weapons, became self aware. Tomorrow it begins its assault on humanity. Tomorrow is to be Judgement Day. Hmmmm.  I'm a big Terminator fan but I've heard this story before.  If memory serves me right, I shouldn't be preparing for the day the machines are set to rise and take over the Earth.  I should be preparing for disappointment.

Space 1999

Remember way back when nuclear waste from Earth was stored on the Moon's far side and it was to explode in a catastrophic accident on September 13, 1999?  It was to knock the Moon out of orbit and send it and the 311 inhabitants of Moonbase Alpha hurtling uncontrollably into space.  It didn't happen!

Millennium Bug

Remember all of those crazy people who were stockpiling gold, food, and water leading up to December 31, 1999?  Sure, I still have a container of TVP somewhere in the basement.  It's now there in the event of a zombie apocalypse.  Butt CNN Money reported that we spent over $500 Billion on Y2K.  Again, nothing really happened!

2001: A Space Odyssey

Some technologies portrayed as common which have not materialized include commonplace civilian space travel, space stations with hotels, moon colonization, suspended animation of humans, and strong artificial intelligence like HAL.  We're getting there, but it hasn't happened.  Arther C. Clarke went on to write three sequel novels: 2010: Odyssey Two, 2061: Odyssey Three, and 3001: The Final Odyssey. Two out of four have come to pass and we missed the mark.

So, what is my science fiction rambling all about?

Why do we keep making predictions?  Aren't we setting ourselves up for a fall over and over again?  Sure, I'm all about setting goals.  We did get a man on the moon by 1970, as President Kennedy pledged.  But fact or fiction, I just don't see 99% of these predictions as coming true.  Just as I have less and less faith in predicting the completion date and scope of a project before it begins, I'm not going to buy into Judgement Day either.  I'm just trying to manage this cone of uncertainty. Let's just review what happened yesterday, let's see what we're doing today, and then we'll see what we can get done tomorrow.

HT: Wikipedia

Drawing from Pictofigo