Never Break The Chain

With an ongoing quest to be as productive as possible and continue forming good habits, I decided to test a new strategy this last week. It's called “never break the chain”. 

Years ago, comedian Jerry Seinfeld shared the biggest secret of his continued success. When Seinfeld was a new television show, Jerry Seinfeld was still a touring comic. He said the way to be a better comic was to create better jokes and the way to create better jokes was to write every day. Specifically, each January, he hangs a year-at-a-glance calendar on a prominent wall of his office, and for every day that he writes new material, he gets to mark a big “X” over that date. After a few days, a chain of Xs begins to form. The goal is to NOT break the chain, and write every single day.

Keep at it and the chain grows longer every day. You'll like seeing that chain, especially when it stretches past a few weeks.  Your only job next is to not break the chain.

The goal of writing every day for a year, in the case of Jerry Seinfeld, sound impossible. But, if you can just focus on the single daily goal of "write something today", it becomes much more attainable.  

Not only does this approach program the body and mind to do something daily, it also motivates you to continue that long string of Xs. If you don't do your goal one day, you don't get to draw the X.  That pressure could be just enough to keep you going.

It doesn't particularly matter what your goal is. It can be anything, as long as you're actively and routinely pushing yourself.  Daily action builds habits. It gives you practice and will make you an expert in a short time. If you don't break the chain, you'll start to spot opportunities you otherwise wouldn't. Small improvements accumulate into large improvements rapidly because daily action capitalizes on previous improvements.

As I noted in a previous blog post, to be productive you need 3 things: A system, ritual, and habit.

System: Never Break The Chain
Ritual: Mark X on calendar for every day you accomplish your task
Habit: Complete your task every day without breaking the chain

Protective Collaboration

I was recently asked my opinion about collaboration within an organization.  Being I just completed an organizational assessment for a client, I have a fresh perspective of the topic. I was specifically asked:

"Is it healthy for Scrum teams to work in a bubble protected from the business around them? Should collaboration go beyond the team?"

There are two common threads that I see time and time again. One, what is the goal? Two, is that goal communicated?  Until these two threads are tied together, you can't have good collaboration.  I don't see this being unique to the world of Scrum.  To help illustrate my point, I'll try to use terms people outside the Scrum community can understand.

Strategic Mission (Goals)

Executive Leadership, in order to lead, needs to communicate the strategic vision of the organization.  Strategic vision translates into strategic mission or long-term goals. Strategic mission should be understood by the entire organization.  If you don't know the mission, how will you be able to help the organization reach its goals?  From there, the leadership needs to empower people tasked to do the work to figure out how they will accomplish the goals.

Tactical Mission (Goals)

This is where you keep lines of communication open but insert a protective buffer.  If you're leveraging Scrum, that first buffer is called a Product Owner.  This person understands the strategic mission of the organization and is able to translate it into tactical mission.  You could also refer to this person as an organizational liaison.  This person or group of people don't need to know all of the answers.  But, they do need to be readily available to answer questions from the team and to reach out to the appropriation organizational subject matter expert(s) when necessary.  The second buffer, when leveraging Scrum, is called the ScrumMaster.  If not leveraging Scrum, they could also be known as a process manager.  This person understands organizational process on a team level and is there to ensure the team consistently follows that process.  They also work to keep those who do not aid in tactical execution from derailing the team from getting work down.

Collaborative Team

It's time for me to answer the first direct question. Is it healthy for Scrum teams to work in a bubble protected from the business around them?  Though I do believe the team should be protected from the business directly trying to change their tactical priorities, you should never operate in a vacuum. If people from within the organization do try to change team short-term priorities, the process manager (ScrumMaster) should be right there to impress upon them the needs of the organization and to respect the agreed upon processes.

Collaborative Organization

The second question was, should collaboration go beyond the team? My short answer is, yes.  Communications is different from collaboration and it needs to flow up and down the organization.  With information flowing freely, I've seen good (strategic) ideas become bad ideas overnight.  All it might take is one executive standing in the back of the room during a daily (stand-up) meeting.  Once the appropriate information is presented to the appropriate people, real collaboration can take place.  The entire organization, which includes all cost and profit centers, needs to collaborate to discover the best solutions and work toward common goals.

What do you think?

Did I miss anything?

The Larger Goal

One of the things I find really interesting, when working within different organizations, is how everyone feels they are the true center of the universe.  If they are in Security, they see things one way.  If they are in Program Control, they see it another.  Regardless of the silo, plug in the functional area name and there will be different processes to follow.  They each have a different agenda that motivates them.  Even those considered as project/program overhead (Human Resources) will have their own way of doing things. Do I see something wrong with this scenario?

Do I think the organization could deliver more value if it were more goal driven and less process driven?

The answers? Yes and Yes

What's missing?  I think it's knowing where within the organization structure everyone is and how each can work together to reach the larger goals.

The larger the institution or project, commonly, the larger the bureaucracy that accompanies it.  We have our Executive bureaucracies, Director bureaucracies, and Manager bureaucracies.  Each step down the organizational chart, there is layer upon layer of bureaucracy.  Rather than the people at the top thinking more strategic and people toward the bottom thinking more tactical, there are just different shades of bureaucracy.  And you think that's bad, each (functional) branch of the organization has its own bureaucracy.

Commonly, people become too focused on their key subject matter in their functional area and forget the goals of the project or organization.   I see motivations shift to support the process itself instead of the product or service to be delivered.  When asked to do something that may directly apply to the highest goals of the organization, like "Deliver the product to the customer by this date", they act like their individual job is more important than getting the overall job done.  Instead of asking themselves what they can do to help the organization be successful, they may instead argue some point about how you didn't submit the request in the correct format, to the correct person, at the correct time.

But this post is not about being pessimistic about bureaucracies.  I'm not saying we don't need structure or processes.  This short story helps articulate what I'm trying to explain.

Perhaps you have heard the story of Christopher Wren, one of the greatest of English architects, who walked one day unrecognized among the men who were at work upon the building of St. Paul's cathedral in London which he had designed. "What are you doing?" he inquired of one of the workmen, and the man replied, "I am cutting a piece of stone." As he went on he put the same question to another man, and the man replied, "I am earning five shillings twopence a day." And to a third man he addressed the same inquiry and the man answered, "I am helping Sir Christopher Wren build a beautiful cathedral." That man had vision. He could see beyond the cutting of the stone, beyond the earning of his daily wage, to the creation of a work of art- the building of a great cathedral.

And in your organization or on your project, it is important for you to strive to attain a vision of the larger goal.

Like the images?  Find them 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

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.

Ask Derek - Required Experience to take the PMP

I'm always looking for ways to help others in their quests to be better project managers.  It doesn't matter if it's about getting the PMP® certification, getting PDUs, or even finding good tools to make a given task easier.  I field questions from both emails and Twitter.  Today I read an email that was not unlike others I've answered directly.  But, I thought others would benefit if I answered publicly.  Here is the content of the email:

I read your article about how the PMP certification is commercialized and an example of a PMP holder hiding behind the credential.  I want to become a good IT Project Manager.  I read the requirements to become a PMP. According to requirements, a person needs 3 years exp before attempting this test. My question is, how can I get exp without a certificate or who would give me a job to get the exp as a project manager and thereby attempt my PMP certification.  Can you please help me set my goals in an orderly fashion so I can ultimately become a good Manager?

Does this sound familiar? It's kind of like the chicken and the egg.  First, I would like to say the person asking the question made a statement that resonated with me.  I want to become a good IT Project Manager. I really want to help because if they wrote that, they are half way there.  Let's be clear.  You don't need to have a PMP to be a good PM. I know very gifted people who do not possess the credential.  I would be a liar if I did not believe the deck is stacked against them.  Companies have bought into the idea that good PMs have PMPs.  But I digress.  Back to the question at hand.

It can be a challenge to become a project manager, if you have no experience.  If you have ever lead a team or managed a task, you have more experience than you give yourself credit for.  PMI will recognize that.  Remember, the PMP is not a test about something you are learning.  The PMP is an exam about what you should already know and do, but categorized within the framework of the PMBOK.  Let's say you're a QA Engineer.  I bet you have a lot of experience in the Monitoring & Controlling Process Group and specifically in the Project Quality Management knowledge area.  Document your experience around what you know and do.

In order to qualify to take the PMP exam, you do need to have experience in all 5 Process Groups (Initiating, Planning, Executing, Monitoring & Controlling, and Closing).  Honestly, you could have 99.9% of your experience in one process group and 1 hour in each of the remaining 4.  PMI doesn't care.  You just need to document that you have experience in all.  If you want to be a good PM, I would recommend you get exposure to each of the progress groups. Fewer things are as bad as a PM who does not empathize with all of the functional areas or have experience in the different phases of the project lifecycle.

On a practical note, I recommend you engage others in other functional areas of your current project(s).  Offer to help them in some way.  Don't go in with an ulterior motive.  Honestly, help someone and you'll get the experience you need as a byproduct.  The PMP should be for someone with overall experience. However, I do know managers in specific functional areas who also hold the credential.  I would recommend, if you want to be a good manager, to become educated through practical experiences and not solely through academia.  You can learn just so much from a book.

Did I answer the question?  Is it a good start?

Please post some comments and let me know.

Best April Fools Day Ever

On April 1, 1988, I graduated from Marine Corps boot camp.  To this day, the sights and sounds of MCRD San Diego are still vividly fresh in my head.  I joined the Marines on November 24, 1987.  One month into training, I broke my foot and was sequentially diagnosed with pneumonia (nobody said boot camp was easy).  I found myself with the decision of being discharged from the Marines or continue training after my injuries had healed.  It wasn't an easy decision. After being discharged from the hospital, I could go back to my old life (leave the Marines).  The other choice was to be sent to a medical rehabilitation platoon (MRP).  MRP is a kind of Purgatory for Marine Corps recruits.  In boot camp, your world revolves around a 12-week countdown calendar.  Every day you'd look to your fellow recruits and say "n days to a wake up".  That meant waking up from the living hell of boot camp.  If you go to MRP, you don't get any closer to day 0, until you're back in a training platoon.  I chose to go to MRP.  There I waited for almost 2 months.

I cycled back to a training platoon and my countdown restarted.  My new day 0 was set for April 1.  The day April 1 arrived, I actually thought graduating was going to be a big April Fools joke on me.  There were so many psychological games, anything was possible.   I thought for certain the Drill Instructors were going to swarm me, while in formation, and send me back to "the classroom" (a place of figurative mental and physical torture).  OK, maybe a little physical torture but that's the way the Marines were back then.  Well, they didn't swarm on me.  I graduated from Boot Camp.  I entered the Fleet as a "boot" private.

So, what's the moral of this story?  Sometime in your life, you may reach a fork in the road.  The easier path, though very attractive tactically, may not be your best decision strategically.  This critical event in my life made me the pain-in-the-ass person I am today.  Nothing, and I mean nothing, has come remotely close to the physical and psychological challenges of Marine Corps Boot Camp.  It doesn't matter if you're a project manager, an entrepreneur, or just trying to reach a personal goal.  Anything is possible if you're focused enough on the outcome.  Anything is possible if you have passion, commitment, and skill.

Graphic courtesy of Leatherneck

GQM: If you can not measure it, you can not improve it

In trying to determine what to measure in order to achieve the goals of a project, a Goal-Question-Metric (GQM) paradigm should be used.  It can actually be applied to all life-cycle products, processes, and resources.  The GQM paradigm is based on the theory that all measurement should be [1]goal-oriented i.e., there has to be some rationale and need for collecting measurements, rather than collecting for the sake of collecting. Each metric collected is stated in terms of the major goals of the project or program. [2] Questions are then derived from the goals and help to refine, articulate, and determine if the goals can be achieved. [3] The metrics or measurements that are collected are then used to answer the questions in a quantifiable manner.

Image based on Basili, Caldiera, and Rombach "The Goal Question Metric Approach", 1990

Here is an example of the GQM in action:

Goal 1 (use this 4-step process to shape a goal) [1] Purpose [2] Issue [3] Object (process) [4] Viewpoint

Goal 1 [1] Maintain [2] a maximum level of [3] customer satisfaction [4] from the Help Desk user’s viewpoint

Question 1 What is the current help desk ticket trend?

Metric 1, 2, 3, 4 Number of help desk tickets closed Number of new help desk tickets % tickets outside of the upper limit Subjective rating of satisfaction

As the great Lord Kelvin once said, "If you can not measure it, you can not improve it."