The Critical Path by Derek Huether

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

Epics, User Stories and Tasks

Derek Huether — Sun, 06 May 2012 12:42:58 +0000

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.

PMI Eating its Own Dogfood

Derek Huether — Fri, 04 May 2012 23:48:18 +0000

I am happy to report that the PMI-ACP Community Guide project is off and running. Each day, I see new content being added. I wonder if this is how Jimmy Wales felt in the early days of Wikipedia. Our first measure of success is to get the content of each page of The Guide as close to the vision of the ACP Steering Committee as quickly as possible. Our second measure of success is to reach a tipping point, whereby the community (not the support team) is maintaining the guide. Remember, future versions of the ACP exam will be based on this Guide.

Community Guide

To reaffirm, there will not be an AgileBOK. The Community Guide of the PMI-ACP (login required) is an initiative of the PMI Agile Community of Practice to provide ongoing support for the PMI-ACP agile certification.

ACP Support Team

Lead by Joseph Flahiff of Whitewater Projects and myself, the ACP Support Team has kickstarted the Community Guide content creation process. We are empowered and 100% self-organized.

The Backlog

In order to deliver something of value to the community, Joseph and I leveraged the wiki within PMI’s website to create a Product Backlog. We wanted transparency and for everyone to know what we are focused on. Every major area of the ACP exam has a page waiting to be edited. If you had a traditional product backlog, the 10 major areas that comprise the Tools & Techniques of the exam could easily be considered Epics. Each page of our wiki could be compared to a User Story. We’re not estimating our work. We’re just doing it.

Iteration 1

We are currently in Iteration 1, which ends on May 10, 2012. Of our 15 member team, we asked volunteers to commit to work on the first 7 pages of the first content area. At the end of each iteration, we can ask members of the ACP steering committee to review what we have done. It’s important that we stay focused, have short feedback loops, and deliver something of value on a regular basis.

Eating the Dogfood

When you think of PMI, you probably think of project plans, schedules, and stuff like that. As a self-organized and empowered team, we decided what is important, to increase the chances of our success. Though there should be a predictable date of completion, based on the currently defined deliverables and length of the iterations, we’re prepared for things to change. We may have to rework some of the pages. We may have some team turnover. Regardless, we can guarantee we will deliver value on a regular basis. We can guarantee there is collaboration with the community.

Joining the Team

If you are interested in creating or maintaining articles for the Community Guide, join our team! If you want to work independently, we welcome your valuable contributions.

Free Agile PDU List

Derek Huether — Wed, 25 Apr 2012 15:20:04 +0000

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