Zombie Manifesto

Who would have thought that a year after publishing Zombie Project Management that I would be asked to brief a Federal Agency (which is not to be named at this time) on the topic.  As part of my briefing, I will be including the Zombie Manifesto. Nobody has said I have lost my sense of humor.  Then again, nobody has told me I have ever had a sense of humor.  I look forward to writing a blog post next week after the briefing.  "Briefing" makes me talking for over an hour sound so official!

Become a Signatory! Leave a comment below

When PMI Introduced the Elephant - Part 2

In just a few weeks, I will be speaking at an upcoming (sold out) Agile conference here in Washington D.C.  It's unfortunate that I had to decide between going to the PMI North American Congress and speaking at the AgileDC event.  The events are happening the same week.  I had to decide if I wanted to speak or if I wanted to just attend. The title of my talk at AgileDC is "When PMI introduced the elephant in the room".  Let's define that.  We're talking about an important and obvious topic, which everyone present is aware of, but which isn't discussed, as such discussion is considered to be uncomfortable.  That elephant, of course, is the mainstream adoption of Agile.  Many of us saw the momentum of agile practices growing.  And I think just as many out there have tried to ignore it, misrepresent it, or dismiss it.  Though it took 10 years, I see PMI's move to formally embrace Agile, with its own Agile certification, as a sign we're about to cross the chasm.  The PMI wouldn't do this if they didn't see market trends supporting it.  With the PMI endorsement, Agile will be more widely used, more openly adopted...and yes, abused.

But I'm not here to rain on PMI's parade.  I take my hat off to the PMI leadership, the PMI Agile Community of Practice leadership, and the informal Agile luminaries we all know in the industry.  I know there are people who are not very happy with the idea of PMI being the organization to release a comprehensive Agile exam.  Like it not, someone has to do it!  Agile needs something that will motivate people to accept it as a legitimate alternative (or primary choice) and leverage it.  Though not every project environment appears to be conducive to what the Agile Alliance or the Scrum Alliance offer, they seem to be more receptive when the PMI offers it.  In the U.S. market, the Project Management Professional (PMP) certification has reached a point in the adoption curve whereby if you are a Project Manager and don't have it, you are at a disadvantage.  It has reached such a fever pitch that even people who are not Project Managers (by trade) are finding ways to get the certification.  People are believing certifications will make them more marketable and better managers or leaders.  PMI is merely capitalizing on that belief, with the introduction of the Agile Certified Practitioner certification.  A certification that is not easy to get, immediately has a perception of value.

When you think of PMI, what do you think of?

Processes and tools?
Comprehensive documentation?
Contract negotiation?
Following a plan?

PMI is the world's largest project management member association, representing more than half a million practitioners in more than 185 countries. As a global thought leader and knowledge resource, PMI advances the profession through its global standards and credentials, collaborative chapters and virtual communities and academic research.

When you think of Agile, what do you think of?

Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan

The authors of the Agile Manifesto wrote "We are uncovering better ways of developing software by doing it and helping others do it."

So, is this a contradiction?

LeanKit Kanban

When the Agile Manifesto for Agile Software Development was written 10 years ago, it stated "We are uncovering better ways of developing software by doing it and helping others do it." The very first of four values listed within the Manifesto was "Individuals and interactions over processes and tools"

The Manifesto goes on to state "...while there is value in the items on the right, we value the items on the left more."

Well, I am compelled to write about one of the items on the right.  I still believe the tool should be good enough that it helps you reach your goals.  But after that, it should not become a big process onto itself.  What I want to do is finish tasks and get some actual closure on them.

I recently read in the book Personal Kanban by Jim Benson and Tonianne DeMaria Barry, a phenomenon known as the "Zeigarnik Effect".  It states that 90% of people remember uncompleted or interrupted tasks better than completed tasks.  Soviet psychologist Bluma Zeigarnic found that the human brain becomes preoccupied with things that are not closed.

Though I have leveraged Kanban with teams, it took me a while to realize that Visual Control Systems could be used to visualize and manage both personal and professional work.  I then found myself using a physical board at the office and an electronic version (web-based tool) at home.

What is visual control, exactly?

A visual control is a technique employed in many places where information is communicated by using visual signals instead of texts or other written instructions. The design is deliberate in allowing quick recognition of the information being communicated, in order to increase efficiency and clarity.

The real question is, can a process tool take the place of individuals and interactions?  Perhaps we need to stop and think about the reality of our world.  Is everyone in your company physically located in the same office space or are you geographically dispersed?  If you're not all sitting there together in an open workspace, you need to find a tool that will bridge that physical gap and then stay out of the way. Bandit Software's  LeanKit Kanban does that.  Let me tell you what puts LeanKit in the lead of the Kanban tool race.  It's called mobile computing.

I seem to carry my iPad with me everywhere. (I'll be getting an iPhone as soon as my contract is up).  Though the LeanKit iPhone/iPod interface could use a little work, the iPad interface is completely awesome.  The image above is actually a screen print from my iPad.  The design is simple; it's lightweight; it's functional.  It helps me visualize my work and it helps control my work in process.  Merge LeanKit Kanban and an iPad and you will have an amazing user experience, as it allows individuals to interact wherever they see fit.  I'm happy because I can access half a dozen different boards with tap of my finger and my wife is happy because I didn't cover the walls of my home office with whiteboards and sticky notes.

If you're thinking about using a web-based Kanban tool for yourself, your team, or your organization, all of the vendors out there have relatively similar features.  See which one fits your budget.  If you or your teams are using mobile devices like iPhones, iPods, or iPads (in addition to desktops or laptops), you need to go to iTunes and download this app.  Though you need to have an existing LeanKit account to make the Apple App versions work, you can get a personal account for free!

After you see how well it works for your personal life, I don't doubt you'll be using it in the office in the not-too-distant future.

HT: Wikipedia HT: LeanKit HT: Personal Kanban

Individuals & Interactions over Processes & Tools

It's pretty exciting to hear that LinkedIn just reached over 100 million users.  Upon review this morning, my LinkedIn profile stated that I have 149 connections, adding it links me to 3,156,950+ professionals.  Unfortunately, I believe a tool is only as good at the individual(s) using it.  I'll admit, I don't really get LinkedIn.  I don't leverage it the way it was probably intended.  To me, it's an online resume with connections to people who I should have some kind of affiliation with.  I think of it more as Classmates.com for business.  I actually have a majority of my LinkedIn contacts as a result of an extended Fail Whale that happened on Twitter last year.  Twitter may be great for interactions but it's not so great as a professional contact management tool. A few days ago, I received a LinkedIn connect request from someone I interact with on Twitter.  She wrote

Derek, Would you have any interest in connecting on LinkedIn? I went to send an invite but for some reason the option isn't there!

Since we've interacted on Twitter and share some professional affiliations, I figured I'd add her to my LinkedIn connections.  I logged into LinkedIn to send her the  connection request and realized why she did not see the option.  The LinkedIn user interface had recommended she connect with me, though we were already connected.

In the end, we just laughed it off. We're still following each other on Twitter. We've reaffirmed that we're connected via LinkedIn. But, it raises an interesting question.  How useful is an interaction tool if you don't interact with other individuals?  How useful is have connections, if you don't connect with them?

Like the drawings?  Get them free on Pictofigo!

The Agile Introduction

When you meet someone new and they ask you what you do, what do you say to them?  Do you have a prepared introduction?  Have you prepared an explanation of your unique qualities?  If you think that is hard enough to communicate to the layman, try explaining Agile. If someone says "Hi, I'm Bob. I'm a Project Manager", most people get it.  We've all had a generation to get it.  Oh ya, so you manager some one or some thing.  I get it.  Now, when explaining Agile and how it relates to what we do, there is an extra layer of complexity.

For those in the Agile community, you'd be willing to take 10 minutes trying to explain Agile, rather than to be associated with the status quo.

But here is our problem as Agile proponents.  We don't all agree as to what Agile means.  There's a bit of a disconnect there.  I've heard people basically recite the Agile Manifesto when asked what Agile was.  The Manifesto (for Agile Software Development) hasn't been around long, being written and signed in February of 2001.  Though the authors signed it, I doubt they would all agree specifically what Agile is.

I've heard people describe Agile as "caring, loving, respectful"...  Though I don't discount you may see people exhibit this behavior, I don't go that far.  I'm talking Agile here, not my wife!  You see, to some, Agile is a living breathing thing.  But, I'm much more pragmatic.  I'm still passionate about Agile.  But, I'm not going to hold some dudes hand and sing Kumbayah by a campfire.

Let's get back on point.  The Agile Manifesto originally related to software development.  Some are now applying the 12 principles of the Manifesto and items the authors came to value to areas beyond software development.  This does not make these approaches any less "Agile".

I read a very interesting comment on the Agile Scout website, where someone explained how they use Agile as a Marathon Training Approach. One of the comments was: I think we are getting a little carried away here with Agile. Some say it is a philosophy (for developing software), but people seem to want to extend it to be a religion almost. I am sure that is not what the writers of the Agile Manifesto had in mind. This is a good way to get a good idea written off as a cult.

My response to this is an analogy.  For those who celebrate Christmas or think they know what Christmas is, ask them "What is Christmas?"  I am sure that is not what the creators of Christmas had in mind.

To summarize, Agile has become something bigger than what anyone could have imagined.  The concepts, approaches, and philosophies associated with it will continue to expand to other verticals as long as the Agile community (as a whole) accepts them.  So, how do I try to explain Agile to someone I just met?  Though I reserve the right to refine my introduction, I believe

I am a Agile Proponent

Agile focuses on the frequent delivery of something that works, by using small collaborative groups of people and small units of time to make sure whatever has the highest value get done first.  As each unit of time progresses, more gets done and more information becomes available to which future work can be done.

Like the image? Find it at Pictofigo

Why Ask Why

Before you spend the next week, redesigning the TPS report, you need to stop and ask yourself a simple question.

Why?

Why are you doing it?   If you can not map the task back to a stakeholder or customer objective/requirement (goal) you better stop now.  Some people call this gold-plating.  Additionally if you can not map the task back to one of your personal goals, you better stop now.  I call that flushing time down a toilet.

Do you sometimes feel like you're rearranging deck chairs on the Titanic?  Are you spending all of your time doing stuff that is not getting you any closer the real goal?  Well, stop for a minute and pretend you are a 5-year-old.

Whenever you ask a 5-year-old to do something, they never seem to do it without first asking why.

Go sit down Why?

Because it's dinner time. Why?

Because you need to eat your dinner. Why?

Because I don't want child protective services saying we don't feed you. Why?

Because we're trying to get you to adulthood without scarring you too much.

What's our main personal goal as it relates to our son?

Goal 1: Get him to adulthood without scarring him too much

Now, as project managers and leaders, what are your primary goals? Is it keep the project on schedule? Is it keep the project from going over budget? Or, is it one of the 12 principles of the Agile Manifesto?  Whatever your answer(s), when asked to do something, keep asking why until you reach your main goal(s).

We want to add this change to the next deployed version Why?

Because it is now a priority Why?

Because it will either save time, money, or both

What's one of our documented goals related to our project?

Goal 1: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Like the image?  Find it at Pictofigo

Principles Behind The Twitter Manifesto

We follow these principles: Our highest priority is to satisfy the follower through early and continuous delivery of valuable tweets.

Welcome a changing Twitter stream, even late in the day. Twitter processes harness change for the follower's informative advantage.

Deliver working links frequently, from a couple of hours to a couple of days, with a preference to the shorter timescale.

Tweeters and followers must work together continuously throughout the day.

Write tweets around motivated followers.  Give them the environment and support they need, and trust them to get the retweet done.

The most efficient and effective method of conveying information to and within the Twitter community is continuous conversation.

Reading informative tweets is the primary measure of progress.

Twitter processes promote sustainable tweeting and retweeting. The tweeters, followers, and twibes should be able to maintain a constant pace indefinitely.

Continuous attention to tweet excellence and good spelling enhances retweeting.

Simplicity--the art of maximizing the amount of letters not used--is essential.

The best blog posts, pics, and links emerge from self-organizing twibes.

At regular intervals, the twibe reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Thank you to the authors of the Agile Manifesto.  Without it, my life would have less direction and this post would have even less value.

Graphic: Pictofigo

Using Agile does not mean a lack of defined process

Agile Scrum process

Sometimes I'm not surprised to hear one of our current contractor say they are now usingAgile.  This is their explanation for ad-hoc builds, lack of documentation, and lack of predictable process.  It can be frustrating to hear of development groups using it as a scapegoat.  Waterfall has been the decided process for our main program I'm working and it makes sense.  The requirements have been clearly identified, for several years.  The budget and schedule have been fixed, for several years. I'm not saying we can't use Agile in different areas of the program.  But, most important the current contract is not structured to support it. The contractor does not seem to understand the difference between cowboy coding and Agile.  Agile teams, do follow defined and often very disciplined and rigorous processes.  What is lacking, by this contractor, is any example of a defined process.

Agile certainly can work well if utilized by people who know what it is.  I've signed the Agile Manifesto. I know what Agile is.  Don't use a lowecase "agile" and think you're getting away with it.