The Critical Path by Derek Huether

PMI-ACP Numbers So Far

Derek Huether — Fri, 01 Jun 2012 03:15:55 +0000

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

Retrospective Shades of Gray

Derek Huether — Wed, 30 May 2012 17:51:58 +0000

The Retrospective

I love retrospectives. It doesn’t matter if it’s an informal process that occurs naturally as team members interact or it is a formal process that occurs at the end of a meeting, an iteration, or a release. It’s an opportunity for the team and organization to make things better. It most certainly is on the minds of others today. I’ve read about the goals of a retrospective on George Dinwiddie’s blog and also retrospectives – wronger and righter on Bob Marshall’s blog.

I honestly believe we should be constantly looking for things to start doing, stop doing, do less of, do more of, or keep doing to improve the things we do. I have been a part of projects where a Lessons Learned meeting was part of the Project Closeout activities. What good is it then!? We should constantly be learning and constantly trying to make things better.

Shades of Gray

Depending on the team, I may use the four-quadrant grid, starfish retrospective diagram (or both) to capture ideas. I love the format of the four-quadrant grid, in that the team can communicate what is working, what isn’t going so well, any ah-ha moments they’ve recently had, or appreciations they would like to note for their teammates. Unfortunately, just as some organizations or teams think of writing documentation as an afterthought, I see them doing the same with retrospectives. Retrospectives are a critical component of any process. Without them taking place, you are pretty much guaranteed to make the same mistakes twice, a third time, ad nauseam.

Retrospective Starfish

When to do it

Don’t wait until the end of your current iteration, release, or project to document and improve. On a team board or flip chart, draw a circle. Segment the circle into five quadrants: Stop Doing, Do Less, Keep Doing, Do More, Start Doing. Please note that these are merely recommendations. The content and order are not retrospective commandments. Have a stack of Post-It notes and a Sharpie nearby. Encourage the team to add notes to the board when the mood or event strikes them. Don’t wait!

If you struggle to get cards on a regular basis, perhaps a facilitated retrospective is in order. The act of collecting ideas is not just to make people feel better. Notes captured on this board are all candidates for conversion to action items. If you have the fortunate problem of having too many ideas on the board, use a concensus strategy like fist of five or dot voting to identify the most valuable action items.

Keep Doing (=): Capture good things that are happening. As a facilitator, ask the team what they would miss if something was taken away from them.

Do Less (<): Anything that might need a bit more refining or that is simply waste. Is there something that adds value but not as much as something else could?

Do More (>): Are there value-add activities the team may want to try more of but are not necessarily taking full advantage of?

Stop Doing (-): What are some things that are not very helpful or not adding much value? My prime target is long formal meetings.

Start Doing (+): Suggest new things! You read or heard about something that helped others like you. What do you have to lose?

Agile Project Leader Job

Derek Huether — Fri, 25 May 2012 02:22:02 +0000

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?

Derek Huether — Thu, 17 May 2012 19:00:05 +0000

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

Derek Huether — Fri, 11 May 2012 15:21:46 +0000

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