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

Servant-Leadership

I have a very distinct leadership style.  Those who I work for will attest to this.  I'm not talking about superiors.  I'm talking about subordinates.   In order to help build a culture I am proud of, I uphold altruistic principles.  I am a servant-leader.

Servant-leadership is a philosophy and practice of leadership, coined and defined by Robert Greenleaf. Upon doing my research, I read that Greenleaf felt a growing suspicion that the power-centered authoritarian leadership style so prominent in U.S. institutions (of the time) was not working. In 1964, he took an early retirement from IBM to founded the Center for Applied Ethics. Yes, 1964!

When representing ethical leadership on a grid (see above), the graphic should help put into perspective who leaders are and what leaders do. Egoism: When a person acts to create the greatest good for himself or herself.  You can find people exhibiting this orientation at every level of an organization.   When the organization and its employees make decisions merely to achieve individual goals (at the expense of others), they lose sight of a larger goal.

Utilitarianism: The idea that the moral worth of an action is determined solely by its usefulness in maximizing utility or minimizing negative utility.  The focus is to create the greatest good for the greatest number of people.  In Star Trek II: The Wrath of Khan, Spock says "logic clearly dictates that the needs of the many outweigh the needs of the few."

Altruism: The opposite of egoism, a person's primary purpose is to promote the best interests of others.   From this perspective, a leader may be called on to act in the interests of others, even when it runs contrary to his or her own self-interests. In Start Trek III: The Search for Spock, Kirk says altruistically,   "Because the needs of the one... outweigh the needs of the many."

Larry Spears, the head of the Greenleaf Center for Servant-Leadership for 17 years, identified ten characteristics of servant-leaders in his 2004 article Practicing Servant-Leadership. The ten characteristics are listening, empathy, healing, awareness, persuasion, conceptualization, foresight, stewardship, commitment to the growth of people, and building community.

Unlike leadership approaches with a top-down hierarchical style, servant leadership instead spawns collaboration, trust, empathy, and the ethical use of power. At heart, the leader is a servant first, making the conscious decision to lead in order to better serve others, not to increase their own power.

The objective is to enhance the growth of individuals in the organization and increase teamwork and personal involvement.  Exhibiting servant-leader qualities tends to give a leader authority versus power.

Are you a servant-leader?

Measuring (Project) Health

You'd think I would follow my own advice when it comes to my own health.  When dealing with project deliverables or tasks, I like to get feedback from the team as often as I can.  Ideally, I recommend daily feedback.  Realistically, there are extended team members who you don't deal with on a daily basis.  Due to their expertise, you may need to share this person with others on the program.  Notice I didn't call him or her a "resource".  Anyway, you need to make sure you do a few things, when interacting with these team members.  One, identify the maximum amount of time that will elapse between interactions.  Two, identify some threshold criteria.  Exceed the threshold and you should be interacting with this team member. Now, I've followed this prescription in the past, when dealing with experts like Software Architects.  Seriously, it doesn't matter the title of the person we're talking about.  What's important is you know you have maybe one or two of these types on your program.  The other important thing to note is if you don't do either of these things, you run the risk of this coming back and biting you.

3 indicators you've gone too far

1. You have not interacted with your expert within the predefined timeframe
2. You have not interacted with your expert after a threashold has been exceeded
3. Your expert has prescribed Levofloxacin to you

The Stormy Present

The dogmas of the quiet past, are inadequate to the stormy present. The occasion is piled high with difficulty, and we must rise -- with the occasion. As our case is new, so we must think anew, and act anew. We must disenthrall ourselves, and then we shall save our country. That passage was read by Abraham Lincoln in 1862.  As I read it today, I couldn't help but think of a parallel.  I hear of projects struggling and hear people complain that this is just how we've always done it...and that this is good enough.  Why don't you stop and ask yourself why?  At a time when the country and the world struggle financially, shouldn't you consider just for a moment, that the ways we used to do things may no longer be good enough?  I think if you let go of the past and keep an open mind, there is time to save your project.

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

Take the Oath

Over the last few years, I've seen more and more people get certifications (or accreditations) from PMI, Scrum Alliance, APMG, and now SAFe.  Some will demonize the organizations for offering certifications and accreditations without actually proposing anything to deal with what they perceive as a problem. I believe certifications and accreditations are only as good as the people who get them.  One component I see missing is an oath of honor.  Yes, like Kingon honor or knights of the round table honor. (oh ya, I'm a geek)

When I wanted to be a Boy Scout, I met the qualifications.  But I then took an oath.

When I wanted to be a U.S. Marine, I met the qualifications.  But I then took an oath.

When I wanted to be a Freemason, I met the qualifications. But I then took an oath (which I can't repeat)

Not to compare project managers and leaders to doctors, but they take the Hippocratic Oath!  From that, I took inspiration.  Instead of trying to save lives, we're trying to save projects.

So, here is my first shot at it.  I call it the Metis Oath.  Metis was the Titan goddess of good counsel, advise, planning, cunning, craftiness and wisdom. Let me know what you think.

Metis Oath

I swear to fulfill, to the best of my ability and judgment, this covenant:

I will respect the hard-won gains of those practitioners in whose steps I walk, and gladly share such knowledge as is mine with those who are to follow.

I will apply, for the benefit of the stakeholders, all measures [that] are required, avoiding those twin traps of overtreatment and therapeutic nihilism.

I will remember that there is art to project management and leadership as well as science, and that empathy and understanding may outweigh all other things.

I will not be ashamed to say "I know not," nor will I fail to call in my colleagues when the skills of another are needed for a project's recovery.

I will respect the privacy of my stakeholders, for their problems are not disclosed to me that the world may know. Most especially must I tread with care in matters of project success or failure. If it is given to me to save a project, all thanks. But it may also be within my power to fail a project; this awesome responsibility must be faced with great humbleness and awareness of my own frailty.

I will remember that I do not serve a budget, or a schedule, but a human being, whose success may affect the person's project and economic stability. My responsibility includes these related problems, if I am to care adequately for the project.

I will prevent waste whenever I can, for prevention is preferable to cure.

I will remember that I remain a member of society, with special obligations to all my fellow human beings, those sound of mind and body as well as the infirm.

If I do not violate this oath, may I enjoy life and art, respected while I live and remembered with affection thereafter. May I always act so as to preserve the finest traditions of my calling and may I long experience the joy of managing and leading those who seek my help.

Pomodora Relationship

I have a dirty little secret.  I have an on-again off-again love affair with the Pomodoro technique.  Though I deal with a wicked case of ADD, I seem to keep it in check, thanks in part to my Personal Kanban.  The other method I use, though I admit not as commonly, is a pomodoro timer.  When things get really bad, I break out the timer.  And ya know, things get back on track!  You'd think I would learn. If you find yourself reading this blog, you'll find that I'm a proponent of  using simple techniques to get things done.  If you're looking for me to do a deep dive on policy, process, and procedure, you're in the wrong place.

So, how do I get some of my work done?  [1] I limit my work in progress (WIP) and [2] I limit my time (timebox). When I do both, I tend to stay focused and deliver more. The pomodoro technique, like other techniques I like, is pretty darned simple.

So, let's talk about my Piggy Pomodoro!

1. Choose a task to be accomplished
2. Set the Pomodoro to 25 minutes (the Pomodoro is the timer)
3. Work on the task until the Pomodoro rings, annotate the task you were working on
4. Take a short break (I take 5 minutes)
5. Every 4 Pomodoros take a longer break (I take 10 minutes)

As part of this process, I'm moving tasks on my Kanban from Backlog to Work in Progress.  If I take a break, I move it to Blocked.  When I return, I move it back to Work in Progress.  This allows me to visualize what I'm working on and know what I was working on before my break.

Have a Kanban or Pomodoro story?  I would love to hear it.

Why do I use a Piggy, you ask?  Because tomatoes give me gas and Chickens would just be wrong.

Image:  Amazon

The Cave of Zombies

The “Allegory of the Cave” by Plato represents an extended metaphor that is to contrast the way in which we perceive and believe is reality. Plato said what we see are actually imperfect “reflections” of the ultimate Forms, which represent reality and truth.  In his story, there is a cave in which prisoners are chained down and forced to look at the front wall of the cave.  Behind the prisoners is a fire and puppeteers, casting shadows on the wall in which the prisoners perceive as reality.  Being you and I know there are puppeteers, we know the shadows the prisoners are seeing are not reality.  But, it's their reality, none the less. Once a prisoner is released, he is forced to look at the fire and objects that once provided his perception of reality.  Only then does he realize these new images in front of him are now the accepted forms of reality. Plato described the vision of the real truth to be “aching” to the eyes of the prisoners. He added they would naturally want to go back to the cave and look at what they had always seen as a pleasant and painless acceptance of truth.

Once a prisoner climbs out of the cave and is fully immersed in the rays of the sun, the prisoner would suffer bewilderment, fear, and blindness to the objects he was now being told were real. The natural reaction of the prisoner would be to recognize shadows and reflections. After his eyes adjust to the sunlight, he begins to see things as they really are.

Plato's allegory made me think about zombies. Oh hell, what doesn't!?

We're not just prisoners in a cave, we're zombies.  Those who have left the cave come to visit once in a while.  They may complain that the food outside isn't as good.  But, they've taken the uncomfortable step of leaving the cave and merely want you to eat something other than brains.  If you are a zombie still in the cave, the other zombies are going to tell you to just eat more brains.

It doesn't matter what kind of zombie you are.  If someone offers to expand your reality with ideas foreign to your own, don't be so negative.  Don't just dismiss them. Don't eat more brains.

Like the image?  Find them at Pictofigo