4squareviews

In John Stenbeck’s book “PMI-ACP and Certified Scrum Professional Exam Prep and Desk Reference”, he creates an Agile Project Management Process Grid containing 87 processes divided into 5 Process Groups and 7 knowledge areas.

Here are the five process groups in Traditional and Agile PM.

Notice how the Initiating, Planning, and Closing are the same between the three (using the normal verb form in Agile rather than gerund or noun form used in Traditional).   Monitoring & Controlling is shortened to Control, and then Executing is replaced by Iterate.    In reality traditional PM also goes back and forth between Executing (doing the project work) and Monitoring & Controlling (checking the project work), but this “back and forth” pattern is emphasized in Agile with the word “Iterate”.   So far so good; these two sets of process groups correlate pretty clearly.    Now let’s go on to the knowledge areas.

Note that this is just the order that the knowledge areas are listed in.    There are 10 knowledge areas for Traditional PM, and 7 knowledge areas for Agile.     How do these knowledge areas correlate?     Well, here’s my best attempt to put those knowledge areas in Traditional PM next to their Agile counterparts.

The Risk Management area in Agile PM covers the same ground as in Traditional PM.

Here are the three processes in agile Risk Management that fall under the Initiate Process Group:

• Process 5.1–Organizational Practices
• Process 5.2–Regulatory Discovery
• Process 5.3–Quality Standards

Why are these in the Initiate Process Group?   Because they are risk factors that exist prior to the existence of the project.    In traditional PM, the inputs to risk management that come from inside or outside the organization regardless of the contents of the project are referred to as Enterprise Environmental Factors.   They are environmental factors because they come from practices and standards that exist in the environment in which the project takes place.    They are enterprise factors because they are not peculiar to the project itself, but exist at the level of the enterprise.

The next three posts will cover these three processes to show how Risk Management can be started even before the start of planning for an agile project.

Filed under: Uncategorized | 1 Comment »

Back in May 2011, Shawn Achor, a psychologist who is the CEO of Good Think, Inc., gave a talk about positive psychology at a TED talk  in May 2011.   I outline his talk below which he concludes with a methodology on how to press the “reset” button for your mindset so that you are more optimistic.    One of the methods includes writing three things you are grateful for, so I thought it would be appropriate to repost this on Thanksgiving Day.   I have some additional information on how not just psychology, but neuroscience also proves that gratitude gives you a positive mental advantage.

1. Escaping the law of the average

Social scientists make pronouncements about trends based on averages within populations, but people have to realize that when you are dealing with the potential for individual happiness or creativity, you need to escape the “law of the average”. When psychologists strive to make people “normal”, then if they succeed, people will continue to remain merely average.

I can illustrate Shawn Achor’s point with a story.  A friend of mine who was taking economics in graduate school, and I saw him one day in a coffee shop looking a little glum. “What’s wrong?” I asked him. “Oh, it sounds silly, but I’m a little bummed. My statistics professor said that up to 50% of us in the class would end up doing below average on the test.”

Intellectually, he knew that this was of course true because it hinges on the technical definition of the word “average”. However, it was the implication that he had only a 1 out of 2 chance of escaping mediocrity that was a challenge to his self-esteem.

2. Studying outliers

Shawn Achor has studied those individuals who have higher than average potential to find out what their secret is in order to be see if some of those secrets can be passed on to the rest.  Instead of a psychology model that tries to drag everybody down towards being average by making them “normal”, he wants to have a positive psychology model that moves everyone’s average up.

3. Changing the lens

We view the world through the lens of the media, which selectively captures negative events and brings them to our attention, with the news hour occasionally ending in a positive story. This has an effect on us where we start to assume a false picture of the world where that same ratio of negative events to positive events is replicated throughout the world.

4. External circumstance does not determine inner attitude

Shawn Achor related how the students he counseled at Harvard University should have been happy to be at such an elite school, but they sought counseling because they concentrated on the negatives of the workload, peer pressure, etc. He realized that no matter how good the outer circumstances, there were some people who have a negative attitude internally. He found that the external circumstances only account for 10% of a person’s happiness over the long term; the other 90% are determined by the way in which that person views the world.

In the work environment, he found that only 25% of job successes are predicted by a person’s intelligence level. The other 75% are accounted for by your optimism levels, your social support levels, and your ability to see stress as a challenge rather than as a threat.

5. How can you change your mindset?   A gratitude journal!
Here’s the kernel of what Shawn Achor came to talk about. Most schools and workplaces have the mindset “if you work hard, you will be successful. If you are successful, then you will be happier.”  This theory of motivation is backwards.  If you have a success, then the workplace or school simply changes the goalposts and you have to achieve even better success the next time. If happiness is thought to be on the other side of success, your brain never gets there, it pushes happiness over the cognitive horizon.   Just remember that one of the definitions of a horizon is “an imaginary line that gets farther away from you the closer you get to it.”

The problem with this method of motivation is that our brains work in the opposite order:  if you raise a person’s happiness in the present, then their brain experiences a happiness advantage, meaning that performs better than if it is negative, neutral, or stressed.  Every business outcome improves for an employee who has this happiness advantage: people are 31% more productive, they produce 37% more sales, doctors are 19% more accurate at diagnosis, etc.  So if our brain is more positive in the present, than it becomes more successful.

If people do the following 21 days in a row, it can rewire their brains to be more optimistic and therefore more successful.

6.  Why does the Gratitude Journal method work?

Here Shawn gives an explanation of these 5 factors; I have added a sixth factor which I explain below.

1. Writing down the 3 items for which you feel gratitude changes you mind so that it starts scanning the world for the positives rather than the negatives. It doesn’t change the ratio of positives to negatives in the outside world, but it does change which factors you focus on as being the most significant.
2. Writing about a positive experience you’ve had in the past 24 hours allows you relive it.
3. Exercise teaches your brain that behavior matters
4. Meditation allows you to detach from the cultural pattern of ADHD which we are creating through the constant attempts at multitasking, and increases the ability of the brain to focus on the task at hand.
5. You can write in your journal about a random act of kindness which you performed in the last 24 hours for someone, meaning that you did it without consideration of being paid back by the person whom you helped.  Alternately, perform a conscious act of kindness by sending a note of support to someone in your social support network.
6. To these activities, I have added a sixth of my own to Shawn’s list, which is to take a negative experience which you had in the past 24 hours, and created some lessons learned from it so that you will experience it in the future not as a threat, but as an opportunity to overcome a challenge.
   

I have to tell you that Shawn Achor’s method WORKS! I did try it for 21 days and found that I do see live in a more positive way than I did a month ago. The interesting thing for me was that, at first I thought I was just changing the way things were appearing for me, that is, the same ratio of negatives to positives happened out there in the external world, but I was gradually starting to focus on the positives.  The negatives were seen as less and less threatening and more and more as opportunities.

However, by the end of the 21-day period, I was starting to experience more and more positives on the outside.  I think that the positive attitude I took with me while networking, for example, automatically drew people towards me and made them more helpful to me than they would have previously precisely BECAUSE I had a positive attitude.  So it does change your interior “weather” first, but that sunnier internal weather will gradually become reflected in your exterior circumstances.  I don’t know if it will work for everybody, but I recommend that you at least try it, because you have literally nothing to lose, and we could all stand to win a little more, right?

7.  The Neuroscience of Gratitude

In an article written by Ocean Robbins back in October 2013 in a blog called “The Neuroscience of Why Gratitude Makes Us Healthier,” there is additional evidence from neuroscientists that keeping a gratitude journal helps keep people happier than the control group that did not keep such a j0urnal.   Even those people who kept a journal simply describing their lives did not do as well as those who kept a journal to describe things they were grateful for.

Robert A. Emmons, Ph.D., at the University of California at Davis and his colleague Mike McCullough at the University of Miami found that  the gratitude journal group felt better about their lives as a whole and were a full 25 percent happier than the control group.

8.   The Limits of Gratitude

Of course,  I have to caution people against thinking that the gratitude journal alone will be enough to change someone’s brain chemistry if person is clinically depressed.   Stephen Fry, in describing his struggle with bipolar disorder (what used to be called manic depression), said that when you are in the “depressed” part of the cycle, it doesn’t matter how good the internal weather should be, you find yourself living under a metaphorical cloud.    For people whose brain chemistry has severe challenges, just having a gratitude journal will not be enough–you will need professional guidance and medication to alter your brain chemistry to the point where you can live a productive life.

However, for those with “situational depression”, that is, a temporary state of hopelessness or helplessness brought about by traumatic circumstances, and not any particular imbalance in the brain itself, the gratitude journal can lessen the amount of time it can take to snap out of it.

9.  Summary

Gratitude is a feeling that lends itself to a) mindfulness, because you don’t take the blessings of everyday life, both large and small, for granted, and b) a sense of connection, because you realize that your true happiness  comes not from your material possessions, but your wealth in human connections.   This is no more evident than on a holiday like today, on Thanksgiving Day.    So why not make EVERY day Thanksgiving Day?   Get a journal and give yourself the Gratitude Journal Advantage!

Filed under: Uncategorized | Leave a comment »

In the book “PMI-ACP Exam Prep PLUS Desk Reference”, John Stenbeck created an Agile PM Processes Grid, which has 87 Agile PM Processes divided up between the 5 process groups and 7 knowledge areas.

In this series of posts, I am covering the last of three processes in the block of processes that comprise the first process group “Initiate” and the fourth knowledge area, “Team Performance,” which corresponds roughly to the “Human Resources Management” knowledge area in traditional PM.

The last process in this block is process 4.3 Emotional Intelligence.

Elements of Emotional Intelligence

As opposed to the “hard” or “technical” skills one must master to be a project manager, the “soft” skills that deal with managing people rather than projects can be characterized as follows:

• self-awareness
• self-regulation (discipline)
• motivation (both self-motivation and the ability to motivate others)
• empathy
• social skills (being able to project confidence, etc.)

Projecting these qualities to team members can’t help but rub off on most them.   However, team members must also treat each other in a way that supports appropriate responses and discourages appropriate responses.   For example, when brainstorming, having an “open mode” frame of mind is important, and belittling someone’s idea discourages that person from ever giving their opinion again.   So this is where ground rules can be helpful.

Ground Rules

Setting ground rules is important on a traditional project as well.   However, rather than you, as the project manager telling everybody what the ground rules are and expecting the team to obey them, in the more cooperative environment of an agile project, the team discuss and define them, and then these rules are posted in a prominent place where people will see them on a regular basis.   This has the affect of making everybody accountable and therefore self-discipline keeps everybody in check rather than some external threat of punishment or hope of a reward.

Two important ground rules are 1) attack problems, not people, and 2) the point of power is in the present, not what people did in the past.   If egos are taken off line, then conflict between alternatives becomes a healthy, and not a toxic, process.

The next post will discuss how the knowledge area of Risk Management is handled in the Initiate phase of an agile project.

Filed under: Uncategorized | Leave a comment »

This past Wednesday it was Veterans Day here in the United States, and that got me thinking about the program I volunteered for at the Chicagoland chapter of the Project Management Institute in conjunction with Black Diamond Charities that helps veterans or those who are active duty military personnel who are thinking of pursuing a career in project management

The Veterans PMP program consists of the following three phases:

1. PMP Instruction (5 weeks)
2. PMP mentoring (2 weeks)
3. PMP study group (12 weeks)

Black Diamond Charities (referred hereafter as BDC) goes to where active duty military or veterans are likely to be in the Chicagoland area, such as the Great Lakes Naval Station or the U.S. Army Reserve Training Center, and recruits those who might be interested in the program.   Once they express interest and are enrolled in the next group of candidates for the program, BDC coordinates with the Director of Social Outreach at PMI Chicagoland chapter to get volunteer instructors for the program.    I volunteered to be involved in all phases this time around.

The program started last year around this time and had about 15 participants.    The second round of the program was this summer and had about 30 participants.    The third round that started in October of this year had about 15 participants as well.

PMP Instruction

This phase gives 35 hours of general instruction in project management, and was given by a team of about half a dozen instructors, including myself.     Besides the instruction, the participants were split up into three teams of 5 people each and given the assignment of creating an idea for a project, and not only doing all of the project documents (such as the project management plan), but doing a presentation to the group on the final day of class explaining the project and showing those documents to the project sponsors.    It not only gives them the theoretical foundation through the classroom instruction, but also gives them a hands-on example of what doing a real project is like.

PMP Mentoring

This is a group mentoring session, where we ask the participants from the first phase what topics they would like to hear about more.   The instructor group then gives presentations on these topics split into 2 Saturday mornings.

PMP Study Group

For those that are serious about going on to take the exam, I run a PMP Study Group which covers one chapter of the PMBOK Guide every week.    This not only presents the material in detail, as opposed to the high-level introduction that was done in the PMP Instruction phase.    I will probably do that again this next time, although I’m thinking of doing an online WebEx webinar rather than an in-person study group like I did last time.

Today was the graduation day for the PMP Instruction, and all three groups did great presentations.    I knew they were all nervous about doing well on their presentations, and the relief in the room was palpable when they were done, as was the done they all showed in receiving that completion certificates.

Personally, I got a lot of helping the veterans and feel that my five weeks I sacrificed on their behalf can only repay a fraction of their sacrifice they have already made.    I hope to be involved in the next round of the program and hope that more volunteers from PMI Chicagoland can assist us in this very worthwhile effort!

Filed under: Uncategorized | 1 Comment »

In this series of posts, I am covering the first of three processes in the first process group “Initiate” and in the fourth knowledge area, “Team Performance,” which corresponds roughly to the “Human Resources Management” knowledge area in traditional PM.

The second process in this block is process 4.2 Servant/Adaptive Leadership.   I will discuss what agile or adaptive leadership means.   You can say that servant leadership is one of the principles behind it, but let me clear from the start that servant leadership is a principle that ALL project managers should practice, no matter what methodology is used.  However, this principle is particular important in agile methodology.

Servant Leadership–An Introduction

Once when I entered a meeting of the PMI Orange County Toastmasters Club, the Area Governor was visiting and I saw that he had on a shirt that said “Servant Leader”.   I asked him what it meant, and he said to be a leader, you have to serve the people you are leading.   Rather than the traditional management standpoint being that members exist to serve the needs of the leader, this turns that paradigm on its head and dares to say that the leader needs to serve the members.   As an Area Governor, that meant that he visited all of the clubs in his area twice a year, met with the club officers of each of these clubs, and tried to help the clubs get the resources they needed to face their challenges.

In a similar way, the leader of an agile project needs to serve not just the needs of the customer, but the needs of the team.   This approach serves a project manager well in any environment, but it is particularly useful in agile project management.

Servant Leadership

Here are the elements of servant leadership:

1. Creating an environment of personal safety–this doesn’t mean physical safety, but psychological safety, in other words, a person has to feel free to express opinions and to resolve conflicts between the different opinions of team members when that occurs.
2. Monitoring skills of team members–this doesn’t just mean skills with respect to agile project management, but technical skills and “soft skills” needed to work cohesively as a team.
3. Facilitating (not controlling) team meetings–you create ground rules to the extent that they create the environment of personal safety mentioned in element 1 above.
4. Guiding the decision-making process–this should always be based on creating the most value for the customer.
5. Removing obstacles that impede progress–this is the “scrum” aspect of leadership where you block others from tackling the person with the ball, or you get handle events or conditions that will impede the person’s path to the goal line.

The focus is not on leading the team in a direction that you have in mind; rather, it is creating the environment in which the team can decide collectively on the best direction to go in.  A lot of these principles can be applied to traditional project management as well.   j.

Agile/Adaptive Leadership

Those principles which are specifically geared towards managing agile projects can be referred to as agile or adaptive leadership principles.  Here are the elements of agile or adaptive leadership:

1. Adapting to change in the spirit of embracing it rather than avoiding it.   If there are changes to the scope that are suggested, the agile project manager needs to consult with the customer/proxy and decide a) which changes to respond to during an iteration, and b) which changes to defer until an iteration is complete.
2. Guiding the agile process outcome through adaptive actions, such as:  reducing features, adding an iteration, creating another agile team to handle part of the project, and identifying a new metric.
3. Adapting the agile framework to the work environment and the customer/proxy.   This is especially true if the customer is relatively new to the agile approach.   The agile project manager might customer its numbering schema for estimating story points, like assigning shirt sizes S, M, L, and XL to them, rather than adhering strictly to the Fibonacci sequence (1, 2, 3, 5, 8, 13, etc.).

The skillset that allows one to be a successful agile leader comes under the rubric of emotional intelligence, being skillful at the so-called “soft skills” of persuading and influencing other people.   Emotional intelligence is, therefore, considered a legitimate tool and technique of agile project management and is the subject of the next post.

Filed under: Uncategorized | Leave a comment »

In the book “PMI-ACP Exam Prep PLUS Desk Reference”, John Stenbeck created an Agile PM Processes Grid, which has 87 Agile PM Processes divided up between the 5 process groups and 7 knowledge areas.    In this series of posts, I am covering the first of three processes in the first process group “Initiate” and in the fourth knowledge area, “Team Performance,” which corresponds roughly to the “Human Resources Management” knowledge area in traditional PM.

The first process in this block is process 4.1 Coach Recruiting.   I will discuss what an agile coach is, and why you should think about getting one for your agile project.

Agile Coach

An agile coach’s mission is threefold:

1. Trainer–knowledge transfer regarding the agile framework to the team
2. Coach–applying the agile framework to the specific environment the team will encounter
3. Consultant–removing impediments that the team may face

The whole purpose of the agile coach is to facilitate teams to create change and improve delivery.   They help the team rethink their assumptions and create mental models so that the team can solve their own problems.

Internal or External Coach

When you think about an agile coach, you probably are thinking about hiring a consultant, which would be an external coach, but someone who is in the company and has reached the level of Certified Scrum Coach can act as an internal coach.  The internal coach has the advantage of knowing the corporate culture and history as well as being familiar with the team.   The external coach can bring a new perspective based on experience dealing with a variety of corporations to bring the best practices to bear on the specific environment that the team will encounter on the project.

The idea is to transfer the knowledge, to have the team apply it, and to gradually fade from the picture, only coming back into it when the team asks for advice.

The next post will cover Process 4.2 Servant/Adaptive Leadership.

Filed under: Uncategorized | Leave a comment »

In the book “PMI-ACP Exam Prep PLUS Desk Reference”, John Stenbeck created an Agile PM Processes Grid, which has 87 Agile PM Processes divided up between the 5 process groups and 7 knowledge areas.   The 5 process groups are equivalent to the 5 process groups in traditional PM:

1. Initiate
2. Plan
3. Iterate (rather than Execute)
4. Control
5. Close

The 7 knowledge areas are a little more complicated, because there is not a clear one-to-one mapping between the knowledge areas of agile PM and the 10 knowledge areas of traditional PM.   Here’s my attempt to correlate the two:

You can see it’s not a neat, one-to-one mapping as with the process groups, mainly for the reason that there are 10 knowledge areas in Traditional PM and 7 knowledge areas in Agile PM.

Let’s take the Agile knowledge areas as they appear in the original order and discuss how they correlate.

1. External Stakeholders Engagement–this obviously correlates with Stakeholder Management in Traditional PM, but notice that it is the first knowledge area rather than the last one as in Traditional PM, which shows the priority that Agile places on feedback to and from the customer throughout the entire set of Agile Processes
2. Value-Driven Delivery–This covers Scope Management in traditional PM.  In that quality is considered creating a product whose technical characteristics fulfill the functional requirements gathered from the customer, this covers the quality control portion of the Quality Management knowledge area in Traditional PM
3. Adaptive Planning–This covers the Time and Cost Management knowledge areas in Traditional PM
4. Team Performance–This covers the Human Resources Management knowledge area in Traditional PM
5. Risk Management—This covers the Risk Management knowledge area in Traditional PM
6. Communication–This covers the Communication Management knowledge area in Traditional PM
7. Continuous Improvement–This covers the quality assurance portion of the Quality Management knowledge area in Traditional PM, rather than the quality control portion which falls more under Value-Driven Delivery knowledge area in the Agile PM Processes Grid.

One additional comparison needs to be made, and that is the difference between the Agile PM Processes Grid and the domains listed by PMI that are covered by its PMI-ACP exam.   This comparison is below.

What I’ve done in the past two months of posts is go through the grid one block at a time, starting with the first process group in the grid vertically called “Initiate”, and going down horizontally through each of the 7 knowledge areas.   That’s a total then of 87 processes spread across 7 x 5 = 35 different blocks.  I’ve completed the “External Stakeholders Engagement”, “Value-Driven Delivery”, and the “Adaptive Planning” knowledge areas for the first process group, and in the next couple of posts I move on to the fourth block, the knowledge area “Team Performance”, which covers the same area as “Human Resources Management” in traditional project management.

Here are the three processes in this fourth block covering “Team Performance”:

1. Coach Recruiting
2. Servant/Adaptive Leadership
3. Emotional Intelligence

Filed under: Uncategorized | Leave a comment »

In the book “PMI-ACP Exam Prep PLUS Desk Reference”, John Stenbeck created an Agile PM Processes Grid, which has 87 Agile PM Processes divided up between the 5 process groups and 7 knowledge areas.

I just got done summarizing the first blocs of processes, those in the first process group (the Initiate process group) and the first two knowledge areas (External Stakeholders Engagement and Value-Driven Delivery).

Now, I am embarking on a description of the third block of processes, those in the first process group (the Initiate process group) and the third knowledge area (Adaptive Planning). Adaptive Planning might be better termed “Juggling the Constraints”.

I covered the first two of the four processes in this knowledge area, Process 3.1 Team Acquisition and Process 3.2 Project Kick-Off Meeting, in previous posts.  This post will cover the last two of the four processes in this knowledge area, namely Process 3.3 Incremental Delivery and Process 3.4 Timeboxing.

The first two processes in this knowledge area of agile project management share features with the tools & techniques used in traditional project management.   For example, team acquisition can be done in both agile and traditional PM through a) negotiation (with functional managers for team members within the company), b) acquisition (for team members outside of the company on a temporary basis), and pre-assignment (for team members designated as being desired on the project in the project charter itself).   And the kick-off meeting is important in both agile and traditional PM environments, although the agile version contains more emphasis on elements of team-building exercises.

With Process 3.3 Incremental Delivery and Process 3.4 Timeboxing, however, agile comes into its own.

Process 3.3 Incremental Delivery

To explain how incremental delivery works, it might be best to review the three categories of project lifecycles as set forth in Chapter 2 of the PMBOK Guide.

Project Lifecycles

1. Predictive life cycles (aka fully plan-driven) are predominant in traditional PM, where the project scope, and the time and cost required to deliver that scope, are precisely determined as early in the project life cycle as practically possible.   For the image of this, think of a series of blocks connected on a straight line, which each block representing a phase of the project.
2. Iterative life cycles are predominant in traditional PM, where the project scope is developed at a high-level in the first iteration, and the detailed scope is elaborated upon in subsequent iterations.   Sometimes this process is referred to as progressive elaboration.   A special form of this, which I personally refer to as “progressive elaboration on steroids”, is rolling wave planning, where the detailed scope of the initial phase of the project is completed and the project is started while the detailed scope of the subsequent phases are still being elaborated upon.   This is like laying the tracks of the railroad while the train is starting to come down the tracks.   Although it captures some of the flavor of the agile PM process in terms of iterations, it is still considered as part of the toolkit for traditional PM because of the assumption that eventually the scope of the project will be precisely determined.  An image that I find helpful here is a helix, which is the pathway you take around a cone that narrows to a point.  It starts out with wide circles that gradually narrow as you get closer to the point, which represents the place where the scope ends up being completely defined.
3. Incremental life cycles (aka agile or change-driven) are predominant in agile PM, and these share the feature with iterative life cycles that iterations are used.   However, the iterations are rapid (2 to 4 weeks in duration) and are fixed in time and cost.   The major shift is in mindset, because incremental life cycles are used for when there are high levels of change, when requirements and scope are difficult to define in advance.   An image that In find helpful here is a spring, which goes around and around in circles that are always the same height.   Of course the spring does end, but it is not at the point where the scope ends up being completely defined, rather it is the point at which the customer is satisfied with the value delivered at the last iteration when either the time or cost constraint has been depleted.

Incremental delivery focuses on delivering value to customers at the end of each iteration.   In order to do this, the next process 4.4 Timeboxing serves to define that iteration or timebox.   For the sake of brevity, I will use the scrum term “timebox” for “iteration” in the explanation of the next process.

Process 4.4:  Timeboxing

Here are the various elements that go into defining the timeboxes that will be used for incremental delivery to the customer.

1. Defining the length of time for each timebox–since each timebox begins and ends with specific planning and review activities, there is a specific “overhead” that is fixed at each end of the timebox.   Usually timeboxes are specified as to be 2 or 4 weeks in duration.   Having a two-week timebox gives more flexibility and opportunities for customer engagement, but essentially doubles the “planning and review” overhead for the span of the timebox as compared to a four-week timebox.
2. Defining the vision of the project–this will guide the types of work the team will be required to accomplish in each timebox
3. Defining the human resources–team members must have the right knowledge, skills, tools and processes to accomplish the work in each timebox.
4. Defining the environment–the environment is preferably collocated, but even for those members who work virtually on the project, the right tools and workspace need to be defined so that the team members can work together as a team to accomplish the work in each timebox.
5. Defining the communication protocols–communication requirements are defined so that members can transmit ideas to other members of the team transparently.   This is opposed to the “need-to-know” basis that some projects use as a guiding principle, which often translates to “if you’re on the team, you don’t need to know.”
6. Defining the high-level architectural outlines of the timeboxes–since the iterations often fit into higher-level cycles such as release plans (corresponding to project-level plans in traditional PM) and roadmaps (corresponding to program-level plans in traditional PM), you must define the architecture of the timeboxes, i.e.,  how the timeboxes fit into the larger cycles so that it deliver values to the customer incrementally AND serves the emergent design of which the iterations are a part (at the project and program level).

Because timeboxes define the work environment for the entire project, that is why so much care is given to their definition.   Just as in the same way that “ground rules” for collaboration are set up at the kick-off meeting when team members meet each other for the first time to work on the project, ground rules for the iterations or timeboxes within which they will be doing that work are also essential.

This concludes the discussion of the third knowledge area, Adaptive Planning, in the Initiate process group.  The next post will start the discussion of the fourth knowledge area, “Team Performance.”

Filed under: Uncategorized | Leave a comment »

In the book “PMI-ACP Exam Prep PLUS Desk Reference”, John Stenbeck created an Agile PM Processes Grid, which has 87 Agile PM Processes divided up between the 5 process groups and 7 knowledge areas.

I just got done summarizing the first blocs of processes, those in the first process group (the Initiate process group) and the first two knowledge areas (External Stakeholders Engagement and Value-Driven Delivery).

Now, I am embarking on a description of the third block of processes, those in the first process group (the Initiate process group) and the third knowledge area (Adaptive Planning). Adaptive Planning might be better termed “Juggling the Constraints”.

The first of the four processes in this knowledge area is Process 3.1 Team Acquisition and that was covered in the previous post.  This post will cover the second of the four processes in this knowledge area, namely Process 3.2 Project Kick-Off Meeting.

The kickoff meeting is an important meeting in both traditional and agile PM.   But agile PM emphasizes more of a hands-on approach where group exercises are used to clarify project scope, rather than just a presentation by the PM to the team as happens in more of a traditional kickoff meeting.

Here’s the key objectives of a project kickoff meeting.

1. Establish ground rules–identification of the agile framework being used and agreeing upon the ground rules for team members to behave with each other and to collaborate
2. Have the project vision presented by the customer/proxy–group exercises are used to develop the product vision box, the elevator statement (a succinct version of the vision statement), and the product data sheet (see previous blog posts for detailed explanations of all of these)
3. Review the high-level business case–every team member must understand why the project is being done, both from the customer and from the company’s point of view
4. Document the one or two dozen key features–every team member must have a clear understanding of what is being developed
5. Project setup and release and iteration planning–the top four objectives can be accomplished in two hours, after which the senior stakeholder may leave because this fifth objective may take the rest of the day.   Project setup involves identifying proof-of-concept work as well as laying out subsequent iterations.   Release and iteration planning allows the customer/proxy to make planning decisions regarding feature priority.

What happens if some team members will work remotely?   Every effort should be made to bring them in at least for the kickoff meeting.   It’s not enough to just read the meeting minutes, because again agile is not a spectator sport, it’s a hands-on activity (which is one of the reasons why Scrum is such an apt name) which requires team interaction.

The next process is incremental delivery, which is the subject of the next post.

Filed under: Uncategorized | Leave a comment »

In the book “PMI-ACP Exam Prep PLUS Desk Reference”, John Stenbeck created an Agile PM Processes Grid, which has 87 Agile PM Processes divided up between the 5 process groups and 7 knowledge areas.

I just got done summarizing the first blocs of processes, those in the first process group (the Initiate process group) and the first two knowledge areas (External Stakeholders Engagement and Value-Driven Delivery).

Now, I am embarking on a description of the third block of processes, those in the first process group (the Initiate process group) and the third knowledge area (Adaptive Planning). Adaptive Planning might be better termed “Juggling the Constraints”.

The first of the four processes in this knowledge area is Process 3.1 Team Acquisition.

The most important aspect of acquiring a team for a project using agile project management is that it must be cross-functional, meaning that each team member has to work well within his or her function or area of expertise, but also be able to translate between each function so that he or she understands the point of view of the other members of the team.

More specifically, members of the team need to have elements of the following key factors:

1. Ability–what specific competencies do they have
2. Availability–what bandwidth or, more conventionally speaking, number of hours can they commit to this particular project, and if so, until how long?    Also, can they co-locate with other members of the team for team meetings?
3. Cost–how appropriate is their cost given the budget constraint of the project?
4. Chemistry–how well do their work style preferences along with those of the other members of the team
5. Experience–what similar or related work have they done in the past?

Just as in traditional project management, there are in general three ways a team member may be acquired.

1. Pre-assignment–this is when a person’s expertise is required for the project to succeed and that expertise is in short supply.   The pre-assignment of that team member is expressed in the contract with customer.   It is called pre-assignment because it is done in the initiating process group even BEFORE planning begins.
2. Negotiation–this is when a team member is obtained from within the organization
3. Acquisition–this is when a team member is obtained from without the organization (as in a contractor)

Getting the right person in the right role at the right time, who can also work together with other people on the team, is the key to getting this critical process right in order to make the project a success.

Once you’ve got the team members acquired, forming them into a team is the next step.   One of the processes that achieves this is the project kickoff meeting, which is the subject of the next post.

Filed under: Uncategorized | Leave a comment »