PMI-ACP Numbers So Far

Tomorrow, the June 2012 edition of PMI Today will be formally available.  Before that happens, I wanted to give a progress report on the PMI Agile Certified Practitioner numbers.  Since the certification was launched back in January, the number of certification holders has grown from 542 to 758.  Though this may be perceived as a slow start for number of people holding the credential, it has already surpassed the PMI-SP and will surpass the PgMP next month.  Let's not forget, these certifications have been out for a few years, not a few months.  I'm not trying to minimize the value these certifications hold.  Rather, I believe the Agile community is responsible for the ACP number reaching these milestones as quickly as they have. Based on informal polling of learners from my classes, people are taking the exam within two months of taking a class.  Though I don't expect to see the certification rates to rival the PMP any time in the near future, I'm excited to see an upward trend in the ACP adoption rate.

Data Source: PMI Today

Agile Project Leader Job

Some Just Don't Get It

I've seen way too many job postings in the last year, asking for Agile Project Managers.  These postings are basically Project Manager positions with some Agile language thrown into the mix.  It's actually quite frustrating to read them.  I just shake my head and know that they just don't get it.  If asked if an agilist should apply for the job, I would say run as fast as you can in the other direction.  Today, I was sent a link to the job posting below.  I just happen to know the hiring manager.  After reading it, I nodded and murmured "she gets it".

 She Gets it

So many times, Human Resources writes up these job advertisements.  They don't have a clue as to what they are writing.  They don't realize how contradictory the titles and essential duties and responsibilities can be.  As Agile coaches and trainers, I wonder if we sometimes are ignoring teams who could really use our help. I'm talking about an HR department.  Wouldn't it be nice to be able to give them some insights into what businesses need rather then what they advertise for?  I've read ads for Agile Project Leaders and in the next sentence saw responsibilities that included maintaining Gantt charts, controlling scope, budget, and schedule.

I want to thank the person who wrote the ad below.  Again, she gets it!  As a result, I believe she will get more qualified applicants for this job who can help her business deliver value.

Agile Project Leader Valpak Largo, FL, United States Full-Time

Summary:Leadership of technology-focused projects and teams relying on Agile values and principles.  This position assumes the role of ScrumMaster, Kanban Lead, and/or Project Manager depending on the work at hand. The focus of this position is on delivering value over meeting constraints, leading the team over managing tasks, and adapting to change over conforming to plans. Essential Duties and Responsibilities: In the Project Manager role, leads complex initiatives across multiple functions and teams by planning, directing, and coordinating to the project objectives with consideration for risk. In the ScrumMaster role, facilitates the Scrum process of planning, daily stand-ups, reviews, and retrospectives with team and Product Owner and proactively removes impediments to progress. In the Kanban Lead role, facilitates the Kanban process with team and stakeholders and proactively removes impediments to progress. Leads and contributes to the decision making process and facilitates conflict resolution. Embraces, coaches, and evangelizes Agile values and principles across the organization and in the community. Defines and refines Agile metrics to understand team performance. Works with management and other Agile Project Leaders to continually identify and implement organization-wide process improvements Performs related work and additional duties as needed or required.

Image Source: Pictofigo

What is Agile, anyway?

The parable

Ever heard the story about the blind men and an elephant?  In various versions of the tale, a group of blind men touch an elephant. Each man feels a different part, but only one part, such as the leg, the tail, or the trunk.  They then compare notes and learn that they are in complete disagreement.

Agile, my friends, is an elephant.

The first blind man

I just completed an initial engagement with a client, for LitheSpeed.  Some of the people I interacted with were newly minted Certified ScrumMasters, some experienced developers, and some executive management.  In the mix, I met UX designers, architects, and more functional roles than this blog post should list.  The catalyst of this post happened on the first day of the engagement.  To set the stage, the organization was very clear the team is to "do" Scrum.  Due to user stories not being quite ready, the team pushed back at Sprint Planning and refused to estimate or commit to the work to be done.  I recommended the group visualize the workflow and maturation of user stories by way of a Kanban. I've made this recommendation before and it worked out quite well.  The response from one of the newly minted ScrumMasters was, "That sounds like waterfall!"  When I corrected him, confirming that it was not a waterfall approach,  he came back with an even better response.  "Well, it's not Scrum.  If it's not Scrum, it's not Agile".

If it's not Scrum, it's not Agile

A few days ago, I read a really great post by Joel Bancroft-Connors titled A Gorilla Primer: What the heck is Agile? Maybe this question is more common than I initially thought!  What I liked about Joel's post was it exposed the fact that Agile is different for so many people.  When asked what Agile is, I tend answer the question with a question.  Are you being Agile or doing Agile?  If you are being Agile, then how?  If you are doing Agile, then how?  Before I even attempt to answer the question, I want to know your perspective.  Why?  Because as with the parable and also reality, it's going to depend on your touch points.

Go read Joel's post.  I think you'll enjoy it.  When you're done, I'm sure you'll agree that if it's not Scrum, it can still be Agile.

Image Source: Pictofigo (Go get one. They're free)

Hawthorne Effect Coaching Dilemma

The Hawthorne Effect is something I wrote about over a year ago.  Previously as a Project Management Adviser and now as an Enterprise Agile Coach, I've seen it numerous times.  To all those currently advising or coaching, do you tend to see clients trying to impress you? The Hawthorne Effect refers to the tendency of some people to modify their behavior, when they know they are being watched, due to the attention they are receiving from researchers, auditors, or coaches.

This effect was first discovered and named by researchers at Harvard University who were studying the relationship between productivity and work environment. Researchers conducted these experiments at the Hawthorne Works plant of Western Electric. The study was originally commissioned to determine if increasing or decreasing the amount of light workers received increased or decreased worker productivity. The researchers found that productivity temporarily increased, regardless if the light was increased or decreases. They then realized the increase in productivity was due to the attention given the workers by the research team and not because of changes to the experimental variable.  (Thanks Wikipedia)

This is one reason short term engagements can be challenging.  People are on their best behavior, until they get used to you being there.  This is also why I don't believe in annual reviews.  How do you, as managers, leaders, coaches, or auditors get past the effect?  How do you ensure you get a true representation of individual and team behavior and not suffer from the Hawthorne Effect?

Image Source: Pictofigo

Epics, User Stories and Tasks

I was working with a client this last week and I overheard one team member trying to explain the difference between Epics, User Stories, and Tasks.  He finally offered an analogy.

The Analogy

Epics are to User Stories are to Tasks as Rocks are to Pebbles are to Sand.

I thought it was a clever description of comparing relative size and complexity of work. But would it pass muster with the Agile Community? I figured I would send it out to the Twitter-verse and see if any conversations would result.

The result was an excellent conversation with David Koontz.

The Conversation

Though I will admit there are some challenges in communicating in 140 characters or less, it really forced me to think about what I was trying to say.  David did a really great job of challenging me to explain what I was thinking.  In tweet responses, David stated if it can fit in a Sprint, he calls it a User Story.  If it is too big to fit in a Sprint, it is called an Epic.  I have to say, if we all followed that model, it certainly would simplify things.

I find customers asking if they can call them sub-stories, major stories, and craziness like that. Customers take a stab at breaking down work to manageable chunks but when the team estimates the work, it's still too big to fit into a sprint.  To restate David's identifying criteria, too big equals epic; small enough equals user story.

David then asked me,

does Epic == collection of stories? Or some stories and some waste we should never do?

My response was,

I believe epic != collection of stories. I believe epic == placeholder of a goal or idea. Stories may result but no guarantee

The Clarification

To clarify my beliefs, I believe a User Story as merely a placeholder for a conversation.  I believe an Epic is a placeholder for a goal or an idea.  Along the way, there will be resulting value delivered and waste.

Though you should be able to map all of your User Stories (and waste) back to Epics, that's not the goal.  You don't just do tasks and then look for a bucket of stories or epics to group your efforts.

I won't say having something small enough to fit in a Sprint is automatically called a User Story.  What if you don't leverage Scrum?  What if you are leveraging Kanban?  In either case, we refer back to the conversations.  As long as your work meets your definition of Ready, I don't care what you call it.

Thank you, David, for an excellent conversation.  I hope others will join in.

Free Agile PDU List

I was juggling some ideas on how I could list some free "Agile" PMI-ACP or PDUs for people. I think there is a crazy amount of free resources for PMP PDUs.  Because of that, I think there needs to be more giving for the Agile contact hours or PDUs.  So, without getting too spamming and self-promoting, please feel free to list some places you know of that have free PDUs or contact hours to offer.  Make sure you list which PMI PDU category it is applicable to.  I will add them as well.  

I'm going to be a little self-promoting here.  If you would like some Category E (Volunteer Service) PDUs, come help the PMI Agile Community of Practice build and iterate the Community Guide of the ACP.  You can claim up to 45 PDUs for your efforts!

Image Source: Pictofigo

PMI Agile CoP Retrospective

Agile CoP Retro

When you think of spending a Saturday afternoon among friends and colleagues, do you picture yourself sitting in front of your computer, collaborating for three hours on a web-based tool and discussing what is working and what could work better? Well, that is exactly what a group of us did. It was time for the quarterly PMI Agile Community of Practice (CoP) retrospective. We couldn't all be in the same physical location so some of us from the community jumped online and tried to make the world (or at least our CoP) a better place.  When you look at the graphic above, you may be left scratching your head, if you are neither an Agilist nor a member of the PMI Agile CoP. If you are either, I hope you nod in recognizing the mechanism we used to interact and make our Agile Community of Practice a better place for us all to belong.

Community of Practice

You could describe us as a motley crew of discontents and zealots. You could also describe us as a passionate group of Agilists drawn together, with the hope of helping the PMI community discover the value of Agile practices and approaches.  We all hold a sense of belonging to our community.  We all believe in the altruistic sharing of knowledge, methods, stories, cases, tools, and documents.

Retrospective

Generically speaking, a retrospective meeting is held at the end of a scheduled event or time interval. With the aid of a facilitator (in this case Brian Bozzuto), a team discusses what went well and what could be improved during the next interval or prior to the next scheduled event.  The meeting is time-boxed to help ensure it doesn't just turn into an out-of-control complaining session.  When properly facilitated, you come out of the meeting with an actionable list for improvement. Though I always recommend doing retrospectives in person, actually having the retrospective takes priority. Do it wherever you can however you can.  Successful teams need to take the time to have retrospectives if they have any chance of improving what they do.

PMI Agile CoP Quarterly Retrospective

The leadership of this community recognizes that as our community grows, some things will work and some challenges will need to be overcome (zoom into the graphic to see what we thought).  One thing is for certain: with almost 14,000 members, our PMI community has a lot to offer both members and non-members.  Every minute of that Saturday afternoon was well spent.  I hope this post and the link to the Cacoo graphic provides some transparency into what we've been doing the last three months.

Source:  This post was originally written and published by me on the PMI Agile Community of Practice blog

Agile Process Posters v2.0

I am happy to announce the collaboration with Pictofigo has resulted with a new Agile Process poster. The new process poster includes product backlogs, sprint backlogs, and user stories. We have these posters in three sizes and they come in both male and female styles.  Want to hang some original artwork in your team area, while helping people understand the standard Agile process?  Check them out!