On Monday, during my flight from Denver to Boston I sat next to a delightful couple who were both retired. When they asked the inevitable question about what I did for a living I told them my story of being an agile trainer and coach and the basics of agility (all in under a minute!). At that point the usual response is “Oh, thats interesting” (yeah, right), but this time I was in for a surprise.

The woman asked me a question I have never been asked after telling people what I do for a living.  She calmly looked at me and asked “Don’t the people you teach have mothers that cook?”  I thought one of two things were true at this point: 1) she was senile – high probability or 2) she hadn’t heard me correctly – low probability since she was very attentive when I was speaking.  I gave her the benefit of the doubt and went along with her question by responding, “I assume so, but why?”

Her answer was priceless.  I wish I could have quoted her exactly, but this is the best I could do to capture her words and immortalize her digitally.  She said…

Cooking has to be considered an agile process by your definition.  You certainly don’t do everything up front, then put it all together and finally find out at the end if the meal came out correctly.  That would be foolish and embarrassing more often than not!  No, instead you test each ingredient for quality as you go along.  In fact, you will do what you called building quality in by removing more items as you chopped them and determined they didn’t meet your standards!  You even “test” each dish at various points in time to see if it is coming out right.  You may add some salt, pepper or a certain spice if something seems off.  You would test the wine with the food to make sure it matched.  You wouldn’t do this in specific time intervals, but you would definitely make sure at many points along the way the meal was coming out the way you wanted it to come out.  You would never just test it once at the end!  That’s just common sense.  Most people have seen their mothers cook, and to me this is so obvious I just can’t believe others don’t see it automatically.

Then she finished with the killer…

And you say people pay you to teach this to them?  For 34 years I was paid to teach common sense to 5th graders and I enjoyed it tremendously, but I clearly missed my true calling if you make a living teaching common sense to intelligent adults!

To say I was blown away by this 70+ year old woman is an understatement.  She not only understood what I said, but put it in her own world view and decided it was just common sense!  As an aside, I became a Certified Scrum Master by taking a course given by Ken Schwaber, and on the cover of the handouts it says “Scrum – It’s Common Sense”

Maybe this isn’t a perfect example of an agile process, but after thinking about it, I’m pretty convinced it is better than what non-agile teams do today.  In fact, if non-agile teams would treat their project like they were creating a fancy dinner they would probably improve tremendously!

Now for the rest of the story…  I wouldn’t even have had the opportunity to speak with these fine people if I hadn’t been nice to someone on the plane.  A family was traveling on the flight and had been split across multiple areas of the plane.  In order to allow mother and daughter to sit together I agreed to move my seat by a few rows and go from a window to an aisle seat.  I often do this when I see a situation like the one described.  I just think it is what I would like done for me in a similar situation.  I thought my reward would just be to feel good about helping a family out.  Instead I got a much greater reward – I found out I know how to cook!    So next time you have the opportunity to help someone out, do it – you never know what your true reward will be!

Until next time I’ll be cooking up new ways to help in Making Agile a Reality™.  (OK, poor ending, but it’s the best I could do with a jetlagged brain!)

Related posts:

1. Agile Ponderings: Certification – useful or not? I’ve had to do a lot of thinking about certification recently. Why?...
2. New to agile? Work at a sustainable pace Question:  Which is better: a) Working nights and weekends to meet iteration...
3. New to agile? Get focused with a vision Bear with me on this blog entry.  It takes a bit of...

James Shore recently changed the entire focus of his company. This blog entry gives his reasons why. The blog post really struck a chord with me because I often use the phrase “To me mediocre is not acceptable.” Now I’ve found someone that agrees with me!  To me there is nothing worse than seeing a team not reaching their full potential because they are unable to see the problems they are causing themselves.  In fact, some teams even laugh about it when it is pointed out to them!  Grrr, don’t let that happen to you.  Read on for some things to watch out for.

There are many ways mediocrity can appear and seem harmless. If you are new to agile, here are a few that you need to be careful about.

• Daily stand-up meetings taking more than 15 minutes
• Team members being late to meetings
• “Just a little” testing not completed within the iteration
• Not inviting users, customers or stakeholders to iteration demos
• A retrospective where no action items for improvement are created
• Decreasing the committed scope of an iteration
• Team members not working on stories in priority order
• Boring daily stand-up, retrospective or planning meetings
• Defects regularly being found after an iteration is completed
• Iteration planning taking forever because the Product Owner is not ready
• Lack of release planning
• The big picture for the project is never made clear

There are many more things which could become commonplace and accepted.

DO NOT ALLOW IT TO HAPPEN!

Once you allow mediocrity (or worse!) to occur once, it suddenly becomes accepted behavior.  Do yourself and your team a favor and insist mediocrity is not acceptable!

Until next time I’ll be standing my ground on this issue while Making Agile a Reality™ for my clients.

Related posts:

1. New to agile? Tips for better daily stand-ups As an agile coach I have attended a lot of daily stand-up...
2. Agile antipattern: Extending an iteration I had a previous blog post about stopping an iteration and how...
3. Agile antipattern: Doing Agile! I spent the past week in Orlando, Florida  at the Agile Development...

Now that I have your attention, let me be VERY clear I don’t believe the title of this post.  However, many people do believe it, and that is troubling. 

Now that some of you are confused let’s back up a minute and explain the term PMP.  It stands for Project Management Professional.  It is a specific level of achievement obtained through the Project Management Institute (PMI).  The PMP level recognizes demonstrated knowledge and skill in leading and directing project teams and in delivering project results within the constraints of schedule, budget and resources based on the Project Management Body of Knowledge (PMBOK).  The PMP designation requires a significant amount of documented project management experience as well as demonstrating significant knowledge of the PMBOK through passing a rigorous test.  All of this is very good in theory, but there are some issues which may need to be addressed.

As I said in the first sentence, I don’t believe the title of this post as it is written.  Unfortunately, I can also see reasons why many people do have this particular belief.  The biggest reason being the way most PMPs look at the world of project management.  To them it is the traditional interpretation of the PMBOK or it isn’t worth doing.  I find this interesting because PMI has an official position which is the PMBOK is process independent.  It is simply good project management practices regardless of the underly process being used.  Yet traditional interpretations tend to conflict with agile interpretations of the same document.  I touched on some of this in an earlier blog post containing my feelings about agile and various bodies of knowledge.  At that time I was focusing on my observation that simply implementing a process based on a body of knowledge document was very likely to lead to a traditional waterfall process.  Now I want to take that thought a step further and say a traditional intepretation of the PMBOK while using an agile process is going to lead to conflict and eventually a project failure.  I know that’s a bold statement, but if you take a big picture view, a non-agile PM trying to help an agile team is definitely a square peg in a round hole.  Eventually something will break if the peg is going to get inserted at all.  Others agree with me.  Mike Cottmeyer has a presentation he does called Agile PMP: Teaching an Old Dog New Tricks.  Alex Hamer also has a blog post on this topic.

Fortunately, the PMBOK can be interpreted through something I’ll call “agile sunglasses.”  When you wear your agile sunglasses and look at the PMBOK you can see how the various practices may actually be useful in an agile world.  You may do them much differently than you would on a traditional project, but you can still do them.

I used to think it would be great if there was a translation between the PMBOK and agile.  I guess Michele Sliger and Stacia Broderick thought the same thing because their book, “The Software Project Managers Bridge to Agility” is exactly that!  It translates from PMBOK terms to agile terms and gives PMPs some direction on how to change from traditional PMs which are ineffective in an agile process to agile PMs with a lot of useful knowledge they can draw on to help their teams succeed.  This book is a must read for anyone stuck on traditional PM practices.  Anonymously drop a copy on your PMPs desk if you need to!  Click on the image of the book if you need to order it.  Go ahead, do it now, the rest of this post can wait.

In my experience the best agile project managers were also the best traditional waterfall project managers.  I believe the primary reason for this is they have found success by using some agile techniques without even knowing it.  This shows up when they are in a course and say things like “I already do that.”  When I press further I find out they have been very successful, and they are truly doing some agile things within their waterfall process.  At that point I can smile and know the team will be even more successful with the lighter weight agile process.

Now, back to the title of this post.  If it said “On an agile team never have a PMP who relies on a traditional interpretation of the PMBOK” I have to say I’d agree.  Unfortunately, the reality is many people fitting that description are in companies currently undergoing agile transformations, so what do you do?  I would start with some sort of coaching or mentoring.  Most people who have achieved the level of PMP are very knowledgeable and can adapt if given a chance and a path to follow.  In an organization undergoing agile transformation I like to schedule regular meeting time with all people fitting this profile.  This allows me to be sure they all share their experiences so they learn from each other and improve rapidly. At some point there is a moment when they spread their wings and fly again on their own.  Give them some time to allow it to occur.  However, don’t give them too much time.  There are some people in every role that won’t be able to transition to an agile process.  Project managers are no different in that regard from ornery developers that won’t change.

Until next time, get to work with your PMPs to help them adjust their habits and practices so that together you are working on Making Agile a Reality™ for your organization.  Let me know how it goes or if you have had experiences others can learn from.

Related posts:

1. Agile and various bodies of knowledge (PMBOK and BABOK) In case you aren’t aware, there are at least two international organizations...
2. Agile Ponderings: Certification – useful or not? I’ve had to do a lot of thinking about certification recently. Why?...
3. Agile for Business Analysts This past week I was fortunate enough to be a speaker at the...

Like many other agile consultants I am often asked how agile adoptions could fail.  This question has a myriad of answers.  A search on Google for agile failure leads to over 1,960,000 hits (fortunately agile success has 5,370,000 hits so we’re ok!).  But it is obvious this is still a big problem.  Executives are worried about a new process failing, especially when they don’t know a lot about it.  Over time I’ll blog about a lot more agile failure modes, but for this post I want to discuss one that is hidden from sight most of the time – the big white elephant in the corner of the room!

The big white elephant in the corner is a very playful creature.  We usually only have to deal with him once every release cycle and we ignore him the rest of the time.  He doesn’t come out and get in our way very often, but when he does get in the way things usually get pretty ugly.  What is the big white elephant?  Well, it really depends on your organization.  Think of him as the biggest issue you face which is not process related.  He may be a lack of testing capacity.  He may be a difficulty in moving code from one environment to another (such as from the dev environment to QA).  He may be a lack of bodies to create quality documentation.  Whatever he represents, he causes a big ruckus any time you get near so everyone stays away as much as possible.  Remember, he’s a nice elephant most of the time, just don’t get too close.

Unfortunately, in an agile process we disturb him a LOT more.  In fact, we are probably stirring him up every single iteration.  After all, each iteration we are supposed to produce potentially shippable/marketable software.  In effect every iteration is at least an internal release if not an external release of our product.  Our good friend Mr. Big White Elephant likes it when we release stuff – he gets to play with us!  At least it is play to him.  To us it is our worst nightmare.  Having our worst nightmare come around every iteration instead of just a couple of times per year (or less!) really causes us some heartache.

For many companies this results in an agile failure.  They blame the agile process, when they should blame their big white elephant.  When you start down an agile path, be sure you are ready to deal with your big white elephant(s).  If you repeatedly have the same problem ask the question “Is it an agile process failure, or is it our failure?”  Almost every time it will be your failure, not a process failure.

So what do you do when you find a big white elephant.  For starters, give it a nice sounding name.  OK, I’m only half-kidding on that part.  Once you identify the problem, use your retrospective time (you are doing retrospectives, right???) to determine some possible solutions and try one during the next iteration.  Continue to use retrospectives to improve based on the results of each iteration.  Most of the big white elephants have grown to gigantic proportions over many years.  They are not easy to eliminate.  It may take several iterations until you feel it has been eliminated, but keep vigilant watch for a return.  You never really kill these elephants.  They are just waiting for you to get lazy and forget about them.  They will wait until the worst possible moment, and then… BAM!  There they are again, and somehow while they were gone they grew to twice their previous size.

Remember to hunt elephants during every retrospective and you will exit the jungle in fine shape.  Until next time I’ll be busy helping my clients hunt elephants while Making Agile a Reality™.

Related posts:

1. Agile antipattern: Hiding unfortunate truths “Unfortunate truths” are things which are true – unfortunately!  I’ve heard the...
2. Agile antipattern: Moving work from one iteration to the next All agile teams start at something less than the completely proficient level. ...
3. Agile is like… golfing? Well, if agile could be like cooking and a fishing trip could be...

I recently read this blog post from Chris Sterling and while funny, it made me wonder about the similarities between fishing and agile development.  Since I am a decent fly fisherman (I had an earlier blog post about a trip to Montana), I was definitely intrigued.  After some pondering I believe the two have significant similarities.  Starting with the fact trying hard doesn’t always lead to success!  Let’s dig deeper and see if there are further parallels in this analogy.

 Reasons for Failure

Maybe I’m stretching things a little bit, but it seems like the analogy holds up pretty well.

The point I’m trying to make is we need to pay attention to the details.  It is well known in fishing circles that small things can make a big difference.  The same is true in agile.  It may not seem like we are doing anything wrong when we don’t have continuous integration or automated testing, but those things add up.  This causes large scale failures over time.

Next time you go fishing, think in an agile way.  Don’t get me wrong, if your idea of a good day of fishing is sitting on the bank with a beer and watching a bobber, there is nothing wrong with that, but if you are in a place where it is really challenging to catch fish, pay attention to the details and adapt to what you see.

Now I want to go fishing, but until I get that opportunity I’ll be continuing to help organizations transform by Making Agile a Reality™.

Related posts:

1. Fishing in Montana is agile! I know you think the title of this post is absolutely crazy,...
2. Testing to find defects is waste Have you ever heard someone say that testing to find defects is...
3. Agile is like… golfing? Well, if agile could be like cooking and a fishing trip could be...

I’d be rich if I had a nickel for every time I’ve heard this, or something very similar to it, in the past 30 years!  Alright, that’s taking it too far, but I think I could at least afford a really nice dinner out with my family on the amount I’d have received.  But that isn’t the point.  The point is anyone thinking this statement is a valid excuse for poor results is wrong on several fronts.

Before we go any further, if the title intrigued you, immediately click on the image to the left and purchase Mike Cohn’s bible about agile estimating and planning!  If you don’t own this book, then I now know why the title of this blog post made you look further! 

Now, back to the issue at hand and why it is wrong to think this way.  First of all, this type of statement is part of the reason a waterfall model doesn’t work.  In the waterfall model it is typically development leads or other managers giving the time estimates.  This isn’t a written rule for a waterfall approach, but it seems to be given how often I have seen it in my career.  Let’s think about it for a second and see why this is the wrong way to approach things.  Is the development lead rewarded when a lot of software gets completed?  If so, this incentive is at least subliminally causing them to cut time estimates to the bone.  Is the development lead more experienced than most members of the team?  If so (and I hope the answer is yes!), then he or she is likely to estimate for their rate of development, not the rate of development for an average team member.  Does the development lead have enough clarity to actually give a meaningful answer?  If yes, great, but in most cases the answer is no.  Again, this leads to an estimate which may be on the low side due to a lack of knowledge about specifics.  So just from a logic point of view, using a model where the development lead estimates time is bad.

Second, on agile teams some goals are to collaborate well, and be held accountable for results.  If this is true (and it is), then we are completely bypassing both of these.  We are not allowing the team to collaborate to come up with an estimate they can live with.  Further we are holding them accountable to a result when they were not given the opportunity to give input.  We are back to waterfall where someone says we need x by date y and I told with Joe and he said we could do it, so do it.  That isn’t agile, that’s lunacy!

Lastly, we have taken a single data point and assumed it is 100% accurate at the start.  Even in a waterfall project it is well known that accuracy of estimates at the beginning of a project vary widely.  Review the cone of uncertainty to learn more about how bad it can be.  Part of our goal in agile is to deal with the cone of uncertainty by iterating toward a result.  So to add insult to injury, we assumed the estimate was correct, and we didn’t check on it each iteration to deal with reality.  How not agile can you get?

Project managers are starting to recognize that estimating is different in agile.  This blog post from PM Toolbox is just one example.  There are many more things to consider when estimating.  For example, things sometimes get more difficult at the end of a project (or at least development slows down).  There is a reason the 80/20 rule is often cited!  There are lots of ways to estimate, and lots of ways to do it poorly.

The bottom line is the worst thing anyone can do is ask a development lead to estimate something and then hold an agile team accountable to the estimate.  Collaborate and use planning poker to create estimates and you will be a lot happier in the long run.  There is even planningpoker.com for teams that are distributed! 

Time for me to get ready for a trip to Boston where I’ll be starting down the path of  Making Agile a Reality™ for another client.

Related posts:

1. Agile antipattern: Insanity! (5 insanity antipatterns) It is sometimes said the definition of insanity is doing the same...
2. Agile antipattern: Code freezes during each iteration Over the past 18 months I’ve encountered a number of teams where...
3. Agile antipattern: Burndown “wall” Does your team have an iteration burndown chart (giving credit only for...

I was just working on some Powerpoint slides for our Agile Product Management Boot Camp coming up on March 9 and 10 and I realized I should post a blog entry about the point the slides are making.  Actually, I’m trying to make two points with the slides.  The first point is we tend to work in organizations where the phrase “everything is priority 1″ is common.  The second point is my personal distaste for using the phrase “prioritized product backlog.”  I’ll cover each of these points separately.I’ll start with the “everything is priority #1″ problem, since that is the title of this blog entry.  Let’s be very clear THIS CANNOT BE ALLOWED!!!  There are many blog posts on the web such as the ones here and here.  I like what the first of those links says about how to explain why everything can’t be priority 1 – we can’t build it all at once!  I usually approach this with product managers/product owners/stakeholders by asking them what they want if they can only get one thing.  They quickly say one thing is useless they need it all.  To which I reply, I know, but I want to make sure we have the most important item built first so we can learn from it and make changes to other items based on what we learn.  I’d like to rank all of the items 1 to whatever, with no ties, so we can always be working on the next most important item and be able to learn from it as well as all the other items which were more important.  This way we will make sure the most important items are in the release and meet expectations.

Which leads into my second point about the phrase “prioritized product backlog.”  If you simply say the words, nearly everyone in the software industry will say  they already do that.  Why are they saying this when a casual observer can tell it isn’t true?  It is because we have overloaded the word prioritization.  Most software people think having a list of 100 items which has the top 97 as priority 1, the next 3 as priority 2 and no priority 3 items is a prioritized backlog.  Sorry folks, but that is a useless list.  We really need a RANKED backlog, where the rankings go from 1-N and there are no ties.  Then we use the list by making sure we work on the next item in the ranking, not just work on some random thing which seems interesting.

We simply have to keep these two issues in mind when we are dealing with the product backlog or we will not be successful.

So, what do the two slides look like?  Here they are:

This is the first post in the “Agile Antipattern” category.  I anticipate having a few more over time.

Until next time, let me know what you think so together we can be working toward Making Agile a Reality™.

Related posts:

1. New to agile? 3 ways to cut scope (and live) The primary way I see teams release products faster is by reducing...
2. Agile antipattern: Sizing or estimating bug fixes Is the bug to the left a large bug or a small...
3. Agile antipattern: Waiting for all the requirements before starting Time for a short blog entry (I tend to be way too...

When I teach any agile course I start out with the principles of lean that Mary and Tom Poppendieck have written about in their books.  The very first of these principles is Eliminate Waste.

What does this really mean in practice?  Let’s start with a definition – waste is anything which does not add value.  We’ll leave the blog post about what value is for sometime in the future.  For now let’s focus on what some non-value adding activities could be.

High on my list are two things we often take for granted: a) email and b) meetings.  Let’s start with email.  How much of it do you get?  How much of it do you read?  How often do you read email?  Now on the other side – how much of it do you really need to be getting and reading?  Last year I had a blog post on how Outlook is causing problems with agile teams which may be worth reviewing.  It is astounding how much time we waste each day on email.  Take some of the tips in the Outlook blog post and see if your productivity improves.  Then remove yourself from some mailing lists that you never really pay attention to.  Finally, try to empty your Inbox by doing something with each message – delete it, delegate it, or do something with it (file it or answer it).  If you need a more serious intervention try this book:

Now, what about meetings.  I won’t say a lot here about them because we all know in the past 30 days we have probably been to one or more meetings that we shouldn’t have been required to attend.  Do yourself and your organization a favor – send out agendas for meetings you call.  Ask others to do the same.  This way people can make logical choices about attending each meeting.

What other wastes are there?  An astounding number.  Here are some of the big ones:

1. Partially done work – any work in progress is waste because it isn’t delivering value yet.  Try to minimize the amount of work you scrap.  Do this by concentrating on high priority items and getting them completed.  Remember, “just enough, just in time“, not “almost finished, but not quite!”
2. Extra features – 64% of features are rarely or never used (Standish Group study).  Look at each feature very carefully.  Cut out the lowest value half before you even start.
3. Complexity – I’ll have a lot more of this in a future blog posting, but suffice it to say that agile architecture and agile design are NOT oxymorons.  Keep in mind that you are always trying to do the simplest thing that solves the current problem.
4. Paperwork – need I write more?  It is 100% waste to create paper by reformatting things available digitally.  It is 100% waste to create a status report rather than having status be visible as a result of doing work (think about the taskboard and how it shows status).
5. Delays – are there any points in time when your process gets delayed?  A delay is always waste.  It is time which can never be recovered.  If your process has lots of periods where things are delayed, then those areas need to be closely examined.
6. Churn – task switching, project switching and other switches cause churn.  If you are working on more than one thing at a time you are losing efficiency and causing waste!  Organizations need to recognize that shared resources while sounding good end up losing a lot of productivity to churn.
7. Silos – when everyone has their own area of expertise the team will suffer.  It is nearly impossible to get “flow” through the process when there is a handoff among nearly everyone on the team.  We often have this in miniature when we do design then do coding then do testing, while still calling it agile.  I call that Wagile (pronounced waj-il) for Waterfallish Agile.  This will cause waste as people responsible for one part of the process wait on others to deliver something to them.  That’s before we even consider the wastes inherent in the waterfall process alone.
8. Lost knowledge – this is one many people miss.  Why do we do “Lessons Learned” meetings at the end of projects if we aren’t ever going to learn those lessons???  We need to make sure the things we learn are captured and easily accessible to others.  This is absolutely vital to improvement.

Some examples of areas of waste which can usually be eliminated:  meetings, emails, status reports, and approvals.  Areas of improvement include creating less architecture (just enough), less complex code (simplest solution that solves the problem, consider refactoring and pair programming), prioritization (work on highest priority item first, complete it, then move on), cross-functional teams (pair programming, shared code ownership, look for mentoring opportunities), and reducing churn (reduce the number of active projects, only work on one task at a time until it is either blocked or completed).  Other things to consider include coming up with at least one action during every retrospective which will help reduce waste, eliminating something entirely for an iteration followed by deciding which small parts need to return, and making a rule that email should not be used for communication unless the email is less than 2 lines in length.

I know a lot of these things are difficult to change, so let me tell you a story to make the importance clear.  As a trainer I have done many seminars and courses where one of the exercises is to create a value stream map of a process.  I specifically tell attendees to pick a process where time is critical to their organization.  Most end up picking something like a bug fix process.  Once the value stream map is created we then calculate process efficiency by dividing value added time by total time.  The average efficiency has been about 16%, although I’ve seen numbers lower than 1%!  The second half of the exercise includes redrawing the value stream map by making changes that could eliminate waste.  The efficiency usually goes up by a factor of 2-3X.  There are huge gains in productivity just waiting for us to take them. 

Do you have any good ways you’ve eliminated waste which aren’t mentioned here?  If so, be sure to leave a comment so that others can learn from you!

Make eliminating waste a mindset in your organization and you will be successful in Making Agile a Reality™.

Related posts:

1. New to agile? Remember how to say “No” No.  Only two letters.  Very simple word.  Yet for some reason, with...
2. Testing to find defects is waste Have you ever heard someone say that testing to find defects is...
3. New to agile? Remember one thing: Just enough, just in time If you lived through the past few decades you have undoubtedly heard...

In agile it is often counterproductive to use the title of “manager” for any role. Manager tends to imply command and control which is just not present in an agile environment. I often have teams struggle with this basic concept. Managers understand that they don’t get to manage the same way, but they struggle with how to think of themselves if they aren’t using the dreaded “manager” word. The problem is more one of terminology than anything else, so let’s explore a few possibilities I’ve either used or heard used by others:

1. “supporter” Instead of the word manager in a role, use the word supporter. For example, a Project Supporter, a Development Supporter, a QA Supporter, etc. I think this generally gives the right connotation. I like it because it forces people to think how to give support from their role rather than how to lead from their role.

2. “master” Ugh! Something that’s actually worse than manager! I put this one here because I’m not so sure I like the role Scrum Master. I like what the role is supposed to do, but the name of the role could use some help.

3. “mentor” I could live with this one. Project Mentor, Development Mentor, QA Mentor. Those all sound good to me. Unfortunately I’m not sure the people that think of themselves as managers always have the proper skill set to be mentors.

4. “shepherd” This one is interesting. It implies some leadership, but at the same time has undercurrents of someone that would let the team make their own decisions and solve their own problems. Project Shepherd, Development Shepherd and QA Shepherd. Not bad. Additionally it seems the people in these roles would shelter their teams from outside issues, which is also something I like.

5. “champion” Another interesting one. Project Champion, Development Champion, QA Champion. Definitely implies a bit about leadership. It also implies something deeper though – representation of that function. Much like a knight could be a champion for a princess in a joust, the Development Champion is the person that represents development in ways that go beyond just being a member of the team. Net Objectives has used the term Product Champion instead of Product Owner for quite a while, and I like that term as well.

This was all written in a bit of stream of consciousness mode based on some conversations I heard today. As a result I haven’t really given them a lot of thought yet. What do you think? Are there other words you think could be used? Do you have a favorite among the ones I listed? Be sure to let me know!

Related posts:

1. Agile antipattern: Changing the definition of done Ever see a burndown chart like the one to the left?  I’ve...
2. Are you agile – the Nokia test I’ve been helping lots of clients start new agile initiatives recently.  This...
3. New to agile? Work at a sustainable pace Question:  Which is better: a) Working nights and weekends to meet iteration...